A couple of friends were talking about doing a small “game jam.” I’ve always wanted to do one. We decided to make a 2D platforming style of game and one weekend, sometime in the near future, we’ll all get together and jam for 24-48 hours and see what we can pump out by the end.
One issue came to light as we talked: what would we use as the sprite engine? I certainly don’t want to spend the entire game jam working on the sprite engine and come away at the end of the weekend with nothing to show for it. That’s a huge task to make the thing that runs the game and then the game itself on top. I wanted to use XNA and I’m sure there are tons of hobbyist programmers out there that have programmed their own full-fledged sprite authoring and rendering engines.
But I’m an engineer. I know I shouldn’t re-invent the wheel, and we could certainly shop around the Internet and find someone’s sprite engine to use, but I want to know how the wheel works, and I think there’s a mentality amongst the guys interested to do the game jam where we want to brew our own. Plus, there’s the added advantage of getting tech support within our little group. We don’t have to plow through someone else’s undocumented, bullshit, and badly written code. We can plow through our own.
I would certainly love to have the tech homegrown just so I can use it for my own purposes. So this weekend, I sat down and did my own little “code jam.” I wanted to code for 24 hours straight, but I got maybe 18 over the course of the two days — I’m writing this post at the tail end of this journey. Twelve hours on Saturday and another 6 today. What do I have to show for it?
A rudimentary and crude sprite engine.
Features:
- Basic sprite rendering using SpriteBatches in XNA
- Use of 2^n x 2^n sprites (in this case 64 x 64 pixel tiles)
- Ability to save/load tile set and sprite map XML data files.
- A sprite map editor using windows forms.
- Ability to add new tiles to the current map in the editor
- Ability to interactively put down new tiles into the sprite map
This won’t play a game. There’s no collision detection, no player character, no enemies, nothing. Not yet. Those are all things that need to be coded in another session. Some other nice to have features would be sprite layers so we could do backgrounds at different sprite sizes rather than a tiled sprite set. Animated sprites would be fun to do as well. All of the data is saved and loaded in XML and the document format is custom and would need to be extended as things get integrated in.
I’m not even sure if I want to use SpriteBatches for rendering, but I’ll go with it for now. I consider everything I did in the last 18 hours to be molded yet again into something even more robust.
I would say this weekend’s code session was a success. I’ll have to post about my previous weekend code jam which was focused on implementing and learning Perlin noise and using it in a height map. I’m rekindling my love of all things procedural. I do have ideas for this sprite engine in terms of procedural algorithms…mainly, I’d love to see if I could use an L-system to generate platforming levels. That would be fun. Imagine turning on a game and just having new levels made for you on the fly. An artist would still be needed to make the tiles and then they would work on generating the L-system grammar to work with their tileset, but levels would just come together on the fly. I’m sure that’s harder than what I said, but you know what they say, “easier said then done.”
