Okhlos is a game about an angry mob in ancient Greece. You will have to travel all around Greece and conform a very large group of angry people to fight armies, mythological creatures and even the gods themselves! Each stage will have its unique challenges based around the gods they worshipped there. You will have lots of fighting in Sparta, lots of thinking to do in Athens, and lots of partying when facing Dionysius. You get the idea. Also, each unit will have its unique set of skills, making the mob unique each time you play. There will be heroes, warriors, philosophers, slaves, and much more!
The painfully long process of making enviroments for a game.
Posted by CoffeePower on Aug 28th, 2013
I’ve been, for the last few weeks, trying to decide how we will be doing the environments of Okhlos.
This process was not pleasant, to say the least. It would normally be a cool process, prototyping, trying to decide aesthetics, profiling, etc. But with the IGF around the corner, every method I discarded, made me feel more pressured to have something definitive, and less time I had to have something nice to show.
We are planning on having two “playable” levels for the IGF, where you can have an idea of what will be the overall aesthetic, plus the core mechanic.
It all started with the buildings (I will do an update on how I managed to get the pixel art in the textures, soon).
We had some nice buildings. The main problem was that they were too historically accurate. They were damaged, filled with imperfections, and mainly made of stone. The rock texture gave the impression of something old and neglected.
Later, Sebastian pointed out that they were no fit for Delphi, as Apollo represents order, thus Delphi should have been spotless, and showing that everything is in order. I thought that changing the textures should suffice, unfortunately, it required some uv mapping changes, also removing the sprites objects in order to make everything more marble-like, and some geometry changes were in order.
That took me some time, but the result helped the general idea of the level.
Later, when we had what would be the main buildings of the levels (we could add more variation later) it was time to figure out how to put these buildings into this:
We use 2dToolkit. It’s extremely cool, fast, intuitive, yadda yadda yadda. We use it mainly for the characters and ornaments It has some tilemap functionality, but it’s not its core.
First of all, setting the map was not very intuitive, we had to upgrade the plugin, which was not that painful, but it took some time, in order to be able to have the new features specially for the tilemap editor. Finally, we figured out how to set a scale congruent with our current one.
Later, we found out that the meshes didn’t have normals, so we must generated them by code. (without normals, we wouldn’t have shadows!)
And finally, we had the problem of Y (in Unity, Z in Max). Greece was full of mounts, mountains, cliffs, and working in 2d for a map that would be 3d was not practical at all.
We could have discarded the Y, and made all the levels flat, but there was one more main problem, and that was the materials we use for the bump mapping. There was no easy way of setting the normal maps in the atlas we used for the tilemaps. And that is one of the main things I use to take some work form the textures
Unfortunately, there is no picture, as I deleted it accidentally, and it’s a long process to do it again, just for the sake of the screenshot.
I do have here what could have been the necessary tiles for making different roads.
And some tiles that could eventually end up in the final version (not in the same way probably)
Second try: Unity terrain
At first, a long shot, but it could be cool, the contrast. Eventually, mixing high poly mesh, low poly buildings, pixel art characters, was not such a good idea.
The first problem, as always, was setting parameters that would be consistent with our scale. It was not easy, and the values were extremely different.
From the aesthetic side was not good either.
I tried to export some heightmaps, making them by hand in photoshop, and later working them into Unity or Zbrush. Eventually I could set up some kind of pipeline, but it was not very efficient, as the heightmap, when exported into Unity, was not very precise.
The terrains in unity, are definitively nasty. The vertex painting part is incredible cool, but otherwise, there are just a headache, or just something quick for prototyping (if you are working in the same scale).
Before I came to this, I was really frustrated. I was searching for something consistent within the game, something beauty, and light in performance. Also fast. I wanted to do a few clicks and have something working.
Eventually, it hit me. We are making low poly buildings, for pixel art characters. The environment it has to be all low poly. And as it would be a stupid amount of work making an entire city unique, the best approach was to made it modular.
In this train of thought, I arrived to my second error. The concept (which all of you can see here!) was very vague in some areas. I didn’t figure out how all parts would fit together, and the blank spaces in which “I’ll put a mountain or something later” were really not helping to gain a big picture.
So I sat, tok the map, and did it again, now having in mind a tile size, and that each square had to be declared.
That helped me figuring out what will be the definitive layout.
As for the side of the amount of meshes, eventually, I realized what Sebastian was trying to say for a week now. It’s not time for optimization. We will have that time, but for now, we can take a few liberties. Also, the performance problems are coming from the physics side, not the rendering one.