First devlog entry
Technical changesData handlingTo support the split screen on an open world I had to rewrite most of the block data handling. Previously everything was stored in one three dimensional array and chunks were removed from this array and added if you moved around the map. If you have a second camera they both must share the data which does not work if one camera goes to the left and one to the right. So now I'm using custom containers and iterators. Iterating is bit slower but some things are faster like loading new chunks. A new chunk can now just be added to a list. With a 3d array I moved chunks of data inside the array.
CVar SystemI had some messaging system from which I could enter „cheats“. I extended this into a more proper in-game console. You can modify and read some variables which is very handy for development but also can be useful tool for the user. For example you can modify the the game speed or change the color of the fog during runtime.
I will extend this to have game, world and save specific cvars.
Small video of auto suggestion featureNormal map renderingBecause all the assets are pre-rendered in 3D we could generate normal maps. At the moment the light engine only supports two global light sources: the moon and the sun. It looks very beautiful because we can put as many details as we want. However the art style of the game is still some low-poly. Maybe you have seen a youtube video of some game engine doing this. However he has dropped the work of it because texture sizes were too big. Wurfel Engine solves the problem by using tiles.
Also the world is only shaded by diffuse light which is faster because no specular map is needed and diffuse light can be calculated with only one dot product. This is some nice coincidence of the art style and the algorithms working so well together.
In future I want to upload some local light sources via uniform to the shaders. But I guess there will some performance issues if there are too many of them. I’m still new to this topic so I have to take an extended look at this at a later time. Before that I will implement local light sources via the vertex color like I did in WE v1.3. I think this feature is a must have because during night you want to have some light somewhere.
Sound engineI added some sound engine which at the moment handles only the volume of the sounds based on the position. It needs some tweaking though. Using libGDX I am a bit limited by the interfaces. I have to do some research on how to access OpenAL directly for adding some special effects and filters later in beta.
I would be very happy to hear your feedback, share knowledge and answer your questions.
No feedback yet
Second progress update
Adding Save Slots and Improving the Data FormatHow to Implement an Open World with Real Time ActorsRecently I found a fundamental flaw in the connection of my game design and the possible technical implementation. What if you want to have mine carts and robots working autonomously all over the map which is theoretically limitless in size? At this time I was only storing nine chunks around the player character in memory where stuff could actually happen.
I found three ways do solve this:
- Have the complete map in memory -> limit map size
- Have everything in memory where something is happening.
- Change the game design
First I started implementing the first solution but I dropped my work on this because it’s more limiting then the second solution.
The second solution sounds like it needs a lot of performance and memory. However I found a way to change the way Wurfel Engine handles the data.
It needed a new data format. Now I’m storing every block with only three bytes. Consisting of the id, a sub-id, which I call ‘value’ and the health of each block.
The old way was to have one object for rendering and game logic. So even if blocks were not visible they contained many information not relevant for the game logic. Also each block managed itself in the normal OOP way. Now a table is used for a lookup which id and value par has which properties. Also I dropped the update call for each block in memory.
Currently the default chunk size is 10*40*10 blocks which means there are 4000 blocks in each chunk. At 3 bytes for each block + 8 bytes object overhead (source) (=11 byte/block) 44,000 bytes are stored for each chunk which means each chunk is using 43 KibiByte.
With 200 MB I can now store ca. 4,500 chunks which is like 45 km in each direction which equals like 2025 km^2 which is
almost two times the size of Hong Kong.
So if data is needed it is loaded and being kept until a memory limit is exceeded.
Nice side effect is that there are less allocations of memory which are often a bottleneck and once a chunk is loaded I can keep it in memory. Also the amount of file reading is limited to once per chunk which helps keeping the frame rate stable.
To keep having things like animations the visible chunks are stored as a kind of duplicate as in the old way as dynamic objects with all the data they need.
Working on the clipping again also fixed some bug, black spots appearing if you played in split screen, which made it even into the alpha launch trailer :D
Adding Save SlotsThe new save format copies chunks from the root folder in a sub folder. The sub folder then works as previously. I changed the user interface of the main menu and added the option to select a save slot. It is not very nice looking but will be improved some day.
I also updated the CVar system (console variables) allowing strings to be used. They will replace the map meta data file soon.
Next UpdateNext update will likely have little gameplay changes or additions however this update lays the foundation for much and proper working content.
There are still some bugs related to the fundamental changes and once the game runs with at least the same features as before I will release the next update.
Community
