• Projects
  • Stactory - A physics based 3d puzzle game

Edit: replaced deleted video with some gifs

Above I showcase the level editor I've made for a simple puzzle game. It's probably a little presumptuous of me to think my first game can be any good... but I really like this idea and I'm gunna stick with it. If I can get this puzzle game done I'll turn this into a fully fledged factory game.

I wanted to share my progress earlier but ... it took me 6 months to decide on a name.

@Erich_L said: ... it took me 6 months to decide on a name.

Yes, the most difficult thing, I swear it always is.

That looks really really cool!

Would it cause performance issues if the player piled up a bunch of objects?

@fi-le said: That looks really really cool!

Would it cause performance issues if the player piled up a bunch of objects?

Oh yes. The game levels are not giant open worlds so I can keep things pretty well contained. My desktop can handle about 600 objects, my laptop around 500. I've learned the objects like to keep moving. When I have a bunch of stuff stacked on top of each other stationary there seems to be a larger performance hit, probably because of all the objects are pushing down/up on each other.

@Megalomaniak said: Yes, the most difficult thing, I swear it always is.

I wanted to go with Five Second Rule for the longest time. Perishable foodstuffs can only stay on the floor for 5 seconds before they count as waste. Name patented.

I like how "organic" this is. It constrasts with very industrial games like factorio etc. "Five Second Rule" is a good name and a good concept.

I like the way the video makes it look like the game is on your desk. :smile:

7 days later

@DaveTheCoder said: I like the way the video makes it look like the game is on your desk. :smile:

thanks m8 I've gotta do a better job of that on the next video

5 days later

I don't plan on actually having this many objects in the game, but I noticed when toying around that after 130 of my belt objects are in the scene things break down, specifically the rigid bodies all freeze (the bananas) and ray casts on a number of my belt objects quit working. I can still add more belt pieces but new ones can't be clicked.

Where it gets hilarious: all those frozen bananas are still collecting the forces acting on them. If I delete enough belts to go under 130 they fly off with all that accumulated force and all the belt objects work normally again.

Appreciate any tips or links

This looks really awesome. Thanks for the shout out.

I set this up as a test-level to see if my ~10 year old students could figure it out to get all the bananas going into one hole. They had a really really hard time. Second opinions?

https://stactory.itch.io/stactory-01

Also... if you're too slow the bananas will freeze up your system. It's the ultimate race against the clock. They despawn when falling off the world or going into the hole

4 days later

I am no artist- but here's an attempt to color belts by height

2 months later

@cybereality mentioned recently that we shouldn't use get_overlapping_bodies() in the physics step and signals for entering and exiting are preferable. Hey wait a minute! I'm guilty of doing that! So I thought I'd try both ways and see if there would be any improvement in my game's performance.

Interesting. I would assume since you are still looping though all the bodies the same calculations need to be done. My example would be more for things that don't happen often, like let's say walking over a trigger that opens a trap door. But maybe under-the-hood Godot already has optimization for this use case.

15 days later

As promised @xyz, @OpinionatedGamer . I'm always happy to open up blender and start modeling. It brings me such joy knowing my friend Joe is going to be annoyed as hell as I continue to refuse to use bevels on my edges. Each hard edge is basically a small tear of joy.

I think I'll make a more complete test with collision shapes in a few days. Edit: I misspoke tho the launched speed is displayed speed * 10 not 100.

Literally LOLed :D The launcher looks like a legit piece of industrial strength equipment. But I don't think you're anywhere near mach speeds yet.

And hard edges are cool. I actually prefer them over soft beveled look.

Why not compromise at hard bevels? But seriously with normals being bendable you can do some interesting things with hard edges.

@Megalomaniak said: Why not compromise at hard bevels? But seriously with normals being bendable you can do some interesting things with hard edges.

Curious, what do you mean by hard bevel? I did a bit of fruitless searching. Do you mean a one edge bevel?

@xyz said: Literally LOLed :D The launcher looks like a legit piece of industrial strength equipment. But I don't think you're anywhere near mach speeds yet.

And hard edges are cool. I actually prefer them over soft beveled look.

As you can tell I'm no 3d modeller, but I wanted the 3d objects to match their collision shapes as much as possible. Also the objects snap together on the grid and bevels seem to make ugly creases on edges.

@Erich_L said:

@xyz said: And hard edges are cool. I actually prefer them over soft beveled look.

As you can tell I'm no 3d modeller, but I wanted the 3d objects to match their collision shapes as much as possible. Also the objects snap together on the grid and bevels seem to make ugly creases on edges.

I think you did quite a good job with modeling, and with the whole look of the factory for that matter (color palette, textures etc...) It all looks very industrial, yet fun.

@Erich_L said: Curious, what do you mean by hard bevel? I did a bit of fruitless searching. Do you mean a one edge bevel?

Yep, basically that. It still leaves 2 visible hard edges when looking close up but from a distance it might look better than a single edge. Hard edge as in normals would still be split.

@Erich_L said: Also the objects snap together on the grid and bevels seem to make ugly creases on edges.

Yeah, connecting sides should probably not feature them.

22 days later

I would like to achieve the following effect but I don't know what to start googling. I'll use a rigid body to bounce around a scene. At some point it will start spraying muck on my static bodies in a cone (think spray can). I want to be able to spray and color meshes in a way that I could.. possibly also save? Nah forget the saving.

I would also like to modify the normal map in a way that could make it look as though the affected regions had a wee bit of depth. I have worked hard to keep my geometry simple so I hope this is possible.

I think "decal" is the keyword.

@xyz said: I think "decal" is the keyword.

Ah! Decal is a keyword I need to know. It looks like decals are the fast way to produce some... squished banana debris that get caked on the gear. If I want a continuous spray of yuck muck I don't think decals are right. I am looking at code people have made to make painting tools. Is this (a/the) right direction? https://github.com/tomankirilov/VPainter

Yeah, you can just paint into the texture. I would that still call technically somewhat a decal :) The key question is whether you need to manage blotches after they've been applied (fading etc). So first try to define the behavior as precisely as possible and then look for solutions.

In Splatoon, it looks like no holds were barred. They did everything - projective decals, painted textures and on-the-fly generated meshes.

@xyz said: I think "decal" is the keyword.

Or splatmap if using (typically vertex colors as) a mask.

@xyz said: Yeah, you can just paint into the texture. I would that still call technically somewhat a decal :) The key question is whether you need to manage blotches after they've been applied (fading etc). So first try to define the behavior as precisely as possible and then look for solutions.

In Splatoon, it looks like no holds were barred. They did everything - projective decals, painted textures and on-the-fly generated meshes.

This guy broke the system down and implemented his own splat. (Mostly sharing to save it for myself). The features in that game are amazing thanks for sharing. Since this is my thread anyway, lemem go ahead and explain "my deal". It looks like there's no actual fluid simulation involved; it just seems to be careful manipulation of the texture.

My deal:

! Oh yeah, very cool, good job, you sure did make all those 3D models look really cool by adding dubious ton of scratch marks. What, this clone trooper has been in service for 10 days and his armor has 10 years of marks? Does no one repair armor? Oh cool, I built a new structure in my factory, look how worn down and realistic it looks while it's brand new! People smell their own farts. People usually don't enjoy others farts. If this factory is going to end up nasty, I want to be the one that made it so. ! ! In this game I want to start with pristine, new, freshly fabricated engine of creation sailing the stars. I chose fruit at first not because I really cared about making food but because food can get squished, it can draw the attention of space rats, and it can mold. It can come in dirty and need to get rinsed off. Rats can accidentally get into the machinery and get... "juiced".

"So first try to define the behavior as precisely as possible and then look for solutions."

I want to be specific, but I can really only leave you with "my deal" because I suspect whatever I can accomplish on a technical level will highly influence game design. I made huge progress just by realizing it'll be in space. Now I'm ready to start remaking models if I must to accomplish dirty gunk spilling. I guess to be specific, at the very least I want to have containers break and spill liquid into the room. If it's sticky liquid, I won't have to worry about simulating the liquid in the vacuum of space flying around (probably would be too computationally demanding).

2 months later

I've had enough of papers, I want to get my factory into space. I see cylinder space ships and I don't mind that shape... but I've been scratching my head thinking about how to fit a regular grid neatly on the floor or even sides of the cylinder. I don't think it can be done unless the models are procedurally generated based on the size of the grid cell that they're being placed in. If the factory floor's "floor" is on the sides, that first level I could do, but they'd have to be shrinking as I stack factory objects closer to the center.

Am I right? Is there no decent way to do this unless I... cut corners? I think I might have to go for a diamond shape.

One other question for you guys- would you agree that for the beginning of the space manufacturing revolution that the first destination should/will be the asteroid belt? There's just too much gravity on closer planets for it to be economical. I'm talking space manufacturing for use building stuff in space.

@Erich_L said: One other question for you guys- would you agree that for the beginning of the space manufacturing revolution that the first destination should/will be the asteroid belt? There's just too much gravity on closer planets for it to be economical. I'm talking space manufacturing for use building stuff in space.

Yeah, that seems reasonable. It would also likely be easier to get metal from astroids than from planets.

So you don't have to procedurally generate the mesh. As long as it is a perfect circle, and you know the radius, you can use the circle formula in GDScript and some math to snap to a grid. I don't have the code off hand, but it would probably only be like 5 or 6 lines of code.

Oh, and they discovered an Earth Trojan Asteroid earlier this year, which would be the ideal place to set up a base. Not sure how long it will take for us to get there, but it's orbit will be stable to 4,000 years, so it's a good spot.

https://scitechdaily.com/existence-of-earth-trojan-asteroid-confirmed-could-become-ideal-bases-for-advanced-exploration-of-the-solar-system/

@Erich_L said: One other question for you guys- would you agree that for the beginning of the space manufacturing revolution that the first destination should/will be the asteroid belt? There's just too much gravity on closer planets for it to be economical. I'm talking space manufacturing for use building stuff in space.

Yes. Kinda. Rather asteroids will be "mined" and your factory would likely be a orbital station somewhere.

One current concept that I'm aware of for mining smaller things is to literally cover a mining target with what is essentially a really big bag and then a robot satellite/thing with basically a gun, would be inside there shooting that thing apart.

@Megalomaniak I also came across that method of mining asteroids- seems awesome but too much work for me show much mining happening as I continue development. At most I was planning on just showing the ship close to the asteroid in question and let the ship's mining drones drop of resources. I read somewhere that resource refinement needs ton of energy and water, so I'm going to build the game so that your ship when small just does these things inefficiently, but at later stages your ship might as well be a parked refinery.

@cybereality I didn't know about trojan earths, those seem amazing. For a game if I wanted to set it up multiplayer, I'm afraid that there's not enough individual roids around Earth orbit and that their distances would make things less fun (not gunna stretch too far from existing tech). A bigger problem- I think refining needs energy and water, and a trojan earth asteroid I'd assume wouldn't have any ice unless the asteroid had no spin.

For a circular grid inside a cylinder, the problem is either all the interior space isn't used or that factory components need to be of different sizes.

My first concept of a ship that can build itself up over time:

a year later

Here's a random update that mentions briefly why I quit using Godot for this project. Maybe years from now I'll give it a try in another engine.

edit: also I replaced the old video on the original post with some more fun to watch gifs

Yeah, to be honest, I've been running into a lot of issues with Godot now that I'm trying to do a serious project and not just tech demos.

Starting working on my own engine, but it will probably take forever and not end up being better than Godot.

In order for simulation to look/feel good you often need to fake stuff and not rely solely on physics to handle everything for you. In lots of situations realistic physics alone feels sluggish anyways. You typically want to give it a little "push" in a form of fakery when needed. Games do that a lot. I like to call it "creating an illusion of a simulation"

    so its not only in normord that the engine is strugglin with physics calculations....

    That project helped me learn Godot so no harm done, but I do feel much more confident in the engine now that I'm working on a game that's not physics intensive.

    xyz Some people call it "cartoonish clarity". Exaggeration to make things feel natural. It's incredibly ironic.

    • xyz replied to this.

      Yeah, maybe for like shooter games with rigid bodies that are just for extra effects, they will use the base physics engine. But I'm pretty sure any "physics based" games will do some "help" to make the physics work, just like they do aim-assist on console shooters. It's fake and unrealistic, but if you do it well players don't notice and have a better experience.