Final Update (before Finals)

This is my final version before dedicating myself to my finals. The key features added in this version are:

>> Landing bay gravity (only on the Colonial destroyer at this point)
>> Automatic damage mitigation for larger objects (it's just harder for a viper to destroy a basestar - I had to add this so the structure numbers don't get out of hand)
>> Landing Gears (you can press "L" for landing gears - they don't anything yet; so, you will still take some damage when landing)
>> Landing (you can land on the destroyer!)
>> Turret controls (turrets should go around and around - there's a default value being inputted to all turrets - the system works for when I decide to put AI routines in)
>> Turret destruction (you can destroy turrets without destroying the big ship - the colonial destroyer is the only ship with turrets at this point - but you can test it out)
>> Turret take damage, and damage effects the efficiency of the turret.
>> A colonial destroyer (christened the Hermes Class Destroyer by me - it's even mostly textured)
>> A cylon destroyer (not textured at this point for really functional beyond target practice)

In the next version, I will focus on completing the turret control and develop missile launchers. As it stands, I need to complete the loading functios for turrets. Each turret has a fire zone; a turret should not be able to turn and face its own ship. To facilitate this, I need to define the fire zone for each turret. This will be done via the database. Each turret will be stored and sorted by the turret designation (each turret on a capital ship will have a designation) and ship classification. This means turret TT11 for a Hermes class destroyer may have a different fire zone than turret TT11 on the Battlestar Galactica.

In addition to fire zone information, I will need to store the basic parameter (like vehicle data, turret control, fire control and other variables) in the database. During the Start() routine for the parent ship, these values will be loaded into each turret.

Missile launchers will follow a similar design philosphy. The only real difference will be the projectile and in the AI routines. Bullets require a good line of sight setup to hit a target; missiles can be a release and forget variety. Missiles, after all, can have independent guidance systems. If I can get the turrets completed, I should be able to get missile launchers up and running without any major issue.

With turrets and missile launchers out of the way, I will probably have enough of a game framework to start on the AI routines and mission development. That's assuming that I have not missed anything significant (it's been known to happen on occassion).

At any rate, here is the latest prototype. I think there is a crash error somewhere in this version; however, I have not been able to pin it down. If anyone finds it, I would appreciate the output and crash logs. In addition, a description of what was going on would be really appreciated...

http://dl.dropbox.com/u/43398523/Builds.rar

Update (Late I guess)

School has been hectic lately; so, I haven't been posting here much.  I ave not worked on the project for at least a wek either.  However, I did take time to do some work on the project before finals week (military campus semester). 

I found a couple of issues that set me back somewhat.  First, the turret control system was not functioning with my parameters.  I went back into the class and reworked it.  Basically, the turret control system is a cross between the flight control and the HUD's camera control systems.  It does not utilize a smooth move concept used in the flight control due to the limited update functions in the module. 

Here is the class:


I added sections to make the class functional without an actual load routine system.  The Start() and FixedUpdate() routines have extra statements inserted to make the module functional.  The turrets with this script (along with the PlayerData and VehicleData classes) rotate in a circle.  I've also tested the elevation commands for the turret, and they are functional. 

With this module in place, I can now create the load routines.  I've decided to change the loading routine process (as per my previous posts).  Each turret will only need a fire zone loaded into each turret.  Cutout zones will be simulated by a different method than I originally designed in my last post.

Before firing the guns, the fire control routine will do a line of sight check.  If the ray generated by this process "hits" a friendly target, then the weapon will not fire.  This routine will be inserted into the fire control class. 

I may have to change the setup fo each gun enabled ship in the game.  Each bullet spawn point will need to changed into a camera (cameras easier to implement a draw ray function).  If a ray intersects with a friendly target from these cameras; the weapon won't fire. 

Also, I will need to address the ability to target turrets (and in the future, missile launchers) via a missile lock.  I'm still considering the best way of addressing this issue.

Modeling a Colonial Destroyer

I've been busy this past week.  The time I have spent on Battlestar has been devoted to building a new destroyer for Colonial faction.  Having spent very little time creating models before this, it took me awhile to get a good grasp on the process.  After many failed attempts, I finally produced a semi-finished product.  This is the Battlestar Hermes (at least a Hermes class destroyer) after texturing it in 3D Coat:

This model does not include the turrets.  I decided to add those in Unity itself due to my plans on how to get the turrets and ship to interact.  I actually think I did a decent job of building the model...

However, there were issues in importing it into Unity3D.  I still have not resolved these issues.  The problem is that the texture map is not fully porting over to Unity.  The main engine part of the ship is not textured in Unity.  Here are some screen shots of the destroyer in Unity:

I'm done (mostly due to frustration) with importing the destroyer for now.  I decided to move onto creating the scripts to control the destroyer.  The destroyer, which should be like the other capital ships, will need the same scripts involved in defining a fighter craft.  Player data, vehicle data, flight control and damage control should all work on the capital ship.  Fire control will not exist; however, a turret supersivor script will replace it.  The turret supervisor will load each turret with its important data, such as: firing zones, firing rate, turn rate and so on. 

The turrets will also need control scripts.  Each turret will have a player data (I'm still debating this; however, it will probably be included for score tracking purposes), vehicle data and fire control scripts.  Instead of a flight control, it will have a turret control.  This script will be in charge with the task of turning the turret and making sure it does not go into a fire cutout zone (i.e. pointing the turret at part of the ship). 

These are just control scripts.  In addition, the capital ship and the turrets will have dedicated artificial intelligence scripts.  The turret AI script will get inputs from the destroyer's AI script.  The destroyer will pass target information or will toggle the turret to a certain direction for a sustained covering fire. 

The main issue that I forsee is the parent/child relationship between ship and turret.  My goal is to make each turret a destructable object.  A viper (or a cylon raider) could knock out a turret (and some mission objectives will revolve around this).  However, the way Unity handles collisions might make this somewhat problematic.  I might have to write a dedicated damage control script for child game objects.

Once I get the turrets to work (at least in the damage control sense), I will create missile launch silos.  These, like turrets, will be destructable objects.  Cylons will rely on missiles while Colonial forces will rely on turrets.  After the creation of missile silos, I will go back to creating models.  I will need a Cylon destroyer (a smaller ship than the Basestar) to allow adequate testing.  The player will be able to destroy turrets and silos at that point...

Prototype 2.12

I got the mouse look to work in world view, and I updated the models to support this view.  Basically, the models now have a cockpit...

Here's the build:

http://dl.dropbox.com/u/43398523/Builds.rar

Project Restored!

After troubleshooting the issue, I managed to rebuild the project.  I had created so many test scripts within the original project; there was bound to be a conflict.  Unfortunately, this conflict caused the entire project file to fail to compile or build without sufficient errors to track down the problem.

I rebuilt the project and deleted any failed (or unnecessary) testing scripts.  An unfortunate side effect was the need to rebuild all the models (with associated references to existing scripts).  Luckily, there were only a few models in the game (cylon raider, npc viper, two asteroids and the player's viper). 

After getting all of this resolved, I started to complete the goals for the new UI; however, I discovered a major flaw in my Faction Control algorithms.  While the script was functional (at least before the rebuild), it was a performance hog.  I went back and streamlined the process and eliminated every unnecessary statement without compromising the intended utility of the script.  Since, it's excessive memory usage would have impacted the ability of the player to test the next prototype; I dropped the UI in favor of fixing this issue. 

After fixing the issue, I finished up the UI portion and got everything to work (at least I think I did).  Here's the latest prototype:

http://dl.dropbox.com/u/43398523/Build.zip

This is not a webplayer like the last few builds.  I'm still working on getting the database to play nice wih the web.  Just download the build zip file and unzip it to anywhere on your computer and select the PrototypeV2b12.exe to run the game.  It will build a database in the Build folder and run the game.  If you play the game again, I recommend deleting the database folder.  While it shouldn't be a big deal (and won't after the database functions are fully programmed into the game), it could create duplicate database entries that could cause some problems if they are not cleaned before each use. 

Here are the basic controls for this build:

<w/s> or <mouse scroll> - increase / decrease thrust
<a/d> - roll the ship
<space> - inertial thrusters
<ctrl> + <w/a/s/d> - applies directional thrusters (disabled on Vipers; available on Raptors)
<mouse button #1> or <f> - guns
<mouse button #2> or <g> - missiles
<v> - countermeasures
<mouse position> - turn

In addition, I will be putting an alternate setup into the game.  The user can toggle this mode on and off by pressing the shift key (just once to toggle - not the constant press).

<w/a/s/d> - turns the ship
<e/q> - roll the ship
<mouse scroll> or <r/t> - increases / decreases thrust
<ctrl> + <w/a/s/d> - applies directional thrusters (disabled on Vipers; available on Raptors)
<button #1> or <f> - guns
<button #2> or <g> - missiles
<v> - countermeasures

The next build will feature a camera move feature in the world view mode (the second one). 

I Crashed Unity...

Well, I was working on upgrading the user interface when Unity crashed on me.  My C# editor now refuses to compile the game, and it won't give me a good error message.  Basically, the error states that the compiler encountered an error and to refer to the output text file; however, there is no output text file...

I guess in this situation, I'll have to rebuild the project.  I will slowly import each set of scripts until I discover the error.  At that point, I should have an idea on how to fix it...

Sorry that this is a short post; I just have a headache now...

Prototype 2.1 Feedback

Based off of suggestions from various (meaning two people) on the input controls, I am going to try the following setup:

<w/s> or <mouse scroll> - increase / decrease thrust
<a/d> - roll the ship
<space> - inertial thrusters
<ctrl> + <w/a/s/d> - applies directional thrusters (disabled on Vipers; available on Raptors)
<mouse button #1> or <f>  - guns
<mouse button #2> or <g> - missiles
<v> - countermeasures
<mouse position> - turn

In addition, I will be putting an alternate setup into the game.  While current model does not support this feature (it's just no built right), I do plan on developing the preliminary routines to make it work.  Basically, the user can toggle this mode on and off by pressing the shift key (just once to toggle - not the constant press).

<mouse position> - turns the camera
<w/a/s/d> - turns the ship
<e/q> - roll the ship
<mouse scroll> or <r/t> - increases / decreases thrust
<ctrl> + <w/a/s/d> - applies directional thrusters (disabled on Vipers; available on Raptors)
<button #1> or <f> - guns
<button #2> or <g> - missiles
<v> - countermeasures

In this setup, the current HUD setup will become unavailable.  The goal is to eventually put some type of "real world" instrumentation in the cockpit and let the player to look out the side windows while maintaining control of the fighter.

It was suggested that the game be completely playable from the keyboard, and I do agree with this principle for the most part.  I'm just having a problem visualizing the method without making the game too complicated for the average user.  However, I will be adding (sometime in the future) a customization feature for players to keymap their own preference.

First step is first though.  I want to get the first setup working and functional.  I got the mouse scroll to act as a thruster control.  There is an issue of implementing the <ctrl> feature with Unity; however, I will just have to figure it out.  I do have to add a visual representation of the thruster to the HUD.  After that, I need to develop the toggle feature and implement across the flight control and HUD control scripts (which shouldn't be too hard), but I was thinking that in regards to the <ctrl> feature...  Finally, I need to implement the alternative control features.  The camera movement might present a problem; however, the other features are just an alternate keymap.  Creating an alternate key map might be a pain though...

After all that, I'll start on the custom keymap feature.  That'll probably follow other features though.  You know, the important ones like functonal NPC fighters shooting at you...