Memoirs of a Game Developer
Yesterday I stumbled upon my archives of old projects, and I felt a sudden breeze of nostalgy. Today I will take you along for a trip to my game developing past. My oldest games (or "gamelets", as they were never really finished) haven't survived. I remember a Mad Max -esque, text-based cab driving game and a space shooter similar to Star Control, but I don't even remember their names.
Arty (1999) is my oldest surviving game, if you can call it surviving. Arty was an Artillery Duel clone written for DOS with the Watcom compiler; anyone remember the joys of DOS4GW? The code was horrible, since I had just learned C++, having programmed in C before that. I couldn't get it to run (DOSBox might have helped, but I couldn't be bothered) and couldn't find any pictures, but here's a peek at the jumbled mess of code, from particle system code ("smoke.h"):
{
Smokes[SmokeIndex].XSpeed/=(1+Options.Friction/2000.0);
Smokes[SmokeIndex].X+=Smokes[SmokeIndex].XSpeed+
Wind/500.0+((rand()%21)-10)/20.0;
Smokes[SmokeIndex].Y-=Smokes[SmokeIndex].YSpeed*
(rand()%10)/10.0;
if(Smokes[SmokeIndex].X<0||
Smokes[SmokeIndex].X>=SCENE_XSIZE||
Smokes[SmokeIndex].Y<0)
DeleteSmoke(SmokeIndex);
if(TypeBuffer[(short)Smokes[SmokeIndex].Y]
[(short)Smokes[SmokeIndex].X][0]==TYPE_GUN)
GunDamage(TypeBuffer[(short)Smokes[SmokeIndex].Y]
[(short)Smokes[SmokeIndex].X][1],
Smokes[SmokeIndex].Damage);
Smokes[SmokeIndex].Life-=(1+abs(Wind)/100.0);
if(Smokes[SmokeIndex].Life<=0) DeleteSmoke(SmokeIndex);
}
Despite being a huge mess, the game actually had some very nice features. Aside from cool-looking explosions, fire and smoke generated using "smoke.h", it also had a fully flexible weapon system, where I could assign payload ("bombs") to artillery shells. Bombs in the payload could have triggers (eg. impact or "I'm above a gun"), and explode generating new bombs etc. There was also separate concussion and kinetic damage; kinetic damage was based on the velocity of the projectile. Two of my favorite weapons were napalm, which burned a huge area for a while, and nuke, which was based on a series of different bombs, with the only piece of custom code being a screen flash when it exploded. Arty of course had fully destructable, random terrain.
As a curious detail, I had already started creating a game engine called Solid (revealed by a file called "solid.h"), though at the time only used for Arty. As soon as I realized Solid is quite common a name for absolutely everything, I changed the name to Spineless. Spineless was released as open source at the beginning of 2003.
The project Spineless was really meant for was mproject (2000-2004), a doomed, long-time sci-fi game project by a group of friends (yea, I have a thing for sci-fi). The M in the name stands for Master of Orion, which basically explains what the game was about. Btw, what actually prompted me to write this journal entry was that I had forgotten how far we actually got with it. Frankly, it wasn't far at all, but I didn't remember us getting even that much done. Here are some screenshots of the prototype. It's actually much nicer looking in motion, since it's exceptionally smooth.
sbproject (2004) was kind of a spin-off of mproject, focusing only on combat, á la Homeworld. In some far-fetched plans, it was to be the tactical combat part of mproject, but this project never really got off the ground either. A single image remains:
After that, I haven't really worked on any games. I want to change that now, and it's one of the reasons I killed Spineless; I want to try and concentrate on actual game programming for a change, instead of trying to make a game engine usable by other developers. That might be a side product of my endeavors, but not a major goal.
If you are interested in more details, prototypes or source code for any of the projects, please drop a comment!
Trabalho um pouco
In between reading for my Portuguese exam, I've actually got a bit of work done on my projects.
The major changes are that I abandoned the Spineless Sourceforge project, and moved from Subversion to Bazaar for version control. The Bazaar repository is currently private, but as soon as Spineless is ready for public consumption, I will probably release it again on Launchpad. It might not be soon, or it might never come to be, but if and when it does, you will be the first to know. 
Bazaar seems really cool and much more appropriate for me than Subversion, both now and in the future. I'm not depending on a single server anymore, but I can still keep my repository centrally located on my webhost. If it ever disappears or is unavailable for a while (or I'm on the move with my laptop), I can continue working with the local repository as normal. The biggest problem at the moment is that Windows Explorer integration and the Eclipse plugin are still in alpha. I'll have to brave myself and try them some day.
I also worked a bit on the C parser. It's frankly a bit more complicated than I thought, but I'm already mostly done for my purposes. All that's left is actually generating the ctypes interface from the parsed data. I'll be in for a treat when I get to try and support the horribly convoluted FreeType headers, but that's a can of worms for the future. As long as I can keep the ctypes interface stable, it's not a problem to push working on a more complete parser back a while. When the parser is done, I can finally move on to reimplementing rendering with a shiny new architecture.
Distractions
I immersed myself in a couple of distractions from the relatively boring work on the C header parser. After the last post, I started thinking more about the task scheduler and how to implement it. Originally I was thinking of somehow integrating the main loop with it, but decided that was nonsense and instead created a new module called "reactor" for implementing different main loops. There's currently only one called GameReactor, but a dedicated server or a tool with a normal GUI interface will probably need different kinds of main loops, and thus reactors. I put the task scheduler I was talking about earlier on the back burner, waiting for the moment I'm actually going to need it, and threw away my old task scheduler after converting code using it to the new reactor interface.
I'm not going to write any new entries this weekend, but if there's interest, I might talk about implementation details next week, for the first time in this new blog. A single acknowledging comment will suffice, considering the (still?) relatively tiny reader base of the blog. Would you be interested in details on reactors, and/or semi-regular posts about implementation?
Here's a sneak peek (and a test of the code-highlighting plugin):
# Do the steps
step_time = self._step_time
step_size = self._step_size
steps = int(frame_time / step_size)
for i in range(steps):
step_time += step_size
logic_signal(step_time, step_size)
I also implemented a really simple HTML logger, or rather an HTML log handler for the Python logging module. I will probably extend it in the future to make the logs easier to read and maybe provide extra details with Javascript-powered hiding by default.
Tasks, tools and tribulations
Inspired by Entity Crisis, I'm finally taking the plunge and converting my task scheduler to use generator-powered cooperative multitasking instead of normal functions. It should make both the task scheduler implementation and future task writing much more elegant. I'm also thinking of extending it later with threadable, networked and Stackless-based tasks. More on this as I get it done.
Good-ish news on the parser front: Dave Kuhlman released a new version of generateDS, which now succesfully parses the Collada schema, but the generated parser still fails to parse more complex Collada files, specifically transformation elements such as translate. I hope it's "just" a bug and not a missing feature. If it is, I just might contribute the missing features myself if needed and it's not too complex. In any case, this is promising.
I also started writing the C header parser using Pyparsing. It's easy enough to work with, though I wish its documentation was more decent and its interface cleaner and more Pythonic. Anyway, from the humble start it looks like it won't be too difficult a project for the small subset of C grammar I need it to understand. I already got it to recognize some preprocessor directives, now I just need it to do something with them, and then it's on to actual C grammar.
And I'm still waiting for Trac 0.11 to be released, and hoping it will be easier to install than 0.10, which I never could get to work on shared webhosting.
More infovis
Again, all my programming effort has been spent on the visualization prototype for my university course. On the positive side, I have lots of ideas on how to go on when I have time to continue my hobby projects. Working on the prototype has been a bit of a pain, as programming user interfaces and visualizations is all about the details, and there are loads of details in every graphical application. We're quite tight on the schedule too, but thankfully the prototype doesn't have to be fully functioning, it just has to demonstrate the idea.
I have mixed feelings about working with C#. On the other hand, the GUI facilities of .Net are the best I've ever worked with, but on the other hand, I'm often missing Python when it would make a solution much more straightforward than C#. And why the heck does the size of container have to be either Count or Length, depending on the container? I know, I know, choosing IronPython could potentially combine the benefits of both, but I don't really have time to find out if that's the case.
Anyway, here's a picture of the prototype, now showing article topics. They're generated from article keywords by a simple and crappy clustering algorithm because I didn't have time to implement a better one, and laid out crudely, but that's a start. The square icons are articles, and their colors match topic colors. Additionally, article icons should appear inside topic areas, but they don't yet. I really hope I have the time to improve topic display by the end of the project.
Information visualization
First, an update on the last post: I sent mail to the developer of generateDS, and he has located the problem and is looking into it. That was quick, nice. As for parsing C, I took a look at a couple of tools, including GCC-XML, but I couldn't find anything I could readily use. So I'm still counting on Pyparsing or PLY to do the job. I realized Pyglet is using PLY, maybe I'll look into that for insight.
The last few days I've been spending my programming effort on a university project. I'm on a course called "Information visualization project work", where we're supposed to design and implement a prototype of an information visualization (infovis) application. I already took the infovis introduction course and the topic seems quite interesting, especially since it's related to user interfaces which I'm very interested in. Infovis is visualization of abstract data, as opposed to scientific visualization, which is about visualizing concrete data such as air flow over a wing, or the structural integrity of a bridge. Common applications include maps (although the underlying map might visualize concrete landscape, it's almost always overlaid with abstract data such as routes) stock rates and weather charts.
We had three topics to choose from, and our group chose visualization of research article citations. Since there don't seem to be any suitable visualization libraries for Python, and I don't really like the GUI libraries for Python either, and I hate Java, and I don't know Flash, we chose to do the prototype in C#. It's much nicer to work with than Java, and I'm at least somewhat familiar with both the language and the .NET API. Granted, I could have tried to use IronPython, but I have no experience at all in it, so I decided not to take the risk of trying to learn it for this short project. We're using a visualization library called Piccolo, which at least initially seems quite nice. It's almost trivial to set up too, though the API and especially documentation is a bit confusing. Unfortunately the free version isn't really maintained or updated anymore. It would be nice if someone did something similar for Python... or maybe a library like that exists, but I just couldn't find one.
Parsing, oh my…
Recently I have been thinking about parsing. There are two areas of Spineless (yes, I'm continuing to develop the engine, but only for my game project, not for the public for now) that need some kind of parsing to implement cleanly: C library support and COLLADA loading.
To use C libraries from Python, I'm going to parse their headers to generate a ctypes interface which can then be used from Python without any compiling required. There are existing solutions, such as the ctypes code generator, but nothing that could be called a released product. So I'm going to see how difficult it would be to do myself. Parsing is a huge topic however, as demonstarted, for example, by this old newsgroup topic: http://www.thescripts.com/forum/thread41389.html. The two tools I'm initially considering are Pyparsing, which might be too simple (ie. tedious to do complex stuff with) for my purposes, and PLY, which might be far too complex (ie. hard to learn) for this relatively simple task. Experience on either of the tools or other suggestions are really welcome, I'll be sure to post mine when I have learned more!
COLLADA, as you may know, is an XML-based 3D asset file format. Unfortunately the official API, COLLADA DOM, is a C++ library, and using C++ libraries from Python is a can of worms I'm not willing to open if I can avoid it. Until now, I have been writing code to read COLLADA files by hand, but it's really quickly getting really messy. Instead I'm going to generate a Python interface / COLLADA parser based on the XML Schema describing the file format. There's an excellent-looking tool for it too, called generateDS, but unfortunately it fails when trying to read the COLLADA XML Schema, hanging forever. I sent an e-mail to the author, and I hope he can fix the problem. Failing that, it seems I'm on my own, as there don't seem to be any Python libraries to help with parsing XML Schema. All I can find are tools for validating documents based on a schema, but that's not what I'm trying to do... Again, suggestions are welcome!
On problem solving
It's funny how thinking about problems - and solutions - changes with time. You can get so used to your own ways of doing things that you stop looking for better ways, or worse - ignore better ways when they're staring (and screaming) right at you. I find it's really refreshing to (be forced to) take long breaks from your projects and do something else for a while. It really helps you see your solutions and their flaws from a fresh perspective.
When I started rewriting Spineless some months ago, I thought I'd recycle most of it while rewriting just the parts that were bugging me. Now that work has progressed, barely anything has survived without major changes. The three parts that are still more or less recycled from the old implementation are resource, font and scene management. I didn't find anything really wrong with resource handling; I don't know yet what to do with fonts; and today I got some radical ideas on how to implement scene management instead of my old way of doing it. But more on that when I get something done.
Welcome
So, this is my new home on the Internet. The home of my game development activities anyway; the future is always unclear. Some of you may remember me from my old development journal on GameDev.net (I will follow in the wake of HopeDagger and continue linking from there to here for now). Others might remember me as the author of Spineless game engine, which is temporarily dead, or maybe just avoiding publicity for now.
Currently my time and energy are mostly consumed by studies, capoeira and Real Life, leaving precious little for game development, but it seems with the arriving winter my programming motivation is coming back too. We'll see how long that will last. In the mean time, I might also write about my studies, at least as much as they relate to my hobby programming. We'll see, we'll see...
The blog, especially its theme and style, is far from finished (I'm still using the default style), so expect that to change in the near future. I would especially like to get a logo for the page, but I would need a good and free picture of the human brain for that.
Again, welcome! Comments are welcome too, as always.
About Me
1 month ago from Twitter for iPhone
2 months ago from Digsby
2 months ago from Digsby
Recent Comments
- Benoit Jacob on Help needed
- Jussi Lepistö on Help needed
- Benoit Jacob on Help needed
- Jussi Lepistö on PyEigen 0.2 feature complete
- Benoit Jacob on PyEigen 0.2 feature complete
Cool Python modules
Favourite Blogs
- 2D Boy
- D Baumgart
- Data Realms
- Dwarf Fortress
- Entity Crisis
- Flash of Steel
- Introversion Software
- Kloonigames
- Stephen Whitmore
- Wolfire
- Ysaneya
Archives
- May 2010 (2)
- March 2010 (6)
- November 2009 (1)
- April 2009 (1)
- March 2009 (3)
- February 2009 (2)
- January 2009 (2)
- December 2008 (3)
- October 2008 (1)
- September 2008 (1)
- August 2008 (1)
- July 2008 (4)
- June 2008 (11)
- May 2008 (3)
- April 2008 (2)
- March 2008 (1)
- February 2008 (10)
- January 2008 (4)
- December 2007 (8)
- November 2007 (9)