Strike Ops

Proposal for the pygame 8 week project. Project manager, Pete Shinners


A game of Strike Ops is two players competing over the internet in short game rounds. A player controls a group of soldier units in close quarter gunfights. Each round has a set time limit of 3-5 minutes. The game will be played on one of 4 maps. Each map has a different "objective", one player is offense and one is defense. The offense wins if the objective is finished, the defense wins if the time runs out. A team can also win by eliminating the other player.


Changelog

Additions and changes marked with ** in the text

3-17-2003. Originally I had planned to keep the game logic and interface very simple. After comments and rethinking, the plan was a bit too simplistic. I've added changes which now reflect added "direction" to all player positions, which effects line of site and firing situations. I've added a section "Rules of Engagement" which should detail all decisions made by the computer about unit firing. Because of the added complexity, the plans for limited ammunition clips has been dropped. There are limited bullets in a clip, which requires reloads, but units have unlimited clips.

3-21-3004. After further review, I am dropping the "2 elevations" design to the maps. Playing with some mockup screenshots I see they will be hard to layout the maps. Taking them out also simplifies many parts of the engine and pathfinding.


Theme

The game theme will be "near-future combat". The style will be very arcade oriented, meaning everything is a bit exaggerated and more "fun" than "serious". The graphics will be "low colored pixel art". Gameplay will happen in close-quartered village settings. It will be an "action-strategy" game that happens realtime.

Playing

The game will begin by selecting an online opponent from a list of available players. Once connected, each player will select a country to play as and a map is selected. Before the gameplay starts, the player gets a chance to equip his characters. For each character there are different "equipment packs" that have equal values. Equipment has a primary weapon and comes with various extras and grenades. Finally gameplay begins.

After the round statistics will be displayed and the players choose from different rematch options.

Graphics

The game will be viewed from overhead using tiled 2D graphics. The graphics will have a slight perspective to them, but gameplay is strictly 2D, and we have no issues with overlapping or obstructed areas. The gameplay view will be scrollable in all directions. A small sized status bar along the right edge of the screen with various interface and information. The indoor areas will be divided into room sections. If none of the units can see into a room, it will be 'covered' by roof. When a unit can see inside, the top will pop off and show the interior.

Each nation will have it's own graphics for units. This will likely be the same graphics for each team, with the colors adjusted. Each country will have a major color to distinguish them. Unit animation will start pretty limited, a 3 frame walk cycle for 8 directions will be the mimimum for the game release. Then there will be several "special" animations, like dying and jumping.

Effects will be fairly limited, but we should expect to have tracerlike lines for bullets, bullet and explosion marks, blood trails from damaged units, and simple lighting.


Units

Each country has different statistics for its units. There are three categories "health", "speed", and "technology". Each statistic is one of three ratings "good", "normal", "bad". This makes for 6 different combinations of statistics.

Each unit will have a small inventory, based on what equipment package they started with. The amount of bullets used is carefully tracked. When a clip is out of bullets the unit must reload before firing, which takes several seconds time. ** Units will also have a limited number of grenades. Grenades can be restocked by picking them up from dead units.

Each unit will have a given amount of health. It will only take a couple bullet hits to kill a unit. Wounded units will be slightly crippled and leave a trail of blood as they move.

Weapon firing will have a random accuracy. When a shot is fired it will have its trajectory randomly offset. This means the bullet could stray and hit something unintended. Units will not fire if there is a certain chance they will hit one of their teammates. ** The offset effect will be very small, and only effect long range shooting.

** Each unit has a near 180 degree field of view. When issuing move orders the player can directly choose which way the unit should face, if not the computer will determine a good facing. Units rotate in 1/8 turns. Each eighth rotation takes a set amount of time. Units can only shoot in the given 1/8 arc of their direction, even though they can see a wider area.

Rules of Engagement **

While the user manages the movement of units, the computer will need to make many decisions about when to fire and who to shoot at. This section details all the decisions the computer will make beyond user control.

Standing units will automatically turn to shoot at any unit in their field of view. They will also automatically turn to face units outside their view if shot at. Standing units will automatically fire at any enemy that comes in view.

Moving units will only fire at target units if the target can see the moving unit. If other units are already shooting at a target unit, the moving unit will then also fire, even if not in the targets line of site.

Standing units will automatically move away from a thrown grenade. This movement will try to get the unit outside the "line of sight" of the grenade, or outside the damage perimiter. Units will only be able to move about one single tile before the grenade explodes.

Units will always reload their guns if no enemy has been recently visible and they are missing more than a couple bullets from a full clip. The amount of time after seeing an enemy will be weighted to what percentage of bullets is left in the clip.

Moving a group of units will require simple formation based movement. There are two forms of group movement. "Normal" and "Fast". Fast mode will order a reckless run through rooms with no cover fire. Normal group movement will spread units to keep open lines of fire. Units in front may temoporarily stop behind good areas of cover (windows, boxes, bushes, etc) and move to the back of the group.

Weapons

The choice of weapons will be simplistic. Minimally there will be three of the "Weapon Packs" to give to each unit. "Pistol", "Uzi", and "Assualt Rifle" are the flavors to choose from. The pistol has high accuracy and high damage and quick reload time, but has a low rate of fire. The uzi has the lowest accuracy and lowest damage, but the highest firing rate. The assualt rifle has normal accuracy damage and firing rate but slow reload time. The weapons are listed in order of effectiveness, but there are other advantages/disadvantages. The assault rifle will slow the unit down slightly, while the pistol will provide a small speed boost. When equipped with the pistol the unit can carry 2 grenades. The uzi unit can carry one grenade. No grenades for the two handed rifle.

Grenades can be recovered from the bodies of dead soldiers, but weapon type cannot be switched during the round.

Map

The map will be scrollable, and the standard level will likely be 2x4 "screen areas" in size. ** Maps will be horizontal not vertical, since this will help with the stereo sound effects.

All walls are made of actual tiles. There are no "walls in between tiles" as seen in some overhead strategy games. We will need to use stylized isometric so we can see all wall edges from the overhead view. windows and doorways will be tactical defense points, and it is necessary to easily see them all.

The map will be made of a straight grid of nodes. There are several attributes for nodes, like are they passable, can you see through them, what elevation it is at, and more. Unit movement is not limited to the grid space, and they can move freely between the grid tiles.

Some tiles may not be passable but have a "visible" percentage. The visible percentage will be used for two things. One is to reduce the line of site for looking through that tile. It will also be used to randomly stop bullets from passing through that tile. When standing adjacent to a visibility blocking tile, the effect will be negated. This means you can easily look through the bushes you are hiding in, but not for others to see in. ** This percentage should also reduce grenade damage.

Areas are broken down into room groups. Any interior room is grouped along with other tiles in that room. There are also "outdoor" areas which don't belong to any room. All interior rooms have two display states. If a unit can see into the room, the roof is popped off and we see the interior. If no units can see inside then the roof is drawn over the interior room.

Line of sight will be precomputed and saved with the level data. Every node will have a list of other nodes that are visible from that point. This will allow for realtime dynamic fog to be draw onto the map with little calculation. You will be able to see all the outdoor tiles not in your line of site, they will just be dimmed.

The map will also have built in path information to help units find there way. With the map path information we should be able to direct units without requiring full A* type pathfinding. ** The paths will be made of vector lines.

Sound

The general list of sound effects will not be too high. Each weapon will need a sound, and we will have a few variations with pitch changes. We'll also want various "ricochet" sounds we mix into the gunfights. We need several footprint sounds for walking on different tiles (stone, dirt, etc). The sounds will be stereo panned to help the player locate any actions.

We will need a lots of voice work for each of the nations. We will compile a master "voice" list of the different type of sayings we need. The voices will be used to inform the player of unit conditions and confirmations. There will also be extra "chatter" between units. The voices will be scrubbed through a "dirty radio" type filter to degrade them. This should enable more programmers to pretend they are voice talent.

To complete the "arcade" feel there will also be an announcer. The announcer will have a typical bold announcer voice. It will be used mostly in the pregame and postgame, but barely at all during actual gameplay.

Input

Somewhat described in the "gameplay" section. The game requires a 2 button mouse and keyboard. All of the gameplay can be handled with the mouse, but there will be several keyboard functions that can can be used. They arrows can be used to scroll the map, and there will be hotkeys to select individual units from the keyboard.

** The left mouse button will be used to handle all unit selection. Selecting units can be done from the viewport by directly clicking units, or box selecting them. Units can also be selected from the status bar on the right edge of the screen.

Right clicking issues all movement commands. Right clicking on the map will move a unit or group of units to that location. A "click and drag" input will move units and control the direction they will face at the end of their movement. We will also likely need a "doubleclick" movement command to order fast group movement, which will not slow down for cover fire.

The only challenge to "all mouse input" handling the gameplay is a waypoint system. We will need to determine if waypoints are needed. Traditionally games use the shift key to queue commands and that would be easy to implement.

Players will be able to text chat with each other during the game and pregame screens. That will require the keyboard.

We will only need minor UI controls for the pregame screens. pushbuttons and toggles are obviously needed. other than that we will need 'nonscrolling' text input boxes, and a listbox type control to handle the "list of online users".

Server

The game will communicate as client server. The server will run on one of the client computers, as a separate process. All game computations will be handled on the server. To handle internet lag situations, clients will also help to move friendly units along their paths, but they will not represent the true gamestate. If communication is interrupted for too long the game is paused and waits to get things going again.

Communication between the client and the server will be fairly minimal. We will not be creating a hackproof network game, but we will be smart about the data send back and forth.

The client will not have much to say to the server. When the user issues a move command it will be sent to the server as a simple 2d coordinate and a list of the selected units. The only other controls would be grenade throwing and sending chat messages (or perhaps calling a timeout/pause).

The server will have more information to send the to client. Every game frame the server must send the positions  and directions of friendly units. The friendly units must also get other statistics, like health and bullet counts. There are not that many, so this shouldn't be a problem. The server will also "acknowledge" all movement orders, and timing will be based on when the server has received the order. The server will also send the positions and directions of all visible enemy units.

The other thing that must be sent from the server to the client is the damage and interactive effects that have happened on the level (blood, grenade marks). the server will keep a list of effects like this that have not been seen by either player. when the client sees that tile, it will send and free that list of effects.

While the clients will graphically run at any arbitrary framerate, the server will run locked to a number of updates per second, likely in the lower range like 20.


References

Strike Ops will be borrowing features from other popular games. Here are a list of some of those games, and the features and styles they would bring to strike ops.

Counter-Strike
From this game we will really take the "pace" of gameplay. The quick missions in close quarter areas. The initial few seconds of running to the middle of the map to bunker down the good positions. The devastating early grenade exchanges. Hanging back and looking for the alternate route, and so on. We also get the mission objectives pretty much straight from counterstrike; rescue scientists, plant a bomb and defend it until it explodes, and such. While i don't want to say "it's like counterstrike" anywhere in the game/website, i want people playing it to reach that conclusion without much difficulty. I think we should also pull on some of the counterstrike quirks as 'humor', mainly used in the "chatter" of your troops. I believe hiding various little inside-references will actually help initial popularity of the game.

Command & Conquer
We're talking the 'original' command and conquer here. The direct overhead view with simple mouse control. Originally i mentioned this as a title we would use features from, but don't read much into that, instead substitute C&C with CannonFodder.

Cannon Fodder
This has a lot of elements we will be going for. The biggest change will be the scope. instead of sprawling environments to fight through, we need to go for confined rooms and corridors. in strike ops people should be afraid of the open court in the center of the map, because there's no cover.

Zelda
only for graphic design. i'm thinking here of Link To The Past (zelda3). This has about the right sized characters and tiles for our game. it also has the unique "all wall sides" perspective view we are going to need. i like the lowcolor simplicity of it, but a little to 'candy' for strikeops.

Army Men
here is a snap from one of the original amymen games. They use more of a "free layout" map, where we'll go more tiled. but the look of the city layout is a good 'flavor'.