New game in development!

After recovering from the haze that was CoBots development, we’re back with a new game, Mechropolis! It’s a first person action puzzle game set in what’s the remnants of a lost civilization. The only remaining sign of life are small rusty robots going about their business, long after whoever built has gone.

You need to overcome challenges by throwing them (the robots, that is) together to create new ones that will help you traverse the environment and overcome challenges. I made our first development log to show off how it works:

I’ve mainly focused on the level design so far and it’s coming along really nicely. The process we’re doing consists of me doing the basic level geometry in Unity using the ProBuilder plugin, this allows for quick creation of somewhat complex geometry, much like in the old days of the Radiant and Hammer editors, which is what I’m used too. It allows you to create a whole range customizable simple shapes, which can then be manipulated into basically anything.

Mechropolis_Cavern_1

After the greyboxing and layouting was finished, I started refining and preparing the level for detailing. An example of this are the rock walls seen in the screenshot above, they’re all pretty much flat throughout the entire cavern but have a whole bunch of vertices that can just be manipulated to give it that rock:y look (as on the right side in the screenshot).

Something I learnt a long time ago when doing similar work Radiant years ago was that you should have all terrain pieces of uniform resolution, this makes it a whole lot easier to stitch the different terrains together. Not stitching together them precisely is just a recipe for failure, you’ll have light leaks and the collision might be off causing characters to get stuck, not to mention how bad it’ll look.

The screenshots below shows 2 different pieces of terrain coming together, with all vertices along the edge lined up to avoid the problems listed above.

UnityTerrain

It can be tempting to do higher resolution terrains but in my experience it’s a whole load more pain than gain. When doing large scale manipulations it’s a hassle to deal with the amount of vertices that higher resolution produce and beyond a certain point the extra detail is negligible to the look.

I settled on 1 vertex per 3 meters as it’s a good middle ground, could have probably gotten away with lower resolution on the large walls but as there are intricate details on some parts (the ramp visible to the upper left for example) that need to be stitched together it’s just better to go with the same resolution overall.

Of course, there are times when you really need to transition between terrain resolution, but I try to keep these places far enough from the play-area so player(s) won’t notice any eventual flaws. As in the screenshot below:

UnityTerrain2

I’ve also coded a system for handling puzzles in their entirety (triggers, managers, and parts) but that’s the topic for a whole other post.