This page is a discussion of the Starport Lounge module.
The Starport Lounge module is designed to handle is designed to handle the Lounge interface; more specifically it is designed to handle and generate escort lists, gossip and hints for the player, and missions for the player. The basic architecture of the module is similar to other modules within the game that handle basic data types (such as integers and strings) and hash tables / dictionaries. The Lounge Module will heavily interact with the Event and Plot Handler module (particularly when it comes to generating missions); it will also, of course, be required by the Starport Module, and may affect several other modules as well. As missions and escorts are important new aspects of the game (both are being utilized as partial replacement for colonial recommendations from the original games), the Lounge module is vitally important. All code for the Lounge module is located in the sf3_starport_lounge.py file.
Summary Description
Ofc_lounge objects are created and stored during the initialization of a Starport office if a certain flag is set to True for that port. When created, the ofc_lounge object will generate a short list of escort craft (including crew statistics). It will then determine if any hint or gossip messages will be made available to the player, seeding specific messages into a holder if said messages are generated. Finally, it will generate two or three mission objects and place them in a holder. When the player enters the lounge, the interface loads up, producing clickable areas/or models as needed for the various escorts, gossip sources and mission sources as previously generated. If the player wants to hire an escort, a dialogue will appear giving them information on the available escorts along with their own financial status, allowing the player to rent the escort for a while. If a gossip/hint message is activated, the game will display that message, and replace it with a generic "go away" style message if the player attempts to activate the same message again. If the player wants a mission, a dialogue will appear outlining the mission and giving the player the option to accept or not. Should the player accept, the module will make a series of calls to the Event and Plot Handler module to generate events appropriate to the mission. Game control returns to the Starport concourse when the player clicks anywhere in the "Exit Lounge" portion of the interface. The office object remains in memory until the player leaves the star system in which its containing Starport is located, at which point it is destroyed (along with the parent Starport object).
Data Structure of the Ofc_lounge Object
The following list is an indication of the various variables and methods that will be included in an ofc_lounge object. This list contains suggested methods and variables only; they should be updated as needed when finalized method and variable names are selected. Ofc_lounge objects are meant to be used as child objects of Starport objects, and have three child objects (escort, mission, and gossip objects). Ofc_lounge objects are created during runtime when a player enters a star system and are subsequently destroyed when they leave that system. Thus, while there may be multiple ofc_lounges objects used in the game, only one will be in existence at a time (per Starport located in a system; the Flornea system has two Starports in it and thus may have two ofc_lounge objects in it as well, one for each base). Their data structure is as follows:
- Class: ofc_lounge
- List: Available_escorts
- List: Available_missions
- List: Gossip_Messages
Data Structure of the Escort Object
The following list is an indication of the various variables and methods that will be included in an Escort object. This list contains suggested methods and variables only; they should be updated as needed when finalized method and variable names are selected. Escort objects are meant to be used as child objects of ofc_lounge objects, and have no child objects of their own. Escort objects are created during runtime when their parent ofc_lounge object is created, and are subsequently destroyed when the overall parent Starport object is destroyed. Multiple escort objects may be created under a single ofc_lounge object. Their data structure is as follows:
Data Structure of the Mission Object
The following list is an indication of the various variables and methods that will be included in a Mission object. This list contains suggested methods and variables only; they should be updated as needed when finalized method and variable names are selected. Mission objects are meant to be used as child objects of ofc_lounge objects, and have no child objects of their own. Mission objects are created during runtime when their parent ofc_lounge object is created, and are subsequently destroyed when the overall parent Starport object is destroyed. Multiple Mission objects may be created under a single ofc_lounge object. Their data structure is as follows:
- Class: Mission
- String: Title
- String: Description Text
- Integer: Reward
- Method: Generate_Mission()
Data Structure of the Gossip Object
The following list is an indication of the various variables and methods that will be included in a Gossip object. This list contains suggested methods and variables only; they should be updated as needed when finalized method and variable names are selected. Gossip objects are meant to be used as child objects of ofc_lounge objects, and have no child objects of their own. Gossip objects are created during runtime when their parent ofc_lounge object is created, and are subsequently destroyed when the overall parent Starport object is destroyed. Multiple gossip objects may be created under a single ofc_lounge object. Their data structure is as follows:
- Class: Gossip
- Hash/Dictionary: Messages
- Key (Integer): ID Number
- Value (Tuple): Text of Messages, Replies to Display, Effects
- Hash/Dictionary: Replies
- Key (Integer): ID Number
- Value (Tuple): Text of Replies, Message to Display
Interface
Lounge Interface, Concept, 6/30/2003
The Lounge Interface consists of only one area, as demonstrated in the graphic:
* Action Selection Area
The
Action Selection Area, as the only area involved in the interface, takes up the entire screen. As the name suggests, this area is used by the player to select the actions they would like to take. Action selection is done by scrolling over the interface so that various "activation areas" become highlighted; these areas can either be console displays along the wall (good for missions or escort hiring), or character models (good for missions and gossip/hints). When this occurs, the mouse pointer changes to a different icon, the shape of which will depend on what action is available in that area. A key of these various icons and their meaning may (
should) be included in the game's documentation. Clicking the mouse over an activation area will bring up a pop-up window, in which the player will be able to carry out the action. <Tab> and <Shift>-<Tab> may also be used to scroll through the various activation areas, with the <Return> key activating those areas. Scrolling over an activation area or using the <Tab> keys will sound the SCROLL SELECTION tone, and activation will sound the ACKNOWLEDGED tone. '
If the player has selected a GOSSIP or HINT option, a pop-up window will appear showing the face of the species whose model is being used to represent whoever is giving the player the gossip or hint. Below their face, an area will appear containing the message of the GOSSIP or HINT. If the message is interactive in any way (
the intent is to give messages some level of interactivity here), another area will appear below the message which allows the player to select a response from a list of options. Selecting an option will call up the next message in the series, if there is any, or some kind of farewell message otherwise. Options to end the conversation may also be provided to the player. Once the message has played out, the option "END MESSAGE" will be given to the player; selecting this option will close the pop-up area.
The proposed method to change the player's relationships with the various in-game races may also be best handled this way, so this will need to include a method that can subtract money from the player's account or cargo from their possession when it's finally implemented.If the player has selected a HIRE ESCORT option, a pop-up window will appear showing a list of all available escorts at the Starport, along with the price to hire that escort and a button to VIEW the potential escort. At the bottom of the list will be a button marked CLOSE; clicking this button will close the pop-up. Clicking on the view button beside any given escort or double-clicking the name of the escort will change the pop-up to an informational listing similar to the
Information Area of the Fleet Configuration Module (for more information, see the
Interface discussion of that module. The information provided will, in fact, be exactly the same, except that the hiring price of the escort will appear in place of the ship's fuel status. At the bottom of the pop-up will be two buttons, marked CLOSE and HIRE, preferably with the CLOSE button larger. Clicking CLOSE will close the information pop-up and take the player back to the escort list pop-up. Clicking HIRE will bring up a sanity check; clicking YES on this check will add the escort to the player's Fleet object and remove it from the available escorts list, and subtract the required amount of money from the player's bank account. The cost of an escort is commensurate with the level of equipment and crew training the escort has; ships with better equipment and more crew training will be more expensive to hire on. Escorts remain with the player from the time the player leaves Starport to the time they arrive at another Starport. The keyboard may also be used to navigate the escort pop-up; the up and down arrows will scroll through the escort list, the left and right arrows can be used with the information pop-up open to select between CLOSE and HIRE (with CLOSE selected as the default), and the <Return> key will bring up the information pop-up or the sanity check depending upon which is currently active).
If the player has selected a MISSION option, a pop-up window will appear showing a list of all available missions at the Starport, along with the reward price for that mission and a button to VIEW its details. At the bottom of the list will be a button marked CLOSE; clicking this button will close the pop-up. Clicking on the view button beside any given mission or double-clicking its name will change the pop-up to an informational listing. This listing will give the full details of the mission. At the bottom of the pop-up will be two buttons, marked CLOSE and ACCEPT, preferably with the CLOSE button larger. Clicking CLOSE will close the information pop-up and take the player back to the mission list pop-up. Clicking ACCEPT will bring up a sanity check; clicking YES on this check will begun the mission for the player (which activates a method that adds some events to the plot handler). The award associated with a mission is commensurate with its difficulty; more difficult missions will yield greater rewards. A player must complete all missions underway before returning to any Starport; failure to do this will cause the failure of the mission, loss of reputation, and possibly loss of funding. Mission messages are delivered via the Evaluation message system in the Operations office, and any rewards are given to the player (if appropriate) when they visit that office. The keyboard may also be used to navigate the mission pop-up; the up and down arrows will scroll through the mission list, the left and right arrows can be used with the mission information pop-up open to select between CLOSE and ACCEPT (with CLOSE selected as the default), and the <Return> key will bring up the mission information pop-up or the sanity check depending upon which is currently active).
Game control will remain with the pop-up interface until control passes back to the main interface, at which point the mouse will be placed over the same activation area. Lounge interface graphics are set by XML files; activation areas are set by the module itself. All Lounge interfaces must include at least one area that allows the player to leave the lounge and return to the Starport Concourse. As with all Starport modules, no calls will be made to the gameClock object to advance the time while the interface is active.
General Procedures and Notes¶
Okay... purposes of the lounge.
- Hire escorts. This one shouldn't be a biggie, but will require the port to have a Fleet object. I think one was planned anyway.
- Get hints. Shouldn't be too much different than the notices system in Ops. These hints might be a little closer to what appeared in the manual for SF2; general game hints, that sort of thing.
- Inter-species relations. Actually, I think what I need to do is take a look at Freelancer...lounge might do the same thing. Have a representative from one race, pay money to fix rep, but hurts other species rep...
- Hire out as an escort ... this is going to require the addition of some kind of mission system to the game. At which point we can add these little sub-missions we've discussed before.
- Sub-quests. Why not.
- Gossip. See hints.
- Take a hike. Some folks might not want to talk to the player, or have nothing to say to the player. Depends on the base.
I think missions can be handled via the Event handler...just need something that generates the required events in-game. Missions will need a plot event, a victory event, and a defeat event. I might need to add a "remove_encounter" event to the list of valid effects in the Event and Plot Handler module.
Add this to the office data structure.
- Hash/Dictionary: Escort_List
Emotion_Indexes is a dictionary, part of the Player object. Resetting its values should be a snap.
Gossip...gossip...like a message. We'll need to have enough of these to make them not immediately repetitive.
Okay, that should be enough to proceed at least.
Methods
(use this area to list the module's methods and give a description of what the method does. As the methods are written, what they do should be written out procedurally)
Generate_Mission()
This will generate mission specifics. Get text, check the player's current difficulty equivalency level, set a reward level appropriate to the mission, and create an encounter object. This won't be seeded unless the player accepts the mission.
XML
The Lounge Module, like most of the other modules in the game, is largely XML driven; this will help keep things flexible up until SF3's design is finalized (i.e. mission types and gossip messages can be added and removed from the game freely, based upon what data is available in the XML files). The Lounge Module makes use of two different XML files, one containing generic text for mission generation (the file "mission_texts.xml"), and one containing message trees for gossip and interactive messages (the file "gossip.xml"). The following briefly goes over what data is located in these XML files.
mission_texts.xml
The file "mission_texts.xml" is designed as a repository for generic mission descriptive texts, which are utilized by the module's internal mission generator to create a specific set of conditions (parties involved and payment) for individual missions. Under the root element, entries in the XML file are elements named "mission". These elements have one attribute, named "name" (used to give a generic name to the generated mission). Each mission element must contain exactly three sub-elements, named "msg" (used for the descriptive text of the mission), "victory" (text seeded to evaluations upon successful mission completion), and "fail" (text seeded to evaluations upon failure of the mission).
Messages included in the XML may contain several special "tags". Before any messages in the engine are displayed, the create_mission() method will scan the text of all messages within the mission for these tags and replace them with the appropriate information if they are encountered. These tags are "$" for the reward offered for the mission, "@" for a specific location, "~" for a specific quantity, "`" for a specific good, "^" for a specific hostile party, "|" for a specific neutral party, "%" for a specific ship name, and "*" for a specific captain's name. In all cases, the specific replacement words will be selected randomly by the method.
Sample structure of the mission_texts.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<root table-name="mission_texts" version="0.1">
<mission name="Mercy Mission">
<msg>
A recent outbreak of a virulent disease has occurred at the | colony in the system @. We need someone to deliver "~" cubic meters of
Medicines and Narcotics to the medical supply ship %. The supplies will be loaded into your cargo hold upon acceptance of the mission.
Be advised that groups of ^ have been sighted in the area and may try to go after the supplies. The job pays $.
</msg>
<victory>
Excellent! Even with the interference of the ^, the supplies have been delivered, thanks to you. You've definitely earned your reward
of $ MU.
</victory>
<failure>
We're holding you personally responsible for the destruction of the %, and for all those lives that are going be lost thanks to your
stupidity. Thanks for nothing, jerk.
</failure>
</mission>
</root>
gossip.xml
The file gossip.xml is designed as a repository for gossip messages, which include a main message and may include a number of pre-programmed responses and further communicative actions (these messages have the capability to be more interactive than any other single type of message in the entire game). Under the root element, entries in the XML file are elements named "gossip". Gossip elements must contain an "id" attribute, which can be used by the Event and Plot Handler to make specific gossip messages available to the player. Gossip elements may contain one or more empty sub-elements of the type "msg". Each msg sub-element may contain the following attributes:
- id: Used to identify a particular piece of text within a set of gossip messages. This is mandatory, and must be set equal to an integer. The first message to be displayed must be set equal to one.
- type: This contains the intent of the text. This must be set equal to either "message" or "reply", and is again mandatory.
- message: Used for when the character divulging the gossip is speaking.
- reply: Used as a selection option for the player, allowing them to decide how they'll respond to the inital message.
- event: This is used to trigger a specific event when the message appears on screen. May only be used with type="message" sub-elements. The event will need to be pre-programmed into the Event and Plot Handler (see that page for more information).
- replies: This is used to contain the id numbers of the messages to display as replies once the current message has been displayed on screen. Must be used with a type="message" attribute.
- nextMsg: This is used to determine which message appears next, once the player has selected the current message as an option. Setting this value equal to 0 signals the underlying gossip display method to close if the option is selected. Must be used as with a type="reply" attribute.
- text: This contains the actual text of the message or reply, and is (obviously) mandatory.
Sample structure of the gossip.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<root table-name="gossip" version="0.1">
<gossip id="jello_spemin">
<msg id="1" type="message" replies="2" text="I dreamed that I was in a B class star system far away
from any others. The Humna Humna sold me an "encounter scanner," an artifact that projects all the
potential encounters in the vicinity onto your starmap. Of course, I also dreamed that there were
Spemin in my hold playing on a trampoline, and that Starport was made out of jello. Take it for
what it's worth." />
<msg id="2" type="reply" nextMsg="0" text="Okay..." />
</gossip>
<gossip id="topiphopex">
<msg id="1" type="message" replies="5, 6, 7" text="Yes, sir - thank you, sir. I'm a little nervous.
We're leaving Starport soon, and it'll be my first tour of duty. I'm not sure what to expect..." />
<msg id="2" type="message" replies="8" event="increaseRep" text="Thank you, sir. I'm sure it
will be." />
<msg id="3" type="message" replies="8" event="lowerRep" text="Gee, it's that bad? Now I'm more
nervous than ever." />
<msg id="4" type="message" replies="8" text="Okay..." />
<msg id="5" type="reply" nextMsg="2" text="It'll be an experience you'll never forget." />
<msg id="6" type="reply" nextMsg="3" text="Expect the worst, boy." />
<msg id="7" type="reply" nextMsg="4" text="Oh yeah, it's a hoot!" />
<msg id="8" type="reply" nextMsg="0" text="(END CONVERSATION)" />
</gossip>
</root>
Module Status
This is current as of May 2, 2011.This module is currently in the final design phases; while specific descriptions of the intended functions of modules have yet to be written, the remainder of the module's basic description is complete at this point. Further design work on this module has been frozen for the time being, and will remain so until I'm ready to begin method descriptions for all remaining extant modules.
NEXT: Casino Interface and ModulePREVIOUS: Trade Depot Interface and ModuleTOP