Laying eggs
I've been lost on another side path for the past few days (and being lazy on purpose as part of my Christmas holiday 
), but hopefully this is the last one on my main path of producing something I can actually show you, my valued readers! ...and something I can play with myself. Oh, I haven't told about my main path? My roadmap for the near future is:
- Implement resource loaders
- Get the renderer plugin working again
- Start writing scene management
- Start writing Red Nebula
To explain the first step, I probably have to explain plugins in Spineless (as it's still called, new name is pending; also see end of this post). Plugins are used to implement low-level parts of the engine which depend on an underlying library. At the moment these include the window manager (Pygame plugin implemented) and renderer (OpenGL plugin). Audio mixer, networking and physics are other examples. As such, there can only be one plugin per group loaded at a time.
Resource loading used to be based on similar plugins too. There would be eg. Pygame and PIL plugins for images. The problem was that this was mixing resource representation with loading. As such, you couldn't for example load models using both the Collada and OBJ plugins. I'm going to add a second type of plugin now, the resource loader. There can be many of these loaded at once, and any loader can be used to load resources. For some resource types, there can also be toolkit plugins, which you can only load one at a time.
And finally, about the side path. Over the course of this new engine revision, I implemented at least three different ways of loading plugins, none of which I was really happy with. This was before I had learned that setuptools can be used to discover and load plugins! After throwing some code away and writing literally a few lines of setuptools-using code, I had far more elegant plugin loading implemented. Welcome, setuptools!
I've also been thinking about a new name for the engine. It's not critical, but it's something I want changed. Unfortunately, coming up with good names is extremely difficult. I have a couple of options:
- Some derivative of Sampo, since it's from Finnish and magical
- Something related to the (code) name of my game: Red Nebula. Unfortunately the obvious choice Nebula is already taken at least a couple of times.
- Something else:
Suggestions are welcome. 
Design phase
First, thanks for the encouraging comments. Even a comment or two will help me keep motivated about the projects, especially since there isn't anything concrete done yet.
Lately I've been spending some time on thinking about design, of both the engine and the game. Specifically:
New name. Now that I pulled the plug on Spineless as a public open source project, it's the perfect time for a name change. Spineless was meant to be an ironic name, but I got a lot of questions on why I chose the name, and probably lots of negative associations. Although the engine won't be public again for a while if ever, I want to make the change now.
Engine layout. Also connected with the "death" of Spineless, I'm going to restructure the engine again based on my experiences with the rewrite. It's more or less just moving things around, not really rewriting anything. I want to get the layout and especially plugin implementation right from the beginning to save major headaches down the road.
Red Nebula roadmap. I now have a rough idea on what to work on first, and what's important for the overall goal of the game. I want to get something pretty (well, at least screenshot-worthy) and interactive together as soon as possible. Unfortunately I can't get started on that yet since the renderer isn't ready, but I've been doing some research and design so I can get started as soon as the engine is sufficiently done.
Teasers! Red Nebula will be 3D, it's going to be a long project with no clearly defined "finished" state, and I'm going to develop it incrementally, with ever-increasing scope and detail. As long as I'm interested and have faith on it being fun, that is.
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.
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)