Tuesday, April 24, 2012

HUD Completed and another Basic Overview


The HUD portion is completed for the this prototype. It's still in the basic stages; however, there is now a timer for locking target process and a gun reticle. The gun reticle grows in size when there is a mouse hit to the target. Here are some screen shots of the "final" HUD:




Ordinarily, I would cover this process by providing code; however, I am going to go over the vehicle data script in this blog. In addition, I will cover a portion of a dummy load script, at least, the portion on how to access the player data (from a previous blog) and the vehicle data scripts.

The vehicle data script is very similar in design to the player data script. Its purpose is to store the vehicle's (usually a fighter) capabilities for other scripts. This script is very important to the flight control, fire control and countermeasure scripts. It also provides "benchmark" (the fighter's capabilites when it is undamaged) to the damage calculation routines. This allows for incremental deterioration of the ship's combat capabities.

Like the player data script, it consists of local variables, a load and find function, and a bunch of methods to access the local variables.  So, we need to populate the player data and vehicle data scripts.  I did this through a dummy load script.  This script is a temporary script designed to load a player controlled viper with some default values.  In the future, its functions will be handled by a resource manager.  Here’s the script:

This script loads the player, vehicle, flight control, fire control, faction control and dradis control scripts; however, we’ll just look at the player and vehicle data.  The actual viper has a player and vehicle script attached to it, along with the dummy load script.  In order for a script to access another script, you have to create a reference to it.  The statement “PlayerData vPlayerData = PlayerData.Find(vShip)” and the similar statement for VehicleData create that reference.  (The variable “vShip” represents the viper model and was defined by the statement “Transform vShip = transform”.) 

With the reference, the vVehicleDAta variable has direct access to the “VehicleData” script attached to the viper.  Any changes made within the vVehicleData variable automatically update the script attached to the ship.  The first manipulation of the vVehicleData is done in the statement “vVehicle.Load(…)”.  If you look at the vehicle data script, the Load statement takes a bunch of strings and float values and places them into variables such as the main thrust and fuel capacity variables.  The statement before the vehicle load statement loads player data values into the PlayerData script. 

Other scripts are loaded in this dummy load script.  For example, the statement following the vehicle data load handles the loading of data into the flight control script.  The flight control script, unlike our two data scripts, actually manipulates the data.  We’ll look at that script in a future blog...

2 comments:

  1. Great to see code in there. Something about the comments seems very unary. Maybe that's a CSharp thing, or maybe that's the same for Java - just seems like the comments would be better off inline with the variable names in the actual code in terms of immediate readability. You said you liked being able to read all the comments without looking at the code, and it's standard for other classes, but my concern would be that there's the risk the docs get out of date with the actual code.

    Of course a lot of doc systems will just extract the method header documentation so I think it's pretty common, but from a quick code scanning point of view it seems like a lot of extra typing and replication that can lead to things going out of sync.

    BTW, I think you'd find github integration a huge win:

    http://www.chrisdanielson.com/2011/06/04/unity3d-projects-version-control-git/

    I repeat that from our Skype chat partly because I think it's a win for you, but also, I can't really get much of a sense of the code without seeing the bigger picture. When I'm working with mobile programmers I can check their latest update out from github and have it immediately running in the phone simulator, because github helps me just update precisely the files they've changed and I don't need to re-receive all the major assets associated with the project.

    That way someone can be saying "I made this change", or "I have this problem" and I can immediately check out what it is and explore all the changes they've made in the code, as well as the base code that I maybe haven't seen yet.

    ReplyDelete
    Replies
    1. I'll look at it later. I'm just tickled to have gotten this far. I'll hit a lull in the development process in the near future. That should give my brain some extra processing power to devote to figuring out github.

      Delete