This is really long-winded, so if you make it through all of it and leave feedback I greatly appreciate it.
For my capstone project at school, I am making a game in Flash. This quarter I need to develop a detailed project plan for the game, and as part of the research required for the plan, I need to ask users for thoughts involving the ideas I have for the game's implementation.
The game will be a casual, web-based, turn-based strategy game. Think BattleTech or Heavy Gear lite. I am also planning on including some real time elements for weapon attacks, in order to keep the game from being completely statistics driven. Games should take less than fifteen minutes to play on average. It will take place on a hexagonal grid. Players will control small robots called GunBugs and duel each other until one player's 'Bug is disabled. For the project I turn in, the game will allow only two players in a match, but this will (hopefully) be expanded in the future.
The game sequence will go as follows:
- Players meet in a chat lobby at the main website.
- One player creates a game room.
- Another player joins the game room.
- Players choose their 'Bugs. (only two different options for this project)
- Match begins.
- Turn starts.
- Initiative is determined randomly*. Winner of initiative can either choose to move first, or wait until other player has moved.
- One player moves their 'Bug.
- Other player moves their 'Bug.
- Winner of initiative performs any attacks. Damage is applied. If target is disabled, match ends.
- Other player performs any attacks. Damage is applied. If target is disabled, match ends.
- Turn ends. Proceed to next turn start.
- Match continues until one person's 'Bug is disabled, until neither can attack (draw), or until one player surrenders.
- Players are given a result screen for the match.
- Players are returned to chat lobby on main website.
* - This is will actually be dependent on an individual Bug's Reaction rating plus a random number, but for this project all available Bugs will have the same rating.
These are not completely fleshed out, but I would like feedback to see if this sounds like I'm going in the right direction so far. A lot of it is kind of standard hex-based game stuff.
As stated above, each Bug has a Reaction rating. Initiative is determined by generating a random value for each Bug and adding it to that Bug's Reaction rating. The Bug with the highest result has the initiative, with the rest of the Bugs going in decreasing order. Ties are resolved with a random number test. Since all bugs in this release have the same Reaction rating, intiative will be solely based on the random number. However, when more Bug types are added with different Reaction ratings, I'm hoping this will tend to bias initiative towards Bugs with higher Reaction (such as scout Bugs), but not guarantee that they will always win initiative.
Each Bug will have two different power pools available to it: Movement and Attack. Both are measured in points. At the end of each turn, each Bug will regenerate points for both pools, up to that pool's cap. Cap values are different for different types of Bugs. In addition, at the end of each turn, a player can adjust their Bug's power bias (within limits particular to each Bug type) so that next turn, they might have less power for Move and more for Attack or vice versa. System damage (explained later) can effect how much power a Bug regenerates at the end of the turn.
Movement point costs will be affected by terrain types. There will probably be a few types of terrain for this project release (clear, trees, lots of trees, impassible wall). This will be added to later.
Different weapon types will use different amounts of power to fire. For this release, there will only be a couple of weapons available for a Bug to use.
Terrain will affect attacks. For now, this will simply be number of trees between players modifying the difficulty of the attack(explained later). Things like elevation and concealment will be implemented later.
A player's movement and their target's movement affects attack difficulty as well. If a player uses more than half their Movement power while moving, their attack becomes more difficult. The farther their target moves in hexes, the more difficult the attack becomes.
Bugs have a single HP stat. There is no locational damage. A Bug enters a match with a certain amount of HP, and when this is decreased to 0 the Bug is disabled.
For this release, HP will act as a sponge, basically soaking damage until it is gone. In future releases it may affect how hard it is to damage a Bug.
After a Bug drops below 1/2 HP, it can start suffering system damage. This will affect things like how much power a Bug regenerates, how easily a bug is knocked over, and how difficult weapon attacks are. A Bug can also be disabled through enough system damage even though it still has HP left. Systems become more easily damaged the farther below 50% HP a Bug falls. Basically, once a Bug is heavily damaged things start going downhill for it pretty fast.
Bugs can be knocked over if they take too much damage in a turn. Each Bug has a Stabilizer stat that affects how easy it is to knock over. Damage that a Bug is taken during a turn is accumulated and tracked. When an attack pushes this value over a certain threshold, a test is made against the Bug's Stabilizer rating, which is affected by how far over the threshold their cumulative damage for the turn is. If the test fails, the Bug is knocked over. Note that this test will be made for each attack after the threshold has been passed. This will not matter much for a two player game, but for games with multiple players, this will give more incentive to concentrate fire.
Knocked over Bugs cannot move or perform any actions until they are upright again. It takes Movement power for a Bug to get back up. If a Bug is knocked over and has no movement power left, it will have to wait until next turn to get back up. If a Bug is knocked over before it has a chance to attack, and has no movement power left to right itself with, it essentially loses its attacks for that turn.
The amount of power a Bug uses to right itself will depend upon a test, which will be covered in the Game Interface section.
As stated above, the game will be coded in Flash. It will be in version 8 using Actionscript 2.0, since I don't have CS3 on my home machine. In addition, the game will be using a socket server, either Electroserver or Smartfox. I'm leaning towards the former, because they provide some Actionscript classes designed to help integrate chat and game functionality with Flash.
The Flash clients for both players will be handling most of the work. They will handle all the computations for movement, damage, and such. The socket server will facilitate chat and make sure all clients are updated when someone moves. It will also determine who won initiative and initial game setup. What I'm envisioning is this:
- Game is initiated by client.
- Server assigns numbers to all players.
- Initiating client sends map data to server. All clients send GunBug selection to server.
- Server pulls map data from database and builds XML file for map construction.
- Server pulls GunBug properties for all players from database, builds XML file for unit construction. Individual GunBugs are gagged by their player number.
- Server sends XML map data to all clients.
- Server sends XML GunBug data to all clients.
- Clients build map from XML data, and then GunBugs from XML data.
- Clients populate map with GunBugs, with initial position determined by map.
- Clients send ready signal to server when done constructing game.
- When all clients have sent ready signal, server sends signal to all clients that game has started.
For an individual turn, the following should happen:
- Server signals start of new turn.
- Server signals all clients to regenerate points.
- Clients all calculate their initiatives, send to server.
- Server compares and orders all values sent, determines winner. Ties broken by random number.
- Server sends all client results, signals winner client to move.
- Winner chooses to move or wait. If waiting, sends signal to server indicating this, and they are placed at bottom of movement queue, and server signals next player client to move.
- Client enters moves. When done, ends move. Move data sent to server.
- Server sends movement data to all clients.
- Client maps are updated with move animations and final movement position of player. Return to step 7 and repeat until all players have moved.
- Server signals all clients that attack phase begins.
- Server signals initiative winner to start attacks.
- Client initiates attack. Results calculated client site, sent to server.
- Server sends result of attack to all clients, triggers all animations. If a GunBug is destroyed, they are removed from the initiative determination list and become a spectator.
- Return to step 12 and repeat until Client ends its attack phase. Sends end signal to server.
- Server signals next client to begin attack phase. Return to step 12 and repeat until all clients have completed their attack phase.
- Server signals clients to adjust power bias.
- Clients elect to adjust bias or not, send current bias selection to server.
- Server signals end of turn.
- Return to step 1 until game ends.
Also, throughout the game, the server will pass chat data to clients.
This is how I'm currently thinking of doing the interface.
The areas are as follows:
- This is the map display, where the game action takes place. The user will enter their movement directly on this map.
- A GunBug. In this case, the player's unit.
- Another GunBug. This is the second player's unit.
- Highlight indicating this is the player's currently selected target.
- Player's GunBug information. The green bar shows movement power remaining, the yellow bar is attack power remaining, and the red bar is HP remaining. They will all have text labels and a numeric value with them. Since the overhead map does not show a lot of detail of the player's GunBug, a portrait is provided here. The portrait is animated, and will play a walking animation when it is moving on the map, an attack animation when it attacks, damage animations when it takes damage. Behind it will be a movie clip that will show terrain passing by that matches the type of terrain the GunBug is currently crossing.
- The currently selected target. This is animated similarly to the player's portrait. Also, all attacks are initiated in this window. This will be explained later. If the player has no currently selected target, this will be blank. If a user clicks on a hex, information on the terrain will appear.
- Chat area. Top area is the chat log, bottom is where a player enters their information.
This I am not totally sure how to handle yet.
For the project release, a player will only pay movement costs for moving across hexes. There is no cost for changing facing, and a Bug will automatically turn in the right direction to attack, and to face an incoming attack.
Three methods come to mind for this. One is to highlight all the available hexes that a Bug can move into and just let the player click there to move. The problem here is that the algorithm to find and highlight these hexes is a bit of a pig and will probably run like crap in Flash (it's some weird modification to Dijkstra's algorithm for hexes that takes into account terrain cost). The game isn't real-time, so it's not that huge a concern, but there will be a noticeable delay when a player's movement phase comes up.
The second one is to just let the user use the arrow keys to move their Bug, using the side arrows to turn and the up arrow to move forward a hex. This seems clumsy, though, and I'd rather have the whole game be mouse driven.
A third one is to let the user click and hold on their Bug, and then trace a path over the hex map for it to follow, releasing on the final hex. Their movement cost would decrement as they moved forward each hex to let them know how many points they had spent. I like this idea because it would let a player define the exact path for their bug to take. However, I'm not entirely sure yet how I would implement this. Also, since the first release will not take hex facings into accounts, it could lead to players doing silly things like moving in spirals to keep their speed high for defense reasons. Also, if I'm having a scrolling map, it gets problematic when a player gets to the edge of the viewable map.
Also, turns will be timed. A user will only have a minute or so to get their movement entered, to force them to think quickly, and keep the game from bogging down.
Like I mentioned previously, I want to try and have this game not entirely statistics-driven, so I want to try adding in some real-time elements.
When a user initiates a ranged attack with a cannon, by clicking and holding on a cannon button by the target's portrait in the lower left of the interface area, a set of rings would appear superimposed over the target's portrait. A green ringed crosshair would then start contracting quickly towards the center of the colored rings. The user would then try to release the mouse button while the green ring was superimposed over a region of the colored rings representing maximum damage. Releasing too early or too late would result in a miss. Basically, each colored area of the rings would represent a multiplier to the weapon's base damage. See the image below:
The size of the colored regions would vary depending on the Bug's range to its target. Range will come in four bands: short, medium, long, and maximum. The targeting rings at maximum range will not have a red damage zone, so it will not be possible to deal full damage with a ranged weapon that far out. In contrast, in the short range band, the red zone would be larger. The speed at which the green ring contracts will be determined by player movement, target movement, and intervening terrain penalties. I am also considering having dense terrain hexes reduce the amount of damage done to a target.
For a missile ranged attack, when a user clicks on a missile button and holds, a targeting recticle will appear over the target's portrait and begin to move around randomly. The player's cursor will become a targeting diamond. They will then have to move the diamond around and try to release it inside the targeting recticle as close to the center of the recticle as possible.
The distance from the recticle's center is used to determine the damage multiplier. Anything outside the recticle is a miss. Also, the user will have a limited amount of time in which to complete the attack, if they wait too long it's an automatic miss. The size of the recticle is determined by range, and the speed at which it moves and the time limit are determined by Bug movement and terrain.
For Melee attacks, I am thinking of having a gesture-based system, a la Chick Chick Boom if you remember that game. The gestures wouldn't be anywhere near that complicated, though. They would be something like a simple diagonal slash across the target portrait that the user has to trace in a limited amount of time.
Standing up after getting knocked down would also use a mouse gesture, but this one over the player's own Bug portrait. There would be a time limit to perform this gesture. Tracing the gesture accurately would reduce the amount of points required for the Bug to stand up. If a player runs out of time, their Bug will still get up, but it will use the maximum amount of points required for it to stand.