SC Development Plan

Objectives

The main objectives for this document are to detail out and plan effectively the production plan for the continued, and redevelopment, of Space Crusade. As it stand the game is very inefficient with its code and needs a massive overhauling of most classes and areas. At all times code should either be compacted or functionalized to promote neat and efficient code.

Within this redesign many changes must be made. Pretty much every class needs to be optimized and we need to think about subclasses as well. We need to recode each class so that it is streamlined, can be easily added to, and make sure to include ample commentary on everything.

The weapons equip and buying system should be a major focus, we must get this into a manageable form somehow and not just a huge switch and hundreds of if statements. Creating a weapons class should be examined, while the struct works, we could use the class for the actual weapon attributes instead of those if statements. Another way might be with a matrix using numbered id system similar to how I did the item database in the ASCII RPG.

Saving and loading should be streamlined as well as a remaking of the clone system; it does not currently work correctly. We need to also think about various features that are currently programmed and how we might improve those, as well as what new features could be added and how they would function. One thing that must be implemented is a better version of the movement system, eventually this will need to be real-time, but for now just needs to be turn based but the current solution, while functional, is immature in its execution.

We should also consider moving to an experience based system for rankings. There would need to be three different systems, which I will go into during the ranks section. The Talirath involvement based on Pirate Ranking should also be further developed into such a method as other games where increasing levels of "heat" bring on more difficult enforcement.

Player Class

The next few sections will be dealing directly with what each specific class needs to have worked on, ideas for how these changes should be implemented and what we could do to further compact the code. Some things will be double, or even triple, covered in other sections as well.

The first things I notice are that the functions are not organized in any particular fashion. We could either do this alphabetically by the type name then and/or by the function name. We could also go by what their function is, such as grouping all the getSomething's together. The same goes for the class variables.

Ship to ship battles has three different classes. We should find a way to combine all three versions to save on code space. Obviously this could be a bit difficult as we need to be able to differentiate between each type of encounter as well as include the variations in the battle structure for those encounters.

I also think that the battle functions should be split off of the Player class and moved to either the Map class, or a new class entirely. This could clean up the player implementation file greatly. If this was done, after battle functions like pillaging would also need to be moved to the new class, perhaps called Battles. They would connect to the Player class via simplified functions to add the recovered EXP and items to the player.

The next big issues are the change weapon/ship functions. These make up the bulk of the player implementation file's code. As was discussed in the opener we should consider changing this to either a class-based system with the struct to keep the current functionality or to a matrix based item database using id's to look up the weapons and ships and their attributes. These functions MUST be changed for the betterment of the program. With this change will also have to come some major changes to the Station class shop functions as well.

We need to figure out how to get the for loops in the save and load functions working. I have already fixed the improperly loading of data by implementing a replacement technique to replace underscores with spaces as the data is loaded. These functions take up a lot of space due to the nature of the destroyed planets array and how much data must be saved for the ships. These are not entirely done yet even, with some ship weapon points not being saved.

We need to also think about formatting for any information display functions, like the player status function as well as the bombing information display. Some of these are sloppy or can benefit massively from some improvements.

We could look into how to create planets truly randomly, with random names. Having to hardcode the planet names is time consuming and the array will get VERY unwieldy once the planet name total reaches around 600 to 1000, even then some players might go through every planet and once those are all done that function no longer works. So we should figure out a way to make these planets randomly and in such a way that the player will never run out of planets to find; if it is possible given our current setup of how we track destroyed planets. Given the way we do track them, this idea might be infeasible.

We should move the foundJus function to the Story class and create a variable that can be used to track if they have been found. This way we can separate out anything that does not belong explicitly to the Player class.

We should also look into moving the technologyUpgrade function to the TechMerchant class and use a simplified function to apply any changes.

Alien Class

The alien class is fairly streamlined as it is, but the alien creation function could do with a bit of an overhaul. It faces the same problem as in the Player class with the changeWeapon function. Perhaps we should make an itemSystem class for all weapon and ship related functions?

The Alien class does not need resource variables, as the amount of resources would be determined during the scavenging function. The functions should be all scanned through to see if there are any possibilities for compacting.

A plan to implement multiple ship battles should also be looked into for all ship-to-ship battle functions.

Talirath Class

Currently this class is non-functional. The groundwork has been laid but there is not much implemented here, just the basic test phase functions and variables. As such we should probably just redesign this class from the ground up since there is not much here.

Station Class

The Station class is another area that will need to be hit very hard come recoding time. The entire way the storefront operates will need to change drastically. Either way we choose to go with the item system we will call all of the information from the itemSystem class, there will be no actual information hard coded into the store functions. We also need to examine the Clone function, as I mentioned before, because it is not properly functioning. We might also want to rethink how we get to the stations, how the ranks will effect the various station related prices, and adding in a few new functions.

New Function: Bounty Hunting

Idea:

The basic idea of this function is that outlaws will be randomly posted to a bounty list at a station. Their offenses and reward will be posted along with where they were last seen or have been known to haunt. Players can then travel to these areas, facing unique enemies possibly, and find and duke it out with these wanted persons. We would need to make a Bounty class, subclass of Alien would probably be best, and include the various things we would need.

Instead of the current system where you can be attacked depending on how far the station you are traveling to is, I think we should implement an energy system where by you can only travel so far in one jump. At the end of each jump there is a chance to have to fight off an enemy. You may find resources or an uninhabited planet, which you could then land on to try and find resources.

Technology Merchant Class

This class also needs to be reworked. While it should function as a normal "alien" type class, there should be special functions in it for technology trading, upgrading, and battling. I would suggest making this class and the Talirath class subclasses of Alien, where the normal fighting and variables can be taken and then the unique functions can be implemented themselves into these classes.

Map Class

This class needs a lot of work. For some reason we are creating the ship instances here instead of where they should be. This should be fixed first thing. Next there are several functions that could be broken off into a battleSystem class: encounterCheck, shipBattle, and escapeAttempt. These also do not belong here.

Since we will be making a battleSystem class, we should also move the getPos' and setPos to this class. getDistance should stay here and be passed the information from battleSystem and the moveShip functions should be moved to respective classes.

One major goal for this class is to make it dynamic yet still has more user interaction then it does currently. Players can decide which systems in the sector to go to. If they find warp gates or worm holes they can take these to new sectors. Each system would be dynamically created and a list of planets and or stations, or other objects like asteroids or pirate havens, would be displayed.

One problem here is after a player leaves this system, how will we keep this system in memory incase the player ever comes back to this area. Any planets not pillaged or that were pillaged need to be kept.

In order for this idea to work many more planets and system names will need to be created and saved. It may be more beneficial to use an external file to save this data in and bring it into the game when needed and check it against either an array or another external file to check for destroyed-ness and other economical information.

Planet Class

The planet class, from the perspective of the header, is fairly compacted and streamlined. Renaming the isDeadPlanet function to isPillaged may be prudent. We should check either the planetBombing or the defenseAttack functions to see where some of the bugs are at; currently when the defenses are destroyed they can still get an attack in. Both files are otherwise fairly compressed, maybe look into recoding it and try to take advantage of any extra compression that is possible.

In lieu of recent ideas, we may need to scrap this class and make a new one called system, or extend the system class with this one. Other major edits to the way the data is retrieved and saved must be made as well. Essentially when the system is created, and then the planets in that system, that information must be saved to an external file. We will need to find a way to be able to search these files for the data if it is ever needed again.

Main Class

This class is where we really need to figure out how to streamline the process. Here there should be absolutely no calculations done, these should be done in functions and sent back if necessary. We can easily cut quite a lot of code by moving the battle/station loops into the respective classes; the bombing/ship-to-ship battle loops to the battleSystem class and station loop to the Station class.

We should probably recode the loops to make sure they are as compact as possible and do what they are supposed to. I remember a bug where if you escaped from battle it would take you to the station menu sometimes. Or sometimes when it was supposed to take you to the station after having won a battle or escaped it would take you to the main map menu. We need to look into these.

Other Header and CPP File Changes

We will need to examine the structs and other smaller classes that we are currently using and figure out where we need to cut or combine. Some of these structs, such as ships and weapons, will be obsolete once we get the itemSystem class created. We can probably cut the array header file, not sure why that was needed, probably for the destroyedPlanets array however. This might no longer be needed if we go the rout mentioned above with the system/planet classes.

Storyline Progression and Missions

This has got to be one of the main focuses while we are recoding the game. We need to make a more linear and cohesive plot through out the game in the form of special missions that will progress the story. We basically need to shoot for a sandbox style game that has a story connecting everything under the surface, like Just Cause 2 or Prototype. These missions need to serve the story, they can not just be like MMO style missions of go get this, go kill this, etc.

An example could be if a high-ranking official from what is left of the EASOM contacts the player and asks them to under take a mission, maybe something like a scouting mission into enemy territory or a hit and run style attack on a small enemy fleet, the player can either accept or decline the request.

If they player accepts a new menu option will be added to the main menu selection to begin the mission. The player will then be taken to the sector the mission will take place in and must find the system. Once the mission is completed they will get some kind of reward, resources most likely or maybe even weapons or ships for more difficult ones. If they refuse there should be a down side for doing so, maybe a drop in Earth Alliance Rank points.

Each mission should be progressive, like if you have a mission to sabotage an enemy advanced strike force, if you do the mission and succeed then the battle between them and the EASOM will reflect that. We might include a read out at EA stations about the current state of the SOM fleets, such as how many ships remain active. At the end of the game at the Empire the entire EASOM fleet will arrive to help the player, if there are any left. Keeping the EASOM fleets alive is not a requirement as the player could progress all the way to a Titan class ship and is able to take on the enemies on their own.

Mission difficulty should be related to the player's current status in the EASOM. If the player has a rank of Admiral they would get a more difficult mission then they would at the Private rank. We would need to work out how to do this dynamically instead of having hard coded if/thens based on the player's rank.

Ships

We will be able to remove the ship struct since we will be going through the itemSystem class now. I see two possibilities for this setup, we can either use a matrix with all of the data in it with search codes, somewhat similar to how we do it now but with out all of the bloat code. Or we can outsource all of the information to an external file with can be read and have the data for a specific ship imported.

Either way can be done, but I feel like the matrix idea is a better fit. For one we will not need to worry about converting output spaces into under scores and back, also with an external file the players could mess around with the ship values if they wanted to.

We should come up with some more ships to further diversify game play. We could also add in some new ship types, maybe something like Interceptors or Heavy Frigates.

• Interceptors
  • Lightly armored and standard armaments
  • Can move very quickly, twice the speed of normal ships
  • Can not travel through worm holes due to weak structural armor
  • Can switch out hard points for armor plates or heavier weaponry hard points. If armor is added speed is decreased slightly.
• Heavy Frigates
  • More armor then normal frigates and move slower, but have heavy weapon hard points and can equip modest weaponry.
  • Weak shielding due to having to remove the hardware to make room for weapons hard points and mechanics.
  • Move at half speed of most frigates.
• Assault Ships
  • New class, these ships designed for quick hit and run tactics on enemy ships.
  • While structural and armor are weak they can equip advanced shields typical for most cruisers.
  • Can equip a variety of weaponry, but no bombs or missiles. Most of the Laser Tech tree; save for 7 to 9 are open to these.
  • They can also equip virus-based weaponry designed to crash enemy ship's computer systems and cripple them.
• Barges
  • Heavily armored and slow vessels that can hold massive amounts of cargo.
  • Shielding can be significant in place of the few hard points available for these ships.
  • Can equip basic weaponry, tech trees 1 to 3, a few levels higher depending on the craft.
  • Has extensive bombing capabilities, can equip all but highest tech level bombs.
• Mining Vessels
  • Can be used for mining asteroids.
  • Low Structural strength but can have high armor and shields.
  • Can only equip mining lasers or tech level 1 lasers.
  • One of the few vessels that have a drone interface with the pilot. Can control up to 10 drones at once depending on pilot skills and ship model.
  • Not capable of wormhole travel.
• Excaliburs
  • These ships are very powerful but only available to high ranking EA commanders; requires rank of High Captain or higher and special authorization. These ships are cruiser class with the weaponry and defensive load outs of Mothership class vessels. Very expensive.
  • Up to 14 total hard points and have very advanced shielding technology.
  • Very slow moving and Structurally weak, armor is moderate.
  • Can equip all tech level weaponry except Titan-class.
  • Can carry twice as much cargo as the average cruiser.
• Roughbacks
  • These are a specialty class of frigates.
  • They run heavily armored with Electronic Warfare devices; ECM, Jammers, Virus weaponry, EMP, and simple cloak devices.
  • Designed by the Derlih, an EA allied alien race that specialize in subterfuge.
  • Strong shields but easily destroyed once they are gone.
  • If used correctly, can turn tide of large battles.

Weapons

Weapons will be an area where we will need to think about if we really need to add more or not. We currently have 74 of each kind of weapon at the moment, the old ones I am talking about here: bombs, lasers, and missiles. With that much variety we may not need to add more, however due to the number of ships we will be adding we might have to make more. I may introduce some new tech levels as well as specialized weaponry like armor piercing lasers or missiles and chemical bombs.

• Virus Weaponry
  • These weapons take up missile hard points.
  • Launch a spear shaped implement into the hull of the enemy ship.
  • Depending on installed computer and modules these will incapacitate a ship for a set number of turns.
  • Can not penetrate shields
  • Can be mitigated by the use of firewall modules that can block the virus from entering the computer if of sufficient level.
  • Also includes biological weaponry where weapons contain bacterial viruses engineered to survive in vacuums, or that can be loaded into bombs, to kill off populations but leave more salvageable resources.
• EMP Missiles
  • Missiles that produce an EMP over a large area.
  • Can take out the electronics on a ship for several turns depending on installed repair modules or cripple a ship entirely.
  • Can affect the shooters ship if they are too close.
• Armor Piercing
  • A mod that can be applied to missiles to make them more destructive to armor.
• Shield Modulation
  • Laser mod to allow the laser weapon to pass through shields unaffected if shield harmonics are matched to the frequency of the enemy's shields (randomly but can purchase shield harmonic settings from information brokers).
• Rail Guns
  • Projectile based weaponry that uses a magnetic system to hurl ammunition into the target.
  • Effective against shields but weak against armor.
  • Will have their own hard points
  • Require ammo to operate.
• Heavy Weaponry
  • Specialized weaponry to take out high tech level armor and shields
  • Require massive power grids to operate and have charge and cool down times.
  • Most are not block-able and unaffected by ECM.
  • Very high cost and can only be fitted on specialized tech level 6 or higher ships.

Defenses

Planetary defenses need some reworking. There is a bug currently that allows them to attack even after they are destroyed (for only one turn after they are destroyed) that will likely be taken care of during the recode. We need to add more defenses to the matrix, right now we only have laser defensive systems, but we should also add missile and ECM systems, as well as planetary shields.

Systems

Later on in SC development we may be moving to a more RTS style of game play in which systems will play a greater role. But I will not talk about these roles, as I am unsure if I want to take SC in that direction or a separate game entirely.

So, systems will be a map device that will contain planets. However it will not be in the traditional sense of naming conventions. Some games you might see with a system and plant naming system like Asgad for the star and then Asgad I/II/etc for the planets. Instead each planet in SC will have its own individual name regardless of star name.

Systems will be able to contain anywhere from two fifteen planets. The number of planets per system, the names of the stars, and the planets used will be entirely random so no play through gets the same combination (one would hope, but there are limits).

These will play a role in the graphical version of Space Crusade rather then the ASCII or Command Console versions. In the non-graphical versions it will be more of an information device to let the player know where they are, but the Win API version will have actual systems with planets in them that they player can fly through.

Planets

We are going to also have to make more planets. We currently have 241 names in the pool of names used for planets, but we will need many more. I am not sure how many and maybe we will just add them in until we release the game and add some with updates.

Players will be able to now use virus bombs on planets to depopulate them with little destruction to the resources and infrastructure. This means better loot from salvaging the planet and in the graphical version it also means that these planets can be used to setup a base quickly.

In the graphical version planets will work much differently then in other Space RPG/RTS games. The player can capture a planet once it has been removed from the clutches of its previous residents and can use it as a kind of base. The entire planet will not be used, but the player can choose a city to take over. From there they will be able to continue on and colonize the planet for the EA or just drain it of its resources.

If the player decides to colonize it then they can form their own fleets. I have been toying around with the idea of making this a hybrid game where the player can either individually go through the game or take an RTS route and use space fleets that they can make at these planets. There will be more on this in the Battle System section.

Ranks

Currently there are nine titled ranks for the EA side of the ranking system. We need to add some more for this area and then also create the pirate titled ranks.

Ranks should also have a greater effect on the game, such as if you have a rank of Admiral you can control up to three fleets, each with a total of 260 ships each (just an example). In addition your rank should at some point allow for special missions where you can obtain specialized faction weaponry and modules, such as a Admiral rank mission giving you an Earth Alliance battle cruiser if you complete it.

Ranks already effect the players by changing the repair costs for their own ships and also if the Talirath actively look for them. Maybe we should also add in bonuses for the RTS aspect where their rank with the EA gives the ships stat bonuses or their pirate rank decreases the cost of making the ships.

Their rank will also influence who can attack their planets. A player with a high pirate ranking might have their capture planets attacked by the Talirath while a high EA ranking player might get attacked by hostile alien races and marauders.

Feature Set

Here is the current feature set for Space Crusade:

• Turn Based Battle System
• Planet Bombing
• Customizable Ships
• Massive Array of Weaponry
• More Open World Style Gameplay
• 3D Based Coordinate Battle System
• Clones
• Players Choices Affect the Gameplay
• Large Assortment of Ships
• Range-Based Accuracy on Missiles/Lasers
• Randomly Generated Planets
• Randomly Generated Enemies
• Player Rank System that Affects Some Aspects of Gameplay
• Pillaging of Destroyed Enemy Vessels and Ravaged Planets

Future Features

star - Means it is a planned feature (planned to be used, but not locked in and might not be included due to other issues)

star star - Means it is a proposed feature (may be incorporated)

• Bounty Hunting*
• RTS Style Gamplay**
• Colonizable Planets**
• More Weapon and Ship Types
• More Planet Names
• Graphical Galaxy Map
• New Alien Races*
• Non-Linear Story and Story Missions
• Some Linear Story Events
• Fleets**
• Fleet Battles**
• Multi Ship Battles (MSB)*
• Wingmen for MSB*
• Fuel & Energy Consumption*
• Different Endings Based on Player Actions*
• Player Founded Empires**
• Difficulty Levels*

Battle System

The battle system needs an overhaul. We need to rethink how it functions so that we do not need to overly change it when we move to the graphical version somewhere down the road. We also need to streamline it and break it out of the intertwined mess that it is at the moment (functions located in many different classes and even some of it lurches into game.cpp). We need to enhance it for any and all changes we are considering making into the game, like the RTS aspects and new weaponry.

It would be best to build this from scratch from the ground up because of all of these changes. Trying to modify the existing code would be too much of a hassle and could cause some major bugs due to how it currently flows through all of the classes. We need to bring it back into a singular class with no branches where they are not needed.

Item System

I have already started working on this. Each item type will get its own matrix for the data for those items. There will be functions to search this data by ID (matrix element position) or by name. The needed data will be extracted, casted to the necessary data type if needed, and then inserted into the program where it needs to be. An example is getting the resource totals to buy an item. They are extracted from the array and then input into the buy function.

Graphics and GUI

At present we do not need to work about the GUI or graphics for the graphical version. I also have not yet started on deciding what the GUI will look like nor what exactly will be in the GUI.

For certain though will be the need for several GUI's if we decide to go with a RTS style gameplay feature for some missions or if they player chooses to go that route. We will need GUI's for each choice for all aspects of the game because much will change by choosing to go with Independent or RTS style play.