Saturday, August 4, 2012

Triggered Events

Well, I stepped away from BSG for a few weeks.  I needed the rest.  I started working on it again this past week.  I created a new destroyer which should be more visually pleasing than the original one I created a few months ago.  In addition, I created a model for the Scropion fighter that will be used as the "starter" fighter. 

Here are a couple of images of the untextured versions (I don't have a good texturing setup at this time - btw, you can click on an image to enlarge it):

The Battlestar Trident (Destroyer):

Scropion Class Fighter (mk1):

I wanted both of these ships in the first tutorial, even if they aren't textured at this point.  Both ships play a predominant role in the early game.  It just makes sense to create both ships.  In addition, it gave me more practice at the model creation process.  In addition to these ships, I do have plans to build some asteroids (low polygon count, which is difficult to find), a space station and a "starter" Cylon fighter craft. 

As for the tutorial, I have started some work on it.  I have created a means to access the database and a means to retrieve player and vehicle data from it.  I started to create another access module for mission data related to vehicles and objects.  There are some issues that I need to consider before proceeding with this module. 

First, there will be very few static models in a mission.  Models, whether it is an asteroid or fighter, will be instantiated by the resource manager.  The only static objects will be manager objects, even some of these will be instantiated by the resource manager.  This will require a great deal of information to be stored inside the database.  For example, the positions of all fighters in a mission will need to be stored in the database.  When the mission loads, the resource manager gets each fighter along with positional and rotational data and instatiates it into the mission at time index zero. 

Second, triggers need to be incorporated into the manager early in the development cycle.  Triggers can be a time index or the player entering a trigger area.  Each of these triggers need to be recorded into the database.  The resource manager will load this data and track the triggers.  The problem is identifying and implementing the triggers.  Timed triggers are relatively straightforward.  Other triggers can be problematic.  Here are some triggers that I can think of (along with some variables associated with the trigger):

Timed  - requires a time index value - what is the event
Enter - requires a triggering object - triggering distance - what is the event
Enter (delayed) requires a triggering object - triggering distance - time delay value - what is the event
Exit - requires an triggering object - triggering distance - what is the event
Exit (delayed) requires a triggering object - triggering distance - time delay value - what is the event
Destruction - requires a triggering object - what is the event
Health Trigger - requires a triggering object - triggering health value - what is the event

While I covered instantiate events, there are other events: audio execution, destroy object and others. 

Third, the system needs to be flexible enough to implement new trigger events and actions.  While the tutorial will have a timed, enter and delayed enter trigger events that involve executing audio, the systems needs to be able to easily implement code to include other trigger events and actions like instantiating an object.  This also applies to the database.  If the database cannot hold the data, it design of the code won't matter. 

So, what is the solution?  I'm going to think about it some and attempt to plan out the interactions between the code and database.  If anyone has a suggestion, I'd love to hear it...


  1. Not really sure what the issue is here without more details about the database. Is it relational? Can you store code in it? Are you trying to create an events table? I can't see any problem with having multiple types of events in different tables ...

  2. Basically, i want to create a system that I don't have to redo at a later date. I've done enough recoding for this project. For example, the event manager from the previous build is not sufficient for this prototype. It as too many limitation and expanding it would consume more time than creating a new system.

    The database is, well to put it bluntly, sucks compared to other databases on the market. However, it's lack of features allow it to easily interface with Unity and is one of the few databases out there that does interface with few issues. It's not relational or dynamic. It's just a database; luckily, I have a good amount of experience with databases. I can make it act relational through the design process.

    I'm not sure how to approach the event manager at this point. I could use a system that stores the event (or trigger type), a trigger descriptor (to allow flexibility in the handling a trigger), a time field, a distance field (or a combined time/distance field), a trigger object field and an action object(or string pointing to an audio file...). These fields, of course, would be one object, and the event manager would keep a list of these objects. In a way, it would act like a list of lines of interpreted code with the action field being the statement and the other fields being the arguments.

    However, I'm not sure if those will be sufficient for the game. Is it descriptive enough for future features? Will it be flexible enough? I'm just not sold on it yet. I have to look at what I want done and what I might want done and determine if it will work in the grand scheme of things...

  3. I wonder if this would work...

    Instead of tracking each trigger type. The resource manager could load trigger objects into the game. For example, an area trigger object (invisible to the player) would exist at a waypoint coordinate. When the player (or another object) enters the area, it sends a trigger value to the resource manager. This trigger value is stored in the event manager and executes the appropriate action. Other triggers could happen in this manner. When a fighter or capital ship drops to 50% health (or other values), it sends a trigger to the resource manager. The resource manager then checks the trigger list and executes (if applicable) the appropriate action.

    In addition to this, the event manager would still track timed events. For example, the intial instatiation of all game objects would happen at time index zero. A voice over could occur at time index one.

    This might alleviate some of the problems that I've been thinking of. With this setup, I just need a trigger name (and time value) and action data stored in the database. This is much better than the cluster I was thinking of previously.

    The problem then boils down to implementing actions in a clean and organized manner...