BigShips and their parts

[Husky]

I am currently working on the BigShips ticket in the current PPS.

The HeavyCruiser model was originally created by nicolasc, and I'm adding textures, collisionboxes and everything else needed to make it playable in the game. Most of the texturing as well as collisionboxes and the ship's flight characteristics are done, but the ship still is only one single entity (I cut the model into different parts, but they are all attached to the same entity).
So I started thinking about how to implement the structure of a big ship with different destructible parts, as well as about how to add turrets to it.



(In the following I will refer to the 'main' ship-body which is controlled by the player as BigShip. The parts attached to it are ShipParts, and there's Turrets too.)

My first attempt to add the Turret (the already implemented one) to the ship in XML failed due to Turrets being SpaceShips, which cannot be attached in XML like normal Static or MovableEntities (Console output: Warning (internal): Cannot attach a dynamic object to a WorldEntity.) The same applies to other ShipParts: Attaching them as StaticEntity makes them part of the BigShip, but they are not individually destructible. So something new needs to be done. (It doesn't need to be actually done to finish my ticket, but it would be good to have an idea on how to continue, and create a new ticket for it.)

I've never really coded before (apart from Informatik I and II exercises), so instead of just knocking an ugly makeshift solution together it's probably better to ask people with a bit more experience >.<
Anyhow, here's what I've thought about so far:

Originally I thought it would be good if in the end ShipParts can simply be attached to BigShips like any other Entity, resulting in the corresponding XML to look something like this:

Code: Select all

<BigShip [parameters]>

    <engines>
        ...
    </engines>
    
    <attached>    
        <Model [parameters] />
        
        <ShipPart [parameters]>
            <attached>
                <Model [parameters] />
            </attached>
            <collisionShapes>
                ...
            </collisionShapes>
        </ShipPart>
        
        <ShipPart [parameters]>
            ...
        </ShipPart>
    </attached>
    
    <collisionShapes>
        ...
    </collisionShapes>
    
<BigShip>

First (probably not that good) approach:

Create some sort of DestructibleEntity, which is a StaticEntity, but has health, is able to receive damage and get destroyed. It can be used for other simple destructible objects such as asteroids or crates too.

A ShipPart class would build on that interface. ShipParts would have a pointer to their 'parent' BigShip and be able to modify that parent's values upon being destroyed (e.g. disable weapons/shields or weakening engines).

A new BigShip class extends the existing SpaceShip class. BigShip reads the XML ShipPart Objects and calls the ShipPart constructors. BigShips has parameters which can be changed by its child ShipParts and vice versa (e.g. BigShip can deflect damage to certain parts)

A new Turret class, which is a ShipPart, but needs a controller and weapons added.

Conclusion: At least after this last point one can see that this approach is rather complicated, since one would have to add something which is already provided in SpaceShip.
So Jo suggested simply using Pawns instead.


Alternative, probably better approach:

Both ShipParts and Turrets are Pawns. They have a pointer to their 'parent' BigShip, while BigShip has pointers to its ShipParts. Every tick their position and rotation is moved according to their 'parent' BigShips movement. (This should be possible with some vector calculations.)
Again, ShipPart and Turret can change BigShip's parameters and vice versa.

This way we don't need to worry about <attach>ing the Entity, since the entity follows the BigShip by itself. Also the Pawn already offers hitdetection, weapons and other fancy stuff.

(Jo also brought up the idea of a 'docking' function for SpaceShips or Pawns in general, which could have other applications than BigShips)

Conclusion: This is probably the way to go


Now, I'd like to hear your ideas/feedback.
Maybe you have a completely different ingenious idea? Or maybe there is a feature already included which I'm not aware of which could be useful?

Thanks

[x3n]

Very interesting topic. And I like your thoughts.

I think we could discuss ages about this topic until we find a good solution. But I'm not in the mood to write an essay right now (maybe later), so I'll try to keep it short for the moment.

First of all: If you want to attach something, you should attach it. That's why the "attach" function exists (and Ogre does all the work for you). Don't do the vector calculations by yourself because you would just end up re-implementing Ogre's positioning system.

Second: Unfortunately you cannot attach a dynamic entity because it is controlled by bullet (our physics engine). And because of the very same reason you will also be unable to solve the problem with your own vector math. The problem is not the attaching itself; the problem is that you mess up the physics simulation if you constantly overwrite the position.

I think it's fair to say that it's kind of a design flaw that Pawn (the only class which is able to live and die) inherits from ControllableEntity (which is a dynamic/physical entity). After all, being a static entity should allow you to die as well.

So I think Pawn should probably not inherit from ControllableEntity. Instead you should assign an entity (or multiple) to a Pawn and if this entity is hit, the Pawn should take the damage.

This sounds a bit like your first approach, except that it doesn't involve new classes but rather a refactoring of the existing ones.

----

The question is: Is it possible, to do this in the remaining time of the PPS? Honestly, I don't think so. We (probably) did it wrong the first time and nothing will keep us from doing it wrong again unless we spend more time thinking about it than the first time.

So is there a simple solution for the moment?
Maybe you can simply attach all the individual parts to the Pawn (the parts itself are not Pawns). Give each part a name (in xml: name="xyz"). If the Pawn gets hit (e.g. after 10% damage) iterate over all attached entities of the Pawn, search for specific names (e.g. "left wing", "big tower") and destroy one of them. Repeat this after every 10% of damage until the Pawn dies.
This will slowly destroy your ship, but the destruction happens randomly, i.e. not at the place where the ship was hit. If you want to do better: the hit() function of Pawn takes an argument with the contact point. This may allow to calculate which part of the ship was hit (maybe now you can do some vector calculations).

I hope this helps a little. If you're interested in this topic, we can share some more thoughts about Pawn and how to improve it. I really like your ideas because I think your approach to move health into a different class is the way how we will do it in the end. But I also agree with Jo that it's probably not feasibly to do this in the remaining time of the PPS.

[beni]

I have to agree with x3n there. Approach 1 sounds better, but requires a change of the class hierarchy which is not feasible at the moment. It's definitely the best and cleanest solution to the problem. The design changes could also allow for different sections of a shield, of manually applying energy to different sections of the ship or even upgrading parts of the ship individually. So a ShipPart could definitely be quite powerful or even controllable. It needs to be attachable though.

Granted, some of these things are already possible with other features like Pickups, but an overall solution to the "many parts/many systems" problem would be cool and open up opportunities for new and interesting features.

I also agree with x3n on the quick fix solution. Instead of reimplementing Ogre's vector calculations for attached nodes it makes more sense to internalize a simplified idea of the first approach into your class.

[Husky]

Hm... Didn't think about the physics simulation... Welp, looks like theres no easy solution for this.
I didn't really plan to implement this as part of my PPS task btw, I just wanted to find out how it could be done (maybe in next semesters PPS? )

Anyhow, now that we're already collecting ideas:
I just had another idea, but its rather an ugly fix: One could use that physics engine which gives us those attaching-problems to our advantage and actually physically attach all parts together. One can easily build some sort of 'hook' with collisionboxes which would hold multiple Pawns together.
And by modifying a Pawn class adding pointers to other pawns one could let them interact with each others parameters.
However I don't know if this would require too many physics calculations, resulting in lag...

[x3n]

If you join us for another semester, that would be great I would be happy to support you with this task (or another). I didn't find the time to visit the PPS so far this semester, but I will eventually.

In Orxonox we try to "do it right"; often this isn't the easiest way, but in the end it usually pays off (plus it's more fun and also educational). Classes like Pawn are used by almost every developer, so we can't just change it the way we like - instead we have to think ahead and imagine how this class could be used and what this means for our design. And we want to make it easy for future developers, not just for the one who's currently implementing a new feature.

About the physics:
I guess it could be possible to build a hook, but also quite difficult. Apart from that, Bullet actually supports connecting different physical bodies in different ways (rope, spring, joint, etc). However, we didn't implement this in Orxonox so far. If you search for bullet physics, you will probably find some information (and videos). Btw, I just learned that bullet was used in GTA4 & 5.

[Husky]

As for the physical hook, I thought of something rather simple:

Pawn A has a cube-collisionbox. Now Pawn B gets 6 collisionboxes, which surround A's cube. Basically A's cube is embedded into a hallow cube which belongs to B.
This Cubeception can be placed somewhere inside one of the two pawns (which shouldn't be a problem, since there should be plenty room to do so in a BigShip).

Technically one single of those 'hooks' is sufficent to hold 2 Pawns together. If it turns out to be too wobbly, one can add multiple hooks inbetween 2 Pawns.

Also, if one used a sphere-collisionshape for A, which is held in place by 4 or more spheres belonging to B, one could create a 'hinge', e.g. for a Turret.

[x3n]

I think it's worth to give it a try