Vertico Postmortem

Posted by (twitter: @@UltimateWalrus)
May 14th, 2014 12:11 pm

banner_small

 

Vertico is a  2D isometric “three degrees of freedom” shooter. Dive beneath the ice and fight creatures while moving in any direction, navigating a vertically-oriented coral reef.

Lately I’ve been trying to be more thoughtful about the way I work and how easy it is to get certain common things done in game development, as well as potential pitfalls and bottlenecks I may not be fully aware of.  And since commenters were surprised at how much I got done in 48 hours, I decided to do a different sort of postmortem for Vertico: I’m only going to look at how my time was spent.  I know it’s very self-centered (and also a bit OCD); this writeup is primarily introspective but I’m hoping others find it informative as well.

If you want to watch the goofily-narrated timelapse for yourself it is here.  Since I took the timelapse, I was able to go through frame by frame and (tediously) write up a record of how my time was spent over 48 hours.  Then I made several graphs to help visualize how time was spent.  Here is an overview of how much time I spent on each type of game development task:

piechart_time_analysis

Analysis:

That programming is the biggest slice of the pie is not surprising.  And from previous gamejams, I know that I cannot operate without sleep.  8 hours the first night and 4 hours the second night is my golden rule for 48-hour gamejams.

What’s clear to me from this overview graph is that I burned way too much time on music.  I need to work on improving the creation speed of my compositions.  I know of two reasons why it takes me so long:

1.) I need to improve the quality of my music.  When I make music and it sounds bad, I have to keep reworking, and reworking, and reworking until it sounds good.  I’m sure this is normal to an extent but if I could make better-sounding music on the first pass it would mean less passes overall and more time saved.

2.) I need a better computer.  I spend a lot of time pencilling in notes in the piano roll.  It would most likely be quicker to record notes from my MIDI keyboard.  However, I rarely do this, because on my computer the MIDI latency is so bad, it’s like trying to talk to someone on Skype while you’re hearing your own echo… except you never even hear your own voice in the first place.  It’s only echo and it’s so disorienting I can’t play in notes with any semblance of nuance or skill.

Most everything else was necessary except publicity.  I only took a few minutes here and there, but surprisingly it added up to over an hour.  You can argue it’s “only an hour,” but what could I have done with that hour?  37% more level design!  Or 35% more artwork!  Publicity is good to worry about as a game developer, but I think from now on, I’ll worry about it after the development period is over.  Hardly anyone watched my stream anyway.   😛

It also would have been nice if my tablet was working.  I may have saved a tiny bit of time on art over using the mouse.  However overall 3.15 hours certainly doesn’t sound that bad for art, especially since people have praised the artwork :]

I’m especially curious about bottlenecks in programming, so here is that slice of the pie, expanded:

20140514094721

Analysis:

Sadly this graph wasn’t really as useful as I thought it would be.  But I guess it’s not so bad because it confirms what I really felt strongly about after I finished the game: my programming has finally reached the point I had always hoped for.  When I look at the individual tasks there is almost nothing that took longer than it should have in my mind.

The one thing I do see, though, is that I spent almost an hour coding that stupid energy bar.  I detest coding HUDs for whatever reason, so I guess I let it get the best of me.  I should find a way to make HUD coding fun for me.

Looking through the timelapse, I realized that I almost went into a sort of adrenaline-induced trance on Sunday, and got certain things done perplexingly fast.  If you are motivated by hard deadlines, ride that wave of adrenaline!!  Drink some coffee and it might just be what you need to send you over the edge into “beast mode.”  You can pass out as soon as the game is done.

Finally, I somehow managed to make this color-coded timeline illustrating what type of tasks I was doing over time:


timeline

Analysis:

I’m glad I made this because it’s neat to see how I transitioned from one type of tasks to the next.  I have a couple thoughts about it.

The order of events worked out well for me.  It very well might be different for other people.  But this is what I did:
1.) Music.  Some might not think to start with this.  However I really liked this order because if you make the music first, it sets a sort of primal chromatic tone for the entire thing: art, gameplay, and sound.  I really think it’s good to start with how you want a game to feel and work backwards from there.  Just as most level designers will start with what they want a player to do and work backwards from there.

For some of the time I was making art, I honestly listened to the tracks I had made on loop.  I really think it helped, because I was able to constantly focus on making art to match that music.

2.)Sleep.  I had some issues with my music, and I went to bed thinking it sounded horrible, almost beyond salvaging.  After I’d slept, the pieces sort of fell into place and I tweaked a few things to make it sound good.  Granted, I wish I was able to do the music so fast that I’d be able to start programming before bed, but it didn’t work out that way.

3.) Programming. Of course it’s good to start this ASAP, but remember what I said about mood.  Even cold, logical programming has a mood.  You’re coding a videogame.  It may be ones and zeroes to you, but to the player, it’s magic.  So I still think doing the music first worked out well.

Notice the little slivers of purple though.  I took breaks from programming to draw final assets for the player, coral blocks, etc.  Why bother with placeholders during a solo gamejam?  It just adds another step to the process.

4) Sleep.  Time is of the essence but if you get four hours in it will improve your efficiency tremendously.

5.) Design.   In a gamejam, it’s really good if you can manage to rig up your game so you can design and playtest at the same time.  That’s what I did for Vertico — just hit F7 to go into design mode.  (note: you can even do this in the release version.  Though I think it was bugged by that time)  Taking little bits of time to program editor tweaks will save you loads of time in design, so don’t be afraid to hop back and forth between programming and design.  While they often get separated into two separate jobs in the game industry, programming and design are so closely related you can almost consider them as two sides of the same coin.

6.) Sound.  I left this to the last minute,  because you only know how many sounds you need once the game is finished.  And if you’re going to churn out a bunch of sounds in something like sfxr or LabChirp, I think it’s much quicker to go down a list of assets than it is to generate sounds as needed.

I would’ve liked to spend a little more time polishing the sounds, but I was running low on time so favored speed over quality to an extent.  I did wind up spending more time than I wanted on a “movement” sound effect for the player.  However not only was it buggy but it was also annoying, so I got rid of it in the end.

?.) Art.  I just drew art on-demand throughout the whole process as you can tell by the little purple slivers.  I’m curious as to whether this is faster or slower than doing them in a whole batch.  However, I’m inclined to think doing them in a whole batch would be slower — the reason being that, if you don’t create art as needed, you have to put something in as a placeholder anyway.  This adds an extra step to the process.  Art is a nice break from the other stuff anyway and I think it helped me keep my attention span.

One note about the “what went wrong” in this timeline.  There were certain distractions that could’ve been avoided.  They only took a small amount of time but I suspect they had an impact on my focus.  Such as hardware problems (having a computer that isn’t on its last leg would avoid this).  Or publicity (the stream kept having technical difficulties).  Or having to get a pizza because  me and my girlfriend accidentally bought a gross kind of fish (stick to frozen dinners for gamejams, I say).

Conclusion:

Making these graphs and this analysis gave me a lot of insight into the way I work and how I can improve.  I really need to get quicker with music; save publicity until after the gamejam; make sure I have dependable hardware; don’t drag my feet on HUD coding; make sure food is all set up before I start the gamejam.

Perhaps others can glean insight from these conclusions.  However I think the major takeaway is just that you can do this for yourself as well.  Make sure you take a timelapse of your work.  It’s incredibly tedious and you’ll feel silly spending hours analyzing something that only took you hours to make anyway.  However if you’re thorough enough you’re sure to find some good ways to improve your workflow as hopefully I have.


2 Responses to “Vertico Postmortem”

  1. This is one of the most detailed and helpful post-mortems I’ve read! Time tracking is definitely a great tool for improving your process and making better use of your time in later compos. I personally like to use Hamster for time tracking in Linux, since it just takes a second to click on it to change your current task. I used to use something similar in Windows, but I can’t for the life of me remember what it was 😛

    Thanks for taking the time to write this out!

  2. I’m glad you liked the article! I know RescueTime does automatic time tracking though I don’t remember how detailed. If I do this again in the future I’d probably prefer using software like that rather than tediously picking through the timelapse, although with my method at least I was able to pick apart individual programming tasks.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]