Saturday, December 7, 2013

Damage Control

The more I jot down notes for this script, the more I realize that this script will undergo some huge changes.  In previous versions, Damage Control was a relatively small script with a specific objective that really didn't need to exist outside of Flight Control.  Now, it might just get to be a key script with a lot of code.

Basically, it will have access to the Flight Control script and will be able to update the current structure of the parent ship.  Right now, this is its only true interaction with Flight Control.  In addition, it will need a list of interchangeable parts.  This is where Damage Control will start to get complicated.

The list of interchangeable parts will actually be a list of a programmer defined type.  This type will contain a collider, a component, a replacement component and a damage threshold.  Basically, this script will get the collider hit by an attack.  It will find the collider, if the collider is in the list, and compare the amount of damage dealt to the damage threshold.  If the damage dealt exceeds the damage threshold, the script will "turn off" the original component and "turn on" the damage component.  This will allow space craft to be visually damaged in the game. 

In addition to these visual effects, damaging a craft should have an actual effect on the effectiveness of the craft.  Consequently, this script will need a series of subsystems.  When a collider is "hit", this script will also check for a keyword.  For example, the "left engine" collider has the keyword "engine".  These keywords will funnel hits on specific parts of the ship in a certain direction.

With a keyword system in place, the script will damage various subsystems.  An "engine" hit can affect "thrust", "fuel consumption rate" or other set subsystems.  Hits to other keywords can affect an entirely different set of subsystems. 

So, what are subsystems?  A subsystem is simply a float value representing a percentage.  Hitting the sensor subsystem would decrease the maximum sensor range by a certain percentage.  Hitting the maneuverability subsystem would have a similar effect on the ship's ability to turn.  Other systems would see an increase.  For example, damaging the fuel lines would increase the fuel consumption rate by a certain percentage.

Each of these subsystems would be accessible by other scripts.  The HUD Control would look up the sensor subsystem and incorporate that number into what is displayed to the player.  Flight Control would look up other relevant subsystems, like the fuel consumption, maneuverability and thrusting subsystems as part of its calculations. 

The plan is to eventually make Damage Control into a database compliant object.  This will allow me to use Damage Control to customize various ships using a single model or model set.  Actually, it may be two different database tables: one for cosmetics and another for subsystems.  However, this particular feature will be further down the road.  I will develop this script with a preload routine.  A "testing" script, will be attached to each object and will load the default values for a ship for the time being.  I want to see the new script in action before developing the database portion.

Monday, December 2, 2013

December

I've been busy the last two weeks with work; however, this did give some time to mull things over. 

First, I really don't want to import models into the game until I am ready to texture them.  I hate to say it, but prematurely importing models will just create a situation with I have 15 models of the same plane with only one being used by the game.  I should be getting a texturing program before Christmas; so, I will hold off on importing models until then.

Second, Damage Control will be undergoing a huge revision.  It's going to be a bigger revision than I originally anticipated earlier.  Many features found in the older Flight Control will migrate here.  I'll write a blog dedicated to the changes, but Damage Control will look completely, well very, different from previous versions.

Third, I want to institute a new system in loading scripts.  In the future, I will have to game files.  The first will be the working copy.  I will use a liberal import rule for this version.  When a system is done, I will export it from the working copy and import it into the current copy.  This is just to practice some quality control.  Past prototypes got bogged down with unused models, discarded scripts and many other things.  Every once and awhile, I do plan on purging the working copy and creating a new working copy based on the current copy. 

That's about it for right now.  I got the model done...  Well, ready for painting.  I have the basic colliders ready.  I just need to get a painting program.  I want to map out the changes for the new Damage Control script.  I'm still in the process of discarding, reincorporating and rethinking the script...