News aggregator
PyBotWar
For the Open Source game design class we're going to try and make an online multiplayer version of the classic RoboCode game. We found a python port on google code http://code.google.com/p/pybotwar/ that we hope to put up on open shift. Robo Code is a game where you actually program a robot that fights other robots in an arena. The robots rely solely on the code you right as you cannot control them once the match starts. Our goals for the project are as follows:
Required:
Once our core goals are complete, we'll hopefully have time to focus on adding fun things like new weapons and body types. These would add value to the game play without requiring much time. If we get to this stage of development we should be able to produce several new options.
Required:
- Refactor the graphics stack to support a javascript client. Adding json communication between the server and client.
- Upgrade existing sprites and graphics assets
- Prevent users from calling dangerous python packages in their robots
- Facebook authentication
- Add new arenas beyond the basic square one
- Add additional weapon
- Add different sensors
- Communication protocol for teams of robots
- Ability to hack opposing robot's using communication protocol
- stack overflow, false commands, etc.
- RPG elements including leveling up and earning new weapons or stats
Once our core goals are complete, we'll hopefully have time to focus on adding fun things like new weapons and body types. These would add value to the game play without requiring much time. If we get to this stage of development we should be able to produce several new options.
My blog is moving…
I won’t be updating this blog anymore – please visit http://threebean.org/blog instead.
This wordpress site will be left in tact however, since there are a number of posts linked to from other sites.
Categories: Code
Hacking tw2 resource injection (in pyramid)
In #toscawidgets this morning, zykes- was asking about how to do the jquery removal hack I wrote about a month back but in Pyramid instead of TurboGears2. First I’ll summarize the problem, then show you our solution.
toscawidgets2 tw2.* provides lots of handy web ui widgets including a wrapper around jquery-ui, jqgrid, and lots of fancy data widgets. One of the problems it solves for you is de-duplicating resources. Say you’re including two fancy jquery-related widgets. Both of them require that jquery.js be included on the page. tw2 includes a piece of middleware that tracks all the resources required by the widgets being rendered on a given request, reduces that list to a set with no duplicates, orders it by dependency, and injects it into the <head> tag.
Usually this is fine, but in some cases you want an exception to the rule. Say, like in my previous post, you want to include jquery.js yourself manually and you’d rather not have tw2 stomping all over your javascript namespace. You could disable tw2 injection of all resources, but you want all the others included — just not jquery.
There is no automatic detection and filtration flag implemented in tw2 and it would be tough to do in the general case. tw2 can’t guarantee that it’s own jquery.js and your jquery.js are the same, or different, or included, or not included, or anything — it doesn’t even try.
To get tw2 to not do what you don’t want, you need to un-register tw2‘s jquery resource from the middleware yourself (on each request). Previously we came up with a working hack that does this in the context of a TurboGears2 app. Here’s the same concept applied to a Pyramid app using a Pyramid “tween”.
import tw2.core.core
import tw2.jquery
def remove_jq_factory(handler, registry):
""" Remove tw2 jquery_js from tw2's middleware registry.
In order to use this, you need to add the following to your
myapp/__init__.py file:
config.add_tween('myapp.tween.remove_jq_factory')
"""
def remove_jq_tween(request):
# Send the request on through to other tweens and to our app
response = handler(request)
# Before the response is modified by the tw2 middleware, let's remove
# jquery_js from its registry.
offending_links = [r.req().link for r in [
tw2.jquery.jquery_js,
]]
local = tw2.core.core.request_local()
local['resources'] = [
r for r in local.get('resources', list())
if r.link not in offending_links
]
return response
return remove_jq_tween
Categories: Code
AJAXING It up!
I learned about ajax this week in class. I knew about it in the past but I haven't had much experience implementing it. Seems like a really good way to send and receive data quickly.
The basics of AJAX is that you create a function that will serve json whenever it is called. This function is tied into a URL that can be called with optional parameters. Then you can have another program, be it a web client or desktop software send a request to this URL. The program then receives back json formatted information it can use.
I will be using AJAX to implement my final project for class. I'll be able to run the python pyBotWar program on a server with a modified AJAX function that sends out the state of the game. The client can then ping this function periodically to get information about robot position, angle, health, etc. and draw the state.
The basics of AJAX is that you create a function that will serve json whenever it is called. This function is tied into a URL that can be called with optional parameters. Then you can have another program, be it a web client or desktop software send a request to this URL. The program then receives back json formatted information it can use.
I will be using AJAX to implement my final project for class. I'll be able to run the python pyBotWar program on a server with a modified AJAX function that sends out the state of the game. The client can then ping this function periodically to get information about robot position, angle, health, etc. and draw the state.
Announcing — 24 hour tw2 bug sprint for PyCon
(First published to the toscawidgets-discuss google group)
It came up in IRC the other day that tw2 has been through many, many beta iterations. So many in fact, that a full on tw2 2.0 release is painfully overdue.
That said, there are still plenty of out-standing issues in our issue tracker:
http://bitbucket.org/paj/tw2core
Before we tag and name the 2.0 final product, I’m proposing — no, announcing — a 24 hour tw2 sprint the weekend before PyCon. We’ll write docs, we’ll automate tests, we’ll settle the dispatch dispute and wax philosophic.
I invite you to join me Saturday, March 3rd at 18:00:00 UTC through Sunday, March 4th 18:00:00 UTC. Hop into #toscawidgets on freenode or join me in a hangout on google plus. We’ll nail every last bug on deck and still have time for a beer.
Yours in widgetry-
- threebean
Categories: Code
TurboGears2 on OpenShift, just like it should be
After much work and many trials, I finally have an app pushed to OpenShift with no manual tweaking necessary. As often happens with these things, the solution was much simpler than expected.
Note: I still don't have a foolproof 'follow this' solution ready, as the one I built works exactly as I want it to, but:
- It needs a lot of love and cleanup
- It requires an external git script that isn't well documented
Back on topic, when we last left off this topic, I had finally gotten OpenShift to acknowledge a project in a directory other than tg2app. This is useful because, at least for me, most of my projects are not named tg2app. That turned out to be stupid problem I had made for myself, but unfortunately, the next problem to tackle was not.
You see, when setting up an app on OpenShift, you have very little control over the actual environment the app is running in (this isn't entirely true, but is a useful fiction, especially as the service is likely to become more 'plug-and-go'). One of the few ways you can retain control is through a series of post-commit hooks, one of which was starting off the problematic section of code. When you first push your code to OpenShift, it needs to set up your database so it is ready to store information and do other databasey things.
Naturally, this wasn't happening.
First up was a problem with OpenShift. Python's default egg cache (not too important, it's a place python can use to extract files from installed packages temporarily) is not writable in OpenShift, so that needs to be set before anything else will work. Next, the proper MySQL library is not installed by TurboGears by default (the default is to use sqlite), so that had to be added to the requires list.
And then I hit yet another wall. Despite everything being set up properly, I could not connect to the MySQL database on OpenShift. It wasn't a problem with MySQL, because I could connect fine with the MySQL client. It wasn't even a problem with SQLAlchemy, because I was able to connect from a short example script. Finally, in a fit of insanity, I tried running the build script directly. I'm not even sure why, I was just at the point I would do anything just to see if it would work.
And, strangely enough, it did.
This had some pretty profound implications. It meant something was different during the build hook than in normal execution. Armed with this new knowledge, I headed over to OpenShift's IRC channel to get some answers (I had actually been in there for some time prior, just not with enough information for themore ruby-oriented users to help).
They told me that yes, indeed there was a difference. During the build step, the database is stopped, hence why I could not connect to it. There were, however, hooks for deploy and post_deploy, during both of which the database would be running. I moved the calls needing database access to deploy, and suddenly everything worked! I made a few more changes, cleaned up my tree, and tested it on a new app I wanted to get on OpenShift, and it (mostly) worked. There were a few problems left, but they seemed to be mostly my fault (and problems with the application, not OpenShift), so it looked like I had finally fixed deploying a standard TurboGears app. I've no doubt that there's something I've left out, but I'm pretty amazed at the progress I've made so far, and learned a lot about both OpenShift and TurboGears.
Up In Lights: RIT STEM Hacakthon put on blast at Cooney Center Blog and Opensource.com!
This week for me has been all about outreach. I truly enjoy the role of storytelling, because I get to participate with the FOSS Community in a different way than committing patches to repos (not that I don't enjoy coding, I'm just not quite as good at expressing my thoughts in python as I am in HTML ;) In the land of FOSS, attribution is the coin of the realm. It is the oil between the gears and pistons. Giving credit where credit is due is the simplest default state of many open licenses and is required for fair use.
Drupal
I am well on the way to understanding how Drupal works and now I have an alumni Drupal ninja, Mark DeMayo, helping me out.
So far, I have set up most of the Drupal modules and administrative stuff on the back-end of the site. Remy has just informed me that I will be able to migrate my site soon to RIT's servers which might make administration easier (I hope).
RT @remy_d: #RIT #STEM Video Game Challenge Hackathon is TONIGHT at 6pm. If you'd like to join us http://t.co/p2HrAgwr #FOSS #fossrit
RT @remy_d: #RIT #STEM Video Game Challenge Hackathon is TONIGHT at 6pm. If you'd like to join us http://t.co/p2HrAgwr #FOSS #fossrit
Categories: Tweets
#RIT #STEM Video Game Challenge Hackathon is TONIGHT at 6pm. If you'd like to join us, send me an rsvp. http://t.co/32dmGP8g #FOSS #fossrit
#RIT #STEM Video Game Challenge Hackathon is TONIGHT at 6pm. If you'd like to join us, send me an rsvp. http://t.co/32dmGP8g #FOSS #fossrit
Categories: Tweets
Openshift Troubles Continued
I figured out the problem I was having with OpenShift.
To put it simply, I didn't pay enough attention.
For reference, when moving an existing TurboGears app to OpenShift, make sure you add the changes in config/app_cfg.py
As soon as I saw that, I felt really silly for missing it. I was so sure that I had gotten all the relevant changes, but apparently I somehow missed this file.
More detailed directions coming soon.
Hola Mundo Turbo Gears
Today in the open source game design class we boot strapped for Turbo Gears. This, combined with open shift will allow us to quickly get web apps online and running.
Open shift works by tying it to a Git repository on your computer. When you push the repo to open shift it automatically turns off the Turbo Gears instance running on the cloud, applies the changes you've pushed, and then restarts the server.
This is incredibly useful for small applications when you don't want to spend a lot of time trying to set up your own server. Updating the server is as simple as git commit && git push openshift.
We'll be using this system to launch our app for the final project.
Open shift works by tying it to a Git repository on your computer. When you push the repo to open shift it automatically turns off the Turbo Gears instance running on the cloud, applies the changes you've pushed, and then restarts the server.
This is incredibly useful for small applications when you don't want to spend a lot of time trying to set up your own server. Updating the server is as simple as git commit && git push openshift.
We'll be using this system to launch our app for the final project.
OpenShift Troubles
Recently I've been playing with OpenShift, a new(ish) service from Red Hat as a sort of 'push to cloud' deployment strategy. It's interesting for people like me who can whip up a site quick, but don't necessarily have the framework in place to host it.
Due to my work on CIVX, I've gotten pretty familiar with TurboGears, and the idea of being able to take a site like that and run it without having to set up apache or fiddle with paster sounded real nice. Unfortunately, it was not so simple as it seems.
First up was to get something, anything, running. For a while, OpenShift was throwing a 500 error when you tried to get a new application registered. A brief poke into their IRC told had them aware of the problem and it was fixed shortly. Next came the other part that should have been easy, running TurboGears.
Luke our favorite wizard around these parts, wrote a bit of code to get most of the available applications up and running without too much effort, including the currently unsupported TurboGears. Running this went off without a problem, but the resulting site gave me another happy 500 error. After a consult with Remy, we determined there were some missing version requirements that kept the site from running. After pulling those edits out of his repo and moving them upstream to Luke's, I had a working default TurboGears site.
Until I tried to log in. Then I got another 500 error.
I was beginning to get used to this, but it was still annoying to make a small change, then push it to the server and wait for the server to update the settings before I could test it. Even more fun was the occasional 503 error when OpenShift couldn't keep up with my rapidly building and tearing down sites.
Feeling that that was going to be a project by itself, I set about moving all my non-db-interfacing files to this new repository. The prebuilt version assumes that the site internally is named tg2app, and I was having trouble convincing it to go by anything else. Eventually I just decided to move files across one by one; first the templates that don't care what they're named, then the root controller, than the new model and widget. A lot of frustration, many 403 and 404 errors later, I had something that pretended to work as long as I didn't use the database. But since the database is kind of the point of the site I was building, this was not exactly acceptable.
So back to the drawing board then. I had a hunch something was wrong when I saw SQLAlchemy errors scroll by every time I reloaded the site. My best guess is that SQLAlchemy is failing to create the tables needed to run the site and continuing on blindly. Once I realized that, I dumped a test db from my local copy to the mysql db, and suddenly everything was working. Or almost everything, anyway.
I could read form the db fine, but any time I tried to modify it, I got another dreaded 500 error. I poked into everything I could find to try to figure out where it was failing, and finally determined it couldn't be on my end, as my local copy worked just as expected.
Finally I stumbled across the anwser, almost accidentally. When I moved the db from local sqlite to mysql, I failed to set the auto increment setting on the id of my new databases, so when I neglected to provide an id for the new entries I was making, mysql quite rightly complained at me. Unfortunately, since I can't find how to re-enable debug mode (nor should I really try), I wasn't getting any good error messages.
So what is the site that has been giving me all these troubles? It's a little site I set up to publicly shame Remy into stopping smoking: remysmoke-qalthos.rhcloud.com
Due to my work on CIVX, I've gotten pretty familiar with TurboGears, and the idea of being able to take a site like that and run it without having to set up apache or fiddle with paster sounded real nice. Unfortunately, it was not so simple as it seems.
First up was to get something, anything, running. For a while, OpenShift was throwing a 500 error when you tried to get a new application registered. A brief poke into their IRC told had them aware of the problem and it was fixed shortly. Next came the other part that should have been easy, running TurboGears.
Luke our favorite wizard around these parts, wrote a bit of code to get most of the available applications up and running without too much effort, including the currently unsupported TurboGears. Running this went off without a problem, but the resulting site gave me another happy 500 error. After a consult with Remy, we determined there were some missing version requirements that kept the site from running. After pulling those edits out of his repo and moving them upstream to Luke's, I had a working default TurboGears site.
Until I tried to log in. Then I got another 500 error.
I was beginning to get used to this, but it was still annoying to make a small change, then push it to the server and wait for the server to update the settings before I could test it. Even more fun was the occasional 503 error when OpenShift couldn't keep up with my rapidly building and tearing down sites.
Feeling that that was going to be a project by itself, I set about moving all my non-db-interfacing files to this new repository. The prebuilt version assumes that the site internally is named tg2app, and I was having trouble convincing it to go by anything else. Eventually I just decided to move files across one by one; first the templates that don't care what they're named, then the root controller, than the new model and widget. A lot of frustration, many 403 and 404 errors later, I had something that pretended to work as long as I didn't use the database. But since the database is kind of the point of the site I was building, this was not exactly acceptable.
So back to the drawing board then. I had a hunch something was wrong when I saw SQLAlchemy errors scroll by every time I reloaded the site. My best guess is that SQLAlchemy is failing to create the tables needed to run the site and continuing on blindly. Once I realized that, I dumped a test db from my local copy to the mysql db, and suddenly everything was working. Or almost everything, anyway.
I could read form the db fine, but any time I tried to modify it, I got another dreaded 500 error. I poked into everything I could find to try to figure out where it was failing, and finally determined it couldn't be on my end, as my local copy worked just as expected.
Finally I stumbled across the anwser, almost accidentally. When I moved the db from local sqlite to mysql, I failed to set the auto increment setting on the id of my new databases, so when I neglected to provide an id for the new entries I was making, mysql quite rightly complained at me. Unfortunately, since I can't find how to re-enable debug mode (nor should I really try), I wasn't getting any good error messages.
So what is the site that has been giving me all these troubles? It's a little site I set up to publicly shame Remy into stopping smoking: remysmoke-qalthos.rhcloud.com
MJPP Status
Well...as of right now, I seem to be having issues trying to get a picture to show up on the main page of the site as a blog entry. I have been using my Drupal instance for all testing purposes which you can find a link to in the last blog post. I have also been researching more about the 960.gs (grid system) which is a framework for CSS that allows properly structured Web pages based on a specified number of columns.
Achievement Unlocked: Create a Hello World Facebook App
I am happy to follow up my last open shift post with a much more delightful one: I successfully deployed a TurboGears2 quickstart, and added a very simple web page that will allow client-side oauth2.0 authentication. I'm about to be late for a sitdown at Kodak Park, so I won't be able to expound upon the (many) merits of openshift and how easy it was to get this running, so suffice it to say, here is a link to the app:
FLOSS Seminar Update
So it's week 5, what has been going on?
The class has split into three groups, working on different games. My group's idea is a social update to the venerable likes of robocode, though how exactly that is going to pan out is still debatable.
Ideally, this would comprise of a wrapper around the basic game, not requring much tweaking of the internals, though a new interface would be required for use on the web. All in all the class is shaping up to be pretty interesting.Flash vs Webkit
A nice piece from one of the IGM Grad Project classes of interest to both FOSS and Game folks
http://www.cardkingdomgame.com/2012/01/13/who-needs-flash/
http://www.cardkingdomgame.com/2012/01/13/who-needs-flash/
Made some progress with Open Video Chat. Tomorrow hopefully we can get it fully working on the current Sugar builds #fossrit #fudcon
Made some progress with Open Video Chat. Tomorrow hopefully we can get it fully working on the current Sugar builds #fossrit #fudcon
Categories: Tweets
Openshift Experimentation
After seven tries at getting the foss@rit site migrated to openshift, I must concede... for tonight.
- Vanilla openshift quickstarter for drupal
- First attempt was editing by hand, and I installed modules and themes after bumbling around in the new (to me) drupal 7 interface.
- installed the backup and migrate module, and tried to restore from a mysqldump from this site... and hosed it
- destroy the app, start fresh
- bumble around til I figured out how to enable phpmyadmin
- import the sql backup manually... and hose the site
