Well, a whole week is definitely more of an absence from updating than I would have liked, but such is the reality of doing coding in your spare time. More writing = less coding. Still, I’ve got time tonight for a pretty good status report.

To the right is a screenshot of the development code as it stands now. I’ve created a few objects to populate the room, and the lights are able to be turned on and off with a mouse click. I had a bit of fun generating the light texture, as I didn’t have one yet. even though the game itself is coded in C++, I find Java extremely useful for simple data manipulations like the generation of procedural textures such as this one. All told, it only took about 30 lines of code, including braces, to generate, and I think it turned out much better than I was expecting, with additive blending it almost looks like a bloom effect (I’m not using any shaders at the moment). The other textures are all done in GIMP, because I’m too resourceful cheap to buy a real imaging program.

Everything clips along quite happily at 60 frames a second on my laptop, with less than 1% processor usage. I’m curious to see how much that goes up once I get some roaches roaming around.

I’ve realized as I’ve been working just how important having a good, solid framework is when doing something like this. I’ve seen a lot of advice flying around the ‘net about not worrying about how game code looks, or if it’s elegant or not, since in the end so long as it runs on our target platform/hardware configuration at a reasonable speed and doesn’t lock up, nobody cares how it’s written. I think that’s true in the general sense, but in the case of the programmer(s), it’s extremely important that your low-level “building blocks” be good enough that you can plug them together and rip them back apart with fairly little difficulty. Sweating the small stuff is definitely the way to go with game coding; taking a few extra hours to really make your game components easy to integrate with each other will save many more hours later on. There is nothing worse than wanting to make a conceptually simple change, but finding that there are so many interdependencies between your hastily designed objects that it becomes an incredibly herculean task.

When I was thinking about how exactly I wanted to launch this website, I realized pretty quickly that I would need a hook, something interesting to keep people coming back at first. Ladies and Gentleman, this is that shameless, shameless hook.

I’ve had the happy fortune of discovering both Jonathan Coultan’s “Thing-a-week” as well as the Experimental Games Project almost simultaneously. And I realized something as I was browsing through their work: that rapidly developed work is generally more interesting, both for the artist as well as the viewer, than long-term projects. From the artist’s point of view, there is a very rapid sense of satisfaction that comes from putting things together quickly, as well as the ability to “cheat” a little bit, and not get bogged down in doing things “correctly”. Also, I have found, at least from my own experiences, that doing a lot of small things quickly, as opposed to much longer things over time, forces you to be more creative, to come up with ever more outrageous and ridiculous concepts to put into action. Quantity is not as important as quality, but if the correct effort is put into your creative process, quantity very often leads to a greater quality, in much the same way as running every day will make you physically stronger.

For the viewer, there is a reason to keep coming back, to watch the incremental process of creation and feel that somehow, in some way, you are helping with that creation, through feedback. And feedback that is more likely to be taken into account. Long projects, like a train, have trouble changing direction once they develop too much momentum. Also, the artist will have a greater emotional investment in the project, making him less likely to concede changes. Short, “disposable” projects possess neither of these faults, which is why I have decided to put my current long-term project on hold in favor of a short detour into the land of rapid game development.

I don’t plan on making it quite as rapid as Coulton or Gabler’s work, however. One week timeframes are certainly possible, and I relish the thought of being able to work at that speed, but the truth of the matter is that my current station in life provides me with very little time for much of anything outside of my various responsibilities. So while a weekly basis is out, monthly is definitely possible. And so that is what I am going with. With updates on progress every few days, with any luck I can keep things interesting up until the not-so-bitter end.

But enough blather, on with the game!

Game-in-a-month 1 (will there be a 2?) is called “Silas”, and it stars some of the world’s most detestable creatures. No, not kittens. Cockroaches.

I came across the concept around 3 in the morning. Taking Kyle Gabler’s concept of “themeing”, I started from the idea of light, and then proceeded to come up with as many different things you can do with light as is possible. And my thoughts turned out something like the picture at the top of the post.

From there, it evolved into a game about a dead butler cursed to care for his master, but the only thing he seems to be able to do is turn lights on and off and scatter roaches. Poor guy.