30-30 Unit #01 – Siege Blaster

That’s it. I’ve tasked myself with a new challenge. It’s time to start making games and getting better at this jazz.

I gave it quite a bit of thought. I wanted to come up with something that wouldn’t only sharpen my skills as a game dev and programmer, but something that was going to sharpen my ability to finish games. I wanted to come up with something that would remove some of the coding cobwebs, help me improve my planning skills, and do some nice “feature-creep” habit killing. After some thought on how to kick myself into gear, I devised a self-imposed challenge : the 30-30 challenge.

Simply put, I will make 30 games that are only allowed to last 30 seconds of playtime maximum.

How’d I come up with this? Real quick:

  • Having only 30 seconds to work with, I can only do so much. This forces me to think about what’s necessary, keep it simple, and avoid “feature-creep” that makes my game into a 120 second into a 5 minute into a 20 hour and so on and so forth.
  • A 30 second game isn’t horribly long; still requires effort, but still significantly short. In theory, I can finish a game like this in a matter of days.
  • Over the course of the 30 game marathon, I’ll be able to start applying right away what I’ve been learning from previous games. By the time I hit game 25 or 30, hopefully I’ll be much sharper and faster at planning and hammering out the code.
  •  actually finish some games!

In fact, pertaining to that last point, I already have!


Unit #01 : Siege Blaster

In the Python and Pygame crafted Siege Blaster, you have 30 seconds to take down the boss. Figure out how to deal with destroyable barricades that are randomly spawned each time you play, but watch out for counterattacks because three hits and you’re toast. Take down the boss before time expires and you win!

It was actually a lot of fun and, hey, did I mention I actually finished a game? It has its win/loss conditions and is pretty bug-free to my knowledge! YES.

So now, post-mortem! Really? Yes, really! This is very important. I need to reflect on each unit so that I can carry momentum into the next one. I’ll be keeping it somewhat brief (hopefully), as I tentatively plan to write 30 of these! So…

Unit #01 Post Mortem

What Went Right:

  • Had a good start. I managed to identify some key functionality early and wrap it into a base class that almost every other class inherited from. That helped a lot, even if it didn’t always match up exactly.
  • Kept it simple!
  • Simplicity works! Oh sure, we like to proclaim the KISS principle, but our ambition and that blasted feature-creep…! Though looks may be deceiving, the game is actually rather challenging for what short duration it is! With time working against you, figuring out how to handle barricades and avoid shots (I tweaked the trajectory just so, mwahaha) is a bit more tricky than you might think. In short, it serves as a reminder that two or three well-combined mechanics really can go the distance.
  • I finished a game. Oh yeah. 8)

What Went Wrong:

  • Ugly code is ugly. Past that base class I wrote up, things ended up going kind of downhill in terms of organization. I kind of started slopping things around, especially since Python can let me get away with it (it doesn’t allow for private variables in the same sense as a language like C++ does). When you let your coding get bad and messy, expect it to stay bad and messy, and then get worse, and then stay worse. Shouldn’t I be more cautious of this by now? Heh…
  • Lack of planning and some unmerited optimism. I mean, c’mon, how often have I been over this? Of course it’s not as easy. This stuff actually takes effort and time, and can often be more than you expect! And then when you start code slinging, you can get the previously mentioned ugly code because you aren’t planning too far ahead. I mean, sure, you can get away with it a little more the less you have to organize, but this easily is something I probably should ramp up as I move along, even if its just ten to fifteen minutes hacking together a broad blueprint. A good reminder again of what I’m up against.
  • Lacking HUD and sounds. Yeah, it’s a quick hack, but at least I could have done a little more to keep the player informed? Like maybe displaying player health?

All in all, I consider it a success.

So is this a 30 games in 30 days type thing? Haha… no. I’m not stupid; my schedule probably won’t allow me to devote 3-4 hours a day to this (not that it will always be that short anyway). Hilarious! But fortunately it’s something I could potentially chip away at in 2-3 day periods. And its part of the beauty of having the 30 second stipulation; hopefully it means less waking up two weeks later and wondering what happened to a project that wasn’t meant to be so large. I think its a challenge that I can more easily keep in perspective because of the “limitations”. As well, I may also take a break later for the upcoming Ludum Dare…

Eventually, I may post these games in a compilation executable too.

So that’s 1 down, 29 to go. 🙂

Posted in 30-30 Challenge, Design

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: