GPU computed physics based remake of Scorched Earth

Ground and tanks, buildings and projectiles - everything is and will be made of this particle based matter. It's perfectly optimized and has a nice fps at a medium videocard. 30K particles are being simulated in realtime. Everything is being calculated inside gpu, cpu only handles input and runs Dispatch() of the compute shader. This is prototype video:

 

Looking good. Love the ending of the video (though it's bit too long for a Greenlight one -- think you'll lose too many by half way).
Good luck

 

Wow, fantastic looking demo! I'll stayed tuned to see how this turns out! Good luck @Zolden

 

the end of this video is epic

 

Here's an update: I improved physics, visualization and implemented a system that generates levels based on images.

 

It looks quite cool. Looks very soft-body-ish at the moment, like its made of jelly or something. Can you stiffen it?

I'm curious how the tank think is handled... does the cpu have to get involved in sensing the environment and moving the tank, or is it managed entirely by the gpu? Like usually you'd have to feedback some data to the cpu to do collision detection around it etc and to know where to move etc?

 

It looks like everything is made out of cake.

 

Yes, that's my main concern, and it's what I plan to improve.

The tank is made of the same particles as the ground, so its interaction with the ground is being computed in GPU as well. CPU only handles input and passes a few bytes of player input to the gpu which does the rest. I decided to avoid getting data from gpu because it affected performance more than anything else. Maybe I done it wrong, stalled the pipeline. But there weren't much tutorials of this matter to learn from. So, pure gpu.

 

I had a question about this project, when you say its "GPU based" that sounds really fascinating as I've tried stuff like using the GPU to do this kind of heavy texture editing but never had much luck writing compute shaders or similar stuff, and I was hoping you might share some of your techniques or perhaps even a demo project showing simply how you make changes to textures/world without doing things like Texture2D.Apply() and SetPixel(s) methods which I've been pretty much stuck with the performance issues related to pushing changes to the GPU from the CPU doing it that way....

Any chance you could educate me a little in this department?

 

I used this method:

First, have a CPU side texture:

static public RenderTexture outputTexture;

and set it for the shader:

_shader.SetTexture(kiCalc, "textureOut", outputTexture);

In the shader you have its representative:

RWTexture2D<float4> textureOut;

and you just write to it:

textureOut[id.xy] = float4(1, 0, 0, 1);

id is a parameter passed to the thread uint3 id : SV_DispatchThreadID

So, id.xy is an int2 thread index. For textures it's convenient to run as many threads as there pixels, so each kernel will have index that points to the pixel. If you have 1024x1024 texture, you need to run [1024, 1024, 1] threads.

I actually published a project in Asset Store, that demonstrates basics of compute shader use. The code is well commented, I tried to explain everything the way I wanted anyone explained to me when I've been learning compute shaders.

 

Are compute shaders Windows only or do they work on Mac yet?

 

This is what Unity manual says:

 

If I could "super like" your post I would. Very informative answer, I can't wait to try and see what I can figure out with this. Thank you good sir!

PS, bought your asset since its a great deal and you've gone above and beyond for me there

 

I've published the code of this GPU accelerated ground simulation as an asset in the store. Here's showcase video:

Asset link.

 

I don't know if you realize this but there is so much potential in what you're doing, that if you develop it further you could totally rule in the area of destructible 2d game environments. This is something very difficult to do for most people and, really, a particle-based physics simulation that can handle fluids and firm/solid structures and soft-body stuff and a huge number of animated particles is very cutting edge in 2D technologies. I think that you need to flesh out a bit in terms of the kind of environments that you support here.... for example this looks like it all fits into one screen.... make it support a very large play area such as a 4096x4096 texture. Add support for scrolling or procedural generation algorithms for constructing environments. Add some painting tools. Create a demo that looks like a game. Add the ability to add configurable 'materials' that can interact like in a chemistry way when they touch, like in sandbox/falling sand games. This in my opinion is one of the futures of 2D games and if it kind of thing were well packaged and supported there would be an explosion - pun intended - of games starting to be based on this kind of technology. This is a paradigm shift of technology that opens the doors to a wide variety of games that are practically inconceivable using traditional 2d technologies. You're pioneering, but if you push it even harder and really go for it, I think you could position yourself in a very powerful place in the market with very little competition. I bet you could make a living from it. Right now it's an impressive tech demo.

 

Consider that asset sold, as soon as I get done tearing your other asset apart

EDIT: you know, color me crazy, but I think your work here is worth well over 20 dollars - don't get me wrong, I'm glad that its a very affordable asset because I can get it , but if I were you, I'd flesh it out some more and raise that price as you update to add more features, possibly you could ask as much as 100 dollars for it once you had a character controller system, a background system, things to make it more gamey, and people would probably still totally buy it at that price?

 

I agree this has a lot of potential to be quite a game changer in 2d game development. I wanted to develop something like this myself and have for years been thinking about how to do this ... A very early model was this: http://www.alecrivers.com/projects/physics_engine.htm - it's basically a 2d particle physics engine where each particle is connected by restraints or springs, and everything can be blown apart etc. Same principle as used here, and also the same principle as used in nvidia's physics thing which is based on particles and constraints. This is in my opinion the future especially for 2d... but it requires a huge amount of processing power which is why really it can only work on the GPU, and that means you have to be in cutting-edge technologies to even get an idea of how to implement it - which the OP has done the main work of already.

One major feature you need on this is to be able to 'texture' the landscape ie give each particle a color. I would also look at using 2d blobby objects for liquids - you can do that easily by drawing a small energy field texture with an additive blend and then rendering pixels in a 2nd pass that meet a threshold. They then blend together better and won't look so lumpy.

This really could become like a $50-$100 market-leading asset, and because this kind of stuff is quite hard to do, would have very little competition for a long time. I would like to see it working on Mac as well though, but I understand compute shaders are an issue there.

 

Yes, currently it's a 1024x1024 area, and I definitely plan to enhance it. Not for the current game though, but for the further development of the technology.
I actually found solution without deliberate intention. I recently had a night dream about me playing a 2d platformer game with destructible everything, with intense interaction with environment, with lots of tricky traps - it was fun, and in that dream I thought like "wow, people really good at making games". When I woke up I thought: ok that was just a dream, but the game was cool, can I get my destructible stuff out of 1024x1024 cage? And solution easily came. Not without some neat coding, but it should work smooth and could become a base for games like keen commander.

Yea, that's the plan.

I'm currently creating that Scorched Earth remake, but it will be still in 1024x1024 area. Though, if it will be accepted well, I'll at least could focus on this partcile-related project instead of doing freelance stuff.

It was in the initial plan, to have a whole bunch of different materials with chemical permutations, burning, gas and liquid states. I even wanted to create air with navier-stocks grid, to have explosions naturally form visual patterns of rising fire and smoke. But that was too complex to put in one game, so I went a bit minimalistic way. Though, haven't scrapped these ideas completely.

Yea, that was my intention, to practically utilize for novel game design purposes the power of GPU computing, and I do go this way. I'm glad someone feels the wide and fresh possibilities of this approach, thank you for sharing your optimistic thoughts.

I actually wanted to sell it cheaper, but publishing tips said this kind of stuff usually sells in different range, so I took the minimum price from that range. I put main revenue hopes on the actual game, and the asset is published because people on reddit asked how is it done and how to learn compute shaders, and if I plan to make a tutorial. So, I published basics to link it to the curious. But I pressed "publish" button 3 weeks ago, since then I added some things, that could added to the asset too, like that sweet convertion from images to levels. So, yea, I'll add more stuff for sure, but it's not for money purely, I want developers to use GPU computations more, because physics are funnier to play with than graphics.

Yes, it's already implemented, ground is being generated from images. I recently made a level from a random image, as a showcase, to post on reddit:
https://gfycat.com/TalkativeAmbitiousBooby

This is one of the things I'm currently thinking about. And probably I could insert liquid support right in the functionality of the current particles with little adjustments, and it could look nice with slightly different way of drawing water particles.

Oh, looks nice. Now I understand your optimism about this direction, you know how fun it may be when it works, especially when it works fast. Something like that inspired me in the first place. "Powder toy" is the name of that sandbox game, where everything worked the way you described - with chemistry and different aggregate states, just was CPU based, and thus had optimization, that could make it look less natural. I wanted to go the CPU way as well, thinking of some hardcore computational optimizations instead of the physics ones. But then a guy in #Unity3D irc channel told me about compute sahders, and I was WTF! 50 times faster! That's the solution! And here we are now.

 

In addition to the previous answer, compute shaders for metal are shown on the unity roadmap as being included in unity 5.6. So this means we dont have too long to wait for compute shader support for more recent macs and mobile devices.

Apple computers that support metal are listed here:

https://support.apple.com/en-gb/HT205073

For iOS devices I believe its the iphone 5S or newer, ipad air or newer, all the ipad pro's, ipad mini 2 or newer.

 

Darn, my 5 year old relatively new mac doesn't support Metal. arg! lol

 

Android supports compute shaders on lollipop and up with opengl3.1, if you tinker with the player settings. Problem I'm having is getting RWTexture2D working, I think. I been messing with the asset with the fractal, and so far cannot get it working, and can't say for sure why, as it's supposed to be supported. Anybody got any knowledge about the specifics of compute shaders on mobile?

 

Alot has been done since the last update. Implemented a universal system to add different weapons. Also added VFX for weapon effects. Thanks to Michal_, who created async GPU data reading plugin. Also, made the tanks destructible. Improved physics slightly.

I actually have a playable demo currently:

Even submitted it to Steam Greenlight.

 

Looking cool. I think maybe the main visual thing it needs is making the physics 'stiffer' so that its not so spongey. Or make it adjustable with different materials.

 

Yea, it's actually the main feedback point, and I think I'd like to be fixed the most. I've been trying to increase the rigidity of the matter via subtle optimizations and trade-offs. It helps, but not much. But when I'm out of ideas, I'll probably have to pay raw performance for this. Because it's the key and most effective currency here.

Reduced time step would allow to increase intermolecular forces without affecting overall stability (stronger forces with bigger step makes everything explode). But to keep a fast real time pace of the game I'll have to run more simulation cycles per frame.

So, it's improvable, but I delay the performance paying step until I'm out of other ideas.

 

For the physics calculations, i don't know how you're doing it, I've seen it done with a mass spring system where everything is connected by springs and it holds fairly rigid, or you can increase the spring's tension. Alternatively for solid particles can't you just connect them by constraints that maintain an exact distance?

 

I hit yes for your greenlight! Awesome looking video and steam page! Can't wait to play it

 

Yea, currently particles interact through a spring-alike kind of forces. Specifically I use Lennard-Jones force, which demonstrated the most realistic behaving of the whole mass. But repulse force value grows very fast when particles getting closer, as 1 / r^8. So, if particles are close already, and are flying closer to each rapidly, and time step is relatively big, they can get very close after only one step. And that will cause HUGE repulse force, so they will gain insane velocity from this time step related error. That ruins momentum conservation law, everything explodes.

Reducing time step fixes it, but it means paying performance. So, there's alot of tricks to keep the time step high enough for fast work, and in the same time to keep the force -> velocity factor as high as possible for higher rigidness, but still to compensate possible time step related errors.

For example, one of the tricks: I added "health points" to the links between the particles, increased rigidity parameters for these links, but compensated them with energy dissipation measures. That allowed to have things harder, but still destructible, because explosions reduce hp to the point where connections can be broken.

It would require adding additional relatively more complex computations for the bodies formed by particles. Currently I only calculate particle-particle pairs with really simple interactions. It's also important to keep all calculations equal by time they consume, so parallel threads don't wait each other.

Having dynamically breakable rigid bodies instead of particles is a good idea in general, but I wouldn't mix it with the pure particle approach.

Oh, thank you! The votes are 50/50 of "yes" and "no" currently, but it already got 20% of what is required to have a chance for being published, so there are some chances. Though, I'll finish the game anyway.

 

So, I improved the physics. Implemented different materials with different properties: stone, metal, ice, sand, jelly, etc.

Also implemented a new physical entity, a spring, that can be used to support complex shapes of the matter, and also to animate pieces of matter, so there are platforms in some levels, that lift the tanks between height levels.

Here's a video showcasing these features:

 

I've recently implemented "bonuses" - little things to pick up, that give ammo, upgrades, shield and heals. Also, there are buttons or keys, that change something in the world, for example:

GIF

 

Recently implemented flying enemies. They aren't very smart, but they can aim the player and dodge pieces of matter that can hurt them. Their logic is implemented on gpu side as well as everything else. They will be used in singleplayer campaign.

Next thing to implement is other kinds of enemies: vehicles and turrets.

 

I recently started creating singleplayer campaign. Here's some gameplay footage:

 

This is really awesome, kinda reminds me of Liero

but with Tanks

 

This looks awesome! Superb work!

 

Love Liero, but Scorched Earth has at least a decade on it.

 

It's actually funny, I discovered some cool games because people mentioned them after seeing my game. Liero is one of them. Also Cortex Command. And OE Cake. Also Red Faction series with its 3D environment destruction.

But yes, I mostly based my game on Scorched Earth initially.

 

Scorched Earth, awesome game. Lots of great memories from that one : )

 

Ahh Cortex Command... awesome game. I have based my initial ideas for Pixel Destruction on CC because it really was inspiring how original and fun it felt (even if it borrowed somewhat from these older games too!).

 

You know, maybe for a good follow up you could really lean into the Jello mechanics and make a Liero clone with Jello terrain.

You could have you troops bouncing all over the place and rocket jumping, all while the terrain is flopping about. That sounds like some insane fun to me.

 

Bots fighting in turn based mode on dessert themed maps. They don't drive or switch weapons, just aiming each other.

 

I'm about to publish the first release on Steam, here's a trailer:

 

Wow you've been busy, nice!

 

Very impressive, consider me sold on the steam release

 

Really cool seeing your progress. I remember seeing this on Reddit a long time ago.

But I don't remember if you answered me the last time or not. Everything you're showing here looks really cool, but everything in your game is done using your system which makes it look gimmicky in my opinion. It reminds me too much of Cortex Command to be honest. Cortex Command could have been a fantastic game if the developers just toned it down a tad, but instead they used physics pixels for everything and in the end just moving your player character in Cortex Command was about the most frustrating thing ever, and it was so clumsy compared to any similar game out there.

You're of course free to do anything you want in your own game, but I see that you're selling the terrain part as it's own asset. Is it possible to combine your system with normal meshes and 2D physics colliders?

Your system looks amazing for terrain, but in the example where you show the different materials they all look the same to me and in no way like what they're supposed to represent. And the tank movement and platforms look very awkward. I think using normal meshes would work so much better for the structures, and especially for the tanks. And you could use mesh splitting to much better represent materials like wood, stone, ice etc. These are just my thoughts on how I feel an ideal game like this would be like, but I can understand if one of the limitations of your system is that it can't interact with the normal Unity systems.

Anyway, best of luck with your Steam release!

 

It's not present in the current version of the asset.

But it's not hard to implement passing the 2d colliders data into GPU to interact with the particles and bringing collisions data back to CPU to affect the colliders as if the particles themselves pushed them. Though, the latter would be delayed by 2-3 frames. The only problem I see here is that unity physics work in FixedUpdate(), while compute shaders are being dispatched in Update(). But these two physics worlds interact manually, so it may not be an issue.

An alternative would be to implement 2d colliders inside the shader, to work in GPU. It would work more efficiently, but that would require more work.

If I'll face the necessity to add rigid body colliders to my game, I'll most probably go the second way. But there's a chance I might implement the interactions with cpu side unity 2d colliders, to make the asset more useful. I heard Unity 2017 will have a feature of particles from unity particle systems to interact with the physics colliders both ways, affecting them too. That might bring some new functions to the colliders' API, to make the implementation of interaction between my gpu particles and 2d colliders even easier.

In general, I agree that combining 2d colliders with particles might be useful for the game. It would save performance, improve the physical realism part and allow new gameplay features, that are not possible without truly rigid bodies. But to make it perfect and seamless, I'd have to spend too much time. So, for now I'll focuse on the pure particles approach, but there's a good chance I'll add the colliders later.

My greatest concern currently is to make the simulation deterministic, and implement online multiplayer.

 

That would be awesome to see, as I had been strongly considering doing the same thing, and wondered how hard it is to get from GPU side code to networked code... how might you handle the part where you hand off data to the network, and do you think that doing that would have the "2 frames late" problem as well? Like would RPC's or packets be sent two frames late from the server to clients?

 

I don't know, never tried network coding. I guess, there's some delay, but I don't know how big it is. The "2-3 frames late" is only gpu read related delay. Though, if I fix the non-determinism of the simulation, there might be no need to read from gpu, because its situation will exclusively be dependent on player input, which is available on cpu side.

 

Released early access version on Steam, here's the link if anyone's curious.

 

I'm trying to find unique gameplay features, that would benefit from the physics. Trying to build some singleplayer campaign level. Here are few: