Every week?!

Look at me, writing regular blog posts (as we all know, the month is the smallest atomic unit of time, so there is no way I could have written a follow up to July’s post sooner than this moment, right now). Just over a week ago I stumbled across a fantastic GDC talk by Bennett Foddy & Douglas Wilson called Game a Week: Teaching Students to Prototype. I was mostly watching it in the background, while working on a game. But when the talk finished, one of the final slides included links to the course syllabi. So I took a break, and a quick browse, and found that one syllabus actually included the prompts for each of the 11 projects students would complete for the course. I read this for a bit, thought it was cool, but then went back to work.

But my mind didn’t completely go back to work. It kept thinking about the concept in the background, and before I knew it, I had an idea for the first prompt, “10 seconds or less.” So I made it. And then I made another game, because hey, why not? And also because the first idea I had was really grim, I wanted a more lighthearted counterpoint. You can play both games right now, in your browser, over on itch.io. Check out Happily Ever After, and You are Dead.

I won’t claim that either game is good, but I have already learned so much from making them, and I’m hoping to learn more as player feedback trickles in. So what have I learned so far?

1) Don’t have deadlines on Friday nights

I have friends, and we like beer. I’m also a procrastinator, and like to work up until the very last minute. If I have a due date at midnight on a Friday, something’s going to give. The solution? Midnight on Monday due dates. We’ll see if that moves a little more after the long weekend.

2) The feature creep is real

For You are Dead, I had a very simple idea, and executed it quickly. But as I worked on it, I kept coming up with ideas about how I could expand it into a full game. Then, when I started working on Happily Ever After, I foolishly started out building it in a way that would be easily extensible into a full game. So I designed, and started to build an easily extensible CSV file importer for building different scenarios, I worked on a syntax for the CSVs, I worked on a character designer, and plans for different level designs for different types of level (ex. castle, forest, town, etc.). Needless to say, this was too much to make in a week, especially when I’d already used up half the week making a different game. So I hardcoded a single scenario (ditching the other scenario I’d written, and the CSV import), I changed character creation into character randomization, and I only used a single level, for a single type of area. I’m not sure how to avoid this mistake going forward, but I’m definitely going to watch out for it.

3) You’re not a software developer anymore, god dammit!

This ties into the above, but I really need to watch the tendency—taught to me by computer science—to over-engineer my code. This is doubly true for these tiny prototypes, but even on larger projects, I should make sure a feature actually works, before building it into a robust, extensible bit of code. The CSV file idea is the most glaring example of this. Especially since I’d never handled CSV I/O in C#.

4) But still code in a consistent style

That being said, I still need to make sure I follow a consistent coding style. When I was quickly going back to replace the partial robust code with hacky quick fixes in Happily Ever After it would have been a lot easier if things were already in decent shape, instead of a mishmash of different styles. This is mostly just me transitioning from working mostly in Python at my previous job to working in C# in Unity, but it was still an important lesson to learn.

5) Don’t make too much art until you’ve got a test in the game

I made this mistake twice, once for each game this week. In You are Dead I made too many animations, and then ended up not needing all of them once I actually built the game. I wasted work by putting too much effort into the art pipeline before knowing exactly what I’d need. Oops. I partially learned this lesson for Happily Ever After, stripping out unneeded frames from the base sprite sheet I was building on top of, but made a brand new mistake along the way. After drawing several different layers of clothing, hair, etc. on top of my (modified) base sprite sheet, I finally added a bunch of them to the game (creating animations, prefabs, etc.) and then implemented character movement in a test world. It was at this point that I realized that the sprites I’d created were slightly off center, which caused a physics error when the character would change direction next to a wall (phasing through the wall, and sometimes shooting off into space). I compensated for this in the engine, but it would have been easier and better if I’d caught it before putting so much work into a faulty art pipeline.

So that’s a lot of learning. Pretty much a lesson every day, taught to me by my own mistakes. I can’t wait to see what I screw up this week! I read the next prompt last night, and my next game (only one this time!) will involve, “Find & click.” In the meantime, you can check out this week’s games, along with everything else I’ve made, over on my itch.io profile.

Leave a Reply

Your email address will not be published. Required fields are marked *