Tuesday, October 30, 2012

Starting Scene Transitions

Now that I have two tutorial missions, it's time to create a transition between the tutorials.  To start this process, I will concentrate on building a very simplistic transition system.  Complexity will happen after I finalize things like a scoring system, experience point rewards, a skill system and other features.  That is further down the development process.

To start, there are two key mission loading variables: the mission name and player code.  The mission name dictates what triggers get loaded into the scene.  This includes the loading of asteroids, other fighter and, in the future, capital ships.  It also determines what waypoints are placed into the missions along with any mission objectives.  The player code, on the other hand, loads the player's fighters which can vary in combat capability in the future.

Consequently, the initial iteration of the mission tracker needs to incorporate a mission name and a player code.  Since we are bypassing character creation in this prototype, the player code can be a static "plydftAbanathie".  This is the Scorpion fighter used in the current prototypes. 

The mission names are more complex.  First, the game will need a "generic" mission briefing and debriefing scenes.  In future versions, these will be animated scenes with a NPC avatar briefing or debriefing the player.  In this initial version, it will be a simple menu screen with a section of text that will impart the contents of the briefing or debriefing scene.  These scenes will need to be able to get the next mission, briefing or debriefing data from a table. 

There are a couple things that are pretty static.  We always start with a briefing.  That is followed by a mission which is followed by a debriefing sequence.  The debriefing sequence is followed by another briefing.  While the next briefing is not necessarily a linear set of missions, it can be depending on story arc.  This leads to a third a variable, a must complete next mission flag.  For the tutorial missions, these are set to true.  In addition, the record should point to the next mission on the list, assuming the mission is in a sequence of missions.

This means the mission tracker table needs: a unique identifier, a category (briefing, mission or debriefing), mission name (or briefing or debriefing name), the next mission in the list and a must complete flag.  A load table will have the player code and the unique identifier.  This will provide the basic framework for transitioning between scenes.  Stuff may be added to these features in future iterations; however, this will represent the operating basis for this prototype.

Here's the summary (for when I reference this blog in the future):

MissionTracker
  int OID
  string Category
  string MissionName
  int NextMissionID (Briefing ID relationship - 1 to 1)
  bool MustComplete

LoadTracker
  int OID
  int MissionID (points to an OID in the MissionTracker)
  string PlayerID (points to a player code in the player data table)

The program flow should be:

Start up screen -
  "button" to click which loads "Tutorial #1 Briefing" and "plydftAbanathie".
Briefing Screen -
  "text box" prints out the briefing material
  "button" to click which loads "Tutorial #1 Mission" and "plydftAbanathie" -
    next items in table
Mission Screen -
  actual mission with a load "Tutorial #1 Debriefing" and "plydftAbanathie" before exit -
    next items
Debriefing Screen
  "text box" with debriefing material
  "button" to click which loads "Tutorial #2 Briefing" and plydftAbanathie" -
    next items

The cycle continues with the tutorial #2.

1 comment:

  1. I got the basic template down. The .dll file to access the database is done, and I have a basic startup screen that can transition to the first tutorial.

    It transitions to the actual mission; I'll have to insert the briefing and debriefing screens...

    ReplyDelete