I finished up the Mission and MissionData classes earlier today. They weren't too hard. Most of these data structures follow a pretty standard format. Alot of work can be avoid by copy and paste followed by a replace all. I also forgot to add key database functions to the Turret and TurretData class. I fixed that issue. All four classes should be go to go at this point.
I decided to play around with some graphics. One of my biggest problems in past prototypes was presenting a great visual background. I was using a space sphere. I basically created a sphere in Blender and flipped the normals. That basically allowed you to see the sphere from the inside. I then scaled it and put in the scene with a generic starfield. I found a better way just messing around with Unity3D.
Unity3D, as I discovered, has two built-in methods for skyboxes. The first is to set a skybox by using the Edit>Render Setting option. This will pull up a global setting which include a global skybox texture field. The second method, the one I plan on using in the future, uses the camera. You just select the camera and add a skybox by choosing Component>Rendering>Skybox. This adds a skybox script to the camera. You just drag your skybox texture onto the correct field. Alternately, you can set a new texture with code. You reference the camera, find the skybox script and set the texture field to the desired texture. I'll be using this method in the future.
Which brings me back to the Mission and MissionData classes. I need to add a field for the skybox texture to both classes. The mission will detail the desired background. This will be a string field, and backgrounds will be stored in the "Resource" folder. A "Random" value in this field will lead to a random generation of the background.
After that, I will start working on the Player class. This class will store the basic data for a player and will probably be extended from the entity type. The Player class should hold additional basic data like the amount of prestige earned by the player. This shouldn't be hard to implement.
This will be followed by the first real trigger type. I will work on a method to load a player into a scene. This will require a positioning trigger. This will require a position variable which should include a X, Y and Z. In addition, the trigger should contain a starting rotation which should also include a X, Y and Z or pitch, yaw and roll. It will also include a starting speed. It will also need to reference a player OID. The loading routines for non-player entities will reference an Entity OID. We can keep this in one table by adding a player flag flield. I already created a GameVector class to hold the X, Y and Z data. So, the class will need:
MissionOID (for reference purposes)
EntityOID (used to reference the Player or Entity class)
Player (boolean; true will tell the class to reference the Player class, false = Entity class)
While the class looks like it will be more complex, it really won't at this stage. The decision to use the Player or Entity class will occur in Unity3D. I'm not touching Unity3D at this point; my goal is get my tools in place first. I might have to go back to the Entity class and add a constructor and function to set the record by using an existing Player class...