Dev Story - How we started with Inked

As you all patiently wait for the relaunch of Inked, I want to start sharing a few dev stories (or just late dev logs) on my thoughts behind creating Inked - why and how we created this game and why it matters to us. Hopefully, it will allow you to understand why we wanted to take the time to re-work this game, and it might also be interesting to those who are interested in game design.

Initial development and release

We first got a chance to make the game in 2017, even though the game started development almost a year before that.

Back in 2016, during Casual Connect Europe, we presented an arcade game which was a small side project, and another main project - a psychological horror game. Witnessing several other games that had similar scope, but bigger teams and better funding, we ended up thinking about whether the project was even doable. We realized that we need something that is simpler to make, but something that can catch the eye of the players. I pitched a few months old idea about a hand-drawn samurai fighting against the artist who drew him, with the goal of getting his love back from the said artist. The rest of the team jumped at this idea, and a decision was made there and then to scrap the horror game and make Inked.

About a month later we started working on the game, and after only two weeks we had a very simple “proof of concept” prototype, just in time for the Reboot Develop conference.

Screenshots from the first prototype of Inked in 2016

We expected only some raw feedback, but in turn actually got more than a few very positive comments and even a nomination at the conference competition, which completely cemented our resolve to make this game.

Later that year at the Reboot Infogamer fair, we pitched the game, and after a few months, we signed a publishing deal for Inked with Starbreeze. This allowed us to open a company, and expand the team with actual artists, which opened up huge new visual possibilities for the game. It gave us time to really think about what we want with the game, and since it was our first big project, we understandably got excited, if not even carried away in certain aspects.

Screenshot from the late 2016 build of Inked

While we never felt that we were doing anything wrong, in retrospect we scoped out a bit. We had an initial vision of the game, but putting more and new cool stuff in the game was so much fun, and felt so right. After 9 months of development, Inked was ready for release, and it released to mostly positive reviews holding 80% on Steam, and 67% on Metacritic (at the time of writing).

Screenshot from the 2018 release version of Inked

The reviewers and players praised the visuals, the music and many liked the concept and how it all fits together, but there were negatives. People primarily had problems with controls and punishing platforming/timed sections, which were so big for some it took away from any positives the game had - even if they found them really good. Some also found the story too confusing, the pacing too slow, and some puzzles too repetitive.

And in typical game designer fashion, everything suddenly became so clear, the blinkers were off and I knew everything that went wrong with the design. The only problem was - the game was already out.

Game designers and whole teams get tunnel vision while working on a game, it’s just the way of the world. But constantly broadening your view and reassessing the game is a skil l that you simply get with experience. When we shipped the game, we were aware of some shortcomings, but we were genuinely proud of what we made, and we did our best.

The first takeaway for any game designer reading this is a simple reminder that you should often try to imagine that whatever you are working on is getting shipped tomorrow. Now obviously, disregarding any features that aren’t in, take a good hard look at the stuff that is in and ask yourself some objective design questions.

For Inked these should have been: Is the game pace tight enough? Did we make some basic/core mechanic just good enough so that we could get to the good stuff (and then neglect that basic mechanic)? Even if something was there “from the start” is it still important?

Bottom line is, don’t just question the new things that you introduce to the game - either standalone or how they relate to the old things. Reassess everything.

Of course, even if you do realize you could have done something different/better sometimes the problems simply can’t be helped, and you have to stop sometime, because game development (more so than any other art form) is afflicted with fixed timelines and budgets - but that doesn’t mean you should disregard those realizations.

They can eat away at you, sure, but they can also train your mind to think better for the next project - or in our case - these realizations can be used on the same game just a few years later.