Archive for January, 2017

We had high hopes for 2016; first year in business; we were going to release a game, and then we didn’t. PALEO: Hunt and Gather was supposed to be released by the end of 2016, but currently we are still working to release the beta. Our first goal after the Ludum Dare was to fix any of the bugs found by players, make it a mobile game, and deepen the gameplay a bit. The bug fixing was easy, the porting to mobile was meh (UIs are the devil), but the last one is where a month sprint, turned into three months of new features, internal play testing, more new features, more play testing…you get the picture. So here are some the lessons we’ve learned in 2016.

Lesson 1: If you are still working on core gameplay, Graphics and UI don’t matter!

We spent weeks fine-tuning UI dialog boxes, only to scrap that specific feature after play testing revealed it wasn’t really fun. Now, caveat, neither Paul or I are designers, which can be frustrating if you can envision what it should look like, but executing on that vision is not in your wheelhouse. The solution to this is wireframes. Look at the functionality you are trying to build, and sketch out the required actions. Don’t worry about positioning or what the buttons should look like. Code the core functionality and once you have a final design, you can write the UI code in one go.

Lesson 2: Code smell is okay, especially if you are new to the software or framework you are using

We’ve made some prototypes (some more finished than others), but this is our first real Unity game. You are going to look at code you wrote a month (or maybe a week) ago and think: I need to refactor this. This is okay if the change is small, but refactoring core parts of your gameplay when you are still working on extending/changing it is not an efficient use of your time. We had multiple situations where the refactor had to be refactored to make room for new functionality. Premature optimization is the root of all evil, so instead, write comments in your code with refactor suggestions. Once you are ready to get started, you will already have a list of places to work on.

Lesson 3: Smaller is better

This should come as no surprise, but you really want to keep scope small. Less features means faster iterations, and faster results. If you are planning an epic saga as your first game, I would suggest you make some mini-games first, maybe do a game jam. It’s easy to underestimate how much work it is to build something. Every new feature has the chance to break the balance in the game, meaning your early play test results might no longer be valid. We have a laundry list of features for PALEO that we pushed to V2/V3/Vx because it’s not core, and not within scope for the first release.

Lesson 4: At some point you are going to hate your game, don’t give up!

Once you get into fine tuning, or when you are working on stupid UI code (you might have noticed I hate UI), you are going to look at your game and think this is stupid, and no-one is going to play it. Take a breather. Remember all the moments you were playing your game where you lost track of time just testing a feature because the game was fun. You are probably dreading something (probably UI code) and don’t want to work on it (UI code). Try to simplify the task in front of you, and break it down into smaller chunks. Turning one todo item into ten might look like more work, but the joy of finishing a task will actually increase your productivity (Questwood Studio Guarantee)!

Lesson 5: Show your game to friends and family

Showing an unfinished game to anyone gives me major anxiety, but I still do it. Seeing someone interact with your game (even when they are doing it all wrong) will inspire and motivate you. Make sure you listen to feedback, don’t dismiss anything! Some of the great improvements we made with PALEO were done based on feedback from friends. Not everyone will like your game (especially if they are not in your target audience), but that doesn’t mean their suggestions can’t be useful. Always think about Lesson 3 though, don’t implement features just because someone asked for it. In the end, this is your game, and your vision, so make sure you stay true to that.

Lesson 6: Take care of yourself, and have fun!

Yes it is fun to work 16 hour days if you are super excited about something, but your body is not made for it. If you are doing part-time game dev and you are working at night, please make sure to get enough sleep. Write down what you were planning to do, and then work on it the next day. You might think of the solution right when you wake up, or when you are in the shower, or in the line for coffee. Don’t burn yourself out! Working insane hours and “crushing it” might look great to the people around you, but it will slowly take its toll. There’s no reward for working more hours than someone else, don’t get caught up in the hype. Make sure you hydrate, eat responsibly, and if you can work out, or walk around (easier if you live in a walkable area), do it!

 Happy New Year!