May 9 2010


While Zulu Hour was not my first game, it was my first fully-featured game. Fully- featured, as in, ready for prime time. It works like a player would expect it to. This is not to say it is a good game (though I think it is). Fully-featured is the difference between Deus Ex and Starcraft Ghost. I’m sure somewhere, in some archived repository, there is a playable demo of DNF, but it just isn’t “finished”. It might have a memory leak, it might require a console command to start a level, or it might crash if the player tries to save his/her progress. It doesn’t matter how good Starcraft Ghost would have been; if it’s never released then what good is it? Well, I’ve found even if you think your game is 80% complete, you may very well have 80% to go. The leap from playable to releasable is huge.

Making this game was always supposed to be a learning experience, and it was nothing if not that. I learned so much it’s difficult to decide where to begin, so I’ll start from the beginning. Unless you’re James Silva, and have insane talents both artistically and technically, you need to get a team. Actually, I should elaborate on “artistic”: unless you are familiar with, and good at, creating game art, get a team. I’ve had some modeling experience, but the day I got my first asset from Karl, it was painfully obvious my game art should never see the light of day. However, the fact that I started out making my own assets was a huge advantage, and is one of the most important pieces of advice I can give: get a prototype of your game working before you start looking for an artist. The reasons for this are numerous. First, it shows potential teammates that you are serious about making (read: finishing) the game. Second, it gives a feel for the game. Is it slow and grinding or frenetic? A good artist will pick up on the style of the game and make the art fit. And third, it gives you a head-start on the code. Having art sitting around waiting to be used is not a good thing. The artist is more likely to get bored, and the programmer could quickly become overwhelmed with all the assets that need to be used.

Another lesson learned: get a good art pipeline. If your artists can’t get their assets into the game by themselves, you’ve got a problem. And don’t blame it on the artists. You’re a programmer; you make software that is supposed to make people’s jobs easier. So, do it for your artists! If they can easily tweak their art and see instant results, you’ll get infinitely cooler and prettier results. Also, along these same lines, fast prototyping can be huge. For us, Karl is good with Flash, so he made quick mockups of his ideas so I could replicate them in our engine. Explosions, pop-up messages, etc. were ridiculously easy for me, because I was merely making my effects look like his.

Of course, I learned copious amounts of technical things over the course of this project, but most of them you can learn at Riemers or the XNA website. However, some you won’t. For one, and I may get some nasty comments about this, I somewhat disagree with Shawn Hargreaves’, “don’t optimize until you have to.” Whenever possible and feasible, optimize in-line. If I use foreach loops and new strings everywhere when I’m developing, the last thing I will want to do is replace them later. I might tell myself, “it’s just for now” but I’d be lying. In my opinion it will be just as readable, and you won’t need to do regression testing. Now, I realize Shawn was probably advising against running NProf everyday and accounting for every drop in framerate, and I agree. You can easily start worrying too much about performance and try to figure out why it was just cut in half – even though you’re still getting 150 fps. However, if you wait until you’re at 5 fps, you’re going to give yourself migraines trying to boost your performance. Perhaps you’ll find a much faster way to render dynamic vertex buffers in the beginning and use it throughout your game.

I’m going to try to restrain my gag reflex and end on somewhat of a cliché: beware of scope creep. If the words MMO, FPS, or RTS are in your plan, seriously reconsider. I’m not saying it’s impossible, but I’ve learned it is so much better to release a breakout clone than just a tech demo of an elf running around with a dagger. For your first couple games, just release something that works and is fun. You’ll learn a lot, have a finished product you can show off, and you’ll be much more likely to have energy for another. This being said, don’t be afraid of tiny creeps here and there – it could turn out to be your game’s secret sauce. Your teammates and friends will undoubtedly have suggestions for your game. Use your judgment, but I think a good rule of thumb is if you can’t make a prototype of the idea in a week or less, it’s probably too big. I made the basic chase scene for Zulu Hour in about half a week. It was instantly fun, and added a very unique aspect to the game.

I have realized this turned out way more preachy than I intended. These are simply lessons learned from our first released game, and they may or not apply to other projects. Overall, I had a great time making Zulu Hour, and I hope people get some fun out of playing it.

Mar 27 2010

We’re live!

Zulu Hour has gone live! Check us out on Xbox Live Indie Games! Hope you enjoy it!

Feb 6 2010

still alive

Wow, last post was august…fail.

zulu hour still hasn’t gone live, but it’s dang close. it’s been submitted to review twice, but was rejected due to crashes :( unfortunately, this last one is being a real bastard, since none of us can recreate it….making it pretty difficult to fix. to help the situation, i used this example from nick gravelyn to make an error handler that basically just spits out stack traces. lesson learned: always add this wrapper.

anyway, it’s in playtest until someone can recreate the crash. so if anyone would be so kind…

Aug 7 2009

when it rains it pours

wow, what week. aside from a lot of other stuff going on in my life, dream-build-play ended this week! the team had a laundry list of things to do before the deadline, and my god did we work our asses off. justin got a really sweet piece done for arcade mode, and karl got some incredible assets in, including another beautiful chase scene! i shed a tear, because i got to remember what college was like, working til 5am to meet a deadline…only in college, i didn’t have work the next day. it was a bit rough.

anyway, i think we sent in a respectable entry….7 semi-finished levels, 3 bosses, 4 game modes, a bunch of weapons. the only thing i didn’t want in there is a nasty bug that i can’t seem to remedy. oops.

thanks karl and justin for all the work this week!

now on to get it out the door and online!

Jul 5 2009

plowin’ through

i love finishing a big task, especially one that i’ve been putting off for weeks. checkpoints! it’s so common we take them for granted, but they’re not trivial to implement…i know i wrote the damn thing, but my engine is like a black box. i add stuff to it daily, but i try not to think about it on the whole…however, implementing checkpoints (saving states periodically, so if you die you go back to that point in time) forced me to figure out what exactly determines my game’s state. saving/restoring state isn’t the hard part; figuring out WHAT to save is. do i save every bullet position? what if an enemy’s exploding just as i save state? should i save every particle? i currently saving as little as possible…it’ll be interesting to see what, if anything, i missed.

i also checked off another big box…upgrades! guns and lasers gain power now, and now that we added karl’s art, the visuals change as well, making you feel like you just got a shot of adrenaline.

Jun 12 2009

instant gratification can be nice

been working on menus and finite state machines and the like. it sounds boring, but you know what? i’ve been enjoying it. here’s why:

-there is something to be said about instant gratification, and nothing gives it more than making your game’s interface. if you can make a simple timer, you can make a pretty kick ass gui system. add a 2sec timer that adjusts the height of a window, and you’ve got a slick scroll out window. add a 1 second timer that adjusts your text’s alpha, and it looks like your dialog morphs from sentence to sentence. add a smoohstep() to EVERYTHING and your interface just feels cool.

-forget about performance. during gameplay you watch everything you do. in your gui, it’s quite different. first, it’s all scripted, so culling is a non-issue…you can run it once, and (normally) be sure it will always do the same thing. also, framerate isn’t as big of an issue. as long as your sliding text looks smooth, who cares? not to mention you might actually want a slide show.

don’t get me wrong, i couldn’t do this all the time, but it’s a nice break from trying to get arbitrarily rotated boxes to collide correctly.

oh i have to add, if you’re like me, you NEED to get an artist to help you with your gui widgets. it will mean the difference between windows 3.1 and vista*.

*ech, let’s replace that with Beryl, shall we?

May 24 2009

call me billy

it’s been a while since my last post, but that certainly doesn’t mean i haven’t been working on the game. i know it’s a bogus reason, but it’s not as motivating to write if you know nobody will read it (i never kept a journal). however, i just found 2 comments that weren’t spam -that’s right, live PEOPLE! so, no lame excuse not to write now. i’ll try to do better.

so, what have i been doing? menus and windows! while i wouldn’t want to do it for months on end, it’s been pretty fun. karl has been supplying me with fantastic art, so zulu hour is looking more and more like a “real” game. of course, in the grand scheme, it doesn’t help the game play at all, but at least it doesn’t give you a bad taste in your mouth before you even start playing it. plus, polish is one rating factor in DBP, so it can only help us, right?

closely related to the GUI is the overall framework of the game, meaning starting the game, selecting a level, beating a level, then continuing to the next one. i’m getting close to havig “campaign mode” ready, and once that’s done, it’s off to playtest for some public feeedback!

oh yeah, EMP weapons have been added! man, i’ve got to post more often.

May 4 2009

for instance

i love it when people get on the XNA forums and ask, “how do i make a game?” that is one of the rare occassions where the bastardly answer, “if you don’t know, i can’t tell you” might actually be appropriate. games are designed to be fun to play, and it’s easy to look at a beautiful let-down like far cry 2 and think you coud do better. but my god, video games are not trivial things to make. it’s not like golf…pretty simple to create a game like golf, but as they say, it takes a lifetime to master playing. i would say video games are quite the opposite.

so what brought this mini-rant on? i spent my weekend optimizing. i try to follow the rule of optimization, “don’t do it”, but when you’re running at 20 fps, you don’t have much choice. my newest xbox-crippling feature was about 1200 trees. they’re all the same, so hardware instancing was the obvious solution. now, i could have cut+pasted the xna instancing sample, but where’s the fun in that? actually, getting quick results can be extremely fun, but i’m doing this project partly to learn something so i dissected every LOC in the sample and recreated the whole damn thing. i can’t say it was the funnest thing i’ve done, but the technology is cool, i learned a lot, and it works (what more can a programmer ask for?)!

results? could be better, but on the xbox i’m bottoming out at 45 fps. still needs work (better culling), but if you think about it, if every tree is 100 polys…

100polys * 1200 trees = 120,000
120,000 * 2 (reflection in water) =240,000 polys

plus the terrain…not too shabby.

and what was the point of this post? i’m not sure myself. for one, the game now has trees! second, for those who want to know how to make games, multiply this kinda stuff by…oh i don’t know…the xbox’s fillrate or some other really big number.

May 1 2009

video 3

hey all, ‘nother video has been posted!

Apr 27 2009

80% done, only 80% to go!

Lots of good progress since my last post.  We have a new weapon, the all-poowerful laser, which is loads of fun to use…It’s like butter!  Also, we’ve added a rockin dialog system, which boosted the game’s professionalism far above the “My First Game” look.  Thank heavens for that.  It worked out very well, because Karl prototyped it in Flash, made it look awesome like he always does, and then I merely duplicated it in the game.  I wonder, do most game developers use a similar process?  If not they should!

The other large addition to the game is hush-hush for now.  Hopefully when we make it look better we’ll start showing it off, but until then, let’s just say it adds a whole other dimension to the game.