This is the second article in a series about the story and technical details of Goblin Quest: Escape!. If you’d like to support us on Steam Greenlight, you can find our page here: Botbiteindustries.com
This post is about the evolution of the game, the iterations in graphics and technology we’ve done over the course of development.
Where we started
When first discussing the game, Matt had brought some concepts with him. His idea was a reverse-tower-defense: a game where you’re one of the many faceless enemies in a horde trying to reach the end of the base. Each map would be a maze of sorts, with towers shooting at you and traps trying to kill you. At the end of each map, you would reach a tower and throw a bomb at it.
We liked the idea and started prototyping and working on it immediately.
Soon someone had the idea to turn the game into 3D. This seemed simple at the time – afterall, Unity supports 3D development and the game is simple enough to not cause too many issues. Looking back, the move to 3D seems a little unnecessary, especially because the final iteration of the game brought back a lot of the 2D feel and aestethics. However moving to 3D had an unexpected benefit that came out during late development: by tweaking lights and creating lightmaps we could create beautiful, eerie atmospheric dungeons using the tools we have. Doing that in 2D would have been way too much work.
Game evolution in 2:50
The simplest way to display how our game evolved is to show it on video! Unfortunately I couldn’t find the original 2D prototype, so the following video displays different stages of development of the 3D game.
Tiles in 3D – a lot of work
You may notice a lot of large and small changes in the video. One of the main graphical changes during development was going from a terrain-based map to an underground dungeon theme. This had a technical reason. You see, to simplify map editing, we’ve worked with a tile-based map editor. The issue with 3D tiles is that they don’t really work with rounded corners – specifically our problem was that we’d have to create a LOT of variations for each corner to be able to fit any element next to any other. We didn’t want to spend time and money on creating lots of variations of these simple elements. Instead, Matt had the idea to move to a block-based system. He came up with the dungeon theme, that fits both the game’s style and our technical requirements.
The basic building block is now a simple cube tile. Each side of the tile can have a random modification. These tiles can be automatically fitted together, with unnecessary elements (inward-facing walls, overlapping columns, etc.) removed. This system worked perfectly for us as it allowed for automating this part of the map creation process. This tile-based system and the map editor itself will be presented in the next article.
Mobile or not?
Part of the game’s evolution was slowly moving from mobile to console targets. There are some people on Greenlight who feel very passionately negative about mobile games, and I completely understand their reasons. The mobile markets have become a terrible amalgamation of clones, free2play cash grabs and just all-out bad, uninspired, shitty games.
On the other hand, there were and are some indie gems that targeted mobile. Just look at games like Monument Valley or 80 days.
Our game started out as a mobile game. Remember, this was in 2012, when (while already filled with cow-clickers) the mobile markets were a little different than today, less saturated. For example, one of my favorite mobile games, PewPew had become a small success. It had a core gameplay somewhat similar to our idea (even though the presentation was completely different). Another similar game that was a smaller success is Only One.
So we started making a mobile game that:
- is controlled with a (virtual) joystick
- is content-based with a storyline and a small-ish number of short but challenging maps
- allows for organic player progression through a simple economy system similar to RPGs
- is developed and tested on a PC with a gamepad
- has a button-based ability system with a maximum of 4 active abilities (at a time)
- has detailed graphics with high-end lighting
Only in the final stages of development did we realise that instead of making a mobile game we actually made… a console game. There was no good application of microtransactions in the game, it wasn’t nearly casual enough for mobile players and is generally not overly simple to control on a touchscreen. It does however look and play amazingly well on a large screen with a game controller. This is why our first and possibly most successful release was on consoles (OUYA, Fire TV) and this is why we’re trying to get on Steam.
What’s next
Again, thanks for reading the article, hope you enjoyed it!
In the next post we will get more technical and take a detailed look at the editor created for the game.
And again, if you wish to support us on Greenlight, the link is: Botbiteindustries.com
