After a couple of hours of thinking and drinking, I’ve finally hit upon an idea that I think is feasible and interesting for the Ludum Dare theme “Evolution.”

I’m a mild ochlophobe, which means I have difficulty with large, densely populated crowds. As such, reading the research paper Crowd Disasters as Systemic Failures: Analysis of the Love Parade Disaster was terrifying and it has remained lodged in my mind ever since.

All of this is a long winded way of saying I’ve had crowds on my mind lately. So when Evolution was announced, a thousand ideas came and went (“Lemmings + Genetic Algorithms!”, “Temple of Doom and Speciation!”) until I settled on something interesting, but also simple enough I stand a chance of implementing it in a weekend: selecting paths through a city for rioters such that they pick up new and diverse elements from the city while avoiding cops and opposing elements.

Still vague and high level, but the idea will be to trace a path through the lines of a Voronoi diagram (which should theoretically resemble the winding streets of an old European city)so that a cloud of dots can traverse it and “absorb” some of the elements of the Voronoi polygons it walks adjacent to.

I had a marvelously fun time at my first Ludum Dare. To say I fell short of my goal is the kind of breathtaking understatement not seen since the Bush era. But I WILL BE DAMNED IF THAT WILL KEEP ME FROM SUBMITTING THIS AND CALLING MYSELF A WINNER!

PARTICIPATION!

Rather than a blow-by-blow recounting of the events of the past 48 hours (see the end for that), I’m just going to have some general thoughts.

TOP MISTAKES I DIDN’T INTEND TO MAKE (as there were many I intentionally made like learning my tools during the competition)

• Not coming up with an abstraction for game states early on. This basically prevented me from adding any kind of explanatory text / game over screen towards the end of the project.
• Waiting too long for fun. I often had the joy of “Oh, I made this happen!” during development, but I didn’t actually have fun playing the game until nearly the end.
• Using no one particular abstraction for time. Some portions of the game are tuned to the system clock, some to physics cycles, and a couple to FPS. As such, I basically can’t guarantee the game will play the same on any other computer or do things like slow the game down for testing (it plays pretty damn fast)

TOP SUCCESSES I DIDN’T INTEND TO HAVE

• Using minimalist abstract art for placeholders. Sure the game looks like an angry gun battle between Pez dispensers, but I find that rather charming and don’t regret it one bit.
• Incorporating a physics engine. At first I thought I could hack together the physics I needed and was just using Chipmunk for fun, but I discovered unexpected joys from this. (I LOVE the way enemies get toppled by bullets)

Other miscellaneous insights.

GAME DEVELOPMENT IN RUBY IS REALLY, REALLY FUN

Ruby allows me to go incredibly fast (by my standards anyway, shut up thanks) and change the hell out of my code with very few impediments. The fact that it is mostly geared to OO lends itself extremely well to the problem domain. Definitely far more pleasurable than my old games from 6-7 years ago written in Java and C++.

I WANT TO WRITE SOME DOCS FOR INTEGRATING GOSU AND CHIPMUNK

I really enjoyed working with Gosu and Chipmunk in Ruby and want to contribute back to both projects. I lost a ton of time to bugs in integrating the two and trying to understand the concepts behind them (lost a great deal of time stumbling towards CP::Shape#rehash_static_shapes alone). While there’s great reference documentation for both projects and incredibly responsive maintainers, there’s precious little in the way of quick-start / conceptual overview.

I’M MORE INTERESTED IN ALTERNATIVE FRAMEWORKS

While I really like Gosu and Chipmunk, it feels as if they’re a bit of a dead-end for the kinds of projects I’m interested in. Gosu in particular is an awkward fit for pixel-perfect drawing and the resulting blur in my project still bugs me. Not to mention that packaging my project would have been a pain. In particular, I want to give EaselJS and Play4N a look, as well as perhaps just using my own pixel drawing with something like LWJGL.

Thanks to the organizers for making this happen, and I look forward to the next time!

Rather than worry too much about making something a “game” under any definition, I spent most of today hacking around on whatever interested me. Primarily this has been map support, allowing me to take this:

… and turn that into this:

Tiling of the surface turns out to be a major problem for movement, though. Between each square tile is an invisible seam that will still trip up your movement. Solving this would be conceptually-simple - simply join these blocks together and output them as large rectangles rather than squares. However, that sounds like an opportunity to introduce more bugs and problems, so I’ll let this sleeping dragon lie.

Really, I’m just about done with the “game” parts. I want to add in the concept of player death and give the motionless agents the ability to shoot bullets every so often, but both of these should be easy enough. After that, I only want to do some cleanup (sound effects, music if I’m so inclined, and an intro screen on game launch.)

Tianmen Shan (Heaven’s Gate Mountain). Hunan Province, China.

Someday, I will see this personally.

With my jumping bug put to rest, on to shooting things! With this, I got my first amusing bug (aside from that brief time I had people jumping off the screen)

Shoot to the right, all is well. Shoot to the left, though, and you hit yourself before quickly launching yourself off the screen.

Suicidal tendencies aside, this has revealed a few issues in my program. I almost certainly have some disconnects between the box models of my physics model of the world, and the display thereof. That bullet shouldn’t be so high on the player model (people don’t generally fire guns by holding them at face-level, as far as I know)

One of the fun parts of using decoupled libraries for display vs physics.