Ludum Dare 29
Ludum Dare 22
About Snowflower (twitter: @christinacoffin)
veteran professional game developer gone feral indie.
Past jam games:
Tri Soup Shmup: http://bit.ly/ySuviN
Forever Alone Kitten
1st playable version uploaded
full jam submission post with story, controls and dev notes is here:
All feedback and ratings appreciated, thanks!
Ok so I crashed for some sleep after submitting my compo entry and I figure now is the best time to do a postmortem.
In traditional game projects people usually go off on vacation or put off post mortems long enough to forget about the details
Forever Alone Kitten
Play / Rate it here:
Made with: Unity3d / Photoshop / BFXR / Maya
Points of frustration
- Indecision about Dialogue/Story, after the theme was announced I was at a loss for what to do. So I went through the motions of creating the game engine shell while being nagged by this. I originally wanted to make a shmup, but tried to do something moody to fit with the ‘Alone’ theme and sort of flailed around for several hours trying to define it.
- I’m still new at learning unity and wanted my entry to be made with it, so consulting the documentation repeatedly or trying to figure out proper script code to control material properties or other things slowed me down bit.
- No time for visual polish/build a proper environment. At the end I lied to myself and said its supposed to look bleak and empty anyways.
- No game restart. I realized early that worrying about adding/testing restart functionality would have slowed me down considerably, so I abandoned it even though there is some fragments of it in the game.
- Based on the player input, its possible to not see all the game narration paths, so if someone plays it only once, there is stuff I put time into that they may not see and the length or mood impact can vary. The lack of #4 (restart), or communicating that there is ‘another path’ in the game content is also problematic. This is why I don’t like permanent branching games as a game player, and prefer ‘networked world’/sandbox games because all content is explorable at anytime or multiple times. I’m not convinced story heavy games really hold up to replayability since they all seem to suck at this issue (you played this before, but this menu option here will show you something different, a hint like that would be kind of spoilerish or break immersion).
Things I was happy with
- I learned a lot. I’m a ‘learn by doing’ type of person, so forcing myself to deliver something in 48hrs made from scratch in the time limit = learn + do fast. I used version control even for this short-term project so i could document its construction in the commit messages and would stop worrying about ‘accidents’ where i would lose work or mangle things so badly and could rollback.
- Some people commented on liking the mood in the game, which is what I decided to focus most on. Someone despaired that when they played there seemed to be no “happy ending”. My goal of toying with the player’s emotion = ‘mission accomplished!’
- I came up with a neat little forcefield behavior around character that affects the things that swarm and come for you, the enemies still face+approach you, but when the shield is up it holds them back and they get pushed around fairly smoothly when you forcibly move into them. I’ll have to re-use that for another project….
- Although the code is absolute spaghetti, there is alot of it with some lengthy comments sprinkled in it so I could remember what I was doing along the way, so its not a complete throw-away game shell for something in the future. For the curious: Link to source/assets/unity project are here: http://db.tt/eJOJT6Dx
In reference to point #4 above, I call my rapid code prototyping style ‘Freestyle Spaghetti / Chaos Coding’. People that care about ‘coding style’ or ‘designing clean systems’ will be outright offended by what they see here haha
The basic rules of ‘Freestyle Spaghetti / Chaos Coding for rapid prototypes+game jams:
- Extra Comments, you need them. You need more comments than you think you do. I write comments as a way of ‘talking out loud’ about what i’m doing. It makes things more clear, and when I come back to the code later, I can more easily remember where I left off.
- Extra Verbose variable/object names. you want every variable name to make it painly obvious as to what its scope and contents are. Between #1 + # 2, I rarely ever need to step through code using a debugger because I can work out what is going on following these 2 rules.
- New ideas may often come to you while writing code for other things, jumping to act on that new idea is okay, as long as everything still runs you’re cool. Unfinished things = comment verbosely what is going on. Before you jump to the new thing, always write a note in code about what you were just doing+need to do next there, then jump to the new thing while the idea is fresh to you.
- Everything can look to a base (GameBase.cs) to figure out what is going on (access a global value state) to gate/ungate a script that doesnt work or isnt complete.
- Take the path of least resistance in implementation. Data driven? Code Driven? Do I need a tool? Do I need a file format? Could you just hack it in code and be done with it?
- The person playing your game doesn’t see your code when they play it. Stop worrying about what your code looks like and focus on the results that people will play. You can pretty up your code and ‘refactor it’ later if you need to build on it.
Things that took more time than I expected:
- Audio – I spent a lot of time with bfxr trying to get sounds out of it that matched the mood I wanted (trying to get a sad kitten+spooky type sounds out of a synth). There’s a lot of extra sounds in the source that I didnt use which fit the mood target but i didn’t get to implement due to the time limit+needing more supporting graphics+code to go with them.
- Art/Tweaks – I went crazy with the particles. I liked the square/fine grain look of the particles so i kept the particles untextured to save time. I fussed with the colors of everything several times to keep it the right ‘mood’ as well as all the other particle effect sliders. I lost time modeling a few other things that didnt make it into the game and realized that there wasn’t going to be enough time to texture+rig+animate them so I trashed that given the time pressure.
- Dialogue/Narration – changed multiple times after playtesting through it over and over and over…. Having a premade system to handle complex dialogue/interaction would have been much better. hacking something from scratch+testing it with time pressure was painful.
- Setting up+modifying my game in unity. To save time I did some things in the unity editor instead of explicit code, which i’m still getting the hang of. The editor workflow method has little quirks like nuking connections or values on scripts if you change the variable name in the class to something new ended up biting me several times, breaking the game. Trying to find a balance of initializing/setting script values hardcoded or in the editor view on an instance of something with a given script slowed me down and I should have more clearly defined this.
Things to do next time:
- Setup and do a timelapse next time. In retrospect i’m even more sad I didnt do this. Ideally I would do record this for 3 screens since I work across 2 screens on my mac (playtest+code+ photoshop on cintiq), + geo modeling pc.
- Do something that doesn’t waste so much time with unique dialogue flow with one-off internal triggers/unlocks that the player might not ever trigger.
- Continue to write code fast+freely for the sake of progress, and don’t be so worried about what people think of your code that you hacked together over the weekend. (I write much better code for normal games I swear! )
- Build out a more of traditional game to play?
- Worry less about story/playtesting dialogue flow. Focusing the first half of the compo time on this was good/bad since it ate up a ton of time – it was uncharted territory for me in terms of content+code implementation.
- Better schedule my time and set time limits on doing a feature/asset.
- Start visual polish phase and test deployment earlier so there is less of a frantic rush at the end.
I didn’t get to spend as much time as I would have liked on my entry.
Its got bugs and a ton of stuff didnt make it into the 48hr limit, but the time pressure was an amazing push to get something done.
I’ll continue working on it for the next day to the point im happy with it, I forced myself to submit something even though I might be alittle emberassed by it, because I said I was going to do something from scratch in 48 hours.
Participating in LD 22 is an amazing learning experience. I made my entry with unity, which i’ve been learning seriously for about a month now.
I also bit off more than I could chew by going outside my comfort zone and trying to code some complex dialogue flow to create a ‘mood’ which is something i’ve never tried before. that part alone took way more time than it should have.