Weekly update on progress #3

Big week; many world engine changes, closing in on alpha. Version is 0.3.1

Almost all the last week's time was dedicated to refactoring the world engine into a threaded and optimized one. The result is working perfectly and allows us to have an in-memory world big enough to stop caring about limits.

World engine optimizations

A save file of the world in the previous engine, took about 83 MB for a 256x256x128 sized world. In the new system, it's around 480 KB (variable, as it depends on terrain features). The per-block information hasn't changed much (in fact we added some flags) but the memory footprint has decreased dramatically. That is an uncompressed size too, no zip used.

What did we do to achieve that?

• We only store the "visible" part of the world now. We have traded memory for computing power here because now, each time you dig we have to generate the new visible blocks beneath. That required finding solution for keeping a kind of history so you don't generate a block which was dug/destroyed previously.
• We refactored all the internal world collections to support the new system. There are engines for "neighborhood" and "walkability"  which allow rapid detection of block statuses and changes.

The finished result is that the world's footprint will start small and grow with you. Of course, at some point you'll reach the end of the installed memory but we hope to find till then solutions for running all the game world's economy using offloaded chunks. Our target is to allow a player some months of playing the same world before getting at the limit.

Multi-threading

Because Roobuts has special requirements, this was not an easy task. Unlike other block-type games like Minecraft, the world can (and will) change at multiple points at the same time. You could have 100 robots mining/building/scanning distributed in multiple chunks and still talking to each other to make the economy work; managing the world's state in a threaded way is fun. And by fun I mean extremely complex to code and very easy to destroy with a single line.

As of now, we still have some rare dead-locked chunks and we are tracking the last bugs down.

The outcome of all this is that now we can dynamically adjust game's performance for laptops/high end desktops. You have more power? Update more chunks at the same time, if not, wait till the world catches up.

Architect view

We have also started implementing the architect view which is a secondary way of seeing the world. If you press Tab, the game is paused and you can see a pseudo-isometric view of the world in which you can place multiple dig jobs at the same time. This way, you can make plans for all of your underground fortress and when you switch back to normal mode the robots will start digging/building for you. You can still place manual dig jobs for finesse but this is the way to plan the "big world".

There are still issues with our shaders but we're getting there (I'm still learning). Also, I need to find a way to reduce the clutter in the "planned for dig" display. By the way, the red texture in the screen shot is there as a placeholder just to show the artifacts generated by my shader. In the final version, it will be still abstract but more enjoyable (we'll hide the world details because the focus is on fortress planning).

This week, our focus is on GUI

The lack of a complete working GUI is what's keeping us apart from an Alpha version. We have tried to delay this as long as possible waiting for Unity 3.5 which should have an included GUI system (the current one is not really workable for complex cases and performance). We still don't have any information about what will that system include but we can't wait anymore so we'll implement our GUI with the UIToolkit and hope we won't have to rewrite much when Unity 3.5 comes.