Archive for the paleo Category

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!


I wasn’t planning to spend my weekend hacking. Then Maarten said, “Hey, let’s enter Ludum Dare“.

Ludum Dare is a game-writing challenge. A theme is given on Friday, and you need to submit a finished game, incorporating that theme, 72 hours later.

This time, the topic was “ancient technology”. That didn’t really inspire me right away. I didn’t want to make a game about some pseudoscientific pyramid nonsense, nor did I want to make some SimCity or Civilization clone with buildings and a technology tree.

paleoThen we thought, what if we embraced the limits of ancient technology rather than their advances? Let’s go all the way back to the very first technology: stone tools. We wouldn’t even include the basic building block of 4X games: the building. We’d make a pure hunter-gatherer sim, set a hundred thousand years ago, in the Paleolithic.

Life among hunter-gatherers isn’t about building or farming for the future: it’s all about getting enough calories today.

What did Paleolithic people eat? Well, if you don’t know yourself, you probably have a Paleo Diet friend who will be excited to cave-man-splain that to you: they ate meat, berries, seafood, and no grain or processed foods, they’re poison, man. When I thought about that, I realized that that was the touch of self-referential anachronism that I wanted for our game: our actual Paleolithic tribe would succeed or fail based on how well it follows the Paleo Diet.

Obviously there are no processed foods in the cave man era, so your cave folk can’t accidentally eat a whole box of Oreos (as I have several times during game development). And there wasn’t grain, in the modern sense, before agriculture. But apparently Paleolithic people ate grass, and it was poison, man.

So that’s the kernel of the game. You control a tribe. Eat a balanced diet, avoiding grass (which is highly available), gathering berries (less available), and hunting meat (scarce, and sometimes dangerous). Try to survive the scarcity of the winter. Team up to hunt the mighty wooly mammoth, and your food troubles will be over, one way or another.

Want to try it? Sign up for the beta! Be the first on your block to be killed by an elk!

PALEO: Hunt and Gather BETA Sign-Up