Starting to Finalize the Starting Colonial Battlestars

I converted my Berzerk Class Battlestar into a mesh that will be usable with the new prototype.  I didn't have to change any major features.  I just broke the model back down to its basic components and recombined the components into something more game development friendly.  Here are the pictures of the new
model:

I also used a size comparison picture:

Compared to the Hercules, the Berzerk seems very "light".  Consequently, I will use displacement to classify battlestars.  In this case, the Berzerk and
the Hercules are both cruisers. 

In addition, I started on the Defender class destroyer.  It's a much smaller ship and has been seen in the Battlestar universe.  It's a fan made creation that made it into the series, and it does have some minor issues.  For its size, the landing bay is too small to be practical.  You can't land a Viper or Scorpion in the landing bay safely.  It has no launch tubes, and this makes deploying fighters highly problematic.

On the upside, its weapon coverage in the forward firing arc is very impressive.  To me, its a destroyer and recon ship.  By enlarging the landing bay, it can deploy a single, or maybe two, fighters to scout an area.  The fighters would have to make a "ground" takeoff, but that is just a tradeoff for making a smaller ship. 

The ship is still in the preliminary stages; however, here are some pics of the development:

So, I think I will concentrate on having the:

Columbia (basic Galatica body)
Berzerk (Cruiser)
Hercules (Cruiser)
Defender (Destroyer)

Along with the:

Orion (Destroyer - from Blood and Chrome)
Pericles (Destroyer - yet to be developed destroyer from me)

These are ships that will figure predominantly in the game's early war fighting efforts.  I'll leave other ships like the Valkyrie Type Battlestar for later portions of the war. 

Back

My last attempt to refractor the older prototype was a...  disaster.  I'm going to go another direction.  I'm keeping the last prototype; however, I will internally rewrite all of the major scripts.  Once the scripts have been finalized, I will move those scripts to a new project and upload new models into the game. 

I have been working on some of the models.  I want to standardize what I will be incorporating into the game before finalizing scripts.  I have the Scorpion fighter somewhat textured at this point:

It's not done, and there are things I want to add to the texturing map.  However, it is a move in the right direction.

In addition, I created the standard destroyer for the Caprican fleet.  It's based loosely on the Battlestar Galactica.  It is smaller and is designed as a support craft for the larger battlestar.  It is currently untextured and will be replacing a previous concept of a destroyer/cruiser.

The final picture represents the ship with its turrets and other final touch up details.  It should be ready for export to my texturing program. 

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.

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...

Update (November 17, 2013)

I've been offline for the past few days.  I went on trip and spent a lot of time in a car without any internet access.  Before my trip, my computer crashed and required a complete refresh.  I managed to save my game files for this prototype and the previous prototype.  Unfortunately, I couldn't save the programs; I had to reformat and reinstall Windows. 

I've been spending a lot of time reinstalling important programs.  Unity3D is reinstalled; I just reinstalled 3DS Max.  Those are the two important programs.  At this point, I can start making progress again. 

Scorpion Class Fighter

I'm going to be extremely busy for, at least, the next week.  I probably won't be able to post for awhile.  I'll probably get to work some on the project, but that time will be limited.  At this point, I got a functional, well hopefully, flight control script.  There really isn't any great way of testing it at this point.  I need a couple of things to start testing.

First, I need to import the "official" Scorpion fighter.  I got the mesh done.  I still need to create a collider system for it, and I need to create "damaged" parts for the model.  These are the pics of finalized Scorpion:

I still haven't textured this model.  I do plan on getting a decent texturing program this month.  Once I get this model fully imported, I still need to work on a couple of scripts.

I will need a PlayerControl script.  This script will allow me to input movement commands and test FlightControl.  After PlayerControl, I will work on the FireControl and DamageControl scripts.  HUDControl will be the final script developed for the game object.  I might have to develop a level wide FactionManager to make HUDControl functional though. 

So, this week will involve prepping the Scropion to be imported in Unity3D and developing a good flow for the PlayerControl script. 

The New FlightControl

FlightControl is up next.  I just wanted to make some quick points on the new direction of the script. 

First, FlightControl will become a universal script.  Every interactible object will have a flight control script attached to it.  This is to standardize the access of various types of game objects.

Second, this script will receive its inputs from PlayerControl, FighterControl or some other script.  While this script is in charge with the "physical" movement of a vehicle, it cannot move a vehicle without being told to do so by another script.  This means that I will have to move the player control elements from the old FlightControl into the new PlayerControl.  As a side note, FlightControl will end up being an "input" for most scripts attached to a vehicle.

Third, it will use an applied thrust and turn variable like the previous version.  These values will range from -1 to 1 and will be used like percentages.  The turn variable will be a Vector3 with each coordinate representing a different turn component.  X will represent yaw.  Y will represent pitch.  Z will represent roll.  Applied thrust, like the previous prototype, will be a float; however, I want to make significant changes to the thrusting system with this prototype.  There will not be a set maximum speed in this iteration; the maximum speed value stored in the Vehicle type will represent a speed increment.  The amount of applied thrust will be dependent on current speed of the craft.  This equation will be the basis for determining the amount of thrust to apply to the craft:

      applied thrust = (1/(2^(current speed / maximum speed)))thrust

As a vehicle travels faster, it will become more difficult to turn the craft.  On the flip side, craft can travel faster.

Fourth, setting whether a player is in charge of the script will be removed from FlightControl.  The existence of the PlayerControl script will be sufficient to designate a player controlled craft.  This "setting" will occur as part of the triggering process.

Fifth, FlightControl will continue to have the basic collider listeners from previous prototypes.  This will make DamageControl very dependent on FlightControl.  I'm just not prepared to make the alteration of separating the listeners from FlightControl at this point.  I will note that the FlightControl script, in itself, will not touch the structure values.  This will be left up to DamageControl.

Depsite these changes, I don't anticipate FlightControl going through a major coding rewrite.  Most code from the previous prototypes will be lifted straight out of the previous version.  Except for the thrusting rewrite, FlightControl will mostly see a cut in the amount of code in it.  Alot of the past code will be cut and pasted into other scripts.