Galaxxon Legacy (Galaxxon 5)

Abstract
Game Name:	Galaxxon Legacy
Development Team Members:	Matt Fister (levels, particles, AI), Sean Kelly (ships, guns, gameplay)
Game Genre:	arcade top-down shooter
Brief Description:	Take on the identity of one of 5 mercenary pilots, fly missions in progressively unlocked chains, destroy enemy ships to earn money and add them and their equipment to your shop. Ships are infinitely upgradable, weapons have up to 10 levels of power, and the ship/weapon/level system is very flexible and welcoming of player-generated content.
Overview
Game Story / Objective:	Survive numerous missions of increasing difficulty, upgrade your personal flagship and build a fleet of captured enemy fighters to take into combat.
Game Mechanics + Controls:	Gameplay is mostly standard arcade shoot-em-up fare. Controls are: Player 1: a/w/d/s - move, change menu selection spacebar - fire gun 1, confirm menu selection , - fire gun 2 Player 2: numpad 4/8/6/5 - move numpad 0 - fire gun 1 numpad . - fire gun 2 or (if keyboard does not accept ~8 simultaneous keypresses) mouse - move mouse left button - fire gun 1 mouse right button - fire gun 2 At the start of the game and between missions the player is presented with a menu screen to access the list of available missions, upgrade currently owned ships, buy currently available ships, save either player's current setup, or load either player from a previously saved file. Player 2 is enabled by loading a save file into the P2 position (Load P2) and disabled by choosing P2 Off at the main menu. Only Player 1 has access to hangar and shop options, although Player 2 still earns money, loses ships, and unlocks levels and equipment independently of Player 1. Getting Started: After selecting New Game at the title screen, you will be presented with a special variant of the shop screen listing available personae and their respective Flagships. Your Flagship is a critical element of the game. While any ship in the game is theoretically available to pilot, only your Flagship will not be lost even if shot down. The weapons on your Flagship are also the only ones available to you at the start of the game. Selecting a Flagship will display its stats and equipment, giving you a better idea what to expect. -= Stats =- - Armor: The structural integrity of your ship. Armor determines how much damage your ship its self can sustain. You start each mission with the listed amount of Armor, and Fail the mission if yor Armor drops below 0. Remaining Armor also determines how much damage you deal to other ships during collisions. - Shield: Armor is not your only defense. Shields defend your ship much like armor, take damage before armor, and recharge by 10% every second of gameplay. Like Armor, you start with the listed Shield capacity every mission. Shields are reduced by impact with ships and shots, but only when your Shields have been reduced to 0 do you begin taking damage to Armor. Shields have no effect on ship-to-ship collision damage. - Speed: This is your maximum rate of motion, in units per second. The game screen is fixed at 640x480 units. - Agility: This is your maximum rate of accelleration, again measured in [units per second] per second. Keep in mind that even if a ship has high Speed, it will be very difficult to control with low Agility. - Expansion Slots: Each ship can be equipped with up to 2 Guns, each at a Level between 1 and 10. Every Level of Gun you equip consumes one Expansion Slot. Thus, a ship with 12 Expansion Slots could carry a Level 10 Gun and a Level 2 Gun, or a Level 6 and a Level 6, etc., but a ship with only 8 Expansion Slots could not even raise a single Gun beyond Level 8, even with no other Gun equipped. - Gun 1 / Gun 2: These are the weapons currently equipped. Each Gun's Level is shown in parentheses after the Gun's name. ---=== The Main Menu ===--- Missions: This option takes you to a list of currently available Missions. Selecting a Mission will take you to a more detailed overview and the chance to accept or decline the Mission. Missions are your ticket into actual combat. While they themselves do not pay directly, you are given rights to all spoils, so the salvage value of any enemy ship destroyed on a Misison is added to your total Cash (displayed in the upper-right for Player 1, and the upper left for Player 2). Every ship destroyed will also unlock some Ship or Gun and add it to your Shop (covered later). Most enemy ships unlock themselves and their own equipment, but some, particularly large Boss ships, may unlock rare and valuable weapons. Upon successful Completion of a Mission, you will be returned to the Main Menu and new Missions may be added to your available list. If you are shot down before you can Complete a mission, one of two things will happen: - If you are piloting a ship other than your Flagship, that ship is permanently lost from your fleet and you automatically continue the Mission in your Flagship. - If you are piloting your Flagship, the Mission Fails and you are automatically returned to the Main Menu. Your Flagship, while automatically rebuilt and not removed from your fleet, loses any and all upgrades you may have made to it. If the Mission Fails, no new Missions are unlocked, but you keep any spoils you earned up until the Failure. Hangar: This option takes you to a list of your currently owned ships. Selecting any one of them will take you to a detail screen from which you can pay to adjust any Statistic by simply moving the selection mark to it and pressing d and a. Armor, Shields, Speed and Agility are adjusted in increments of 10, Expansion SLots and Gun Levels in increments of 1. Armor, Shields, Speed, Agility and Expansion Slots may not be adjusted below their preexisting values. By actually selecting a Gun (spacebar), you will be taken to a list of all currently available Guns, and may from there choose a different Gun to equip. Be aware you must equip some Gun in the Gun 1 slot, and that some Guns are only available for one slot or the other. Throughout the upgrade process, your current Cash, along with the cost of the proposed upgrade (or an (estimate) thereof) is displayed in the upper-right of the screen. It will be more expensive to add Armor, Shields, Guns and Expansion Slots to smaller ships, but more expensive to add Speed and Agility to larger ones. By selecting Confirm Changes, your upgrade will be applied and you will lose (or gain) the amount displayed. You may also choose to sell any ship but your flagship for a quarter of its listed value. Selecting Select for Mission will flag a ship as your preferred choice to take into combat, and you will start every subsequent Mission piloting the selected ship until it is destroyed or sold, or until another selection is made. Shop: This is where you add new ships to your fleet. The process works identically to initial Flagship selection, however this time you must pay for any ship you choose. Initially there will be no ships available in the Shop, but this will change as you fly Missions and unlock new models. The Stats of enemy ships may not be very good relative to your Flagship's, but once you have a ship in your Hangar you can upgrade it like any other. And remember: flying ships purchased from the Shop is the only way you will be alowed to continue mid-Mission if shot down! Save/Load: These options allow you to record to and restore from Save datafiles. The ships in your hangar, all unlocked Missions, Ships and Guns, your Cash, and even your ship preference will be recorded. There is one list of Save files, and it is accessible by Player 1 or Player 2. To save Player 1's current data, use Save P1, to save Player 2's, use Save P2. To load data for Player 1, use Load P1, and to load data for Player 2 (and begin 2-player cooperative gameplay) use Load P2. The final option, P2 Off, disables 2-player gameplay (and does NOT save Player 2's data!). That's it! The rest is up to you. Enjoy!
Technology:	Levels, ships and guns are all loaded from openly-editable ascii and PNG files to facilitate expansion of the game's content base. Libraries used are all multiplatform, so the game compiles and runs identically (down to processor speed/architecture) under Windows, KDE and OSX (PowerPC, but an X86 version is just awaiting programmer access to an X86 Mac). The game should run on any machine with basic OpenGL texture support, but will take advantage of multitexturing where available. While the code is not not totally optimized, the non-OpenGL portion should be minimal enough that no serious slowdown should be present on machines with OpenGL support in hardware. At very low framerates, game speed is keyed to framerate, so game mechanics are preserved even on a 266MHz G3 laptop doing all OpenGL calculations in software.
Aesthetics:	The visual system of the game, with the exception of particle effects, allows for use of bump-mapped sprites and graphics tiles as well as traditional flat sprites and tiles. If bumpmap images are found in the appropriate location, bumpmaps will automatically be applied if the host system supports OpenGL 2.x or certain multitexturing extensions of OpenGL 1.x. Sean pioneered the 'Bumptile' or 'Bumpsprite' Graphics(TM) technique in his earlier lab 'RotoNinja' with some success, and in Galaxxon it adds a level of detail and cosmetic variation not found in any other 'oldschool' top-down 2D shooter.
Reflections
Three Greatest Challenges:	Multiplatform codebase: The course encouraged groups to run their games on the school's KDE graphics cluster. Sean wanted a game he could take away and play on his OSX home machines, and Matt only had a Windows machine for out-of-cluster development. As a result, the Galaxxon source is littered with environment-dependant #ifdefs and #includes, and no fewer than 5 makefiles were used during development, some of which remain mysteries even to Sean and Matt. Time Limitations: Both Matt and Sean were graduating seniors during development of Galaxxon, Matt was working on his senior capstone project at the same time, and Sean was head-mechanic of a buggy team. The original goal was to get all engine code written by shortly after milestone 2 and have the remainder of the semester to create assets (ships, weapons, levels). The codebase was not actually frozen to new features until the week before finals, and much content did not get finalized until the last week before release. Coordination & Versioning: Both Sean and Matt had experienced enough Subversion headaches over the past 2 semesters- inability to login, difficulty ensuring all project files were included, non-recognition of working copies, bloating of working copies leading to quota overruns, inability to control (and remember) login info, etc.- that neither wished to use the provided SVN account prior to final checkin. This worked fine for most of the semester. Work was done in fits and spurts, and after each major addition, the whole project would be exchanged. In the final couple weeks, however, image assets increased the project size to the point where sending the entire project back and forth was not pleasant, and many small changes, revisions and bugfixes were made to various individual files, many late at night or without full understanding of their consequences, and only files that were remembered to have changed were exchanged. The periodic omission of changed files during exchanges led to project fragmentation, a few unexplained bugs (until a full project exchange was done), and a loss of the sense of a single definitive 'latest copy.'
Three things that went right:	Assets: Sean envisioned the project so as to require only assets which could be easily created by tools Sean and Matt already had. As a result, there was no scouring of the internet for textures and models, no scheduling of mocap sessions and subsequent processing of data, no ad-nausiam re-use of assets, and no last-minute content panic, to name a few issues seen in other groups. Design: The decision to make a top-down arcade shooter was made when it was discovered that both Sean and Matt usually chose the genre for their first games on a new development environment. Shared experience with existing shooters led to a fairly coherent shared vision for Galaxxon Legacy, and allowed many pieces of independently developed content to feed into a single engine and feel like it was all supposed to be there. Unexpectedly, things like the automatic pricing functions and menu system worked and felt fair and balanced with very little revision on the original implementations, and the Flagships, while somewhat disperate in price, come off as distinct and well-balanced with very little adjustment from their original concepts. Completion: At the end of the day, Galaxxon Legacy looks and feels like an old shareware title, not like a rushed demo that was hacked out at the last minute. There are certainly improvements to be made after the final 15-466 "release party", but what was done by deadline is nearly everything Sean and Matt hoped for. It is further gratifying to know that, unlike e.g. team Power Monkey who were basically iterating on a long-standing codebase, Sean and Matt brought Galaxxon to marketable completion in a semester starting from scratch.
Three things that went wrong:	There were very few marked failures during the development of Galaxxon. Adequate foresight and planning led to a concept which could be implemented in a semester by a team of two with very few hitches. The most serious setbacks encountered during the project were Library Management: Trying to build one game on 3 platforms, each with its own idea of how the compilation process worked, and each with its own varyingly-nonstandard installation or noninstallation of the required OpenGL libraries, was most entertaining. At multiple times in the semester a small change in the code inadvertantly wrecked compilation on one of the targets, with Windows and KDE being most susceptable. Due to remotely installed linker libraries on the KDE cluster machines, the school-cluster build had to be fixed on a particularly regular basis. Asset Bloat: When there was only one level and a handful of ships and weapons, the name-by-numbers scheme used to allow the game to automatically detect and load all available assets worked out just fine. By the time each asset directory contained over a dozen numbered folders each with identically numbered images and 'config.txt' files, however, it became a mildly infuriating process to track down any single asset by its in-game name for editing. Format Confusion: More a software issue than a game issue, but during early development, 4-channel PNGs were used for sprites. Later, for consistency and copycoding, 4-channel PNGs were used for bumpmaps. Photoshop must explicitly be told at least twice to save a 4th cannel on an image with no transparency, which Sean did not realize until Matt pointed out texture mapping 'bugs' in the Windows build (at the time the Mac build was not using bumpmaps at all).
Lessons learned and/or things that you would have done differently:	As stated previously, development went very smopothly on the whole. If there were any minor caveats to be corrected on a potential second try, they would be Timing: Not a major issue, but it would have been nice to have had the menu system working the day before milestone 2 rather thant he day after, just to have something fundamentally new to show off. Resources: The libgfx libraries really should have been copied to the class include directory where all other provided libraries were. Linking against a former TA's personal copy of the library was an ugly hack at best. Information Sharing: This did not significantly impede progress, but as data file formats and indexed routines (AI, firing pattern, etc.) were being nailed down, it would have been useful to have had from the beginning some formal reference documents so game elements developed by one team member could have been immediately used by the other.
Media
Screenshots:	(KDE) (OSX/PPC) (Windows)
(Optional) Download:	Keep your eyes and ears open! The end-of-semester version of Galaxxon Legacy is not the final and complete version, but once a few enhancements are made and the assets are beefed up and cleaned up, the game should be available over Teh Internets as a stand-alone executable for at least one if not all three of its development platforms!