Room Wars (working title)

Overview:

Room Wars is a casual real-time tactical game set inside a spaceship. The player moves from room to room, clearing out each room with the units he has rescued from previous rooms.

The game is 2D, easy to learn, and does not require reflexes. It has been designed to be made by a small team in a short period of time with low resources and funding.

This project taps the resource of strategy games that has seen very little use in the casual game market up to this point.

Index:

- Intuitiveness, learning curve, controls and the tutorial.

- Controls.

- Semi-dynamic gameplay:

- Project length, projected cost, team size, the business plan.

- Being a "Casual game".

- General game systems: an overview.

- The Player, his abilities, his controls.

- Units.

- The interface.

- The world, the levels, and the terrain.

- To sum up.

Intuitiveness, learning curve, controls and the tutorial:

The game is designed around a single campaign, with no skirmish mode and no multiplayer. In this respect it is very like an RPG or an Adventure game.

The early levels of the game will slowly introduce the various aspects of the gameplay in small steps, trying to allow the player a chance to understand something before dealing with it in combat. For example, the player should walk through all the terrain types in the early levels, before having to fight his way through them.

Since many players when given the option to not do a tutorial will skip it, the game won't give the player that choice. However, the tutorial should be designed to not delay a player who knows how to play. An example of this would be allowing the player to hit enter very fast and repeatedly which would skip past the tutorial messages, and move on to the real game.

By not giving the player the choice between a tutorial and starting a new game, but giving the player the ability to "speed-run" through the tutorial, the problem is solved.

This game has two main themes:

- Reward the player, try not to punish him.

When possible, give the player things in a format that he will enjoy, rather than something he will just use as a tool. This is a single-player game. Balance is not as much of a priority as making the player happy. Don't spoil him, but there is little reason to not give generously.

Make the death/respawn system forgiving on all but the hardest difficulty. Don't punish the player. Draw him on, drag him in, but don't give him a reason to stop playing.

- Keep it simple without removing too much content.

This is about labor, time, resources, and money. It is also about making a casual game, and keeping it simple. The less the player has to learn, the more time he is spending playing the full game.

This is a double-edged sword, don't make it so simple that the game stops being fun. However, with good art work and nice music, this is quite hard to do, especially for a RTT.

Controls:

Controls will be kept simple. The whole game can be played with only the mouse, and only one button. This means that right-clicking and left-clicking do the same thing, and therefore learning the controls is very easy.

Everything is done by clicking on it (skill tree, NPC chat, pop-up menus, movement orders). The most complex form of this is clicking and dragging, and even then, the player will still always get an immediate response when clicking.

Hotkeys are not used, as the game is not multiplayer and not designed for a hard-core market. By not having hotkeys, a casual gamer won't bump one by accident and find himself in a strange menu.

Units can be given movement orders, but not fire orders. If testing shows that this is not enough control (example: players want to tell a certain unit to fire on a certain other unit), then the right mouse click and drag can become a fire order. However, I have made a RTT without fire orders (TacticsZen on my portfolio, on my website), and it worked quite well.

If fire orders are required for some units (the long range ones), then the game can use a single special order for each unit type. Holding Space + clicking and dragging will do this order. Example orders would be a firing location for a mortar, a teleport to this location order for a teleporting unit, or a forced-move order for normal troopers.

Semi-dynamic gameplay:

This game uses dynamic units. This means that when you rescue a unit, it can travel with you to another level, making that new level easier to beat.

This could quickly get out of hand, resulting in the player marching from room-to-room with a large army, wiping out each group of enemies with ease. This is not a bad thing, since the game is single-player. As long as this does not happen too often, it will act as a reward to the player.

However, it would ruin the game from that point on, so the game will be semi-dynamic and will be separated into sections. Each new section will start the player fresh, halting any slide in either direction (the player having too few or too many units). This will have to be done tactfully, or the player will feel that the game is cheating and taking away what he had built up (it is).

Ending each section with a reward, giving the player a winning graphic and some bonus EXP based on the number of units saved and objectives finished will give the player a feeling of having completed that section, and ready him for the next section. It will make him happy that he has finished, rather than annoyed.

The bonus EXP does not have to be completely dynamic either. It can have secret rules, like maximum amounts, and giving exponentially less EXP for each unit in the player's army over a certain amount. This helps prevent the player from getting too powerful.

The reverse problem with this dynamic system is that the player could win a single battle but lose almost all of his units, and not be able to beat the next area, becoming stuck. This can be solved by cheating to help the player.

When the player dies and respawns at the last visited respawn point, or walks back to the last respawn point/safe area, the game checks how many units he has, and spawns reinforcement units to bring the amount up to the secret minimum (for that difficulty level) to make it possible to finish the section.

These reinforcement units will tend towards being the basic marine, and so the player will have a reason to try not to lose his army, because it will be filled with the cool units that he has rescued along the way (Snipers, Brutes, etc).

When a unit dies, it is lost forever, causing the player to value each unit. The only way to get some of the cool units (Snipers, Brutes, etc) is to rescue them in each level, and each section only has a set number of these cool units. This gives the player a reason to want to keep his units alive.

All of this can be adjusted based on difficulty level, including the types of reinforcement units that spawn, their amounts and so on.

Project length, projected cost, team size, the business plan:

This project is designed to be made by a small core team of two, myself (programmer, level designer, game designer, manager) and an artist (2D art). Any extra work or work requiring skills not found on the core team can be contracted out (Music, Marketing, Web design, Sound effects, etc). With this in mind, the game has been designed to be:

- 2D, lowering the amount of work to needed to create the content.

- Single-player, for the same reason as above, and just to avoid the large amount of extra time and work that is required for multiplayer games (Server hosting, keeping an online community).

The basic project time is 8 months, which is separated into:

- 1 month to fully prototype, to test fully test the idea before hiring the artist.

- 2 months to create content,

- 3 months to polish and finish the game,

- 2 months to test it, market it, and as always, more polishing.

The projected cost is $5000-$7000 thousand dollars (USD), not counting the cost to pay me, as designer, programmer, and jack-of-all-trades. This separates into:

- $2000-4000 dollars for the Artist.

- $2500 misc. contract work and outside content (Buying music).

- $500 initial advertising to create more testers and a forum full of fans.

Also, the artist would recieve a percentage of the game's profit (after costs) so that he has a reason to work over and beyond his flat fee (15%-25%).

This gives me 75%-to-85% return of the profits, and full ownership of the game. This can then be handed off in publishing deals, portals, etc.

Being a "Casual game":

I wanted to design this game as a casual game for two reasons. The first is that this is where games are going, and I like being on the new frontier. The second is that publishing, marketing and selling a casual game can be easier, and after Engine of War, I have learned the need for ideas to be designed with certain styles of game portals and markets in mind.

Room Wars is designed as a casual game, so I want the interface and controls to be easy to use and to learn. With this in mind, the units are ordered around the levels by clicking and dragging from the unit to the destination, removing the required skill of selecting units and ordering units with different mouse buttons.

The game also has no camera scrolling, with each level filling one screen. For example, think of Pac-man, but imagine that exiting the map on the left moved the player's character into a new area, rather then teleporting it back into the same level from the right.

Also, the game flows slower then a normal RTS or RTT. The units do not move as fast. This removes the player speed that can be required in a RTS, and allows a more relaxed form of gameplay. It is better for casual gamers.

The slower pace makes the system of clicking and dragging units to give them orders possible, as this is not a fast system, but more of a simple and clear system, with very little skill required to be learned by a new player.

As an example of how this would feel, think of the Close Combat series, which has up to 16 units and yet requires the player to order each unit separately and slowly. Because of the slow flow of the game, this feels good. In Warcraft III it would feel ridiculous, because of the faster pace.

The lack of scrolling means that the levels are smaller, giving the casual gamer a single screen's worth of map to deal with, rather then a normal RTS map, which would give a casual gamer too much information to concentrate on.

This is not a 100% casual game, because it uses combat, and a science fiction storyline. This will not appeal to some casual gamers. But it does not clone other casual games which will allow it to stand out in the crowd of match-3 and hidden object games. It does keep the game simple enough for non-serious gamers and this will allow more portals to pick up the game.

General game systems, an overview:

Pathfinding. The units will find their way around corners and through mazes. I have already programmed this into a prototype, and it can support 300 nodes, and dynamic refreshing of the node map. It is designed for RTSs and so can support many units pathfinding at once.

Click and drag controls. This has already been programmed into the prototype, and seems to flow fine. However, this can't really be tested until a combat encounter can be setup.

Fog of War. This will take the form of a grayed out fog over the map, which is removed in a radius of the player's units. The map starts explored, only dynamic parts such as units are hidden.

AI. This will not need to be that complex, using a system based around each unit deciding what is best for itself. No overall plan needs to be played out by the AI.

NPCs & Chat. This is a simple system, and has already been programmed into the prototype. A cartoon voice bubble floats above the head of an NPC. It will fade when it is hiding a unit from the camera, and simply says something that the player can read.

Example: "I have a mission for you!". When the player clicks on the voice bubble, it cycles to the next in the list, changing to, for example: "Can you get the shields back online?". This is very simple, but allows the use of NPCs, in a dynamic way that does not require very much NPC scripting. It also follows the game theme of being easy to use, as it only requires clicking the mouse.

Player abilities, lack of items. The player's character will have a skill tree that can be toggled by a button on the interface. Glowing text and a small EXP bar will alert the player when he needs to level up. The player character never uses items, and therefore no inventory system is required. This keeps the game simple.

The player's abilities are in the style of Diablo 2. More detail is in the section below, “The Player, his abilities, his controls”.

Mini-map. This should be a center of screen pop-up that is toggled on a key press. This means the map can be detailed, but not use up screen space. This is a good idea because a map is not a tool that is immediately needed. As long there is a clearly labeled button "Map" on the interface, the player can find it when he needs it.

The Player, his abilities, his controls:

The player has a unit in the game, that is his avatar in the game world. If this unit dies, the player loses/respawns. The camera always displays the level that this unit is in.

The player earns EXP for every unit that he rescues, and for every enemy killed. Each level gained gives a Skill Point, which can then be spent on a skill (in the simple style of Diablo 2).

The player’s abilities are in three styles:

- “Buff, aura and passive”. These tend to increase the strength of the player’s units.

- “Movement and capability”. Abilities such as cloaking or immunities that allow the player to stand in for a certain unit, taking over its role in the combat. These also allow the player to scout ahead or escape when overwhelmed.

- “Spells and attacks”. Attacks, bullets, fireballs, weapons, shiny particle effects that can be shot spinning towards enemies.

An example of the player character being used to fill a combat role is like this: The player is missing a Phasing grenadier, and needs to defeat a Plasma gunner. The player can use his ability “Immune to Plasma” and rush the Plasma gunner. He will lose some health but defeat the encounter.

The player’s health is a general resource. The player can spend it to defeat an encounter he is stuck on, but healing is not very easy, and tends to require finding a respawn point in the world.

The player controls the player character like any other unit, by clicking and dragging. Space + Click and dragging will use the player’s currently selected ability. Also, the player will be alerted when this unit’s health is very low.

I will not lay out any player abilities in this version of the game document. The abilities are too interlocking with the units, that these need to be designed later on, when the completed prototype can be used to test each ability.

The two roles of player abilities are to reward the player as the game advances, and to allow the player’s character to help in defeating enemies.

Units:

The units in this game are very important. I will lay down a basic setup for them here, but they will have to be adjusted, tweaked and tuned as the game continues. If unit design falls into a bad direction, it will need to be re-done from scratch, because the unit’s feel, flow and style needs to be the most solid part of this game.

Units should not be designed like they would be for a RTT or a RTS. They should instead be designed as though for a TBS game, with each unit having enough content designed into it, to be worth ordering around individually. This is because of the click and drag movement system, ordering several units to attack at the same time is not convenient. So no cannon fodder units.

Each unit needs to be clear in its role, and simple to use.

The following units are just enough to get the prototype up and running with combat encounters. A full and detailed list will need to be made, but this can only be done when units can be tested in game.

The basic three units (rock, paper, scissors) are:

Plasma gunner – A slow moving defensive unit, armed with a plasma gun. Plasma bullets slow down units that they hit (think of Ice spells in Diablo 2), so while this unit does not deal very much damage, he slows his target down, and kills it over 5-6 seconds. This unit’s range is around a third longer than the Trooper unit (see below).

Phase grenadier – This unit functions like a mortar. It moves slowly, is long range, inaccurate, fires explosive bullets, and can fire past walls.

When it fires, the bullet travels for a few feet and then phases out in a flash of blue light. With another flash of blue light, it teleports into where the unit is aiming, flies a few feet, and explodes. The exact location where the bullet phases in, is offset by a random vector, meaning that the weapon is inaccurate.

Trooper – Fast moving, and tough, this unit is an all around unit. Fast moving and tough enough to counter the Phase grenadier, this unit’s short range means that it is countered by the Plasma gunner.

The Trooper is countered by the Plasma gunner, but tends to counter the Phase grenadier, forming the last side of a tactical triangle. However, the player character can also be used to deal with anyone of these, at the expense over mana and the use of certain player abilities. Also, outnumbering or flanking a unit will also counter it (3 Troopers will be able to defeat a Plasma gunner at high cost).

Because I don’t want to make a full list of 12 units before I can play test ideas in game, I have not fully laid out more then the three basic units. This is a brainstorming list only:

- Warp Spiders (from Dawn of War 40K)

- Snipers (from Company of Heroes or Red Alert 2)

- Tank armor causing enemy bullets to bounce off (Company of heroes).

- Mind controlling Yuri (Red Alert 2)

- A unit with forward facing shields (Half droideka)

- Scouts (Cloaking when not too close and not attacking)

The interface:

This should be kept simple, and present only the information that the player needs to know. The map and the player's skill tree will be hidden in pop-up menus, as neither is needed right away. The idea here is to give the player as little as possible to deal with at first, and to let him stumble over each new system as he needs it. This fits with the game being a casual game.

Also, placing the skill tree and the map into pop-up menus gives more space for the artist to make them look nice, while keeping them clear.

An example of stumbling over a system being that when the player levels up, he will be shown the skill tree menu because the button will suddenly have the glowing text: "Level up!" displayed over it.

The world, the levels, and the terrain:

The game is set inside spaceships, with the player fighting room-to-room, through wrecked hallways, rooms blasted open and exposed to deep space. He is given objectives based around parts of the ship, such as the ship's engine core, the shield generator or the main bridge. These areas, or the paths to them, are filled with enemies. Some areas are completely held by the enemy troops, and some are scattered with friendly crew and enemy marines fighting, being pinned down or awaiting rescue.

Over the course of the game, the player travels through three different spaceships. These spaceships are always in the process of being boarded and some areas are under the control of enemy marines. The player's job, as an officer, is to round up the scattered friendly units, forge them into a solid fighting force, and win back the ship.

The levels are made of three types of terrain (Floor, Wall, Water) and everything else is, from a programming point of view, a unit. What I mean by that is that there may be a landmine, a shield generator, or a slowing aura, but these are not factored into the pathfinding and are units that can be placed in a level. The landmine, for example, is just a unit that does not move, does not shoot, and explodes when a unit steps on it.

- Floor terrain is the basic layer that can be moved around on.

- Walls block movement and weapon fire.

- Water can't be moved over, but can be fired across.

Water is never really water, but could be a patch of electrified floor, a hole in the floor that has only deep space beyond it, some barbed wire, or an area that is on fire. Since this is just part of the 2D level background, the artist can go wild with this, as long as it stays clear to the player how his units will interact with this area.

A note on size. Each level is a single screen, as there is no camera scrolling in the game. Because movement between levels is done by teleporting the unit (a unit stepping into a doorway, going down some stairs, getting on a teleporter, etc), and the camera just shows whichever level the player's character is currently on, there is no real limit to the size of each section and therefore the size of each ship. Few extra resources are required for each additional level in the game, and the lack of scrolling means that the connection of the levels in a section is completely up to the level designer.

Level connection will have to make sense, and remain consistent. The door in the north wall of a room should connect to a door in the south wall of the next room. Rare use of actual teleporter pads would be a good thing, as they will confuse the player's mental layout of the section.

The world should also not be thought of as boring, with lots of gray metal hallways and tiles. There can be animated 2D backgrounds, such as a level with lots of "Water" terrain that shows a really cool stars background. There can be levels where the walls are lined with frozen people in pulsing glowing green tubes, or an engine core room with spinning parts moving in the engine. Whole areas can have space backgrounds, because they take place on narrow walkways slung on the underbelly of the ship, or have large viewing windows in the walls.

To sum up:

This game is a casual game that taps into the large resource of RTS games, using several systems (click and drag orders, no camera scrolling, slow game pace, small levels) to bring the game to a level where casual players can enjoy it.

The game has a unique feel to it, even amongst RTSs, because of the dynamic flow of the world, and the non-linear level connections.

Using NPCs, and giving the player a player character to control allows a simple storyline, without locking the player into scripted quests and missions. This means the story can be ignored or read in detail by the player.

Player abilities are designed with the goal of abilities, not stats. This means that players are not confused by a page of stats, and instead are given new abilities or allowed to upgrade old ones as the game progresses (In the style of the Diablo 2 skill tree). This helps keep the learning curve gradual and rewards the player, rather then boring him. It also follows the game theme of keeping it simple and clear, by using large single-click buttons with a picture on them.

By using only a few basic systems, and choosing the simple choice when possible, the game stays accessible to casual players, and is small enough to be built by an indie team.

Having only 2D graphics, with low resource use (only a single small level loaded at any one time) allows this game to have a possible demo in Flash, allowing the advantage of having an online demo,