Stimergy

Stimergy is a game that I have made with Heather Kelley of Kokoromi for the Bivouac Urbain gamejam/competition last weekend in Québec city. Our team name was EMERGENCY HAMMER… don’t ask?

The point of the jam was to make a game in 3 days – 36 hours. And so we did.

splash stimergy final

Download

stimergy_final.zip (2.1 Mb – Binaries)
stimergy_src.zip (471 Kb – Source Only, get DLLs for TV3D, SlimDX and IrrKlang from the Binaries)

I thought it was so cool that Petri used Chronolapse to film the making of his game Post I.T. Shooter, so I used the same thing for Stimergy :


Details

Heather did most of the game design, defined the graphics style and did the sound effects. I did the programming and some game design.

The game was made from scratch in C# 3.0 using the Truevision3D engine with no prior design, graphics or sound work. All the graphics in the game are procedural, and the gameplay itself is based on AI rules, basically a cellular automaton plus the notion of “stigmergy” from the insect world. (We dropped the G in the game title.)

I used a more recent version of my components system, which now has a sound interface via IrrKlang. It’s the same system I used for Super HYPERCUBE and Trouble in Euclidea, growing quite fond of it.

Goals

  • Guide the ants using suggestive pheromone trails towards or away from the picnic blanket, or killer antlions.

There are 4 levels. Each level has different goals, which are explained when it begins. Some have time limits. If you fail the objective, the level will restart until you get it.

Controls

Mouse Left Button : Attraction Pheromone
Mouse Right Button : Repulsion Pheromone

Escape key to restart the game from Level 1.

Requirements

This game uses the .NET Framework 3.5, installing it is mandatory. I suggest you install the SP1 version just in case.
You will also need a bunch of DirectX DLLs that are provided by the DirectX Web Setup.

Because of the fancy blur effect, the game requires a Shader Model 2.0 compatible graphics card. This type of card is fairly commonplace now.


Post Mortem

This was my first real rapid game prototyping experience. The shortest project span I had seen for a game before was about 15 days… so this was something else. Here’s a couple of random thoughts about that :

  • I need a proper system for timers and interpolators, similar to what Nick Gravelyn posted, or maybe just steal that. It’s really annoying to have a dozen TimeSpan variables to keep track of what changes over time and how long the transition lasts.
  • I need to learn other languages than C#, and other frameworks than TV3D/XNA. I’m making big efforts in my “engines” to cut down the redundant code, but even then I feel like I’m programming much more than is needed to describe the game mechanics.
  • A big part of what makes a game actually fun, is how much direct feedback you get from interacting in the gameworld, and how much you feel like you can control these interactions. Stimergy is a pretty slow game, almost an RTS (funny, because I hate this genre), and I’ve seen other competitors value the responsiveness of player input more than the complexity of game systems, and it ended up being a lot more fun. Maybe it just fit the “jam” context better, too.
  • I need a system for game screens. Something that puts game components in a context, that gives them lifetime. I tend to make all the major components global and automatically-loaded, which is the easiest way, but it makes game state management pretty hard. And it’s dangerous for memory usage. There’s actually a good XNA example that I just need to look at in detail.
  • If I’m going to do more 2D games in TV3D, I need to build something that will load GIF animations and non-power-of-two textures. Material management for stuff that changes color or opacity was kind of a mess too. I may need to wrap it in something more concise. Switching engine would probably be the more logical choice.
  • I spent silly amounts of time on tweaking graphical things that I ended up not using. This time would have been better spent balancing the difficulty level or adding more gameplay elements. I’m used to making demos look pretty,… I have to remind myself that I’m making a game here.

I may sound like I’m complaining about everything, but I’m actually really happy about how the game turned out. It’s fairly fun/challenging and it looks pretty good. I’m still wondering whether I’ll release the code because it’s kind of a mess. I suppose I will if I get a request. The source is available up in the Download section!

6 thoughts on “Stimergy”

  1. fascinating post mortem! I never realized other people were running into the same programming issues I’ve had.

    I’ve just gotten around in the past few months to adding exactly those things you speak of to my engine. It’s in Python, so managing state and actually deleting things is really a chore because of the reference-counting garbage collection. Both my state-changing code and my interpolation / timer code could use some polish, and should probably be much more fundamental parts of the engine instead of the tacked-on tools they are now.

    I have to agree that interpolation / timers should be bread and butter tools for a game programmer, along with events (sometimes called the ‘observer’ or ‘subscriber’ pattern). Usually, when a game event occurs many parts of the system need to react (when a bullet hits, an explosion graphic must be spawned, a sound has to be played, the bullet needs to be destroyed) so it’s helpful to make each subsystem (rendering, audio, model) an observer of this event so they can all decide what to do, rather than have the event itself contain all the code and get into icky encapsulation issues.

    As for frameworks, I suggest you try Python + Pyglet. Pyglet is an awesome library, it’s one of those that keeps out of your way and makes its functionality seem very predictable and flexible. Python really has the issues I mention above (crappy garbage collection) and the fact that it’s fairly slow.

    I’m getting tired of Python + Pyglet myself. I have half a mind to try to use Clojure and Slick. A game in a Lisp dialect? Pure madness!

  2. doh, meant to say, “Python really only has the issues I mention above … but otherwise it is very easy to use, powerful (tons of library support), and fun to program in.”

  3. Thanks!

    @kenny : I’ve given python (with pygame) a shot not long ago, I might come back to it for a small project. Pyglet looks good. Lisp… not in a hundred years. :D

    I find myself always wondering how much functionality should be handled by the event producer or the consumer… It’s hard to control the execution order when working only with consumers, and it’s hard to stay completely order-independant.
    As with most things, it’s probably a question of balance, and how much you want to spend effort designing an idealistic system and sticking to it, versus making things work quickly by sticking to what you know will work.

    One thing I really love about recent versions of C# is how delegates and events are transparent in the language. Having the robust type system of C# and stuff like lambdas, that you usually see in dynamic/functional programming, is a big plus for me.

Leave a Reply

Your email address will not be published. Required fields are marked *