You said that Teardown stages are created in Magicavoxel - that's not exactly true. Teardown has its own level editor, which has minimal modelling features, and then external assets can be loaded into the editor in the form of magicavoxel model files. However, the model files are authored via more than just magicavoxel - A lot of them are authored in blender and voxelized via their Voxtool, but a lot of the assets are also created in Magicavoxel. The level is then created as an arrangement of assets, as well as actual game engine tools like doors, scripting, triggers and vehicles and such.
That makes sense - I remember briefly seeing the level editor while playing it. Taking preexisting assets and voxelizing them is good, but I would love to develop a modeling workflow which is intuitive to end-users too.
This might be one the first reviews of my engine. Thanks (The nonintuitive custom grid still is work in progress havent figure out the maths for controls to feel good)
@@DouglasDwyer I'm a few months away from being able to return to voxel dev, for the moment I'll work slowly, by the way I've corrected the controls, now it's intuitive as how it should be (it just follows the camera)
There is also this neat project called "lay of the land" that could have been interesting to take a look at! also i find it hilarious that everyone here knows John Lin XD. your project is really cool I'm excited to see what can be done with it!
Really happy to see you play Terra Toy, thanks for trying it out. Looking forward to playing a game made with your engine! As for your question about how the normals are updated: whenever the user is sculpting, I recalculate the normals for the surrounding voxels as well as the newly placed voxels. It's just a very naive loop that checks all surrounding voxels for every voxel placed. It sounds slow, but works just fine for the scale of voxels in Terra Toy.
I see. I'll be focusing more on CSG-style building for my first implementation (placing cubes, spheres, etc. on a grid) but having polished sculpting would be cool too. Terra Toy really pulls off the sculpting tools well.
You and Ethan Gore are the best voxel engine devs I’ve ever seen. Ethan Gore is a 10x dev god who works on a side project whenever he wants. But you’re really motivated and don’t just give up or rewrite every 2 months which is a surprisingly useful skill.
Idk if you know but tooley1998 is also making a voxel game and his building system seems pretty good. I also find the hotbar building modes in the minecraft axiom mod to be really intuitive and useful (I haven’t really played around with the advanced menu)
It's not easy to find good pixeldev resources, so to me this video was really valuable. It's nice to hear about your inspirations and references in the scene, as well as sharing insights and your thinking around future features. I appreciate it.
I want to note, that PhysX 5 (which is open source) has features for custom collision shapes. You would only need to implement what you did last time in the context of PhysX and it will handle collision solving and everything for you. And I think PhysX is definitely one of the best physics engines out there!!
I love your work, and love this new tone of content! This videos shows a complete other light on voxel engines, where its rare to see devs interacting or reviewing each other's work. It deeply motivates me to to learn and try to be part of this community.
This is one of the best things you've done yet. This proves why you might have the best voxel engine in the world right now, because you learn from others even though you have an already amazing project. Well done, and good luck on your journey!
Hey I’m watching through some of your earlier devlogs at the moment and I’d love a playlist to binge them easier. Love the vids and keep up the great work!
So I have pondered a lot over all of these micro voxel engines with a building focus, how exactly the building mechanics would work. I had several thoughts which come to mind though. The first thing would be making use of a snap to grid system as shown in Rey's engine. Though additionally this could be expanded into a "snap to x, where x is user defined" so every Nth voxel, good for your 8x8 internal system. Secondly and probably most importantly, directly taking inspiration from the Minecraft mod tools like server edit, or the mod which allows you to look at a face and auto fill that plane face one voxel outwards. Much to take for inspiration there, watching Minecraft build videos for massive builds would be a great starting point for inspiration. Lastly, satisfactory has a very nice blueprint system, one which you can easily share with others. This would couple extremely nicely with the first suggestion of snap to x. Because users would be able to develop building blocks which could be reusable for large scale elegant projects, and after placement could be further refined by the player to create something much smoother visually. For instance the default blueprints would be, a small shack, a wall module, a floor module, a window module, a sloped roof module, and stair module, all of which I'm referencing from the game Rust, which has a building system very similar to a "snap to" system, its just more specific. If a good mix of all of these were included the nitty gritty details of a building could be built once, then constructed into a larger build, then refined with decor such as interior furnishings or exterior foliage and growth. Making building more of a 3 step process, and really only a 1 step process if a player just wants to be lazy and make use of the default building blocks.
I think a really good way to select areas is like in litemattica mod in Minecraft, you select 1st corner, then 2nd one and then you can control the 2nd corner with scrolling, if you scroll up and look in mostly positive x, it'll move it in positive x, if you look in negative x it'll move it in negative x, if you look up it'll move it up(so not exactly the direction is player looking but only cardinal directions if player is mostly looking in that direction). It gives a lot of control I think, also the ability to switch back to 1st corner to control it as well, that'd allow really precise control. About undo, I think storing the areas that were edited for a few actions back could be one way, then undo would be just changing back the area to what it was before those actions
When planning a build mode, you should have destruction in mind. For example, you go mine for ore, how does the pickaxe break block in your game? It should match how you build. One way to find what feels right is by adding a pickaxe and testing what feels right and wrong. Then add the reverse for building
Selecting and editing in both screen space and world space is a must. For undo and redo the server just needs to maintain a stack of edits for each player. This can have a depth limit. Copy and paste can be very useful, even if it is only from a selection of everything in a box. Drag a box in one plane (say X/Y) then mouse wheel (or key combo) drag in another (say Y/Z or X/Z). Many years ago I made a voxel engine. For characters I used what I call a paper doll method where I had a voxel version of naked male and female base character. You could then overlay various voxel clothing, hair, hats, even different facial expressions onto the character. You would build up the final character with layers. Each layer could replace voxels in the previous, for example the shirt layer would go below the coat layer but if the coat had a v neck collar the shirt would show in those places. Another example would be that hair would go under hats and helmets. There was a special voxel material that would effectively be invisible but could be used to mask out voxels in an underlying layer, this way, almost every hat could overlay every hair style even if the hair voxels poked through the top of the hat. Colours in the clothing pieces could be colour shifted thus, creating more variants easily by storing just a few parameters.. Using this paper doll method you could build thousands of unique looking characters. You could begin creating clothing pieces by first taking a 2D image and projecting that onto the naked base model in a particular axis. For example, the clothing piece can be drawn from the front an the back, then projected onto the naked model from the front ant the back. When projected, the naked base models were in their T pose. I then attempted to animate the base models and have the clothing also animate. More complex modes like layers, 3d Mesh imports, animation etc can come later. Good luck, love your work.
Awesome to see how different these engines can look and them getting some exposure from you! I can't imagine the amount of work that goes into making these from scratch! (why I just use Unity instead :') )
I really like the building style of the last engine. I would hope for an extra random brush on top of box and sphere. A brush where it raycasts towards the surface and deletes the top blocks with a percent chance. Stuff like that can go a long way toward adding wear and tear to objects.
I've not really used so can't actually endorse, but it does make sense to me that magica voxel would have a very good 'building' system: as an art tool it's the whole point of the program!
If I were to design a build system for a voxel game In addition to the low level tools, I would heavily lean into an itemized schematic/prefab system. I would create a blueprint editor thingy, store the data in a database, and make it searchable by tag like Table.Wooden.DiningRoomTable, Table.Wooden.Endtable I've grown used to using Unreal Engines FGameplayTag type, and its hierarchical structure really seems to me to be the logical solution to large amounts of user generated items. Voxel data is just data you can create it, separate it, and merge it however you want. It all depends on what you want to do with it.
Seems everyone in this area hoping that John Lin will return... well... we can probably only hope... That last engine looks real cool, will definetly look at it. Think would match your engine best. If I should recomend other games to check - space/medieval engineers (almost same building system) - first you have terrain tool which is not primarly on grid and second is structure/ship building, which allows you to freely put some block creating grid and next blocks are alligned with it, in medieval there is additionally possibility to put multiple things into each other - instruments of destruction - I'm not 100% terain is voxel based, but the building could be definetly used for map designing (with a little less wonky controlls)
Multi-user undo is an interesting problem. If two users make two intersecting edits, one after the other, and the first wants to undo their work, what should happen? You have to solve the user experience problem first. It probably requires non-destructive editing and multiple branches. The model used by git's branching change history would be a good place to start.
Completely agree! I don't plan on implementing anything nearly as complex as Git's branching feature. The two options I have been considering are either: - Don't allow undoing beyond any point where another user has edited nearby. If you have to undo and another user has made an edit, they need to undo their work first. - All operations for a given area are sequential, and you can undo another user's edits. The biggest thing to figure out with the system is when user edits are considered "nearby" one another. If two users are editing different parts of the terrain, they obviously should be able to work independently. I would probably aim to develop tools where users can work independently and then combine their work at the end, rather than force users to work in close proximity. That just creates extra confusion in my mind.
I might not grasp the problem correctly but maybe something like this could work: 1. Track the edits sequentiallly. The data of each edit contains what player did the edit, what blocks were edited, the new state of each block 2. If player A does an edit and creates a line in space and player B creates a line that crosses the first and replaces at least one voxel than undo should work something like this: If player B presses undo, his changes just are undone without any worry If player A presses undo first the game walks through the global list of edits into the future and checks for all voxels which have been changed by others and only undos voxels which are not touched by others. If this global edits list is 10 long and A makes a change first, then B makes 20 changes and then A tries to undo, nothing will happen. So you can only undo as long as others did not make to many changes in-between Maybe you could also save all the chunks an edit touches into the global sequential edits list. So if two edits are in completely different chunks, no checking needs to take place in case of an undo. Or maybe the other way around: each chunk has it's own "global" sequential edits list. And maybe the player has a local list with only his edits which point to the chunk edit lists. This would not fix the issue with player A and B working on the same local build and player b spamming edits until the chunk edits list is full, but at least it would localise this issue. So if a hundred players work in their own chunks the global edits list doesn't overflow
A few others have mentioned Tooley and his "Lay of the Land" but I'll second that. Definitely the most impressive voxel based building system I've seen by far. ua-cam.com/video/XjCSY5x_EQw/v-deo.htmlsi=2P8aiTHAthx3iU6s If that link doesn't work the video is titled "Finally added building to my voxel game" or something like that
Whould be cool if you made so there are diffrent shapes that you can place and then when you hold ctrl or something it snaps it to a controllable grid, or even rotated grid!
To do undo couldn't you log the modification inputs into a database along with who did the input and when. And then to undo you just query the last input in the database from that user. And then when the session ends you clear the database of all entries from that user. Obviously you still need a way to figure out what the opposite of an input is but I assume that something you would be able to figure out I guess.
I'm working on my own game, nothing related to voxels, and it's not even 3D, but I was curious whether you have some insights on how to deal with physics in a networking context. How did you deal with this in your engine? Especially considering user input, where you want an immediate response for character movement.
Great question! Currently, all objects are simulated on the server, and then their positions are sent to the client. The one exception to this is the player. The player's position is controlled locally on the client (so movement feels responsive) and sent to the server.
there should be no different between voxel and triangle game engines, ie same thing, triangles should behave like voxels and voxel should behave like triangles, and rasterization should be like ray tracing and ray tracing should be like rasterization. well triangles form a surface. just have a minimal movement tolerance for the physics objects. then when that limit is reached, they stop moving. put in a player-undo, not global undo.
Why is it so hard for these small-voxel engines to end up as a finished product? To my eyes they seem superior that I would have thought tris/textures would have died out. But really I can only think of Noita (made by the literal inventor of 'Falling Sand') and Teardown that actually have delivered to the broader community. Isotopia maybe if it ever comes out. But seriously, even notch shelved his small-voxel project that he was working on. It seems to be a doom on the creators of such engines.
(This comment is by someone that's only made Twine/Bitsy joke games) My idea comes in how voxels in their very nature are quite granular and quickly become complex to grasp. One can compare this to for how simulation-y games like Noita and Rain World are, are still limited to the 2D plane (even if entities actually use skeletal animation). Triangles and 3D polygons are still almost simple, but there's many reasons why 1-5 people can't create at Ubisoft-scale. Even the smaller 'realistic' games have many compromises/creative decisions to be completed, such as BeamNG starting from a previously open source game to become a paid game that (IIRC) sells their physics to car manufacturers. Same deal with how Bohemia keeps the ARMA series going with actual military contracts.
This does make me curious as what would've happened if Jagex was more hands-off with Ace of Spades and didn't try attempt to turn the game into TF2. Would the devs have kept with Voxlap into the commercial release?
It was such a massive disappointment to find out that Teardown didn't bother putting in structure physics (in a game about destruction) when the engine fully supports it and the whole building system is clearly a rushed afterthought.
seems like you have no clue what to do with your engine.. lol.. i have quite a few ideas for game concepts in voxel engines. i build a shitty version myself once. maybe wen can talk. im from germany. if this mutates to the 20th minecraft clone i can tell you the project is dead in no time.
![Coding rigid body physics for voxels [Voxel Devlog #20]](http://i.ytimg.com/vi/byP6cA71Cgw/mqdefault.jpg)
![Coding rigid body physics for voxels [Voxel Devlog #20]](/img/tr.png)
You said that Teardown stages are created in Magicavoxel - that's not exactly true. Teardown has its own level editor, which has minimal modelling features, and then external assets can be loaded into the editor in the form of magicavoxel model files. However, the model files are authored via more than just magicavoxel - A lot of them are authored in blender and voxelized via their Voxtool, but a lot of the assets are also created in Magicavoxel. The level is then created as an arrangement of assets, as well as actual game engine tools like doors, scripting, triggers and vehicles and such.
That makes sense - I remember briefly seeing the level editor while playing it. Taking preexisting assets and voxelizing them is good, but I would love to develop a modeling workflow which is intuitive to end-users too.
🤓
@@fabulousfox9057shut up mr “my opinions matter”
also, many assets are procedurally generated via Lua scripts
for example trees, bricks, and some terrain
This might be one the first reviews of my engine. Thanks
(The nonintuitive custom grid still is work in progress havent figure out the maths for controls to feel good)
I hope you continue to work on it!
@@DouglasDwyer I'm a few months away from being able to return to voxel dev, for the moment I'll work slowly, by the way I've corrected the controls, now it's intuitive as how it should be (it just follows the camera)
There is also this neat project called "lay of the land" that could have been interesting to take a look at! also i find it hilarious that everyone here knows John Lin XD.
your project is really cool I'm excited to see what can be done with it!
Really happy to see you play Terra Toy, thanks for trying it out. Looking forward to playing a game made with your engine!
As for your question about how the normals are updated: whenever the user is sculpting, I recalculate the normals for the surrounding voxels as well as the newly placed voxels. It's just a very naive loop that checks all surrounding voxels for every voxel placed. It sounds slow, but works just fine for the scale of voxels in Terra Toy.
I see. I'll be focusing more on CSG-style building for my first implementation (placing cubes, spheres, etc. on a grid) but having polished sculpting would be cool too. Terra Toy really pulls off the sculpting tools well.
Man John Lin was the goat of voxels where did he disappear. His engine looks surreal.
He disappeared to do 'AI' shit
Quite the fall from grace
@@ThylineTheGay source?
@@TheDroidsb He made one blog post about ai a year ago lol
but yea, he hasn't really posted much anywhere in the last 2 years
@@theneonbop ah I missed have missed that one. Sad. I was scouring the internet trying to see what he was doing now 😂
insanely tragic
You and Ethan Gore are the best voxel engine devs I’ve ever seen.
Ethan Gore is a 10x dev god who works on a side project whenever he wants.
But you’re really motivated and don’t just give up or rewrite every 2 months which is a surprisingly useful skill.
I was just about to tell him about ethan gore
gotta watch John Lin's voxel game, i doubt it'll ever be completed, but still, its the best.
Idk if you know but tooley1998 is also making a voxel game and his building system seems pretty good.
I also find the hotbar building modes in the minecraft axiom mod to be really intuitive and useful (I haven’t really played around with the advanced menu)
Ah the Minecraft Axiom mod! I was looking for that but couldn't remember what it was called.
It's not easy to find good pixeldev resources, so to me this video was really valuable. It's nice to hear about your inspirations and references in the scene, as well as sharing insights and your thinking around future features. I appreciate it.
Thanks for watching :)
John Lin's unnamed engine, Gavan Woolery's Voxel Quest, Ken Silverman's Voxlap.
I want to note, that PhysX 5 (which is open source) has features for custom collision shapes. You would only need to implement what you did last time in the context of PhysX and it will handle collision solving and everything for you. And I think PhysX is definitely one of the best physics engines out there!!
I love your work, and love this new tone of content! This videos shows a complete other light on voxel engines, where its rare to see devs interacting or reviewing each other's work. It deeply motivates me to to learn and try to be part of this community.
This is one of the best things you've done yet. This proves why you might have the best voxel engine in the world right now, because you learn from others even though you have an already amazing project. Well done, and good luck on your journey!
10:17 Good point, you seem to know what you're doing!
Hey I’m watching through some of your earlier devlogs at the moment and I’d love a playlist to binge them easier. Love the vids and keep up the great work!
So I have pondered a lot over all of these micro voxel engines with a building focus, how exactly the building mechanics would work.
I had several thoughts which come to mind though.
The first thing would be making use of a snap to grid system as shown in Rey's engine. Though additionally this could be expanded into a "snap to x, where x is user defined" so every Nth voxel, good for your 8x8 internal system.
Secondly and probably most importantly, directly taking inspiration from the Minecraft mod tools like server edit, or the mod which allows you to look at a face and auto fill that plane face one voxel outwards. Much to take for inspiration there, watching Minecraft build videos for massive builds would be a great starting point for inspiration.
Lastly, satisfactory has a very nice blueprint system, one which you can easily share with others. This would couple extremely nicely with the first suggestion of snap to x. Because users would be able to develop building blocks which could be reusable for large scale elegant projects, and after placement could be further refined by the player to create something much smoother visually. For instance the default blueprints would be, a small shack, a wall module, a floor module, a window module, a sloped roof module, and stair module, all of which I'm referencing from the game Rust, which has a building system very similar to a "snap to" system, its just more specific.
If a good mix of all of these were included the nitty gritty details of a building could be built once, then constructed into a larger build, then refined with decor such as interior furnishings or exterior foliage and growth. Making building more of a 3 step process, and really only a 1 step process if a player just wants to be lazy and make use of the default building blocks.
I think a really good way to select areas is like in litemattica mod in Minecraft, you select 1st corner, then 2nd one and then you can control the 2nd corner with scrolling, if you scroll up and look in mostly positive x, it'll move it in positive x, if you look in negative x it'll move it in negative x, if you look up it'll move it up(so not exactly the direction is player looking but only cardinal directions if player is mostly looking in that direction). It gives a lot of control I think, also the ability to switch back to 1st corner to control it as well, that'd allow really precise control.
About undo, I think storing the areas that were edited for a few actions back could be one way, then undo would be just changing back the area to what it was before those actions
When planning a build mode, you should have destruction in mind.
For example, you go mine for ore, how does the pickaxe break block in your game? It should match how you build.
One way to find what feels right is by adding a pickaxe and testing what feels right and wrong. Then add the reverse for building
this kind of video is really cool ! i like it a lot, can't wait for more in the future, i def know other voxel engines worth checking out
Selecting and editing in both screen space and world space is a must.
For undo and redo the server just needs to maintain a stack of edits for each player. This can have a depth limit.
Copy and paste can be very useful, even if it is only from a selection of everything in a box. Drag a box in one plane (say X/Y) then mouse wheel (or key combo) drag in another (say Y/Z or X/Z).
Many years ago I made a voxel engine. For characters I used what I call a paper doll method where I had a voxel version of naked male and female base character. You could then overlay various voxel clothing, hair, hats, even different facial expressions onto the character. You would build up the final character with layers. Each layer could replace voxels in the previous, for example the shirt layer would go below the coat layer but if the coat had a v neck collar the shirt would show in those places. Another example would be that hair would go under hats and helmets. There was a special voxel material that would effectively be invisible but could be used to mask out voxels in an underlying layer, this way, almost every hat could overlay every hair style even if the hair voxels poked through the top of the hat. Colours in the clothing pieces could be colour shifted thus, creating more variants easily by storing just a few parameters.. Using this paper doll method you could build thousands of unique looking characters. You could begin creating clothing pieces by first taking a 2D image and projecting that onto the naked base model in a particular axis. For example, the clothing piece can be drawn from the front an the back, then projected onto the naked model from the front ant the back. When projected, the naked base models were in their T pose. I then attempted to animate the base models and have the clothing also animate.
More complex modes like layers, 3d Mesh imports, animation etc can come later.
Good luck, love your work.
Awesome to see how different these engines can look and them getting some exposure from you!
I can't imagine the amount of work that goes into making these from scratch! (why I just use Unity instead :') )
Haha it's amazing what you've been able to pull off in Unity! Keep up the good work, yourself :)
I really like the building style of the last engine. I would hope for an extra random brush on top of box and sphere. A brush where it raycasts towards the surface and deletes the top blocks with a percent chance. Stuff like that can go a long way toward adding wear and tear to objects.
I've not really used so can't actually endorse, but it does make sense to me that magica voxel would have a very good 'building' system: as an art tool it's the whole point of the program!
you need to play teardown again. the mods made by the community are insane.
I think the lighting in teardown is also very impressive! It looks so good and still runs well. Will you also do some volumetric lighting?
Yes, I think volumetrics would be a nice effect to add.
If I were to design a build system for a voxel game In addition to the low level tools, I would heavily lean into an itemized schematic/prefab system. I would create a blueprint editor thingy, store the data in a database, and make it searchable by tag like Table.Wooden.DiningRoomTable, Table.Wooden.Endtable
I've grown used to using Unreal Engines FGameplayTag type, and its hierarchical structure really seems to me to be the logical solution to large amounts of user generated items.
Voxel data is just data you can create it, separate it, and merge it however you want. It all depends on what you want to do with it.
pt 2 reviewing the other engines people have suggested?
Yeah, there are lots of other engines out there to try!
Seems everyone in this area hoping that John Lin will return... well... we can probably only hope...
That last engine looks real cool, will definetly look at it. Think would match your engine best.
If I should recomend other games to check
- space/medieval engineers (almost same building system) - first you have terrain tool which is not primarly on grid and second is structure/ship building, which allows you to freely put some block creating grid and next blocks are alligned with it, in medieval there is additionally possibility to put multiple things into each other
- instruments of destruction - I'm not 100% terain is voxel based, but the building could be definetly used for map designing (with a little less wonky controlls)
9:55 minecraft do you know tech mods or infection mods.
Multi-user undo is an interesting problem. If two users make two intersecting edits, one after the other, and the first wants to undo their work, what should happen? You have to solve the user experience problem first. It probably requires non-destructive editing and multiple branches. The model used by git's branching change history would be a good place to start.
Completely agree! I don't plan on implementing anything nearly as complex as Git's branching feature. The two options I have been considering are either:
- Don't allow undoing beyond any point where another user has edited nearby. If you have to undo and another user has made an edit, they need to undo their work first.
- All operations for a given area are sequential, and you can undo another user's edits.
The biggest thing to figure out with the system is when user edits are considered "nearby" one another. If two users are editing different parts of the terrain, they obviously should be able to work independently.
I would probably aim to develop tools where users can work independently and then combine their work at the end, rather than force users to work in close proximity. That just creates extra confusion in my mind.
I might not grasp the problem correctly but maybe something like this could work:
1. Track the edits sequentiallly. The data of each edit contains what player did the edit, what blocks were edited, the new state of each block
2. If player A does an edit and creates a line in space and player B creates a line that crosses the first and replaces at least one voxel than undo should work something like this:
If player B presses undo, his changes just are undone without any worry
If player A presses undo first the game walks through the global list of edits into the future and checks for all voxels which have been changed by others and only undos voxels which are not touched by others.
If this global edits list is 10 long and A makes a change first, then B makes 20 changes and then A tries to undo, nothing will happen. So you can only undo as long as others did not make to many changes in-between
Maybe you could also save all the chunks an edit touches into the global sequential edits list. So if two edits are in completely different chunks, no checking needs to take place in case of an undo.
Or maybe the other way around: each chunk has it's own "global" sequential edits list. And maybe the player has a local list with only his edits which point to the chunk edit lists.
This would not fix the issue with player A and B working on the same local build and player b spamming edits until the chunk edits list is full, but at least it would localise this issue. So if a hundred players work in their own chunks the global edits list doesn't overflow
@@DouglasDwyer You could try to look at how the minecraft worldedit plugin handles this stuff, the multi user undo is a pretty intuitive one in that
lets go
A few others have mentioned Tooley and his "Lay of the Land" but I'll second that. Definitely the most impressive voxel based building system I've seen by far.
ua-cam.com/video/XjCSY5x_EQw/v-deo.htmlsi=2P8aiTHAthx3iU6s
If that link doesn't work the video is titled "Finally added building to my voxel game" or something like that
"Lay the land" game?
That one has proper building integrated
Try "Lay of the land" the building mode it's close to Ray´s voxel engine.
Whould be cool if you made so there are diffrent shapes that you can place and then when you hold ctrl or something it snaps it to a controllable grid, or even rotated grid!
To do undo couldn't you log the modification inputs into a database along with who did the input and when. And then to undo you just query the last input in the database from that user. And then when the session ends you clear the database of all entries from that user.
Obviously you still need a way to figure out what the opposite of an input is but I assume that something you would be able to figure out I guess.
Good suggestion!
you should check out lay of the land! it’s a great voxel game that’s being worked on at the moment
You didn’t look at Teardowns built in level editor
I'm working on my own game, nothing related to voxels, and it's not even 3D, but I was curious whether you have some insights on how to deal with physics in a networking context. How did you deal with this in your engine? Especially considering user input, where you want an immediate response for character movement.
Great question! Currently, all objects are simulated on the server, and then their positions are sent to the client. The one exception to this is the player. The player's position is controlled locally on the client (so movement feels responsive) and sent to the server.
john lin mentioned (day ruined (pls come back :c))
Sehr schön 👍
Thanks!
Mentioned John Lin
there should be no different between voxel and triangle game engines, ie same thing, triangles should behave like voxels and voxel should behave like triangles, and rasterization should be like ray tracing and ray tracing should be like rasterization. well triangles form a surface. just have a minimal movement tolerance for the physics objects. then when that limit is reached, they stop moving. put in a player-undo, not global undo.
How the fuck does terraworld create a globe from voxels?
Why is it so hard for these small-voxel engines to end up as a finished product? To my eyes they seem superior that I would have thought tris/textures would have died out. But really I can only think of Noita (made by the literal inventor of 'Falling Sand') and Teardown that actually have delivered to the broader community. Isotopia maybe if it ever comes out. But seriously, even notch shelved his small-voxel project that he was working on. It seems to be a doom on the creators of such engines.
(This comment is by someone that's only made Twine/Bitsy joke games) My idea comes in how voxels in their very nature are quite granular and quickly become complex to grasp. One can compare this to for how simulation-y games like Noita and Rain World are, are still limited to the 2D plane (even if entities actually use skeletal animation). Triangles and 3D polygons are still almost simple, but there's many reasons why 1-5 people can't create at Ubisoft-scale. Even the smaller 'realistic' games have many compromises/creative decisions to be completed, such as BeamNG starting from a previously open source game to become a paid game that (IIRC) sells their physics to car manufacturers. Same deal with how Bohemia keeps the ARMA series going with actual military contracts.
This does make me curious as what would've happened if Jagex was more hands-off with Ace of Spades and didn't try attempt to turn the game into TF2. Would the devs have kept with Voxlap into the commercial release?
It was such a massive disappointment to find out that Teardown didn't bother putting in structure physics (in a game about destruction) when the engine fully supports it and the whole building system is clearly a rushed afterthought.
seems like you have no clue what to do with your engine.. lol.. i have quite a few ideas for game concepts in voxel engines. i build a shitty version myself once. maybe wen can talk. im from germany. if this mutates to the 20th minecraft clone i can tell you the project is dead in no time.
Fortnite (seriously)