FANDOM


This page outlines the phases of the game's development, and also gives a rough indication of how complete a particular phase is at the present time. This page is meant to be used by the group as a means of measuring the project's overall completeness and to give an indication of what areas still require additional work.

Elements of a phase may have one of the following levels of completeness:

  • NOT DESIGNED: This element does not yet have a cogent design available.
  • INITIAL DESIGN: This element has got some design work completed on it, but the design is not yet complete.
  • FINAL DESIGN: This element has enough design work complete to begin initial coding, but is design is not yet complete. Should probably be reserved for pages awaiting final review.
  • COMPLETED DESIGN: The element has a completed designed but no one is currently working towards its completion.
  • IN PROGRESS: A project member is currently working on the element but has yet to complete it.
  • DEBUGGING: A project member has completed principle work on the element but it has not yet been certified as error-free.
  • COMPLETE: The element is fully complete as designed and has been certified as error free.

PHASE ONE: SPACE NAVIGATIONEdit

  • Space Artwork (NOT DESIGNED): This set of artwork is needed for the interstellar module and includes the stars seen while traveling through space.
  • Planetary System Artwork (NOT DESIGNED): This set of artwork is needed for the interplanetary module, including planet and star images when traveling in-system.
  • Player's Ship Artwork (NOT DESIGNED): Only a single sprite or model for the player's ship is required during this phase because the different ship classes do not come into play until a later phase.
  • Core Modular Game Engine (FINAL DESIGN): This is the core engine that powers the entire game. All modules rely on this core engine for their very existence. The engine makes it possible to create new modules and/or work on modules without a programmer needing to know how the rest of the game works. This allows a new person to work on part of the game without understanding the whole of the source code.
  • Title Screen (INITIAL DESIGN): The title screen will eventually need a menu such as NEW, LOAD, QUIT, and be able to implement those various options.
  • Starmap (FINAL DESIGN): The starmap is simple but may be improved, possibly switching to a scrolling view. This is a simplistic starmap that gets the job done.
  • Interstellar Travel (FINAL DESIGN): Retrieves star data off from XML data and allows travel of the ship sprite between stars.
  • Interplanetary Travel (FINAL DESIGN): The planets are put into random orbits around the star using a random number generator.
  • Control Panel (FINAL DESIGN): The control panel is the game menu that the player uses to communicate with the ship's crew, displaying Captain, Science Officer, etc. This menu will be revised as each new module is added to the game engine. We need a basic control panel set up for Phase One and 2; we'd like to begin giving the game it's actual interface rather than jumping directly to the modules. This code can be added in the root game screen module.

PHASE TWO: PLANETARY EXPLORATIONEdit

  • Planet Orbit Artwork (NOT DESIGNED): The image displayed in the main viewscreen when orbiting a planet based on planet class/type.
  • Planet Orbit (FINAL DESIGN): When the ship moves over a planet, the player can choose to orbit. The planet orbit module displays a drawing of the correct planet type. It needs to also allow the player to choose a landing site and descend to the planet. Also, the player should be able to scan the planet and display the info in the Aux window. This will need to have the control panel integrated, and needs planet scan, and ability to choose landing site.
  • Planet Surface (FINAL DESIGN): This module needs to display the planet surface as a tile-based scroller, allowing the player to move the Terrain Vehicle over the planet surface, explore for minerals, life forms, and Trade Centers. The I.T.V. has a limited amount of fuel and cargo space so the player must manage these resources carefully, returning to the ship often to unload and refuel.
  • Planet Surface Artwork (NOT DESIGNED): We should be using stub art for planet tiles at this point, so for this section we just need a sprite for minerals and a sprite for lifeforms. We can fill in the multiple images for each type of lifeform, cities, and other details later. This will include LIFEFORMS and MINERALS artwork for the planet surface.
  • Basic Combat Engine (FINAL DESIGN): This module will be required for all forms of combat, in space (starship-scale) and on-planets (vehicle-scale). This module will handle combatant involvement, movement, range determination, hit determination and damage allocation. SFRPG's design will be heavily involved in this module.

PHASE THREE: ENCOUNTERS AND COMBATEdit

  • Alien Portraits and Ships (NOT DESIGNED): This artwork will use the sprite sheet created, which combines the alien portrait (main viewer), the alien ship scan image (aux window), and the alien ship sprite for encounters. We may perhaps share the same image for the aux window image and encounter sprite with scaling.
  • Alien Encounters (FINAL DESIGN): This module works closely with ship combat. Before combat occurs, first an "encounter" takes place. The player may hail the alien fleet to engage in dialog, engage in combat, or leave. This is the dialog portion of an encounter. This module will show the player's ship and alien ship(s) in the main viewer, and will be able to scan alien ships via science off. When combat occurs, control transfers to the ship combat module, which goes fullscreen.
  • Ship Combat Artwork (NOT DESIGNED): We'll need the portrait/ship images filled in (above), and will also need misc animations for missiles and other weapons, as well as flaring shields, explosions, debris (including minerals that can be gathered by the player).
  • Ship Combat (FINAL DESIGN): We'll need to set controls and physics, characteristics of all starships and other combat units (such as damage capabilities and hit points), and set initial locations of all combatants. May rely on SFRPG design here for general ideas.
  • Artificial Intelligence (FINAL DESIGN): We'll need to set all behavioral controls for all NPC components of the game.

PHASE FOUR: STARPORT AND TRADEEdit

  • Starmap Enhancement (FINAL DESIGN): The original starmap was simple and needs refinement, possibly by switching to a scrolling view. This new starmap will allow player to select destination in a scrolling view which will display distance and fuel cost based on engine class. An "autopilot" feature may also be needed at this point.
  • Message Window (NOT DESIGNED): We need a reusable class for working with the Message Window in the main game screen, that makes it easy to send text to the message window during alien encounters and so on. This class should have several methods such as ClearAll, and should allow the player to scroll back through the text. We don't have a reusable message window yet, as modules are just writing out to it directly.
  • Trade Item Artwork (NOT DESIGNED): There are many trade items in the game and many of them can share the same image based on class of trade item (such as Electronic Gadgets, Foodstuff, etc). We need at least a basic image for all the major categories of trade items at this point. --We will need to revise the design wiki with the actual trade items in the game, per the trade item editor.--(we need to add a list of trade items to THIS wiki.)
  • Trade Engine (COMPLETED DESIGN): This large and challenging module should be taken on by an experienced programmer. It will require modifications to the DataMgr class and Player class to incorporate inventory into the player's data, making it possible for the player to acquire minerals and lifeforms for trade (via planet exploration and ship combat). This trade engine will be used at Starport and at alien trade centers.
  • Starport Artwork (NOT DESIGNED): The starport artwork will involve a space-based starport image, and the background image and sprites for the player walking around the starport, as well as screens for each of the starport areas.
  • Starport Concourse (COMPLETED DESIGN): The main starport mode/module will link all of the various starport modules and will animate the little animated player that walks through the starport to visit each of the areas, such as the Bank.
  • Starport: Personnel and Crew Assignment (COMPLETED DESIGN): This module allows the player to hire and train crew members of different alien races. People are not "created" as in the old games; they are recruited or hired depending on player's profession, from a roster of available military officers, scientists, or freelance individuals. Random list of people generated, with a few adds/deletes now and then to give the appearance of a dynamic environment. Cost to hire based on the character's statistics.
  • Starport: Ship Configuration (COMPLETED DESIGN): The player's fleet is customized with this screen, where ships, vehicles, pods and equipment may be purchased.
  • Starport: Bank (COMPLETED DESIGN): The bank displays player's credits and list of transactions. Perhaps we will add a loan feature which requires regular repayments with interest to allow the player to get a loan in order to upgrade the ship? Failing to repay a loan results in a bounty on the player. Loans will be limited to ship upgrades as collateral, and defaulting results in loss of ship upgrades.
  • Starport: Trade Depot (COMPLETED DESIGN): Player can buy/sell minerals, lifeforms, and artifacts. Will be based heavily on already existing trade engine designed earlier in this phase.

PHASE FIVE: STORYLINE QUESTS AND MISSIONSEdit

  • Quest/Mission System (COMPLETED DESIGN): Player must be able to engage in quests/missions for Arth and alien races in order to unlock secrets that reveal the plot of the story. Numerous small quests gradually lead player toward important items and facts which are available via a logical chain or tree system via the Mission Editor database.
  • Internal Game Clock (COMPLETED DESIGN): Needed for the event handler, this should be a simple Clock class with functions for keeping track of the in-game time and date as well as a function for advancing the clock.
  • Event Handler (COMPLETED DESIGN): The game routine will need to trigger and keep track of events as time progresses in game. The event handler will need to be able to interact with the navigation, starport and communications modules to allow events after a certain time or cause events. May also need to include a database or set of flags saved with the player's data.
  • Music and Sound Effects (INITIAL DESIGN): In-game music will be needed at this point for hyperspace travel, in-system travel, orbiting, launching/landing on planets, planetary exploration (by planetary type), encounter communications, combat, victory, defeat, and the main title screen. Sound effects such as explosions, beeps, and background noise will also be required.
  • Music and Sound Handler (FINAL DESIGN): Once music and sound effects are ready, the music handler will have to be set to play certain tracks given certain in-game conditions. Will need to work with the core game routine and event handler. Probably will use XML for data on specific tracks needed.

PHASE SIX: BUILDING, BETA TESTING AND RELEASEEdit

  • Backup and Beta v1 Release (NOT DESIGNED): Prior to Beta testing, a full backup of the game will be created as a baseline version, used in case any new or debugged modules added during the beta phase cause irreparable damage to the game's build.
  • Feature Bloat and Beta Testing (NOT DESIGNED): During this part all remaining details are filled in that were not foreseen earlier, broken down into modules when the remaining needs are identified. All bugs will need to be worked out of all modules. Any additional features that members of the project propose during game construction will need to be included in this category, tested and debugged.

NEXT: Utilities and Editors
PREVIOUS: Main Menu Module
TOP