Week of Awesome II - Post Mortem

Published September 30, 2014
Advertisement
So this is a summary of my feelings about my game "Little Jimmy", or like whatever. So read it and take my bad advice.

What Went Right?



The Idea


Whether you think the idea is "fun" or not is up for debate, but the fact is that the idea was very simple and reasonable to make within one week. Right from the beginning I knew I had to come up with an idea that was almost painfully simple... otherwise I'd be subject to the usual feature creep situation that we're all too familiar with.

Unity


I feel sorry for, yet envious of, all of the people that entirely coded their games. Unity allowed me to focus on the important parts and have a decent looking game (regardless of my less-than-mediocre art skills).

The Art Style

(or lack thereof)


I chose not to texture unimportant objects in the scenes. This worked in various ways:

  • No time wasted doing UV maps
  • No time wasted texturing in photoshop
  • Directs the players focus to what is important

It's not something I would want to repeat for every game I make, but it was a great idea at the time.

Reusing Assets


I've really got to emphasise this. Not all models in this game were made specifically for this game. Quite a few models were taken from another project I made. I don't think this qualifies as cheating, but it is a huge time saver. It sort of makes me want to build up a big reservoir of models, textures, scripts, sounds, music, etc so then I can reuse everything to make whatever game I want with the least amount of effort and in the least amount of time. Also, I used MakeHuman to make Little Jimmy in 5 minutes. Let me repeat that: Five. Minutes. That includes modelling, texturing and rigging. Five minutes.

Working By Myself


This is something that some may disagree with, but it depends on the project and who you are working with. I work very well by myself because I am a bit of a jack of all trades (master of nothing). Working in teams works best when you can properly communicate with others and when you can properly delegate tasks among each team member. I'm not suggesting that it would work for you, I'm just saying that it worked quite well for me.

Writing Crappy Code


Who ever said writing crappy code was a bad thing? Obviously they've never made a game in 7 days. Some of my cutscenes were partially hard coded into core scripts. I would never even consider doing things like this in a large project, but it saved a bucket load of work for this situation.

What Went Wrong



Too Much Graphics


Way too much time was spent on the graphical side. There were too many models that needed to be made, too much animation and too much texturing. This sort of goes against a few other things I have mentioned above, but if I were to make a game with more complex gameplay, I would have to sacrifice this way of dealing with graphics to make up for it. It wasn't a huge issue for this game (because it was a super simple idea), but if I were to do another one of these, I would probably want to make a game that's more fun to play.

Unity Free


My graphics aren't fantastic, there's no denying it, and I'm not going to blame it on Unity. But I always thought that this style of graphics would've looked much greater with SSAO. But, alas, Unity free only allows access to a forward renderer, meaning that SSAO is out of the question. So why did I go with this art style anyways, you ask? Because I am, obviously, not as smart as you.

Testing


I probably could've released a prototype earlier than I did which could've easily ironed out some of the design issues and bugs.

The Music


I recorded the music straight off the piano, which included my awful sense of timing (even with a metronome). It was good in that it saved a lot of time putting each note into a program, but not so well in the final quality.

My Health


You wouldn't believe it, but getting the flu in the last few days of development doesn't make game development any easier. The moral of the story? Allow time for unexpected interruptions. I was just lucky that I got ill towards the end of the project.

Not Enough Time


Well duh. The main reason I mention this is because there were a few features I thought up that would've been really cool but just weren't plausible with the given time. So I'll mention some of them here just for the hell of it:

  • Little Jimmy has to get dressed. This would've made for a good level but it would've required more modelling.
  • Tiny Tammy. She was going to be another child that Little Jimmy would have to compete for the toys with. This would've complicated the AI code a lot more.
  • More dynamic music when Little Jimmy sees the toys moving. I had enough trouble with the music already.


So that's it. It's all over. Overall it was a quite fun and adrenaline-saturated experience. I'm looking forward to doing another whenever I can. I'd like to try doing a game jam in maybe a 48 hour time-span, which I would expect to be a completely different experience. I'd also like to try working with other people to see how things churn out in comparison.
3 likes 3 comments

Comments

Stormynature

To put it bluntly - the idea was simple, the execution worked well (bar the occasional "exit stage left"), the lack of textures worked well to highlight the game points, the puzzles weren't overly complex once having mastered the "do not let the toys die!" principle but still engaged me, a longer game might suffer from repetition aspects but for it's current length it was a great showcase that even a very simple idea can provide quality entertainment in a simple package. My personal opinion is that demonstrated what many people have forgotten...features are not what is important about a game at its heart. Well done - get better - get rest :)

September 30, 2014 09:26 AM
Thaumaturge

An interesting read! ^_^

I'm particularly interested in your inclusion of "working alone" under "things that went right"--it's not something that I would have expected someone to be glad of, especially given the rather limited time-frame of the competition. However, you do make good arguments for it!

For myself, as someone who worked by himself as well, I recall thinking that while having a partner might be helpful in order to spread the workload--but I also don't want to entirely give up either the development or art side of things.

As to Unity, it's an engine that I've recommended to others a number of times, I believe--albeit that it's not my own choice of engine, at least in part because of the differences between the free and commercial versions. However, I have worked with it, as I recall, and it can be a very good engine indeed, and I recall rather liking the tools that it provides.

Coding from scratch, while brave, is not something that I think that I'd likely recommend for a competition such as this, save perhaps in isolated cases.

September 30, 2014 03:55 PM
Eck

Very nice post mortem sir. Sorry you got the flu. :/

Even though I had a teammate, I agree with the "Working By Myself" being a strong option. I had the chance to add another coder to our team, but I thought it would slow us down. My wife did the art, story, and sound editing for our game, so we only had to briefly chat between stints of work.

Writing Crappy Code - YES! 1000 x YES! At the start of the competition, I was doing pretty well, spending time naming variables, encapsulating things into nice classes. The last day of the competition, I was cramming code wherever it would go and making everything global that I needed access to. At the end, my code was so brittle and I was so sleep deprived that I didn't trust myself to fix a couple of simple bugs. SHIP IT!

And I'll have to check out MakeHuman when I finally take the plunge into 3D. Thanks for the tip.

Feel better man,

- Eck

September 30, 2014 05:01 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement