#voxelengine

[behindstarsandunderhills]

To showcase the game in Poznan to people not speaking/reading English that well, we prepared a simpler demo by changing the temple level to a single quest level.

[reiti-net]

Working on Saving/Loading

In the last video I actually showed the newly farming feature and also let the agents build a house by only using orders (the supposed way to do it). I've also felt the current lights look a bit odd and decided to rapidly code some fire and light jitter as well

Most of this is actually mocking up a new feature, making it work and then followed by some days refactoring smaller or larger parts of the engine to get better performance or readability (ideally both, but that's not always possible here)

Anyway - I am currently tackling the cumbersome approach of "saving the gamestate" - yes I could just use binary serialization and use one of the benefits of .Net .. but honestly - I fear it will be to slow and the result would be just too big files. I also may be adding some sort of different saving approaches (in terms of speed for loading/unloading inactive but modified chunks, etc) - so I jumped the train and did a fully manual(!) approach of saving/loading the current game state.

This engine is a bit different from regular voxel engines - being mainly for building games. So there is a lot of references handed around over several threads and - oh boy - this is not funny to code a serialization for :-)

At least I am currently at a spot where saving loading basically works and I am just searching/fixing several bugs which appear during testing. There is no video for that, because there is basically nothing to show with loading/saving (it's one of those things, everyone expects to just be there).

As soon as this is in a complete state, I really want to push production chains, like chopping a tree to get wood (already working), making planks and using planks to make a chair (for example).

[reiti-net]

Alright - so some weeks ago I stumbled over mutliple performance issues, which basically dropped the framerate heavily to a point where I didn’t consider it to be playable. It was frustrating and I put it away for some time.

After some time I decided to displace some code into an externall native c++ DLL to speed things related to noise generation up - this worked a bit but I also had to do a lot of result chaching in order to really eliminate that bottleneck.

The engine now also works with 4 concurrent threads to do several things asyncronoulsy, like path finding, order/job handling and such things - which brought HUGE problems in terms of syncronizing and weird errors which were hard to find the initial issue for. Most work on this engine is heavily related to performance, this really is the main work.

Regular “locking” will just not work out, as it’s slowing down everything up to a point where the framedrops get noticeable, so what the engine actually does is working a lot with chaches multiple objects and syncrinizing those on demand from the threads themselves.

Anyway - I think the basic thing in zoning/logistics is done in the engine. Agent’s are able to get a job/order assigned an able to fulfill whatever they are supposed to do - there are still some problems and hickups in terms of “unexpected behaviour” of the agents but they will be tackled when they arise

I did another Progress Video, which is mainly related to zoning and order/job fulfillment. The engine can (chained) issue jobs/orders and add/remove zones and building tasks now, what do you think?

[atmikez]

DreamZEngine v.0.0.2 - Landscape Generation Test

[atmikez]

DreamZEngine v.0.0.8

[atmikez]

DreamZEngine v.0.0.4 (W.i.P)