search

vegastrike / Vega-Strike-Engine-Source

Vega Strike Engine
Other
256 stars 42 forks source link

Game components are inefficiently and inconsistently created and stored #608

Open royfalk opened 2 years ago

royfalk commented 2 years ago

Currently, game components (ships, shields, jump engines, etc.) are inefficiently and inconsistently created and stored. Inefficient creation - every component is created separately. Inefficient storage - every component is listed in its own line and has all attributes, not just those relevant to it. Inconsistent creation - because of the inefficient storage, it's hard for the content creator to see that A is 20% better than B in a certain attribute and 20% worse than the average in another. Furthermore, the same overdrive, for example covers a small fighter and a capital ship.

Proposal

  1. Create components quickly and efficiently by generating them from existing templates.
  2. Either store components as a list of modifications to a base template (Lancelot - fighter 4, mod a, mod b, mod, z...) or generate them from this list.

Attached an excel demonstrating the above.

royfalk commented 2 years ago

vegastrike_components.ods

BenjamenMeyer commented 2 years ago

I'd prefer having a base heirarchy such that we have a series of component types, and each component type.

For example, a jump drive would be one component type while a reactor would be another type. Within each type, the attributes should be able to change. We'd have a shared common type for all just for internal storage purposes, but the immediate component type would define its own interfaces/attributes for it which may not all be shared.

So all component types would probably have some shared attributes:

So the initial WC Privateer game had the same issue as far as a single component type effecting all ships the same way, and PWCU may want to continue doing that; however, with Vega Strike games we probably do want to move to requiring more powerful ships (e.g. a capital ship) to use a bigger reactor than a smaller ship (e.g the llama).

Thoughts?

royfalk commented 2 years ago

I'd prefer having a base hierarchy such that we have a series of component types, and each component type. I agree with everything you said there, though I think we're discussing two different things. The excel is a way of generating a large number of consistent components. It should ultimately be ported to a series of yaml or some such files and a python script. This would be stored in asset-production or whatever it's called.

Once generated, the resulting JSON or yaml files will be in the form you wrote.

As for the class hierarchy, it sounds very much like what I thought.

Regarding PWCU, it is intentionally much more limited to small craft only (for game play), though there was an opportunity to get a capital ship at the end of the game in some versions.

BenjamenMeyer commented 2 years ago

Regarding PWCU, it is intentionally much more limited to small craft only (for game play), though there was an opportunity to get a capital ship at the end of the game in some versions.

The only difference between a players' craft and an AI craft should be that we have a module for the player vs an AI to control it. ;) We should save ourselves some hassle and build them both the same way if we're not already.