Westdude

I’ve recently gone through my old games - student projects, game jam submissions, raw prototypes - in a mission to collect it all together in one place before it’s too late. In doing so, I’ve looked at them with a fresh pair of eyes and couldn’t resist to ask myself - what have those little projects taught me about making games? This article sums up the little gems I’ve found among them. Have a good read!

Lesson 1 — Consistency In Repetition

From the development of Nordic Trolling

Nordic Trolling

Games from that time were far from being masterpieces. Sometimes they weren’t even good! But with each attempt, with each lesson learned, we were getting better and better. We showed up each time to do this average work, made an average game, and moved on to the next one. The consistency in repetition was slowly shifting our games from mediocrity to decency.

In hindsight, Nordic Trolling was just another average game jam project. But, at the same time, it was the next average step to making better games in the future.

Lesson 2 — Prototype the Unknowns

From the development of Grocery Clash (Prototype)

Grocery Clash prototype

Prototype early. I cannot stress this enough. Look for the biggest unknown and make it the first thing to test. Mitigate the risk. Cut corners wherever it’s possible. Don’t over-engineer. Find your ways to do it quickly. Maybe choose different engines, make mockups, fake the features, make it on paper, show only a video of how you play, hack the code, or be a narrator and voice-over of missing features. There are many options, choose what suits you! Remember, the prototype is going to be thrown in the trash anyway, so don’t push it.

In the case of Grocery Clash, we were about to make a game on our own tech, so checking the gameplay beforehand was a crucial step — it would take months to see the game in action otherwise. I made a quick test in Unity, tweaked the systems and we could enter making the proper version with much bigger confidence. A small prototype done in one week prevented us from failing six months later.

Please, make prototypes.

Lesson 3 — Put It Out There

From the development of Project SANTA

Project SANTA

Show your work. Collect feedback. Put the project out there. It’s scary, it might be painful, you might hear that your family game looks like a nazi camp. But it’s worth the trouble. There is no better way to learn what works than to test your assumptions against people. Especially experienced ones.

Project SANTA was one of these games that we have really put out there. Competitions, expos, mentorship programmes — I’ve just submitted it everywhere I could. It was the first bigger game I made, so getting candid feedback, often from game industry veterans, was a real game changer for me.

Lesson 4 — Embrace the Creative Fog

From the development of Grocery Clash

Grocery Clash

In the development of every game, there are times when you feel hopeless. Everything is broken, the finish line seems to be so far away that you cannot imagine that it’s possible to get there. You’re like a tiny ship on a stormy, foggy day seeking desperately for a small piece of a dry land. But the land is there. Just stick to your compass.

Making Grocery Clash on our own tech left us having no gameplay for most of the development time. Having two colliding carrots on a black screen felt like a huge victory. Keep going forward despite having almost nothing led us to game that we were eventually really proud of.

Lesson 5 — Watch Your Scope

From the development of Red in the Woods

Red in the Woods

I LOVE being over-optimistic. Dream what can be done like nothing can stop us — nor budget, time, or resources. Generating thousands of ideas on the spot and reaching the capacities of human excitement. I love it. It gives the enthusiasm to keep pushing and the courage to take risks.

But the time for reflection, for the rational mind, is also necessary. Pause from time to time and ask yourself: “Do I need it? Is it the right direction? What are the unknowns? How can I get the smallest and the simplest possible piece of gameplay to test? “. For me, a cyclical switch between “the dreamer” and “the rationalist” works best.

But, when making Red in the Woods I apparently wasn’t aware of that. This game rather consists of “the dreamer “ and “the inpatient”. I wanted to do a play-with-the-shadows Heroes of Might & Magic 3 game during 72 game jam hours. We started, got slapped in the face after a few hours and felt offended by the possibility of defeat and left the project half-done. Good times!

Lesson 6 — Write It Down

From the development of Get Me Out Of Here

Get Me Out Of Here

Before starting to do the work, imagine it. What does the game look like? What are the mechanics? What is the core of the experience? The idea is cool, but can I create more than five minutes of interesting content? More than one level?

So many times, I had this ‘perfect idea’ when I went straight to the engine, only to discard it when the actual implementation started. And often, if a feature needs to stay in the game for some reason, you don’t have the time and energy to do it all over again, so you stick to a not-so-fun solution.

Of course, nothing is better than actually playing something, and I’m not talking about creating a huge document upfront either. But many ideas can be crossed out during the ideation phase if you spend just 10 more minutes thinking about the exact details, minute-to-minute gameplay.

Get Me Out Of Here was the first game for which I conducted such an analysis. I spent some time imagining it holistically, considering every angle of the game before writing any line of code.

Lesson  7 — Innovation Through Ignorance

From the development of Westdude

Westude

Sometimes not knowing the standards can lead to innovation. You don’t know what people have done before you, you’re not biased of what is “right”, “wrong”, “easy” or “impossible”. You just do what you feel, bringing analogies from other genres or fields, accidentally questioning the status quo. That’s why, it is often said, that the best teams consist of a combination of juniors and seniors, where juniors bring the “outside of the box” thinking and seniors are there to catch them if they fall.

When guys at SUPERHOT told me to make a game in their internal ASCII framework, there wasn’t any wiki or demo project to look for. I took what I thought was a standard and accidently made a narrative game with full screen animations, never seen before in the ASCII world of SUPERHOT.That’s all for today! I hope some of those lessons will prove useful for you too. Lessons from later games are yet to be discovered so the topic may pop again in the near future.

What are your golden nuggets from your early game