I’m in for LD 27! and a tale about a gdx-archetype

Posted by (twitter: @wrongcoder)
August 6th, 2013 2:59 am

This is an early “I’m in!” for LD 27 as well as spam. I mean, an advertisement for my base code. I mean, declaration. Yeah, that’s it. Declaration. Of base code. Right. Also, I’m in. And there’s some new base code you can check out. It’s probably terrible.

You wouldn’t know it from looking at my LD 26 entry, but I’ve been making (more accurately, trying and usually failing to make) game demos using LibGDX for well over a year. In fact, I attempted LD 25, but at the end of the weekend all I had was a Santa Claus sprite running around a tree. The idea was for you to unload gift-wrapped bombs from your sleigh while the computer-controlled Grinches tried to save the children. I think it would have been worth a giggle if it ever became playable but I spent way too much time being a software architect to get anything done.

What’s a software architect? You know, one of those useless people who spends all day drawing boxes and arrows on a whiteboard, somehow getting in your way despite doing no actual work. And how bad was it? Oh, it was bad. Real bad. To illustrate, here are the first few commit messages I made on the project:

Fri Dec 14 18:12:45 2012 -0800 Initialize repository
Fri Dec 14 18:12:59 2012 -0800 Maven skeleton
Fri Dec 14 20:56:07 2012 -0800 Ignore generated files
Fri Dec 14 20:56:14 2012 -0800 Title/Loading screen
Fri Dec 14 21:00:29 2012 -0800 Exclude source images from JAR
Fri Dec 14 21:02:14 2012 -0800 comment
Fri Dec 14 21:03:09 2012 -0800 Less logging

And it went downhill from there. No question, this game was doomed to fail.

You see, I have a problem. You could even call it a disability. Let me tell you about it. Okay. Ahem. Here it is. By day, I am a senior enterprise software developer. I lead the design of big fat enterprise applications that process many millions of records every year, that have to process every record perfectly or else there’s trouble, that have to be built automatically in a reproducible way after every commit so that every change can be tested, that have to withstand daily development and feature requests and frequent about-face design changes, yet remain maintainable for a decade or more. So there you have it. Feel free to hate, laugh, ridicule, or take pity; go ahead, I’ve had it all, and I deserve all of it and more. But the point is, I have developed a need to feel that my software has some essence of correctness or I become very uneasy. It has to be right, or I am compelled to make it right. Like I said, you could even call it a disability.

Game development, I’ve discovered, is the polar opposite of enterprise software development. It’s all about struggling to add whiz-bang features and faking it until it’s barely working. It’s all about fine-grained performance optimization and hunting the elusive framerate increase. It’s all about how the game makes the player feel while playing. (That’s the big one. Watch Extra Credits if you don’t believe me.) Get one more change in, and as long as the player’s overall interactive experience is better for it, the game has been improved, and nothing else matters. Ship it, and you never have to deal with the tangled unfathomable mess again, so don’t bother cleaning up. This way of working makes me very excited, but also very uncomfortable. Very, very uncomfortable. I know it doesn’t matter. I know the purpose of the software is different. I know it doesn’t need to be good software to fulfill all the requirements of being a good game. But it still makes me uncomfortable. It’s like an itch that I can’t scratch. And the more I work with the code, the itchier it gets, and the harder it becomes to let it be instead of taking off to a whiteboard, with the deadline ticking down, to figure out a way to make it right.

So after this painfully unproductive LD 25 experience, and after considerable thought in the following months, I managed to make a deal with myself. It consists of two parts. The first part is that, during a LD or a mini LD, for the entire duration of the event, I would let myself be messy, and I wouldn’t worry about it. I’d be a pig in mud. I’d enjoy adding features to make a better game, sparing no thought to what may need to be changed later. I’d do whatever it takes to deliver my game design by the deadline. Software architecture wouldn’t matter because I’d never have to touch the resulting colossal tangled mess ever again. I wouldn’t care that it’s piling crap upon crap upon crap — by the way, huge Gordon Ramsay fan — because it’d all be over soon. Everything would be permissible in the name of making the game design come to life.

And the second part is, after it’s over, I’d take my time performing a postmortem on whatever I ended up making. I’d reflect on what was cumbersome, what was pleasant to work with, what changes I had no choice but to make in order to implement a feature. And then I’d take these lessons and incorporate them into base code so that I could build upon them for the next iteration.

After all, I embrace agile software development in my professional life, so why not be flexible and iterate towards sustainable, maintainable, understandable, sensible software architecture for games as well?

And so I am reservedly pleased to refer to my LibGDX Maven archetype project. I worked on it after gathering my thoughts following LD 25. And I kept working on it, until it seemed complete. And after using it as base code for MiniLD 44, I caught a second wind and worked on it some more, tearing apart the changelog for the game, learning all the lessons I could, and applying them in code form. I think I can say it’s something, now. It can be more. The work continues.

And at last, the story takes us to the present time. Who’s that snoring? Oh, it’s probably me. Wake up anyway.

Do you believe that Maven is the one true build system? (I don’t. Gradle is cooler. SBT is pretty neat, too. Just agree if you understood the question.) Do you spend days agonizing over whether something should be a Singleton or a static field reference? (You shouldn’t. That’s a stupid decision. Both are faulty, but one is worse.) Do you wish you could put everything in a J2EE container? (I hope not. Spring is way better.) If you said yes to all of those questions, then kindly stay away from this project. I don’t need any more enterprise software developers telling me what they think. I’m enough of a liability by myself.

Did none of that make any sense, or the least bit of difference? Are you more excited by rendering realistic hair and sweat in a sports game than ensuring that your game engine can be used again next year? Do you yearn to give the player a unique experience? Then please look at my skeletal software architecture. Please help me find all the ways that it will prevent me from turning my game ideas into a reality, so I can fix them.

After all, I’m no artist, I’m no designer, I’m no musician, I’m no game programmer, but still, my game ideas aren’t terrible, right? Worth a giggle, at least?


Well, I’ll show you! My LD 27 entry is going to be awesome!!!



Leave a Reply

You must be logged in to post a comment.

[cache: storing page]