Path Of The Indie — Rebuilding The Prototype

CEO of Rummy Games creating Saturated Outer Space proceeds to share his experience with other independent developers

Greetings!

For newcomers here is the first post about me and reasons why these articles might interest you.

Disclaimer: I’m not going to tell you how to make video games properly. Instead, I am sharing my personal experience and training while managing an indie team following the Path.

The Experiment is the Experiment!
Arkady Strugatsky and Boris Strugatsky, ‘The Doomed City’

In the 5th episode of these series I mentioned the role of our first build in the overall development. Well, it’s safe to say that Rummy Games wouldn’t have existed without it.

Just a short reminder. Back in 2018, the Developer & Founder of our game took a course Management Of Game Projects (increasingly popular in Russia & CIS region) in HSBI. The graduate project was to create your own video game and pitch it to gamedev experts. That’s where the game was born. The very first version was built on Unity. And only he knows what’s happened to it. After graduation he knew that it wasn’t enough so he started to learn blueprints in Unreal Engine having 4 years of experience in Unity.

He spent almost 8 months moving all his work from Unity to Unreal making adjustments and improvements along the way. In February 2019 the prototype powered by Unreal Engine was shown to the Producer who decided to create a study case from it. That’s how our team was created. This was our first step on the Indie’s Path.

We were all fond of the Sci-Fi setting so we started to add the narrative and other features. At a glance it seemed impossible to turn this prototype into a real game right after our first showcase in May 2019. We tried hard to fix the bugs but when one was fixed the other two appeared.

When our programmers who had joined us in Summer 2019 looked at all those ‘blueprint spaghetti’ and sentenced their diagnosis right away: “that’s not going to work at all”.

It’s important to understand though that a game prototype doesn’t have to work perfectly or be optimized and completely free of bugs. Not yet aware of it we wanted more than this build could ever provide.

Autumn was coming and new Game events as well. We decided to reanimate our blueprint build — added new colors, a new level and an experimental UI. With all that done we went to the showcase. That build remained with us till December 2019 and we are currently polishing new architecture.

The reason was the lack of time and part-time format. It’s not easy to create a new build especially when you have only the ‘how NOT to’ as a reference.

Thanks to our Producer we got invited to one of the podcasts where we could show our old build barely alive. It got even worse by that moment — experiments with inventory made navigation go nuts, some NPC and squad members began to run towards zero coordinates.

As a result, we received tons of recommendations on ‘what to fix’. The most relevant was ‘add the game, pls’. There was no fun in the prototype. And ‘no fun’ means ‘no game’.

After the podcast we unanimously decided to abandon that ugly ‘Frankenstein’ and concentrate all our efforts to develop a better version.

In Spring 2020 came the isolation and lots of unmissable game conferences in online format. We used again our ‘frozen’ build. In July we applied for the Unreal Engine Contest where we successfully passed two eliminatory stages to our own surprise.

However, getting into finals with our build seemed unlikely. So right before the ending of semi-finals stage we decided again to raise the previous prototype ‘for the last time’.

There are two main gameplay activities in the game: rescuing missions and preparation for missions a.k.a. Life on Ship. During the last summer we had been completely redesigning the second part of core loop and had implemented it in our build. In addition, we changed the UI, improved visuals, turn-based tactics and temporarily removed non-functional stuff. We promised to ourselves that’s the last time we were distracted by the old build.

Even with appealing visuals, two in-game cutscenes, reworked UI, core loop and other minor changes we didn’t get to the finals of the Contest. Audience and judges wanted to see the ‘game’.

As for the new build with no ‘blueprint spaghetti’, we are planning to release it in February 2021. Right now we’re working on a tile movement system, certain mechanics (i.e. deep interaction with HNPC like healing/escorting/covering from fire), lighting, color, VFX effects and other features. Before implementing a new mechanic we prototype it using blueprints, test them in the present build and then make a clean copy in C++.

* * *

This part covers the time from February 2019 to October 2020.

The moral of the story:
In our case it took one prototype to assemble a team around it, participate in dozens of game events and competitions, create game documentation, announce the game on Steam. That build moved us really forward on the way to MVP.

A high-quality build is your best friend in development and promotion when you don’t have financial support. It’s better to have a build as soon as possible and keep it updated regularly.

Prototype doesn’t have to be perfect — it just has to be.

Build can be used in the release version of your game for testing different mechanics and features. It’s easier to remake into a clean copy than write code from scratch.