Need help with a school project [warning: very long]

Syngyne

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.

---

Game Concept
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:

1. Players meet in a chat lobby at the main website.
2. One player creates a game room.
3. Another player joins the game room.
4. Players choose their 'Bugs. (only two different options for this project)
5. Match begins.
   1. Turn starts.
   2. Initiative is determined randomly*. Winner of initiative can either choose to move first, or wait until other player has moved.
   3. One player moves their 'Bug.
   4. Other player moves their 'Bug.
   5. Winner of initiative performs any attacks. Damage is applied. If target is disabled, match ends.
   6. Other player performs any attacks. Damage is applied. If target is disabled, match ends.
   7. Turn ends. Proceed to next turn start.
6. Match continues until one person's 'Bug is disabled, until neither can attack (draw), or until one player surrenders.
7. Players are given a result screen for the match.
8. 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.

Game Mechanics

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.

Initiative
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.

Power
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

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.

Damage

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.

Technical

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:

1. Game is initiated by client.
2. Server assigns numbers to all players.
3. Initiating client sends map data to server. All clients send GunBug selection to server.
4. Server pulls map data from database and builds XML file for map construction.
5. Server pulls GunBug properties for all players from database, builds XML file for unit construction. Individual GunBugs are gagged by their player number.
6. Server sends XML map data to all clients.
7. Server sends XML GunBug data to all clients.
8. Clients build map from XML data, and then GunBugs from XML data.
9. Clients populate map with GunBugs, with initial position determined by map.
10. Clients send ready signal to server when done constructing game.
11. 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:

1. Server signals start of new turn.
2. Server signals all clients to regenerate points.
3. Clients all calculate their initiatives, send to server.
4. Server compares and orders all values sent, determines winner. Ties broken by random number.
5. Server sends all client results, signals winner client to move.
6. 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.
7. Client enters moves. When done, ends move. Move data sent to server.
8. Server sends movement data to all clients.
9. Client maps are updated with move animations and final movement position of player. Return to step 7 and repeat until all players have moved.
10. Server signals all clients that attack phase begins.
11. Server signals initiative winner to start attacks.
12. Client initiates attack. Results calculated client site, sent to server.
13. 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.
14. Return to step 12 and repeat until Client ends its attack phase. Sends end signal to server.
15. Server signals next client to begin attack phase. Return to step 12 and repeat until all clients have completed their attack phase.
16. Server signals clients to adjust power bias.
17. Clients elect to adjust bias or not, send current bias selection to server.
18. Server signals end of turn.
19. Return to step 1 until game ends.

Also, throughout the game, the server will pass chat data to clients.

Interface Mechanics

This is how I'm currently thinking of doing the interface.



The areas are as follows:

1. This is the map display, where the game action takes place. The user will enter their movement directly on this map.
2. A GunBug. In this case, the player's unit.
3. Another GunBug. This is the second player's unit.
4. Highlight indicating this is the player's currently selected target.
5. 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.
6. 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.
7. Chat area. Top area is the chat log, bottom is where a player enters their information.

Movement
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.

Attacks
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.

Getting up
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.

Lord Yod

That looks like it'd be a lot of fun.

For the movement interface: instead of highlighting all available hexes, why not make the hex under the mouse highlight? Maybe scale the highlighted color according to movement cost. That would use the same algorithm, but wouldn't it take less time to do?

Syngyne

Lord Yod wrote: »

That looks like it'd be a lot of fun.

For the movement interface: instead of highlighting all available hexes, why not make the hex under the mouse highlight? Maybe scale the highlighted color according to movement cost. That would use the same algorithm, but wouldn't it take less time to do?

Well, instead of having a big delay at the beginning of the user's movement phase, it would make a smaller delay every time the user moved their mouse into another hex. It's something to think about.

I'm also thinking since each Bug will have a maximum distance it can move, I could work out some way to limit how far the pathfinding algorithm searches, so if a movement path goes over a certain cost it automatically disqualifies that path and starts searching along another.

When I posted this idea on another forum, one of the people who responded commented that some of the mechanics (knockback, system damage, multiple attack mechanics) seemed excessive for a casual strategy game. Do you agree with this? Does it need to be simplified a bit?

acidlacedpenguin

as long as you can implement those mechanics without pulling your hair out trying to meet deadlines or anything, I don't see those mechanics to be too much for a casual strategy game. If it were me I'd probably shoot for having those in there, but if I started to run out of time then I'd cut multiple attack mechanics, knockback, and system damage in that order.

anyway, best of luck to you.

Syngyne

Thanks for the feedback, guys. I appreciate it.

Another point that was brought up was that the knockback and system damage mechanics seemed to really punish a player that lost initiative, and it was suggested I either mitigate the severity of the penalties or eliminate them entirely. One thing I was thinking of changing was to have the knockdown penalty changed to the player losing half their movement points for the next turn. What are your thoughts on this?

bamjo

This game sounds awesome. I don't think its too complex at all. That kind of depth really sets it apart from all the other clicky clicky flash games. I really like the gesture and attack mechanics.

Also is it just me or does this game sound like it would be sweet on the DS?

lowlylowlycook

Reading through this I can't help but think this should be a DS game

One thing that might help in keeping the calculation of allowed moves under controll is to have the amount of hexes moved per turn low. I have done the calculation but I'm pretty sure the amount of time to calculate will go up very, very fast as you increase the number of hexes that could be moved through.

As for knockback, etc., is there any reason not to go to simultaneous moves then do combat that way as well? Keep the same time limits and the game would be twice (more if you allow more than 2 players) as fast. Then there is no need for a initiantive stat. If you want to have "fast" bugs, I'd suggest a large movement value and/or a stat that makes the effect of speed moved on the targeting games less. Since it is at heart a strategy game there shouldn't be any latency or lag issues but you would have to figure out how to handle collisions, i.e. when two bugs end on the same hex. I suggest another mini game.

[Edit] Dammit I had this off in a tab then came back to it and so get sooo beat on the DS thing. heh

peterdevore

You seem to be calculating some important things (initiative and attack rolls for example) client side and then sending them to the server. This has big security 'risks'; there are a lot of people who enjoy reverse engineering and then exploiting holes in flash games. There is a simple rule: 'don't trust anything that comes from a client', so don't have the client calculate anything important. This is easy for the turn based part, but impossible for the real time part unfortunately. Try to minimize these kind of exploitables and make notes about them in your reports to show that you thought about it, they will really appreciate it.

You mentioned how damaged bugs get extra penalties like less regeneration etc. It can be quite frustrating for a player to have the game work even more against him if he is already doing badly, but this has already been mentioned.

Having facings graphically, yet not with any impact on the actual gameplay might be an extra burden on your graphics designer if he has to make all the different facings for all the bugs (unless it's purely top-down and you can simply rotate the graphic).

Try and make some risk/reward tables, where options for the player with regards to weapon type, terrain (concealment & cost), and maybe some special items/power ups (mines, instaknockback that costs a lot of power, repair kits?) are explained with their associated risks and rewards.

A question you might want to ask yourself: is using XML for maps and bugs necessary? I'm not really well versed in Flash and its libraries, but you will probably get a measurable performance and bandwith hit compared to a binary based solution. Just using the standard serialization features of Flash might be easier and faster, and you don't really need the compatibility XML offers anyway.

Making a casual strategy game is pretty hard. Balancing is a big deal, answering all those questions like 'will knockdown be too harsh' can only be done properly when you start playtesting. This plan is quite ambitious compared to most casual flash games, but then again, as a last project you want something good to show to people.

Syngyne

peterdevore wrote: »

You seem to be calculating some important things (initiative and attack rolls for example) client side and then sending them to the server. This has big security 'risks'; there are a lot of people who enjoy reverse engineering and then exploiting holes in flash games. There is a simple rule: 'don't trust anything that comes from a client', so don't have the client calculate anything important. This is easy for the turn based part, but impossible for the real time part unfortunately. Try to minimize these kind of exploitables and make notes about them in your reports to show that you thought about it, they will really appreciate it.

Yes, security is one thing I haven't really addressed yet. I'll have to look more at it, but it might be something that gets cut before the project release. I'm working on a really, really tight timeframe.

You mentioned how damaged bugs get extra penalties like less regeneration etc. It can be quite frustrating for a player to have the game work even more against him if he is already doing badly, but this has already been mentioned.

Yeah, I mentioned above about removing system damage and making knockback just cost a player half their movement for next turn. Does that sound more reasonable?

Having facings graphically, yet not with any impact on the actual gameplay might be an extra burden on your graphics designer if he has to make all the different facings for all the bugs (unless it's purely top-down and you can simply rotate the graphic).

The map view is probably going to be all top-down and vector at this point, that way the player units can just be rotated for new facings. In later versions I want to go more isometric.

Try and make some risk/reward tables, where options for the player with regards to weapon type, terrain (concealment & cost), and maybe some special items/power ups (mines, instaknockback that costs a lot of power, repair kits?) are explained with their associated risks and rewards.

This is another thing I'll have to look into as well. For the project release, so far I was thinking of just having two weapons - a machinegun and missiles. One Bug would have one of each, and one would have two machineguns. Missiles would be harder to aim and have a minimum range, but be longer range and higher damage than machineguns. The Bug with double machineguns would just attack with both and do twice the damage of a single machinegun.

A question you might want to ask yourself: is using XML for maps and bugs necessary? I'm not really well versed in Flash and its libraries, but you will probably get a measurable performance and bandwith hit compared to a binary based solution. Just using the standard serialization features of Flash might be easier and faster, and you don't really need the compatibility XML offers anyway.

I'm using XML for data now because I've done Flash and XML integration previously, and because of where I would like to take the game eventually. After I graduate, I'd like to work on this game more as a hobby and add persistence to the game, letting a player earn upgrades for Bugs as well as new Bugs. All this info would be in a database, and XML would be the intermediary when pulling the data back. I'm just trying to get some groundwork laid now to make my life easier down the road.

Making a casual strategy game is pretty hard. Balancing is a big deal, answering all those questions like 'will knockdown be too harsh' can only be done properly when you start playtesting. This plan is quite ambitious compared to most casual flash games, but then again, as a last project you want something good to show to people.

Yeah, I'm beginning to wish I could go back in time and punch myself in the face before I suggested this project to my teacher.

Thanks for the feedback, all, and keep it coming. This is a great help.

Lord Yod

Re: complicated mechanics

IMO anybody who will be really interested in a game like this will more than likely have at least seen Battletech played. Compared to that, this is child's play, so I think you've got your mechanics spot-on for a casual game. (I would go one step further and say that for a fully-developed release, you should add in more complexity like terrain modifiers, hit locations, heat buildup, ammunition, etc)

Re: knockdown

Perhaps make it so the machineguns don't do knockdown, but instead only missiles. Thus, to pull it off, you have to be really good at aiming the missiles. (Perhaps you'd have to get a 'critical' or whatever to do it)

Re: movement, initiative, etc

Have you thought about implementing a charge timer a la Final Fantasy? Maybe the bug with dual MG's is a bit faster than the MG/missile bug. Both players start off with full charge, when you attack or move it depletes the charge, and you get a new turn when your charge reaches 100. Most of the time it will result in the dual-MG bug going first and every 4th or 5th turn going twice, for example.

Also this completely eliminates initiative checks. (Though you could have that at the start of combat maybe)

Syngyne

Lord Yod wrote: »

Have you thought about implementing a charge timer a la Final Fantasy? Maybe the bug with dual MG's is a bit faster than the MG/missile bug. Both players start off with full charge, when you attack or move it depletes the charge, and you get a new turn when your charge reaches 100. Most of the time it will result in the dual-MG bug going first and every 4th or 5th turn going twice, for example.

Also this completely eliminates initiative checks. (Though you could have that at the start of combat maybe)

The main reason I currently have it set up the way it is is to eliminate the game being dependent on client/server communication for anything real time. I don't have much experience with socket servers, so I don't think I could code workable real time netcode in the amount of time I have available. Keeping the movement individually turn based keeps it simple enough for me to tackle (simple being a relative term. ).

It might be something to try for a later revision, but for this project I'm going to keep it turn based to keep myself from going insane trying to finish this.

lowlylowlycook

Just to clarify, I suggest changing the sequence as follows:

1. Players meet in a chat lobby at the main website.
2. One player creates a game room.
3. Another player joins the game room.
4. Players choose their 'Bugs. (only two different options for this project)
5. Match begins.
   1. Turn starts.
   2. All players make their move simultaneously and within the time limit.
      1. One player moves their 'Bug.
      2. Other player moves their 'Bug.
   3. After both/all moves are made the server applies moves simultaneously.
   4. If there are any collisions they are resolved by some means.
   5. All players make their attack simulateously and within the time limit.
      1. One player attacks
      2. Other player attacks
   6. Damage is applied for all attacks. If any/all targets are disabled, match ends.
   7. Turn ends. Proceed to next turn start.
6. Match continues until one person's 'Bug is disabled, until neither can attack (draw), or until one player surrenders.
7. Players are given a result screen for the match.
8. Players are returned to chat lobby on main website.

I think this would remove the random element of initiative from the game. As you have it being able to move second and attack first is a very big advantage which is given randomly. As an aside, are there reasons to ever move first?

Additionally it would make the game move 2x as fast and eliminate most time spent waiting for your opponents move. This might really increase the casual friendlyness of it. The main downside I can see is that the strategy will be less straitforward since you will have to guess at what your oppenent will be doing in the movement phase but this should not be a huge deal since facing isn't taken into account.

Just thinking about it, it shouldn't be any harder to code since it is mostly just reordering the timing on the server side. You will have to deal with possible bug collisions in some way though.

Syngyne

lowlylowlycook wrote: »

You will have to deal with possible bug collisions in some way though.

This is why I'm currently not doing simultaneous movement-- I'd have to come up with a way to deal with collisions during movement, or players trying to end up in the same hex. Having each player move individually simplifies things.

As far as moving first, if a player wants to get to a particular piece of terrain before someone else does, they'd want to go first to make sure they got there. You'd probably want to end up going last most of the time, though.

Lord Yod

The other thing to think about is to only check initiative at the start of combat, and from there go to A/B turn-based mode.

lowlylowlycook

Syngyne wrote: »

lowlylowlycook wrote: »

You will have to deal with possible bug collisions in some way though.

This is why I'm currently not doing simultaneous movement-- I'd have to come up with a way to deal with collisions during movement, or players trying to end up in the same hex. Having each player move individually simplifies things.

As far as moving first, if a player wants to get to a particular piece of terrain before someone else does, they'd want to go first to make sure they got there. You'd probably want to end up going last most of the time, though.

Well you should absolutely keep it as simple as possible given your rather grand plans but I think the speedup in play may be worth it. Two simple ways to do it are that the first player to complete their move gets the hex or the one that used the fewest movement points gets the hex. Have the player that lost the hex end up in the last hex they would have occupied. Working out how to display that graphically is left as an exercise for the reader.

acidlacedpenguin

I might also suggest that instead of having to deal with collisions to make it so they are allowed to occupy the same space, possibly making it so that if this were to occur there would be a melee battle, the loser of said battle could be pushed back to whichever hex they came from.

Not sure if you would want it but it could be implemented in a sort of "twitch" fashion, like "oh shit we both moved into the same hex, first one to do some mouse input wins the melee.