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
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. There
have been other changes as well, they are marked with ** in the text.
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 size 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. The map will
be split into 2 levels of elevation. Like "Doom" these areas will not be
able to overlap. Units can only climb up to the top level at stairs, but
can jump down from any edge. Units can only shoot other units on the
same level as they are (considering walls and lineofsite). Units can
only shoot between levels if one of the units is along the edge of the
upper level.
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.
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'.