Thursday, November 8, 2012

Overview of Player Data


After the setting up the waypoint game objects, the Trigger Manager creates the player.  The first script loaded into memory to create a player is the player data script.  This script is simple data script used to define a player.  In addition to defining a player, this script also contains the basic data necessary to define non-player entities in the game. 
Here’s the script:

 
This is a simple script.  It only contains a series of methods to access the stored data.  However, it is used as a primary reference to drive accessing the database for player data.  Its primary purpose is to centralize the data relating to the player.  Centralization, while not necessary currently, will become essential to implement a system to track scores during and between missions.  In addition, it will become more important after I add skills to customize individual players.

Capital Ships: Launching and Landing Fighters

I've been busy the last few days; so, I haven't had time to flesh out exactly how to approach the capital ship's role in launching and landing fighter craft.  This blog will, hopefully, give me a clear road map as to how to to handle this aspect of the game.

First, landing isn't a big concern at this point.  The current system needs alot of polish; however, it does represent a functional, bare-bones skeleton.  Adding features to this can come later in the development process.  Right now, it is more important to get all the capital ship's features a skeleton for future development.  Consequently, this round of priorities will not see any additions to the landing of fighter craft on a battlestar.

Second, launching fighters needs some significant additions to the game. 

First, I need to add launch points associated with each launch tube on the current destroyer model.  This will be a simple empty game object oriented 90 degrees off from forward.  Obviously, the 90 degree offset will depend on whether the launch tube is located on the port or starboard side of the ship.  The launch points will be used as instantiation points for launching fighters. 

In addition, I need to create a dedicated fighter manager script for the battlestar.  This script will be attached to main battlestar game object.  It needs to contain a pilot list at the very least.  It probably will need a pilot list (representing all pilots attached to the battlestar), an active list (all pilots current launched and in space), a reserve list (all pilots that are still onboard the battlestar) and a killed list (list of pilots shot down during the mission).  The script will need methods to move pilots from list to list as necessary.  The full pilot list should contain the pilot's name (first and last), rank and fighter type.  The combination of fighter type and rank would point the script to retrieve a record from the database.  This data would represent the baseline data for a non-player character flying a certain fighter of a certain rank.  The name fields from the database file would be replaced by the first and last name of the pilot list's record. 

This script will also need a method to launch a fighter.  This is a simple instantiation process and will probably be similar to the one currently used in the trigger manager.  A more complex instantiation process will be necessary for the fighters that are already launched at the start of the mission.  This will lead to a change in the trigger manager and will possibly lead to a new trigger type.

To make this model happen, here are the steps that I will use to make things happen.

1.  Add launch points to the launch tube locations.
2.  Create a new FighterManager to be added to the battlestar's game object.
3.  Create a list for all, active, reserve and killed pilots with methods to move members between lists.
4.  Create an instantiation process to launch a fighter.
5.  Create an instantiation process for fighter's launched prior to the start of the mission.
6.  Create a dummy script to test all of these functions

This shouldn't be too hard to implement at this point.  It might take alittle time though...

Tuesday, November 6, 2012

The Role of Capital Ships

The Battlestar IP features capital ships and the small fighters.  In order to remain true to the IP, the game needs to keep capital ships as a meaningful part of the game.  To do that, I need to figure out exactly what role, capabilities and other features to include with capital ships. 

First, capital ships, whether a Battlestar or a Basestar, served as a launching base for the smaller fighters.  Vipers, and the older Scorpions in this game, primarily launch from a Battlestar.  While I do plan on adding some non-carrier capital ships to the game, this is an exception to the rule.  Consequently, each battlestar needs some type of landing control script.  This is actually the GravityControl script attached to the landing collider for each battlestar.  It produces some key triggers, like a fighter entered and landing reached trigger.  In addition, it applies an artifical gravity force to each fighter inside the landing bay.  This helps simulate the landing experience.  I would like to expand this script to include the landing beacon points to facilitate landing NPC fighters.  The current system is functional though, this addition is a low priority.

In addition, each Battlestar and Basestar should come with a fighter roster.  When triggered the capital ships would instantiate a fighter with the appropriate roster stats.  This will simulate launching a fighter.  In away, this will have a significan impact on the trigger manager.  While the trigger manager can still create a fighter, whether PC or NPC, the primary instantiation of a fighter would fall to the battlestar game object.  In addition, some controls would need to be put in place to keep a battlestar from launching more fighters than it has launch tubes.

Second, every battlestar has big guns, and every basestar seems to have big missiles.  While Colonial craft do have missiles and Cylon crafts have guns, the primary weapon focus seems to be faction driven.  However, guns and missiles share some key similarities that will allow them to be integrated into a single control script.  A rudimentary system is already in place to handle gun and missile turrets.  Turrets have scripting that will turn and fire them.  Unfortunately, they don't have an actual AI routine yet that will give commands to turn and fire.  That needs to be a priority.  The TurretControl script will accept commands from a TurretManager script.  The TurretManager will be attached to the main battlestar game object while the TurretControl is attached to each individual turret.  The manager will provide commands to the control script. 

Third, I want to break up the collider meshes for each capital ship.  A key tactic used in the actual TV series, both of them, was an attack on a key battlestar subsystem, usually the landing bay.  I want to give the players a chance to knock out key systems on a capital ship or protect a key system on a battlestar.  Landing bays, FTL drive, sublight engines and individual turrets are things that I think should be targetable at this stage.  While I won't incorporate a fine-tuned subsystem targeting system at this point, I want this feature ready to go for incorporation.

Fourth, I need to write moving parts scripts for each battlestar.  I think this will be determined by the battlestar's class.  For example, the landing bay retraction and extension numbers will probably be slightly different for a Columbia Class Battlestar (Galactica) than a Caprica Class Cruiser.  I will make it generic if possible; however, the initial iteration will probably be class specific.

Fifth, I need to create an AI controller for capital ships.  The FlightControl script is already in place to accept movement commands.  TurretControl exists to move and fire weapons; however, there is no methodology to command these scripts to execute.  A primary AI, CapShipAI, is needed to animate the big ships.  Unlike the relatively enclosed FighterAI script, this script will need to work closely with the TurretManager script.  Data should pass between the two to optimize firing positions.  The AI script will be in charge of determining roll and angling to protect key subsystems and maximize weapon deployment.  The TurretManager will be in charge of the actual deployment of weapons. 

That's alot of stuff I need for a capital ship...

Monday, November 5, 2012

Current Priorities

Well, I only got two of the five priorities done from the previous build; however, I think it is time to do another set of priorities.  The screen transition process has a decent start; the trigger manager is in a decent format.  Unfortunately, I'm sick of programming the trigger manager; so, I'll put the trigger manager off to side for awhile.

The major point that really irks me at this point is the lack of focus on the capital ships.  I need to address that issue before picking the trigger manager up again.  I need to figure out what functions the capital ships will play in missions and how they will impact the gameplay.  This is my first priority.  It's just something that has been sitting on the back burner for too long.  The goal in this step is to get a fully scripted battlestar and basestar into the game.  While getting capital ships integrated into the trigger manager won't happen in this step, the goal is have the system ready and fully operational for integration.

The second priority is to polish the HUD.  The transition screens introduced me to the GUILayout options available in Unity.  I want to convert some of the HUD to utilize these options.  In addition, I need to figure out how the alternate view will work in the game.  Currently, you can hit the "Shift" button to get to the alternate view, but it is nowhere close to being in a playable format at this point.  Part of the HUD overhaul will be fleshout this alternate view.  There is a strong possibility that I will have redesign some models to accommodate the alternate view; however, I'll get to that when I get to it.  I will probably release another build at this point; I anticipate it being build 2.61.

Third, I need to flesh out the trigger manager.  It's currently in the most basic form.  It only accepts a linear progression in a mission.  I need to add different trigger types to make the game more playable and user friendly.  This includes a delete trigger and possibility an "if-else" trigger.  I'll flesh out the options for the trigger manager after I stop being sick of dealing with it.  This will be a major step in getting the game into a more playable format.  In addition, capital ships will be implemented into the trigger manager at this time, and I will be looking at restructuring triggers to make them more database friendly.

Fourth, I will need to redo the first two tutorial missions with these new features.  The tentative plan is to have a "finalize" tutorial #1 and #2 mission at this point.  The goal is to make these missions "dummy proof" and adaptable to player mistakes and deviations.  This will represent a major restructuring of the game and will probably warrant a different build number, 2.70. 

Fifth, I will finish up the basic flight series.  I anticipate a total of five tutorials in this series.  The first one covers the basic flight operations.  The second one covers landing on a battlestar.  The third one is a quick run around the block where the player travels to each waypoint and lands the fighter.  The fourth mission will be a pre-test of the final.  The instructor will run the player through the final exam.  It will represent "hand holding" the player through the final.  The fifth mission will be the final.  In some ways, it will be more similar to an actual mission in that the instructor will limit her interactions with the player.  Each additional tutorial will represent a slight change in versions: 2.71, 2.72 and 2.73. 

My general rule is to complete three of the five priorities before reprioritizing again.  That means the fourth and fifth priority are subject to change at this point. 

Sunday, November 4, 2012

New Prototype Available

I completed the next build for the project.  This build represents prototype series 2 build 60.  It has a Windows 32 bit, Windows 64 bit and MAC version.  To install the game, the user will have to install the programs manually.  Each Windows versions consist of a .exe file, a resources folder and a database folder.  Each of these files need to be in the same folder for the proper execution of the game.  Personally, I recommand extracting the entire Build folder to My Documents.  This will ensure that all files remain in the correct location relative to each other.

Here's the link:

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

This game is still in a pre-alpha stage; however, some basic features are available.  This build incorporates a transition between missions.  These transition screens are in the most basic format.  I envision future builds incorporating a 3D avatar moving about the Battlestar between missions.  Unfortunately, that feature is long ways off at this point.  The current transition screens are only there to test the transitioning process. 

Feel free to provide feedback here.

Saturday, November 3, 2012

Screen Transitions Update

I got the game to go through the first cycle for the briefing, mission and debriefing for the first tutorial mission.  In theory, it should automatically kick into the second tutorial mission cycle.  I need to create the dialog audio and chat files for the second tutorial; so, I can't really confirm that it will work perfectly at this point. 

I did run into an issue getting the first mission to transition to the debriefing scene.  The end of mission checks occur during an Update() function which happens every frame.  It's part of the trigger check routine.  The mission would see a end mission trigger and run the appropriate command, Application.LoadLevel("Debriefing").  However, I failed to delete the trigger after executing this command.  Since the deinstantiation process for the mission, mostly due to having over ninety game objects in the scene, takes more than one frame to complete, the game would execute another LoadLevel() command before the completion of the first LoadLevel() command.  This quickly cascaded into a hard crash of the program. 

So, lesson learned.  Don't try to load level every frame without a method to keep multiple instances of LoadLevel() from happening in your game!  It took me two to three days to figure out what was going on with this.  I got it to work though and am generally happy with the results at this point.

Right now, I'm creating briefing and debriefing dialog for the second tutorial and creating chat records for each dialog used in the second tutorial series.  Once I get those done, I can see if the game flows from tutorial #1 to tutorial #2.  If it works without any problems, I will be releasing my first multi-leveled program for this project...

Thursday, November 1, 2012

Screenshots and the Chat Manager

I have started on the scene transitions and have completed the general layouts for the title and the mission briefing screen.  Here are the screen shots for the current screens:



These are just preliminary screens that probably won't survive for launch.  However, they provide a basic framework to start this phase of development.  In addition, I have the triggers created for the first first briefing and have updated all of the audio triggers for the first and second tutorial missions to be "chat" friendly. 

My current focus is on a basic chat window.  This window will have limited functionality at this point of the development cycle.  It's primary purpose is to accept and display text received from other scripts.  The primary purpose is to display dialogue from the instructor at this time.  Consequently, it will be simplistic at this stage of development.  It should have a method to receive new text from the SoundManager or another script.  It will take that text and display on the screen for the player.  The goal is to give a semi transparent background to keep it from interfering with the player's view of the battle space. 

The briefing screen will be primary location to test this new feature.  I'll have to nail down the timing issues within the game.  The text should only display right after the start of the dialog.  This means that queued speeches should be ignored until the it is actually executed by the sound manager.  This means that the sound manager and chat manager have to work closely together. 

I'll have to sit down and plan this out...