Had a very interesting conversation this morning with a volunteer out in the field (which is to say, in a developing nation) about the opinion being observed that Intel's Classmate is just as much a part of the OLPC project as the XO. There's a perception among those observers that the joining of the board ...
My OLPC priorities at the moment:
* get Productive finished
* use what we've learned from Productive to fix OLPCGames
* get Develop development restarted, produce at least a simple, straight forward IDE similar to SciTE built, tested and delivered
* find people to work on porting to EEE and Classmate
* find people to ...!-->!-->!-->!-->!-->!-->
Got the rendering test code refactored into a set of widgets and then moved those widgets to the UI screen where they are supposed to live. Got all that done and then realised that the demo simulation doesn't work under the olpcgames wrapper because the pygame timer doesn't fire into the wrapped olpcgame queue. Sigh. ...
Productive now has an official, public source archive. The spike test for graphics and simulation is available in spikes/spike_render.py for those who want to start playing.
I've been playing with some scaling tests... will need to do some work there to make larger maps usable, both for the UI (for moving units long distances) ...!-->!-->
Just dropped in Miguel's updated graphics for the starving and dead states for the characters. Poor little characters now "suffer" (deflate) and die (turn to bones) if you don't take care of them properly.
You want to create a battle-hardened army and take over the world? You better have the productive capacity to feed all ...!-->!-->
Got the game-state pack/restore code working. That should let us build a situation-editing tool so that teachers can build situations for students to solve. It's also useful for being able to walk away from a game and pick it up, of course.
Added a quick-and-dirty overview map implementation to the spike test. Need to get ...!-->!-->
Tried a bit of a spike test today. The idea is to try to make it easier to port an X11 application to the XO by using an overlay FS to capture what an installation does and then annotating the results with information to let Sugar launch the overlay.
Basic pattern is as follows:
Working on some refactoring today around the saving/restoring/initialising code for Productive. I'm trying to keep the "Map" class fairly generic, so that teachers and students can write more interesting map types later on. Part of that is deciding which parts of the setup are configurable in the map.
If we make every little setting configurable ...!-->!-->
Been working on the simulation code for Productive. Interesting thing is, even without the movement rules (all movements are instant right now) the game play almost works. That is, you can take over someone else's unit, you can build the cities, have to manage your resources, etceteras.
Doing something wrong with the scrolling code in ...!-->!-->
At some point we should see if we can convince the Python DBUS peoples to expose a method which lets one write a mainloop in Python. That would let Pygame scripts use the DBUS (and thus Telepathy) module natively, rather than having to integrate multiple mainloops in every application.
Yes, yes, I know threading works, ...!-->!-->
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007