Thursday, September 27, 2012

Event Manager

My computer took a dive, and I just got it up and running again.  Consequently, this is my first post in awhile.  I have been reviewing my approach to creating an event manager, and I decided to change my approach (again).  I learned to program back in the 80's, and the popular trend was top-down programming.  I lose sight of some of those principles when programming in the modern world.  I'm changing my approach to a more top-down methodology. 

The goal is to create a trigger manager that passes each trigger to specialized trigger managers.  For example, the primary trigger manager will receive all the trigger events for a mission.  Based on the name, it will pass instantiation of fighter craft to the appropriate manager and audio triggers to an audio manager.  Currently, the game will need a fighter, waypoint, generic object, audio and destruction managers.  In addition, a capital ship manager will become necessary as the game progresses.  Each of these managers will receive data from the primary trigger manager. 

The primary trigger manager will grab data from a trigger table.  The trigger table fields are:

OID (Primary key)
Mission Name : String  // Used to query by mission name
Name : String                // First three letters designate a target table; full name is a key field
Trigger : String             // Name of trigger that triggers the event
Time : Float                  // Time index (if it's a time trigger) or time delay (on other triggers)
Position : Vector3         // x, y and z coordinates for the instantition of objects
Rotation : Vector3        // x, y and z rotation for the instantition of objects

The Name field will contain the action category in the form of a three letter prefix.  The following managers will have these associated prefixes:

Fighter instantiation - ftr
Waypoint instantiation - way
Generic Object instantiation - obj
Audio commands - aud
Destruction commands - des

The prefix will be followed by a unique identifier.  The prefix will direct the data to the appropriate manager and its associated table.  The full name will be used as a search key for a unique record in the table.  This record will contain additional data, like basic fighter data, needed to properly execute the desired action. 

The trigger table will be sorted by the time field and read into a list.  The trigger manager will read from the list by retrieving on a first item basis.  During the normal update procedure, the trigger manager will retrieve the first "Time" event from the list and will compare time indexes.  If the event needs to be executed, it passes it the appropriate manager for immediate execution.  As the trigger manager receives triggers from other scripts, it retrieves the first item with the trigger name.  If an item is retrieved, it is passed to appropriate manager.  That manager handles any time delays that might be present for the action. 

The plan is to create the primary trigger manager followed by the audio manager, generic object manager, waypoint manager, fighter manager and destruction manager in that order. 

6 comments:

  1. In order to dynamically load audio files (or any other type of file) in Unity 3D, I have to keep the audio clip in the resources folder. This folder can get very large in a hurry.

    The resources folder is also loaded with the game. This will happen during the startup splash screen for the game, not the mission; so, retrieval should be relatively quick during an actual mission. However, the file size the game could explode in size.

    I'll deal with the size issue when it presents itself. Right now, I'll continue on the assumption that I can get dynamic loading to work for the game.

    To make it work, I have to carefully manage this resources folder. I can't create subfolders due to using the free version of Unity. To keep these files organized, I will have to categorize via names.

    All files will have a prefix identical to their triggering prefix. Audio files will have an "aud" prefix, fighter objects will have a "ftr" prefix and so on.

    In addition, I will use a secondary prefix (a prefix following the first prefix) to identify the mission. Each mission will end up with a three alphanumeric designator. Following both of these prefixes will be a short description of the clip, fighter or other object.

    As an example, the introduction audio clip present in the first tutorial will have a file name of "audtt1Introduction". This file would equal to audio clip (aud) in the mission "tutorial #1" (tt1) and is the introduction clip (Introduction).

    Everything that goes into the resources folder will follow this convention. We'll see how that goes...

    ReplyDelete
  2. I got the audio triggers to work, at least as far as I have tested the audio triggers. Next item on the list is to create a generic objection creation routine. I'll add a couple of asteroids (big ones, really big ones) to the first tutorial. I'll try to instantiate those during the startup routine using the trigger manager...

    ReplyDelete
  3. Just looking at a generic object, I have a player data, vehicle data, flight control, damage control, dradis control and faction control scripts attached to it. In addition, I want a scaling control to control the overall size and the scaling functions for the x, y and z axis. Position and rotation is already in place in the trigger section.

    Consequently, I need to create a table and accessing function for each of scripts. In can integrate the fighter tables into these tables; I just need to keep the records for fighters distinctive from generic objects. The player data, vehicle data, flight control, damage control, dradis control and faction control can be reused in the fighter instantiation process. The scaling controls will be unique to the generic object.

    In addition, I think I might add two randomizer fields into the scaling controls. This might allow for an "increase" in the number of asteroids and other objects into the game. There will be a single randomizer for the overall scale, and another randomizer for the axis. If the randomizer is true, then the object will range from 50 - 100% of scaling size.

    ReplyDelete
  4. I finished the database routines to access the data for the player data and vehicle data scripts. I feel kind of stupid; the other four scripts derive all data from the player and vehicle data scripts. That means I don't have to create any database components for those scripts. I just need to take the data in the player and vehicle data scripts and route them to the other scripts within the game.

    Before doing that, I will work on creating a database table and access function for the scaling functions. I'm taking out the overall portion. There will be an x, y and z float variable, much like a coordinate system (Vector3). In addition, there will be a randomize boolean variable. If true, then Unity will randomly determin the size from 50% to 100% of the x, y or z value.

    I'll post when the database component is completed.

    ReplyDelete
  5. The database component for scaling is complete; now comes the difficult part of putting it all together inside Unity...

    ReplyDelete
  6. Gameobjects now instantiate into the game via triggers...

    I had a problem with instantiating the objects as a RigidBody; I just instantiated them as a GameObject. That solved that problem; however, it might become a real issue when instantiating fighters. I have to bring them into the game as a RigidBody...

    I cross that bridge when it needs crossing...

    ReplyDelete