The Long Journey: What we had some time ago

We slightly changed the name of the game. Now it is called the "Shquarkz: Meatrified!" and I had designed the first version of it's logo. I have some time at the moment to tell you a little about the development history and show some related screenshots.

Shquarkz: Meatrified logo.

At the beginning we decided to create dedicated cells filled with asteroids which are combined of the atomic elements which are called blocks. We thought that it would be enough for the first time. So we've created three base classes - the "Cell" - a dedicated cubic 3d location in a space, the "Asteroid" - a chunk combined of smallest elements which could exist in the game universe, and the "Block" - exactly that smallest element. On practice this process wasn't so simple and we spent some time on coding, adjusting and optimizing our code. So we got some sort of basic geometry without graphics, not to speak of audio or physics engines.

After that we had started to develop algorithms for universe generation, so we thought about the graphics engine. It is required to see real objects not to mention their existance looking at the hexadecimal numbers in the debugger. We decided to use the OGRE graphics rendering engine, because I had used it before. As the visual part for blocks we used 3d models created in a 3d modeling software.


Simple 8-vertex cubes.	Jammed cubes as bone blocks.


Some experiments at the first stages.	Bones' blocks look like bones.

      As every other game that is in the development stage, the "Shquarkz" game is changing - we're adding new elements, adjusting gameplay and game objects design to get more or less finished image at a certain stage. That's because like a professional game developer could say: "you can't finish a game, you can only release it at a certain development stage". We are getting a lot of new ideas every day which are being filtered and screened and then being added or not added into the game. Anyway we aren't planning anything as development stages and we aren't using any project documentation at the moment. I can't say it's good, but it suits us. Every day we're creating new code or replacing old code pieces with new ones, more optimized and fast. We are searching, studying and using non-standard technologies such as fast dense hash-maps from Google, which perform operations 10-15 times faster than STL maps. We have replaced standard maps with Google maps lately and we got great speed boost during the world generation and saving (7 seconds instead of 20 using maximal asteroid size that is acceptable for OGRE).

      Now let's return to the development history. I want to note that all our cell geometry that is used in the project scene representation is integral and moreover we are using bit-arrays as a storage for the most of required data. A block has 64 bits, which are used for position (3 coordinates), type and flags. Flags are used to determine how the block should be processed. An asteroid also has 64 bits for all its data, and they include its position, orientation quaternion, its biome type and additional flags. 8-byte numbers which we're using to represent blocks and asteroids data allow us to save on a memory. It's RAM when we are creating objects or reading them from the file and it's hard drive space when we're saving our universe into files.

      The geometry system and world generation algorythms worked fast enough. But graphics part that used separate blocks didn't provide us good speed and asteroids size during the rendering process, because tens of thousands and even hundreds of thousands blocks were created at the same time. You can calculate easily that a dense asteroid (an asteroid without hollows) with a just 100 units radius contains much more than 4 millions separate blocks. OGRE and any other graphics engine and any modern CPU\GPU can't render so much triangles (about 48 millions for 6-sided cubes) with somewhat reasonable FPS.

      We improved the generation algorithm, to detect surface blocks and leave only them visible. Such step provided us with some rendering speed boost but it was not enough. We had experiments with the OGRE's static geometry, paging landscape manager, adjusting it for 3d objects and 3d space "pages". But nothing of that gave us expected and desired results. Then we had decided to use the procedural geometry. I had spent some time studying the OGRE's documentation, then I wrote new code (it was really bulky) that could create objects which you can see a bit lower.