- Edited
@xyz said: I think "decal" is the keyword.
Or splatmap if using (typically vertex colors as) a mask.
@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).
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.
@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:
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.
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.
Yeah I agree cybereality . I think @DJM Normord will have no problem at all
packrat Some people call it "cartoonish clarity". Exaggeration to make things feel natural. It's incredibly ironic.
It sounds somewhat silly when you put it like this. But. This "clarity" is part of a very general design principle that, for the lack of a better term, I named "experience condensing". Thorough utilization of this principle is essential for good game design, especially for "realistic" games. The principle could be formulated like this: Condense and amplify all aspects of reality that are fun, feelgood and flowy, minimize or eliminate all that is opposite of that. A simulated experience of the world needs to be heavily condensed in order for simulation to "work" as a fun game.
Experience condensing can be applied to almost any design element, from overarching things to small details; space, time, dimensioning, movement, narration... Here are some examples:
Imho, this is one of the crucial game designs concepts. I didn't really encounter any theorist articulating it clearly. Game designers employ a lot of condensing intuitively though. Once you're aware of this, and start analyzing games with it in mind, it becomes obvious how condensed, fake and cartoony most game worlds actually are, while at the same time successfully sucking you into their "realism". It's just magical.
To bring this back to the topic of physics simulation; you never want realistic physics to run your game entirely. It will bring in dull parts of simulated reality, because a lot of physical reality is inevitably boring. That's why people play games, to escape tediousness of reality. Instead you need to keep feelgood parts of what the physics has to offer, and eliminate all of the clunky pedestrian stuff. Condense the simulation by replacing boring correctness with flowy fakery. The aim is to maximize overall feelgood factor of the experience.