Jump to content
Stray Fawn Community

One potential solution to rigidity


Lurkily

Recommended Posts

What if some mass blocks were part of a separate 'skeletal' layer?  This layer could overlap with other blocks, only colliding with each other and weapons fire.  Ship components could be anchored to these.  Where they were adjacent to other skeletal blocks, they would be absolutely ridid, acting as a single body. (Until they were broken into parts by destruction.)  Very large parts could be more mass-efficient, encouraging players to engineer around more complicated constraints.  Everything else can be anchored to these, and regular mass-blocks in the regular layer would be able to act as armor without the threat that damage to the armor might damage the skeleton it's fused to.

 

Skeletons should be severe weak points; my current thought is that if the enemy can damage a skeletal block, it should split that damage up, and deal it to every connected non-skeletal block. Large ships may experience skeletal damage under excessive maneuvers, so a degree of thought is still required in making big ships.  You can't add a thousand thrusters and handle your battleship like a starfighter.

 

The idea here is to permit more compact ships without sacrificing complexity, to be able to build big, rigid ships while still requiring trade-offs in both mass, vulnerability, and the stress applied to ships.

Link to comment
Share on other sites

Or you could do what besiege does, and allow connecting blocks with struts

That's kind of what the game does now, except it only permits one connection per block.  I was told an earlier build permitted free connection, but you could easily overwhelm the engine by connecting each block to every other block in range.  While it would make things more stable, I was informed that the CPU load that developed from that many interconnections is significant.

 

Even permitting limited interconnection, you introduce the possibility of circular physics interactions.  That's a potential for physics bugs and CPU burden that might be best avoided, if possible, though it would be good to experiment with.  It also doesn't introduce mechanics of build and mass challenges, or introduce real vulnerability.

Link to comment
Share on other sites

Or you could do what besiege does, and allow connecting blocks with struts

That's kind of what the game does now, except it only permits one connection per block.  I was told an earlier build permitted free connection, but you could easily overwhelm the engine by connecting each block to every other block in range. While it would make things more stable, I was informed that the CPU load that developed from that many interconnections is significant.

If the player decides to do that, it's their fault. It is better to give players the freedom to make interconnects rather than preventing it just in case someone makes a million of them and makes the game crash. Besiege lets you build massive creations in 3D with a large number of interconnects. doing the same in 2D should be easier.

 

 

Even permitting limited interconnection, you introduce the possibility of circular physics interactions.  That's a potential for physics bugs and CPU burden that might be best avoided, if possible, though it would be good to experiment with.

I don't know much about game development, so I may be missing something here, but these are problems that have been solved by games with much more complicated physics.

 

It also doesn't introduce mechanics of build and mass challenges, or introduce real vulnerability.

Thrusters not directly connected to the core wobble, parts often clip into each other when they sway. Janky physics is not a good way to make a game challenging.

 

Giving players the freedom to make big and complex designs will also lead to more YouTube videos of people showing off their creations. The game will get a lot of free publicity

Link to comment
Share on other sites

What if some mass blocks were part of a separate 'skeletal' layer?  This layer could overlap with other blocks...

Yes this also my first idea. A car is also build around a chassis and not by putting 4 wheels on an engine. So a background layer that give your drone shape and provide structure as well as stability sounds great. Sure you can build outside this frame but everything that is on the frame become one (until its destroyed)

Link to comment
Share on other sites

I was informed that the CPU load that developed from that many interconnections is significant.
If the player decides to do that, it's their fault. It is better to give players the freedom to make interconnects rather than preventing it just in case someone makes a million of them and makes the game crash. Besiege lets you build massive creations in 3D with a large number of interconnects. doing the same in 2D should be easier.
I can't comment much because I haven't played Besiege, but it seems to cause a problem here, in this engine.  Saying that 'players shouldn't do things that kill their CPU' doesn't absolve the developer of a responsibility to design software that is sustainable by available consumer hardware.

 

Besiege really lets you connect every piece to every other piece?  That's insane.  For 100 pieces, that's 4,950 connections, each of which need to influence the physics of every block, and do that all over again in every frame of gameplay.  (The formula for the number of connections should be X/2 * (X-1), X being the number of blocks.)

 

 

I don't know much about game development, so I may be missing something here, but these are problems that have been solved by games with much more complicated physics.
Usually you do it by forbidding circular interactions where possible, favoring parent-child interactions.  Physics can be unpredictable; circular interactions might be self-reinforcing until a minor wiggle becomes an instability that tears a structure apart.  It's possible to code well enough to avoid that, but usually a developer gets more use out of their time just trying to eliminate the circular interaction so that self-reinforcing loops can't occur.

 

It also doesn't introduce mechanics of build and mass challenges, or introduce real vulnerability.

Thrusters not directly connected to the core wobble, parts often clip into each other when they sway. Janky physics is not a good way to make a game challenging.

 

Giving players the freedom to make big and complex designs will also lead to more YouTube videos of people showing off their creations. The game will get a lot of free publicity

  I think that you think you're disagreeing with me, but my proposal was intended to permit players to make enormous ships without looking like a sack of legos. 

 

The skeletal structure introduces a weak point that must be protected by shields and armor.  This is the mass challenge and vulnerability I spoke of.  I wasn't talking about the wobble as a build challenge.  The weakness is the fact that if the skeleton is damaged, everything attached to that segment is also damaged.  The build challenge I spoke of is the fact that, because larger skeletal pieces are more mass-efficient, it's useful to build a ship around larger skeletal pieces, which will influence the shape of your ship.

 

I absolutely want to permit the player large and rigid ships.  That's the whole point of the rigid skeletons. 

Link to comment
Share on other sites

There are a lot of dampening forces that should be present, but even now you can see reactions that reinforce each other - for instance, very long struts attached to a motorized hinge turn a little wiggle into an insane dance until the whole assembly explodes.

 

Circular interactions have the same potential.  It may be easy to address - one hopes any potential problem would be - but a dev's time is usually better spent by simply eliminating circular physics interactions.

 

They still exist, of course. Parts still bump into each other, and one strut's wobble inciting a wobble in the next strut is probably why hinges with long struts tear themselves apart; the self-reinforcing wobble with a longer lever overcomes any dampening involved.  But if you can eliminate a possible source of jankiness, it's my opinion that you should.  It's not worth a programmer's time to fix what the game doesn't neeed.  Less time spent fixing that means more time making awesome weapons and planetary ecologies, and etc.

 

It's not my place to tell them where to spend their time, of course.  But I strove for a solution that minimized the amount of coding, fixing, and balancing involved.  Pure rigidity eliminates a lot of physics calculations, and a parent-child structure to the connections ensures that every physics interaction through connections has an endpoint.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...