One year ago we started the development of slyceverse. During this time we learned quiet a lot about game development.
It's time to take a look at what we have learned so far and what this means for the future development.
Technology
It was a really fun and interesting experience writing a game framework while discovering DirectX and shaders.
2 Months ago we realized that this approach is really good for learning and understanding the underlying concepts. But it also had a big downside: We had to reinvent and build so many things, like mesh importers, networking, storage, animation, physics interaction and sound. This was quiet a big task for a team as small as and time constraint as ours.
We needed to cut some development time by using a game engine that supplied us with standard implementations. This would allow us to focus on the game concepts and mechanics.
This is why we evaluated Unity3D and decided to use it. Unity offers a wide range of ready-to-use components, an asset store, multi-platform support and most importantly we can use our favorite programming language c#.
Game Concepts and Mechanics
We also decided to take a look at some of the game concepts and mechanics.
So what are our big goals?
- Procedural generated rich game world that is fun to explore
- Share the experience with others
- The ability to shape the world
Shaping the world
Shaping the world means to interact with the environment by removing or adding volume to it. Thus creating mountains, slopes or caves.
Our current approach involves voxel based terrains that we transform into iso-surfaces via the marching cubes algorithm.
Let me explain what this means:
- creating voxel volumes
- compressing and storing of voxel volumes
- manipulation of voxel volumes
- managing of voxel volumes
- iso-surface generation (mesh generation)
- lod-level iso-surface generation
This approach uses a lot of CPU time, RAM and storage space. We need to store not only the voxel volume but also the generated meshes (for performance). And when we add more detail layers, like shadows, grass and decals we have even more data to process and manage.
Our voxels have density, material, light and additional attributes. And most importantly we cannot tell if a voxel is visible by only looking at the voxel itself. Only after iso-surface generation we know where the surface will be.
This problem doesn't exist in a world like Minecraft, where every voxel is represented by a cube.
The big downside of using voxels for terrain representation is that we have to store a lot of information that we rarely need. All those chunks full of stone, wood, sand and air. And even with storage solutions like sparse octrees or compression there is a lot of overhead from managing those voxels.
A mountain in the distance consists of many voxels that we have to create, manage and store. Even when the player will never visit or manipulate it.
Is there a way around this?
- Do we really need to store that a mountain consists of vast amounts of stone?
- Could we somehow interpolate it and thus reduce the required storage space and RAM?
- Would the player mind an interpolation when the result feels good and is nice to look at?
- Do we really need to store all the voxel data and generate the iso-surface from it?
- Could we manipulate the mesh directly? Is this more CPU hungry than a Marching Cubes?
- Are there other methods that produce satisfying results?
- Generally how can we reduce the amount of stored and managed data necessary for the world and player?
We set some requirements for the terrain generation and representation to help us find different solutions:
- The initial iso-surface creation of the terrain in sight should not take more than 30 seconds.
- (Small) Changes to the environment should take effect immediately.
- The needed RAM should be under 1 GB.
Currently we are thinking about these questions and trying some ideas. We don't know where this will lead us. But it will be fun to find out :-)
World generation
Our goal is to create a world that will be generated each time you start a new game. The player should be able to tinker with the generation process. For example what kind of landmasses, climate and biosphere.
The world should be fun to play and interesting to explore. Different landscapes, moods, creatures, plants and weather.
Populate the world with creatures, plants and landmarks.
Later on evolve creatures to sentient beeings and simulate the creation of gods, cities and civilizations. And on top of that create some quests. I think this bit will take us some extra time :-)
The Future
We will need some time to get these questions sorted out and familiarize us with the Unity framework. Then we need to port some of the code-base to Unity or rebuild it from scratch to take advantage of the new framework.
Hope you stay with us…
Until we meet again in the Slyceverse!
