spicylobstergames / astratomic Goto Github PK

Particles are really helpful, and game changer for visuals.

Some of the code implementation is already on the code base, but commented out, I still did not figure out the specifics to make it behave alright.

• #35

• #34

• #36

• Add lava

• Dirt

• Stone

Add some spans to major functions to track where we can improve on performance.
Resource: https://github.com/bevyengine/bevy/blob/main/docs/profiling.md#adding-your-own-spans

Thermodynamic simulation will be awesome! So that we can have rocks melt, water freeze, etc
We probably want to add #52 first

We already have most of the functionality done, we just gotta figure out how to make the rigidbodies not go inside walls.
Also have to keep in mind how we are gonna make it work on a controller.

Maybe this could be on the tool and not a separate item? 🤔

Right now the debug mode is turned off and on with a comment, that's not practical. We should add a flag for the debug mode.
We should also add some egui for turning on/off debug systems, changing simulation parameters, a FPS reader and a proper "brush" tool.

Could maybe be split up into ‘basic lighting’ and ‘fancy lighting’.

Prior art:

• FallingSandEngine lighting shaders: lighting_prep.comp/lighting_propagate.comp/chunk_light.frag
• FancyLighting-Terraria
• 2D global illumination with radiance cascades at ~0.3 ms per frame
• https://github.com/zaycev/bevy-magic-light-2d

This would allow us to use a reference sprite, and for each pixel on the sprite we would spawn a atom on the world corresponding to the pixel position, that way we can have some pretty cool "interactable" pre made textures.
After #33 is closed we can add this.

Hey,
I would like to add this game to SpicyLauncher! 🦞
For that, it would be nice to start creating releases (and automating them).
Is there any plans regarding that? I would be happy to help with the automated releases.

https://github.com/Zac8668/democritus/blob/2f4e1bf5b0387b8dbcd72d3937ea77fdcc5615d9/src/grid.rs#L163-L165

When you use rayon to do a par_iter(), you don't actually need to spawn any threads yourself, because rayon automatically runs your for_each() closure on it's own thread pool.

Spawning threads actually takes some time, because it has to start a new OS process, so what rayon does is create one thread for every CPU core that you have, and then it re-uses those threads to do all of it's work, automatically running your code on it's pre-created threads, so that you don't have to think about it.

The par_iter() won't return until all the jobs are finished, either, so that removes the need to wait for any thread handles or anything like that. That's what's nifty about rayon, you hardly have to think about the threads, you just change iter to par_iter for the most part.

PS: I'm going to be looking at doing the direct write to GPU textures, so I'll have to change this code in a PR if I get to it, so you may not want to change it right away.

Courtesy of @PieKing1215 :

when I was working on my falling sand stuff I set it up so each atom had a physics state (solid/powder/liquid/gas) separate from the material (dirt/stone/gold/etc)
so you could have atoms of solid gold or liquid gold or powder gold or whatever other combo
then you could set it up so the material has properties for melting/freezing/boiling point, friction, density, viscosity, etc that affect how it behaves in different physics states

just an alternate way to think about it vs making different materials for each state

I guess the downside though is that if there's some combination of state/material that you want to be unobtainable (say liquid grass) it'd still be representable.
so you'd have to depend on runtime behavior/tests to make it unobtainable (eg. make melting point be Option where None means can't melt, or something)

Add a background atom layer where solids would be able to be placed. This would be useful to add some background walls to your house, cool mining mechanics, etc.
What's up for discussion is if solids would need or not a background atom to be able to support themselves, this would allow for more realistic behavior but maybe it would be a bit annoying. If a solid is in the world but without a background atom behind it, we could make it behave like a powder with 1.0 inertial resistance, so it would only fall down and not to the sides.

This means we would also need a toggle on the tool precision mode, between the background and normal layer.

A cool mechanic that this can add is to make rare ores to be most commonly found on the background layer, that way your 2d vision can't help you, you would have to dig the normal layer to uncover the background layer to find the ores.

Not sure how this would impact performance, but I think not much, as the background layer would not need to update, just render itself.

This is almost completely done with #62
We just need to make only chunks with rigidbodies to add rapier2d colliders.

Hello!

First off: thanks for sharing your awesome work publicly!

To be able to contribute or take inspiration what is missing is a license though.

Would you be so kind and add one?

Thanks and happy new year!

This would allow us to add liquids that flow differently, like lava.

The current implementation has it's flaws, mainly this:

For now it kinda tells how hard it is to collapse to sand like, but it shouldn't form those types of "sand structures" at all.

@grunnt who made falling-rust wrote this great post on how to achieve organic plant growth:

https://www.basvs.dev/blog/falling-rust-plants/

This seems useful both in the process of procedurally generated levels as well as for real-time simulation of rapid-growth plans.

Add something similar to the inertial resistance of powders/movable solids detailed on this video.

We can't have a flat world forever.

Sometimes the dirty render rect does not update properly, I suspect is a system ordering problem, if I open the game sometimes it updates perfectly, if I close and open again it may or may not update properly.

I hope you @zicklag have an idea on how to fix this? You implemented it(by the way, thank you!) and to be honest I don't understand 100% how it works.

Here's it working perfectly:
Screencast from 2023-12-29 23-15-57.webm

Here's when it does not update properly:
Screencast from 2023-12-29 23-17-05.webm

To be clear, both videos are from the same binary.

I suspect the problem is in the last lines of the chunk_manager.rs file, there's also some after(..... methods I added there in hope to fix it but it didn't, those can be removed.

The tool currently just sucks and shoots atoms in a "messy" way.
But to support some better terrain control we need to add a precision mode. With it you would be able to place the atoms in a square and/or circle shape, and also remove atoms in the same shape, allowing the placement of solids that do not move.

To be able to make this work we probably have to refactor how our actors work.
Not sure if I can make rapier2d apply forces with the current "discrete" movement actors have.

Since this is already a very mathy, physics-driven game, maybe the characters themselves could lean into that as well. The animation system that comes to mind is that of Rain World:

https://www.youtube.com/watch?v=sVntwsrjNe4

This style of procedural animation lends itself very well to a falling-sand environment, since it’s designed to flow along uneven terrain rather than getting easily blocked by unevenness the way standard character controllers do.

It’s a more advanced method, but art-wise it’s probably cheaper because it relies far less on custom character animations for various actions. They could still be quite humanoid as well, just a bit more stretchy/squishy. Basically a pixelated version of Gang Beasts / Party Animals.

This approach can also have implications on the AI of NPCs, as explained in Rain World’s notion of AI behavior (locomotion) == animation.

This probably happens when a atom gets out of its chunk neighboring, we just need to limit how far a atom can go each frame, probably setting a universal speed limit for atoms would be the way to go.

Particles need some improvement. Mainly for finding a place to put themselves, for now if they are surrounded they just go up without any organic place finding.
They also just ignore Object atoms, we probably need them to filter certain Object atoms so that we can have some kind of collider filter.

This is important for #21

We could probably use the savefile crate to do this.

Instead of gluing the camera onto the player, the camera should follow him smoothly.

Right now the rigidbody sprites are rotated in a simple manner, but rotating them with a proper sprite rotating algorithm would give us some better visuals and also better colliders.

Some insights are on the description of this video: https://youtu.be/UbOacNip9u8

Add a way to unload far chunks to the world file, and load close chunks from the same.

Add Rigidbodies made of atoms that can interact with the world and also be simulated.
We could use Rapier2d for this, similar to what Noita and PieKing's engine do, or try a new approach with XPBD.

• #65
• #66
• #68
• #67

run cago run:

error:

WARN bevy_pbr::ssao: ScreenSpaceAmbientOcclusionPlugin not loaded. GPU lacks support: TextureFormat::R16Float does not support TextureUsages::STORAGE_BINDING.
...
thread 'Compute Task Pool (0)' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { kind: UnexpectedEof, message: "failed to fill whole buffer" })', src/chunk_manager.rs:181:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `astratomic::chunk_manager::manager_setup`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!

kernel: 5.15.77-amd64-desktop
rust:rustc 1.72.0 (5680fa18f 2023-08-23)

What causes it and how to fix it? Is it because there is no graphics card?

run target/debug/astratomic：

...
WARN bevy_pbr::ssao: ScreenSpaceAmbientOcclusionPlugin not loaded. GPU lacks support: TextureFormat::R16Float does not support TextureUsages::STORAGE_BINDING.
ERROR bevy_asset::server: path not found: /home/astratomic/astratomic-0.2.0/target/debug/assets/atoms.ron
...
thread 'Compute Task Pool (2)' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { kind: UnexpectedEof, message: "failed to fill whole buffer" })', src/chunk_manager.rs:181:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `astratomic::chunk_manager::manager_setup`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!

This is almost completely done with #62
The way we do this is by getting each atom from the rotated sprite before the simulation step, for each one that is not empty we put a Object atom just to have collision.

The rotated sprite still doesn't match sometimes with the Object atoms for some reason. Pretty rare, we can fix it later if it becomes a problem.

Imminently

• #8
• #41
• #33
• #21
• #28
• #22
• #58

Later

• Port engine to Bones for modding & multiplayer capabilities.

• #18
• #19