reiti.net DevLog

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).

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

Looks like I finally ended up with something which does work not so bad. I am using an asyncronous runnign "Job Manager" which basically cares for assigning jobs to idle agents. To do there is some job queue for manually issued jobs and if this is empty, the Job Manager queries different zones, if they have job to do.

A stockpile is such a zone, and if queried it will determine if there are any ressources lying around which need to be hauled and if so, they will generate a job which is then assigned to the next idle agent. This should basically keep the queue of "open jobs" relatively small. There is several object locking and caching arrays involved for everything to work well with the renderer and keeping the impact on the framerate as low as possible, but under some circumstances (i.e. a fully locked in agent) will still clog everything up a bit. I do need to make a lot of compromisses between object locking and performance and was quite busy with a lot of bugs evolving around that. In the video some of those bugs a re still visible but most of them are already fixed.

Another issue with this system currently is, that the items in the world (which ressources are) are currently a "global list" together with partioned references for them on every chunk. While this has benefits in some situations I am not enterily sure if this will be viable in a highly populated world and so this may change to a fully partioned system with the drawback of having any lookups being slower in some cases.

Current tests with a lot of agents worked out pretty well, beside the fact, the more agents are assigned a job, the longer it will take until everyone has finished it's pathfinding, but there is no way around it and with complexer environments this will slow down even further.

In the current system, there are sort of Job-Chains. So each job can basically have follow-up-jobs defined during creation of the job itself. This is in order to lock/reserve any involved resources. In the example of hauling, the stockpile creates a job, reserves a space for it and locks the item on the map. An agent will now have the order to pick up that item and a follow up job, to drop down the item to a specific spot.

Problems arises, when such a job chain needs to be canceled for whatever reason (agent died, way blocked) as now the full chain needs to be processed in order to free up any reserved spots or items. With follow up items that is pretty straight forward, but there may be situations where this is not enough. Need to see if it's sustainable.

Currently tinkering with the new job-system. Works pretty well now asyncroncously.

The current idea is, that jobs are done in the order of issuing by the nearest agent. When a job can’t be reached yet, it goes to the end of the queue. Basically ok, but with a slight problem. When marking a bigger field to dig out, the order becomes a bit chaotic when I would expect the agent would pick up the next nearest job instead of the next job in the queue.

Building stuff in my engine during testing is actually quite enjoyable .. lot’s of ideas for making a builder game out of it .. let’s see where this will go .. 

With the missing corner piece and the reworked world generation (now able to make ramps) the generated voxel world looks actually pretty cool!

some may argue that this is a cool thing .. well, it’s not if you want to spare method calls. In C++ you would just use a macro to inline repeating chunks of code without having to waste a method call.

This may be no issue for general application development but it is a crucial for high iteration stuff, like I do in my geometry creation code.

Funny enough, there is this thing called “T4″, which is basically able to generate code at design time. It can include other files, so what I did is basically split the repeating parts in distinct .txt files and put the whole geo class in a T4 template. Whenever I need a repeating pattern, I just include the according txt file and T4 generates my big class out of it - with as less method calls as possible but still readable code and less stuff to type. yeah!

Working on a new Blocktype (inverted ramp corners) .. so much possibilities! But today I just remembered, that the water simulation has to adapt to the ramp blocks as well - so there is quite a bit of work in front of me to make that “waterproof” again :-)

So this is my post here at tumblr - just checking out if I can/should/would use this as my regular platform for posting updates on my current developing progress on some interesting stuff.

I am currently working on my own Voxel Engine and the latest (big change) was actually removing the baked-AO and replacing it with SSAO. The main reason for this was actually, that I wont to have other block forms in the engine and not only cubes. With cubes alone I was favoring a baked-AO approach before, but with new blocks I had to sack it and replace that visually with SSAO.

It was kind of stressing and I still have some weird issues in the whole shader which I need to fix, but in the end I am pretty satisfied with the current look an may add more blocktypes in the future.

I have to admit, that I already had lot of fun building the following scene - which is promising :-)

other features already in this engine are water simulation, per-block-lighting, day/night cycle, pathfinding, procedural trees (with ingame editor) and lots of other stuff. I enjoy tinkering with this, so stay tuned