I’m new to gamedev, having only released one minigame so far (without menus or anything!), so LD is a great chance to learn how to prototype quickly and effectively. It’s possible that I’ll completely fail, but I should be able to get it done if I keep the scope of my game small. Here are my tools:

Engine: Unity3D

Graphics: Blender and GIMP

Sound:  Sfxr/Bfxr, Garageband on iPhone, Audacity, PaulStretch

Misc: Chronolapse, lemon-shaped kitchen timer for Pomodoro Technique, pencil and sketch diary, 26 dice (great for prototyping games and visualising arrays).

Prior code:

I’ve taken some time to assemble a nice base game project in Unity to try and smooth my progress at the start. It has some stuff I grabbed from Unify Community’s Wiki (flocking boids, random helpers, a sweet timer class) as well as some helper classes I’ve written myself:

• Fade in music
• Flycam with cursor locking
• Helper methods for working with 2D arrays (checking if an index is valid, flood-filling, printing a 2D array, converting  jagged -> 2D, and grabbing a range of indexed values).

I’ve also got a basic main menu going with a custom GUISkin, and a bunch of example objects in a scene with some interesting code snippets attached (like a cube that hovers on a sine wave, which will come in handy, I just know it). You can download it from here if you’re curious.

I made some productivity tools in Autohotkey, and have been using them for quite a while now. They’re solid and wonderful, although only for Windows users I’m afraid. Some of you may find them handy.

• Instant Text Automator lets you make mouse and keyboard macros by inputting them as text strings (I always found recording macros kind of fiddly).
• Scratchpad is a notepad that displays and hides with a keyboard shortcut. I find it handy for making todo lists, storing text snippets, or logging changes to code as I make them for later addition to the commit.
• TextWrapper adds prefix and suffix strings of your choosing to your currently highlighted text. This can be done through Instant Text Automator too, but this is a ready-to-go tool expressly for this purpose, because I find myself needing this so often.

Tags: tools

This entry was posted on Tuesday, August 21st, 2012 at 4:12 am and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

A rubber ducky for debugging, a  lemon timer for time management, some marbles for playing, and some dice for visualising code!

Tags: deskphoto

I submitted about fifteen minutes ago, so I don’t have any feedback rolling in yet. I think this is a great time to write a post-mortem before the details are lost. I can do another one after my game is rated.

What went great

• I knew my strengths and weaknesses when I went in. Specifically, I knew that I was poor at art, AI, animation and music. This helped me direct my game ideas away from genres where I’d be weak. Knowing I was bad at art and music informed my aesthetic decisions too.
• Doing a puzzle game for LD was a great choice. A puzzle game has depth when it has as few pieces/behaviours as possible. This directly worked against feature creep. My experience with 2D arrays from another project also came in handy with this one (or really any other puzzle game played on a board).
• I used a notebook. I got myself a visual arts diary with unlined pages, and I had some colored pencils. It helped me figure things out and allowed me make to-do lists that were serious business, and not just scrawled on the back of scrap paper.
• I set some time aside to brainstorm ideas. When the theme was announced I put everything aside and made a mind map of all the things associated with the theme. I latched on to the idea of evolution being a gradual change in anything, not just biological, and trying to fit this into a puzzle game resulted in my concept.
• I made a level creation pipeline. And by ‘pipeline’, I mean it loaded a .txt file and parsed it into tiles. Much better than doing things in the editor, though.
• I didn’t drink much coffee. I found that it just made me feel a bit ill.

What went poorly

• Designing puzzle levels is painful. If I do another puzzle game, I will do mathematical puzzles so that I can generate them procedurally. I ended up arranging cutouts of color names on grid paper, working backwards from a semi-solved state.
• Not colorblind-friendly. I’m really, really sorry. The next puzzle game I make will be based on symbols, I pinky-promise.
• Not enough time to deepen the mechanics. I think the behaviours of the tiles are too similar, but I didn’t have time to iterate over changes.

Conclusion

Until now I’ve only finished one crappy minigame. This was my first LD, and I delivered a polished game within 45 hours that I am really quite pleased with. I couldn’t be happier!

Introduction and special thanks

This was my first LD, and I came here fully expecting to faceplant from over-ambition or poor time management. But I submitted my puzzle game, ‘Additive’, polished and complete with hours to spare. It’s the first complete game I’ve ever done, and it’s gotten more positive feedback than I had dared to dream, and the process of making it shoulder-to-shoulder with all you other fine people (especially on IRC) was awesome.

Before I start the post-mortem, I want to thank ‘Cake’ from IRC for giving me a quick pep talk around six hours into the compo, when I was feeling particularly unprepared. I also want to thank all of the IRCers who complained that my first release candidate was too cryptic, and especially ‘Tau’, who played through the entire thing and deliberately found ways to break it. My game would be half of what it is without such playtesting. On with the post-mortem!

Part 1: The pre-feedback post-mortem

This is actually the second post-mortem I’ve written for Additive. The first one, written immediately after submission and before voting opened, can be found here. Its salient points are:

What went great

• I knew my strengths and weaknesses at the start of the competition, and this guided me towards reasonable ideas and goals.
• Making a puzzle game was a great decision because the very nature of a puzzle game works against feature creep.
• I used a notebook to organise myself and work through problems.
• I set some time aside to brainstorm ideas.
• I developed a quick way to make levels, which was more efficient and accessible than building the game board in Unity’s editor.
• I avoided crashes by limiting sugar and caffeine intake.

What went poorly

• It was very difficult to design puzzles.
• The game is not colorblind-friendly because I had a hard time letting go of the aesthetic I had developed. This is not the kind of developer I want to be!
• I didn’t have enough time to deepen the game’s mechanics.

Part 2: The post-feedback post-mortem

 More things that went great

• I decided on a feature lock after the first day. By the end of the first day I had a working game. The second day was dedicated solely to polish and level creation: no gameplay changes allowed.
• I did early testing. Sticking the game up on my Facebook delivered exactly zero constructive criticism. Posting the game on IRC for fellow devs to play got me immediate blow-by-blow feedback, and my time budgeting on Day 2 allowed me to work on every single one of the issues that were raised.
• I put a lot of effort into visual player feedback. I changed the buttons on the main menu at the last minute to make them look more buttony and clickable. There’s a nice marker to indicate the selected block. The marker and the selected block pulse with color. Blocks animate towards their new positions instead of just teleporting over.
• I spent even more time on aural feedback. When you click on a block, it makes a sound. Deselecting a block makes a different sound. You get a different sound again when you try to make an invalid move. When blocks combine, the sound they make depends on the outcome. Sound makes a game feel alive and reactive. Skimp on graphics before you skimp on sound.
• I think I picked a fairly cohesive style. The game is an exercise in minimalism (like I said in Part 1, I knew I was bad at art). Its presentation was informed by the effect of parenting a spotlight to the camera and tilting the camera 45° towards a plane. I felt that an understated look deserved an understated and elegant sound, so I used single piano notes in GarageBand iOS for sound effects. The game would have been a dissonant mess if I had used SFXr.
• Having the tutorial levels was a good idea. It gave me the opportunity to dress the game up with prose, and it also communicated the essence of the game efficiently and enjoyably. It became even better when I added explicit instructions on suggestion from the IRC testers.

The only other thing I can think of that went poorly

• The black squares imbalanced the game. It was intentional that you’d be able to walk the black squares around in the last level, gobbling everything up with wild abandon. I didn’t know that this was possible in the other levels, and the game’s difficulty suffered as a result. Some of the levels have black squares adjacent to each other because I was actively trying to avoid this exploit. If you poke through my timelapse and my source code, you’ll see that I actually did have other ideas for color combinations and win conditions (some of them were actually suggested by players in the game’s comments), but I knew that the game was already pretty good with black squares as they are, and I had no time to change the mechanic and playtest it to my satisfaction.

In all, I’m incredibly proud of what I made. It turned out far better than I expected, and the experience is invaluable. I am already feeling the itch for some rapid prototyping, so you know I’m going to be back in December. Thanks for reading, and don’t forget to play Additive if you haven’t already!

A surprise for you, dearest reader!

I’ve uploaded pictures of the dev notebook entries I made during LD24 to Additive‘s page on my website. It starts the day before LD, and ends with the list of things I wanted to address in this post-mortem.

Tags: journal, notebook, post-mortem, postmortem, SuccessStory

Since my finals I haven’t really gotten any ideas for game dev, plus I have a birthday party to attend right in the middle of the compo. I’m thinking that I’ll make some basic game skeletons to warm up, then see how I feel.

I really want to participate, though. I want to know if my great performance last time was beginner’s luck or not.

Got back from the party, had a nap. Now I have 31 hours left and have done zero work. No ideas, no lines of code. We’ll see.

At the beginning of LD26 I pointed everyone to a suite of creative tools I had made, one of them being a card deck that helped you brainstorm a game, starting from its most basic gameplay. Did anyone use it? How’d you find it?

I’ve had several requests for a professionally-printed version of those cards, and here they are! I call it PlayThinker, and it is US$10 plus postage. I’d be awfully happy if you gave it a look.