These contracts work in stages, each of which comes with a budget. If our proposal is accepted, we will start stage 1, which will be to make what amounts to a demo of the eventual system (which may end up using a different game engine). The demo just has to demonstrate our game mechanics in a way that the government people can understand and appreciate, so it doesn't need to be the latest and greatest in physics simulation (we don't have the budget for the latest and greatest yet; at least not until phase 2 or 3). Based on their criteria, I think that an RTS type game fits the bill for what the MDA is looking for, so I worked up a basic use case style overview of a game design to accommodate our needs. I think that Spring would be a good fit for us, but I wanted to see what people who have experience developing games with Spring say before I commit.
If you guys could help me determine if Spring can do the job we need it to do, it would be a big help.
The MDA wants a few specific things in the design;
Develop and demonstrate a gaming concept
* Feedback should include some type of reward, possibly points, where the users can compete for skill levels.
* Design scoring algorithm that accommodates multiple threats of varying types and capabilities pitted against multiple sensors, shooters, and C2 elements also with varying capabilities.
* Provide feedback to the game participant in a quantitatively measurable format.
* Provide the capability to compare these “scores” based on the participant’s alternatives or courses of action.
* In planning a missile defense design, the blue force asset lay-down (consisting of sensors, shooters, and command and control (C2) elements) will vary in number.
* Collaboration between shooters via their elements also varies based on both proximity (communications restrictions) and capability.
* The threat (red force asset lay-down) will also vary in number and capability.
* Shooters may consist of single or multiple missile configurations with basic ballistic missile trajectories.
They want a nice "human-machine interface" (GUI) so we will probably be contracting that piece to a professional studio. That means we need to be sure Spring can be easily plugged into a custom GUI.
I sketched up a quick "use case" type overview of how the game will work. To some extent, the MDA requirements are tricky because they want to have the ability to start with asymmetric starting positions/forces but they also want the game to be "fun" for their operators, so I don't want games to be just a march of inevitable odds against the smaller player as they are crushed. I also picked up on replay ability. They want their operators to like this enough to come back and play it again repeatedly. To me, upgradable units you can keep from one game scenario to another seemed like a good choice to fit this criteria (obviously, this makes game balance an issue, so I will use "start points" that will allow a player to select their units at the beginning of play).
Compared to most games that use Spring, this game would involve relatively few units, and much less in-game "spawning". Basically you would start with a set of pieces you choose at the beginning and then set them up by placing them on the map. You would have one (or more) cities that you must defend, and which will slowly spawn your offensive ballistic missiles. You would be able to select lower capability offensive missiles spawned faster or better ones slower.
Here is my draft of a sort of broad "use case" for the game design;
Player logs on.
Depending on player history, player may have "veteran" units in their game account that they can use.
"Veteran" units cost more points to deploy than "generic" units, but have increased capabilities.
If player has no "veteran" units, they go to load screen for a new scenario.
During load screen, player selects units for the upcoming scenario.
Units may be cheap (low point cost but low capability) or expensive (high points cost and high capability).
Units include ground based static radars, ground mobile radars, naval mobile radars and missiles, ground mobile missiles, ground static missiles, satellite detection systems, airborne radars, and "wildcard" special units with limited use per scenario (including spec-ops team and cyber-attack). There are multiple types of each, and each has strengths and weaknesses.
Game units will lose the ability to communicate with one another and their sensor capabilities will not benefit the player if they are placed too far away from another unit.
Ground static radars have a great detection range and breadth, but they cannot be moved once deployed. Units should be characterized by the radar band(s) they operate in, since this will affect both their capabilities as well as their vulnerability to detection.
Ground mobile radars are much less powerful, but they can be moved. Their mobility should affect their vulnerability if they employ a radiate-and-run strategy.
Naval units include powerful radars, anti-missile systems, and offensive missiles, but their movement is restricted to water (include multiple naval unit types like destroyers, subs, etc).
Mobile ground missiles have a limited range, but they are cheap and mobile. Their mobility should affect their vulnerability if they employ a shoot-and-run strategy.
Static ground missiles are expensive and immobile, but they are powerful and have great range.
Satellite detection systems are expensive and their movement is somewhat limited (they must progress across the board in set patterns) but they provide great range and unique detection capabilities.
Airborne radars come in a few types (large, AWACS type vehicles and small UAV type vehicles). They are very mobile, but tied to a friendly airfield or aircraft carrier and sometimes provide unique offensive capabilities (UCAV attacking enemy radars or "wild weasel" jamming enemy radar). They tend to be on the expensive side.
Spec Ops wildcard units can be deployed almost anywhere once (or limited number of times) per scenario. They can disrupt any one specific enemy unit by raiding it (with certain restrictions like large naval units or satellites).
Cyber attack wildcard units can be deployed a limited number of times per scenario and can disrupt certain types of enemy units (generally radars and satellites but not static launchers or naval units). Cyber attack units are cheaper than spec ops units.
Units can come in more expensive and capable varieties or more limited but cheaper types (Chinese and Russian units) which allow a player to choose a large number of cheaper units if they want.
Once both or multiple players have selected their units (we may end up having multiple players able to join two or more sides with varying starting power), they select a map type. Multiple maps are possible, including a higher scale "continental" map covering the globe, or a lower scale "battlefield" map covering a region. Maps can be of real places or they can be pre-made or even procedurally generated for maximum variety.
Players start out at set starting positions on the map. As soon as the game starts, everything is "live". They both set up their units in real-time and can attack and defend as they continue to position their starting units. The objective is to destroy the opposing city while preserving your own. Destroying both cities (MAD) may be a technical win, but no friendly units will survive to be carried over as "veteran" units.
Units function like RTS units and will automatically move (if mobile) in pre-set logical ways. They will attempt to detect, warn, intercept, attack, etc, as needed. Obviously, player can override them and direct their actions as necessary.
The map is covered by a "fog of war" in any area not currently covered by detection systems. The player has no knowledge of what is happening in "fog of war" regions.
Small attacks take place when a small unit attacks a small unit (like a spec-ops unit attacking a ground based launcher or a UCAV attacking a radar installation). These attacks are resolved automatically much like most other RTS games.
Large attacks take place when one player attacks another player with ballistic missiles. These attacks are handled by the spawning of a "missile" unit which follows a flight path over the game board in something close to real time (might be real time accelerated slightly for purposes of game speed). This missile unit will follow a set path and during the different phases of it's flight, the opposing player has a chance to destroy or confuse it depending on what systems he has in place. If the opposing player cannot destroy an incoming missile attack, it will wipe out a large section of the map, potentially including his whole city. If a home city falls, that player loses.
To launch a missile, a player must designate the map "hex" it will land on, thus providing it with targeting information beforehand. Different types of missiles will have different warheads, including MIRVs, which act differently at different stages. They also have different ranges, and their cost is dependent on their scale and complexity.
The cities spawn ballistic missiles based on city resources in-game on a constant, but slow basis. They can spawn missiles as set by the player; huge and devastating types cost more and take longer than SCUD types. This pushes the game toward a close by constantly increasing the stakes while also removing the possibility of a player simply setting a silo as his first "unit" placement and launching immediately at the start of the game. The set up phase would take place as the first missiles are rolling off the assembly lines.
Points are awarded for every action that has an adverse effect on an incoming missile, including detection. If a player detects launch phase but can't destroy it then, they get points. If they can destroy it, they get more points. If they detect and destroy in mid-course, they get points, etc. Generally, the closer to the origination point, the more points they get. Obviously destruction pays more than detection as well.
To destroy an incoming missile, a player must launch interceptors (or do whatever) at the right time. Launching an interceptor will also "spawn" a missile unit that will follow a ballistic course. That unit will destroy the incoming missile if it's path takes it close enough to where they occupy the same space at the same time. To make this easier on the player, eligible interceptor systems will light up green when they are able to hit an incoming missile based on where it will be when their missiles get to it. The player should have an action bar where they can select any of their own units in a tab in the bar and command them to launch at any time. These action bar icons would also light up green when they have a chance to attack the incoming missile.
Flights of missiles and interceptors should be physics based. Some randomness [winds and precipitation at low altitude during launch and re-entry phases.] may come into play in order to simulate the likelihood of a given interceptor to be able to do the final phase targeting necessary for an intercept. To make this work, the two units are controlled by a basic ballistic trajectory. The interceptor unit has a range in which it is able to make an attack (very close, usually). It has some level of random chance to complete an attack and an attack takes a certain amount of time. An attack is treated basically like the interceptor unit is a bomb that commits suicide and blows up the enemy missile. If the attack is resolved as not successful, the interceptor continues on its course. If the attack is successful and both units are close enough, the interceptor does X damage to or destroys the enemy missile. Interceptor stats would include a better computer (better % chance of a hit per attack) Better radar (Increased range in which to make attacks, allowing multiple attack attempts), and better warhead (allowing definite destruction as opposed to damage #). In the case of a MIRV, the missile would be one unit until it reached reentry phase, and then it would split into multiple units, each of which would have to be targeted.
Advanced design features like interceptors being able to expend fuel to maneuver can be handled fairly simply. The interceptor would have a limited fuel number, it would have a "move" stat that is usable in 3 dimensions (but which would be vastly slower than the speed endowed by it's launch trajectory) and it would have it's own radar range, outside of which it cannot "see" anything. The interceptor unit AI will try to hit an enemy missile by expending movement toward it in order to optimize it's # of attack attempts and hit chance. Movements would alter it's trajectory, but only by a small amount, so it would seem to be "wiggling" as it moved along the ballistic path. The computer would keep track of that unit's speed and count its "move" attempts against that vector.
After the game, points can be used to buy upgrades to units that survive. Points are also tracked and stats ranked. These can be broken into successful intercepts, enemy city destruction, enemy unit disruption, etc.
After a game, surviving units may be upgraded to "veteran" status and points spent to give them better systems. Depending on the unit type, these upgrades could be detection range, mobility, damage, etc. These units will remain in a player's account and be accessible later, at a starting point cost, if they want to use them in a future game.
This will all be elaborated in much greater detail as we complete our requirements specification document and develop use case narratives and diagrams. Based on the general overview, I think it's possible to say whether this is something Spring could handle.
Our budget for the demo should be sufficient if we win the contract, but we will have a limited time (which means we may be contracting people familiar with our game engine choice on an as-needed basis if we win the bid). For this reason I don't want to have to reinvent the wheel too much. Graphics are not a particular concern for the demonstrator, we just have to show the MDA that our game mechanics are well designed and executed, so we can use open source graphical assets and keep our models simple and generic.
Bottom line, should I go with Spring or try something else for putting our demo together?
Thanks!
