Games [WIP] Hovercrafts Sandbox Prototype (Postponed)

As it is linked to ECS, multithreading and optimization, I'm pretty sure it will be interesting to you.
According to this post, there will be an ECS-based imposter system asset in the future:
https://forum.unity.com/threads/released-imposter-system-optimization.426478/page-5#post-4158214

Do not buy the asset now, the author indicated that the ECS-based imposter system will be a new asset, not the current one.

 

Thanks. Yep I heave looked into it.
But for my project, impostor will be impractical, due to game's nature.
I do not need generate far distance stars, while in your case, this may be more suitable.

 

You don't have buildings, trees, or other fixed objects in your world?

 

The thing is, all is on spherical globe, where horizon distance is relatively close. It isn't the distance as of real real planet. My planets will have no more than few thousands units in diameter max. Hence perspective is changing dynamically, when travelling.

Therefore, every hill, or static structure, in most cases, will be visible, no further than few hundreds units, until horizon.

Even looking down/up from other planet, is relatively close in distance, to make impostor appealing visually. Faking perspective for close distances may be tricky. If that makes sense?

If I can see something few thousand units away, providing it is static, impostor would be very suitable. If I would decide making shift origin for planets, then that could be good application in my case. But otherwise, for now, I aim to enclose all, within distance of +-10k units limits.

 

So, if I understand well, it's a bit like if the player is a giant on a tiny planet.
Will it be possible to build a vehicle around the planet?

 

I wouldn't call a giant players, but rather small planets.
But yeah something like that.

I am just fed up with 1:1 planets in games. They bring very little to gameplay.

If technical issues wont be a limit, then yes, you could probably be able build even giant rotating ring around a 'tiny' planets.

 

I'm sure that there's a lot of possibilities for fun gameplay with tiny planets.
1:1 planets are more for games which are meant to be realistic.

That would be epic!

 

I think best analogy, would be typical RTS game, where player plays on the map, with xy size. Of course most of RTS are allocated on the 'flat maps' with few exceptions.
Populus for example was also allocated on 'tiny' spherical planet.

Sure. But as long such games are some form of, flight simulators, that's ok in my opinion. Otherwise, Walking on 1:1 realistic planet becomes boring very quick. Is just subject, how much unique features, game can provide, to make it even interesting in long term, to be more than just tech show.

Minecraft open world wins here so far, in my opinion. It provides relative uniqueness, while procedurally generated terrain; also has multiple features, which player can interact with, like digging and building, which is persistent. And all thing has a function, I.e. Farms.

That kind of stuff I would love to see, in games, with real scale planet / worlds. Some sense of adventure/challenge, to hook for many hours.

So far, I haven't experienced yet, to hook me up, for more than few hours.

Therefore, I decided go smaller scale. I am only single dev, and I have limited capabilities, to populate anything in interesting way of vast space. Even I was considering it before. Hence more arcadish style game play, on 'tiny' planets

Even if I hit some form of tech limits, while trying to overcome, I am sure, I will be able provide tons of fun in other ways.

 

There is Empyrion which is not so bad at that, while still being far too easy for now, but it's still in alpha and they very recently added limited inventory, which will make it a lot harder.
In Empyrion the size of the world matter a lot, as you may die of lack of oxygen if you go farther than your oxygen (or food) supply allow, and there are a lot of things to explore.
Unfortunately it's still not enough to be really interesting, but at least they're trying hard!

I'm sure that you'll overcome/dodge any technical limitation, and usually making things smaller is easier than making them huge, so it should be OK.

 

It is definitely interesting looking at Empyrion, as a reference point.

Briefly judging on their planet size, while still is quite large, it appears to be far much smaller than even Earth moon. Which brings players closer to the action. Some interesting concepts there tho.

 

That's true, planets aren't Earth-size, but they are still quite big (the starting one is only a medium sized-planet).
The problem is that, while there's a lot of surface, everything is boring quite fast.
They've added a lot of biomes and features to change the ambient feeling, so it takes some time to explore all biomes in all different types of planets.
But in the end, it's still a bit always the same thing.

That said, I like this game and I have spent a lot of time on it (404 hours according to Steam to compare to 3645 hours on FtD, not counting all the hours FtD off-line / dev).
Some planets really do give a creepy feeling while others feels alien without being dangerous, overall they did a good job.

And Empyrion is using Unity.

 

From what I read briefly, Empyrion indeed was apparently quite interesting.
But until very recent update, which did introduced some complexity / depth to UI system, which creeped playability.
Don't know what exactly went wrong, since I don't own game, but I think is good learning case study, to avoid same route.

 

They've added volume and weight for the inventory.
Before the player could have as many things on him as he wanted, so you could mine for hours without having to dump the rocks in a container.

Now you're limited by volume and weight, so you have to be more organized and it had to the micro-management.
But people began complaining before it's been balanced, in fact it was still disabled by default when the Steam comments began to be really negative about that.

Lesson to learn: people will complain very fast, without letting you a chance to balance the thing


That said, haven't yet tested that feature because I'm waiting for the dev to say that's balanced enough, so maybe it will ruin the gameplay, I don't know...

 

I suppose, it is difficult to experiment, once you are on steam, without being raided by cavalry of negatives.

Personally I am leaning toward game modes like Minecraft, KSP, FtD, or factorio for example, where player chooses between creative, survival, campaign, hardcore etc.

I don't want to impose mandatory mining / grinding, to get into basics gameplay.
Maybe considering some form of achievements bonuses, or so, somehow similar to FtD. I think that works well.

 

Empyrion has a creative mode, where you have access to everything in any quantity.
But the build engine is very weak compared to FtD, it's the exploration and survival which are interesting. and probably the multiplayer but I cannot say for sure as I haven't tried it.

I think that if FtD works so well in the designer, it's because building a good ship is very complex, takes dozen of hours, and you spend a lot of time testing it against potentially hundreds of already existing vehicles.
And in addition, you can see how your builds work against the builds of your friends.
All of that in the designer.


In Empyrion there's no challenge in creating a strong ship, just add more turrets/guns than your opponent and you're done.
But in Empyrion you can create buildings/vehicle way more beautiful than in FtD.
They have a decal system which allow you to place up to 2 decals on each face of each block, and you can also paint the different faces of a block with different colors, and you can even have rounded blocks.

So, you can spend hours building a beautiful large base with all the interior and exterior decorations you want. But it will not be more efficient than a small box with one equipment of each type in it...
Which means that the only challenge you have is to build that in survival, so having very limited inventory is a problem (well, I guess, I haven't tested it yet).


So, the conclusion is that you have to provide something in the gameplay which will make the game interesting in the designer.

 

Myself as well, spent tons of hours, playing mainly with designer.
I loved that aspect. Hence yes, it is important as well in my case, to ensure that I can provide equivalent features.

I do wonder however, if this is how it was planned, with current target audience, or this may change in future. In case FtD, designer was pretty much critical path, from the start. From that point game was able grow around it.

Not sure if I will be trying implement similar feature. At least not now. Other aspects are more relevant for me.
But yes, that for the cost of beauty. But I think is relatively small.

While I got some concept of making more 'beauty' like, I don't mind minecraft-ish style. At least constructing will be more familiar for audience.

I suppose you could do that in own way in FtD too. I loved making interiors in my vehicles
But again, there were very blocky like.

From what you said after the patch, my understanding / solution would be, some form of transportation / automation.
Even many RPG games like for example Witcher, had quite extensive inventory, while still with limit. But there was horse with expandable carry storage. And certain type of crafting items, had literally no storage limits.

FtD in this case is very good example.
But I am also thinking, not only form of free build, but for more stable testing, workshop, or dock. For now just a concept.

 

With some delay, as I am a bit busy recently, but I have some new update here.
Never the less, I am happy with results so far.

Testing multi shaped octree in pure ECS, based on buffer arrays, with custom made block builder in action, while physics is based on Classic OOP Unity 2018.3 physX. I am using custom ECS-OOP Tweening mechanics, based on NativeArrays. Using space, to changing shapes. Orientation of shapes changing automatically.

Place holder at mouse pointer, changes color between red and green, depending if block can be placed. Profiler is occupied mainly by debugger logging.

 

With a bit slower pace, I did finally implemented blocks neighbouring.

While 1x1x1 voxel blocks neighbouring is rather straight forward, for blocks of different dimensions is a bit more complex. After some tinkering, now appears to work well. I can traverse through blocks, for example 15 blocks left, then 7 up, then 12 forward etc.

Next thing I need to figure out, is how to script flood algorithm, for such variety size of blocks.
I got few concepts on my mind. But not entirely happy of them yet. I nee find most efficient way to "flood".

 

This is rather slower peace moving progress. But never the less progress.


Flood Algorithm WIP

I have revised few flood algorithm options.
The easiest near straight forward, as I already mentioned, is for 1x1x1 cubes.
Where getting neighbors is dead easy, with simple index offset.

I have discussed topic briefly in
3D flood mothods for variate 3D box sizes. Thoughts?

That usually requires however, some predefined grid size (flood 2D example)


https://en.wikipedia.org/wiki/A*_search_algorithm

However, I expect that each row, column, depth lengths are of dynamic sizes and can change anytime, when construction changes. Plus, the fact, I am focusing on multidimensional scaled block sizes. Not 1x1x1 only, but 3x2x1, 2x7x4 etc. Which complicates the matter of such.

For simplicity, 2D representation of multidimensional blocks scales


But anyway, after hours of tinkering and testing, I got this working eventually.
Still got some bugs to resolve, but is getting nice I think. Not yet ready to showoff. But I will when ready

The other alternative I was considering, was to create chunks of 10x10x10, of 1000 1x1x1 cubic possible allocations, and then expand structure, by adding chunks accordingly. Or remove. This solution seams suitable as well, for many applications, where constructs are not too big. I may in fact, consider make such functionality at some point.
However, This works specially, for small cubes (boxes). Now if I consider for example structure, of lets say 100 blocks of 50x5x3, that is 100 x 750 = 75 000 required 1x1x1 cubic allocations in a grid. Which can easily reach 100k or more, with empty allocated spaces. With additional data, that may be few times bigger. If I run flood algorithm through that, that whole structures, that is at minimum 75k iterations. With my approach, I can reduce to few thousands, with side checks etc. So I hope, reduce memory and CPU use, specially for bigger constructs, of mixed sizes blocks.

However, I am aware, that for smaller constructs, typical 1x1x1 grid type with chunks, may be more convenient, or even more performant. Future test will show however, where through lies indeed.

Further on, I got splitting of construct partially working. Mainly much of debugging is to do now.
So for example I split, by removing diagonally all blocks, and smaller part of construct is discarded.




Barriers revision

I have revised Barriers along systems, "collapsing" into one. I had multiple, along systems.
Also, I removed EntityCommandBuffer SetComponent in most system that were still present and replaced with GetComponentFromEntity, or GetBufferFromEntity accordingly.
Plus other improvements.
But further, I want finally to rid off of last barrier injection, and replace with its none injection counterpart.

While this hasn't been commented yet by Unity officials, since November 2018

I believe, I will follow @terlte comment

Which is inittially discussed in first quatation
Two questions about Barriers and EntityCommandBuffer


Other

Other than that, I have posted about my experience, when I did fall into a trap of floating point.
Me falling into floating point error trap.

 

Another while since last update.

This time focusing on disintegration mechanics.
Goal was, to be able remove any selected block and define, which part of the structure is disintegrated, from main voxel structure. Further each decoupled section, meant to automatically disintegrate into smaller sections, by removed random block, until no more division is possible.

In the video, I expand selected structure, by adding range of 1x1x4 blocks. I build kind of a circle. Then removing some blocks, to disintegrate separate section. As the result, new construct is generated, with falling debris, and original blocks are marked as gray, for debugging. Further when automated disintegration of debris is happening every 5 sec, gray blocks are reused as required.

To achieve current solution, I developed and tested 3 different approaches, for partitioning. First two I wasn't happy much of the result and performance. Current mechanics looks promising, but haven't stress tested it yet. I have sacrificed a bit more memory, for CPU ticks gain.

Still under heavy debugging process however, since I got few occasional issues, which I need squash, before I can move on. I must ensure, mechanics is flawless.

The major challenge is, to allow system operate with variate sizes of blocks. And additionally, with dynamically changing structure, without imposing dimensional limits. I need admit, complexity is much greater, than initially anticipated. But I am getting there. Mass of issues are resolved already.

Currently still running on PhysX, but I will be willing move to new DOTS physics, when suitable. Yet, current GameObjects allow me nicely, to manipulate and test constructs and their blocks linked with entities. So it is a bit easier to test, since entities are none clickable yet in the editor. Hence hybrid solution is convenient for the moment.


Edit:
What that mechanics opens, is possibility of making nice damage system, with falling chunks of debris. Also, with some additional code, calculating empty spaces, like rooms, tanks etc, is now feasible.

 

I managed to squash quite number of critical bugs
This following vid is similar to previous, but this time, it has much more smaller blocks (2x1x1). Around 500, which are disintegrating from base construct.

There are some vid subtitles.

Solution has been improved by far, from previous version, however still some issue has been detected, which will be fixed. In the video I show that GameObjects of construct and its blocks can not be selected via scene, but construct rigid body and blocks colliders can be selected via Hierarchy tree. However, all data and rendered mesh seats in ECS entities. Further few blocks are added and predefined construct blocks, which later is decomposed, when center connecting block is removed. Largest part stays as main construct.

Besides some logic matters, I was a bit fighting with ECS Assertion bug. But forgot, that for parallel Entity Command buffer, it requires concurrent. That solved number of issues.

 

Nothing nice to show at this point. But going through heavy debugging of disintegration system.
I test different combinations and cases, to ensure, mechanics is free of bugs. Or at least, eliminate bugs, that I am able to detect. Simply playing with adding and removing blocks and checking, if rest of constructs behaves as expected.

When issue is detected, trying to reproduce taken steps and get same bug. This often is time consuming process on its own. Hence I have developed system, which records order, in which blocks were placed and removed. Determinism in place ensures, I can have same conditions replayed many times over. That helped allot.

Then next step is, to find actual bug, or bugs. Tracking bugs is often playing simulation to n point in time and log data Then replay to n-1 point and log data. And repeat, if necessary. Writing debugging notes in workbook, helps to analyze each bug. Also, using my own Tweening mechanics, which allows me drag entities constructs (not blocks), as GameObjects, helps a tones.

Yet once found bugs, tends to be small hidden thing somewhere. Sometimes earlier forgotten part of logic. But recent major thing I was fighting with, was ECS system execution order with command buffer, and set tags. This are such pain in back side. Specially had to find out and realize, that is one source of issues.

I wanted to split mechanics into DOTS sub systems, and chain them. All appears to work, for smaller amount of blocks and debris. Yet when higher number of debris start playing, some systems were executed, before other system, even they were explicitly told, to execute in order. Major issue appear to be based, on adding and removing component tags and timing. Entity Command Buffer didn't have enough time, to update new entities with tags, before next system were executed. That was causing out of sync conditions, while certain chained system order is critical.

Since at the current state I am still on Unity 2018.3, I can not use yet certain DOTS features, which are in 2019.x that could be handy. For example replacing barrier.Update with barrier.AddJobHandleForProducer. However, I aim to use as minimum, as possible, barrier.Update and job.Complete calls, as these hold main thread, and may be forcing other jobs to wait.


In the end, I decided to reduce number of systems by few. It was handy, but helped with mechanics stability. So I moved certain systems into methods instead. That of course eliminated need, for setting some component tags. Hence that has benefits. Also, easier to jobify and burst. Seams so far works well. But need bet more cleaning after work.

Here I described my problem with more details.
Multiple System vs Methods

I haven't changed every system, but these are, which were most convenient at this point.
That still in total few thousands lines of code, per converted systems / methods.

At this point it appears, I got major bugs caught for that mechanics. But can not say for sure that all, since I just spotted another one. Seam minor, however, any bug can potentially escalate. So I need make sure, that this part is flawless.

I also expanded a bit functionality of this mechanics, while working on it and done improvements toward jobification, which helps.



So where is all complexity come from?

The biggest challenge I want to confront, is to allow constructs be build, from different size of blocks. This part itself is easy enough. The following is the devil in disguise. If construct is made of blocks 1x1x1, removing blocks in middle, results in separating part(s) of the construct. Logic for that is by itself relatively simple, since it can use flood algorithms. However, when multidimensional blocks (3x5x2 for example) comes into play, of different sizes, flood algorithm becomes more complex on its own.

Not too bad. Until setting goal, that construct should be able to expand (when constructed), in any direction. So creating fixed size grid is not really an option. The idea is, creating chunks, similarly as in minecraft. Yet much smaller, since may be, that not all blocks will be occupied. That introduced another challenge. If chunk lets say is of size 5x5x5, and block is longer than 5, or it overlaps with more than one chunk, that all need be taken into account.

While debugging DOTS/ECS entities is possible, it is a bit more complex, than just having GameObject, or class, and be able simply drill down to other classes, or components.



I think that it for now, until next one

 

Need to say, classical Object Oriented Programming has its own advantages, when comes to debugging. Is easy to track references, back to source, by drilling down classes.
Unfortunately that is not so easy with current ECS / DOTS and Data Oriented Design, where large relations hierarchies are involved.

Yet I am managing to squish bugs after bugs and I have definitely a progress. But nothing visually appealing to show of yet. And may be not for a while, since still sitting on the destruction core of blocks. Looks promising now, but not saying, I got all bugs caught yet. Some multiplies in least expected places. Just like cockroaches

However, I am hyping myself with thoughts, I found and resolved bug here and bug there.
Now I am testing and replaying to the death one particular mechanics. It can be a bit boring, but not discouraging.
So basically, I run different sequences, cases and combinations and making sure, they do function as expected.
Now once bug is discovered, I need make sure, I can replicate condition, to be able track it down. Even I have number of tools, which helps to replicate certain conditions, sometimes human factor makes a bit more difficult to test tho.
And I have created more automating and assisting tools.

 

I had nice progress past week.
I feel I cracked something significant, that I wanted for while now.
Not to say, I am done yet on destruction / disintegration system.

My current challenge is, to be able destroy / remove multiple blocks on same construct, in same frame, at the selection time. For example imagine, construct get hit by bullet, in two different areas. Or having explosion, which will destroy multiple blocks at once and then disintegrate rest of relevant part of construct.

I got concept how to approach this problem. I have refactored and adapted few other system, to be compatible with incoming mechanics. That also improved multi threading and burst compatibility. Which is big plus.
But I want to balance performance vs memory usage, while preferably execute that part of functionality in same frame. It would be easy however, to do over multiple frames. But since I delay (few ms) by design deconstruction process, I would like to avoid affecting it for simplicity.

Just on side note, deconstruction process over duration of time and generate derbies as the result, is mainly visual feature. I could destroy all relevant blocks in one system update, which is even faster performance wise. But debris looks cool

Edit:
In fact, I just realized, my current mechanics may be able support multi blocks destruction in the first frame (when selected), with small system adjustment.

 

I am quite happy with recent weeks progress.
I nailed multiple problems, and crushed few walls, I couldn't go through previously.

Tons and tons of testing and deep debugging, to hunt any bugs. Some hunting was quite tired some, specially after necessary modification I made. Some old one surely removed. But new also get born, as I have notice something new recently. Maybe because of added mechanics.

Mechanics to remove multiple blocks, like cutting off bigger chunk of construct, seams to works quite well. I had to do quite few amendments in multiple system, but that helped in code refactoring. Some removals, some additions. However another bit of streamlining was made. So generally good. Plus some cleaning of old commented codes and debug lines.

Another thing I did, was to complete task, where I had some Debug.Log with TODO. At least on these immediate bits, that I am working currently.

Now I think I will move on to Unity 2019. I expect to spend some time porting from 2018.3. There are things I am not familiar with yet in 2019 DOTS, followed by some necessary changes I need to make. Also, I would like reduce my hybrid ECS approach based on GameObjects, toward more pure ECS. This should speed up my update methods by much. Unit 2019 should help me with that. Only concerning part is, I will loose convenient debugging utility, where I can click on GameObject, to find out entity index and block / construct position. Will see. I may leave it for later.

Ah, forgetting all the time. I need fix my center of mass CoM, and mass of constructs themself, as it broke some time ago, which makes my constructs deconstruction very buggy, in terms of physics. Maybe I will leave it until 2019.x porting, and try with new DOTS physics (still beta, or even alpha).