Thursday, May 17, 2012

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

Tuesday, May 8, 2012

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

Saturday, May 5, 2012

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

Wednesday, May 2, 2012

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

Tuesday, May 1, 2012

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