Greed Game Design

HOME
 
Contact

modified: 2017/04/5

GREED

A high speed turn-based strategy action game

By Wouter van Oortmerssen

Executive summary

GREED combines instant action hack & slash fun along the lines of Diablo with strategical depth similar to Advance Wars using a single, continuous, modeless game mechanic. It achieves speed by having the player only control one central character that drives the turns, and retains the strategy by allowing the player to deploy troops on the fly as battles demand it.

Back story

[ note: has to be rewritten by someone with half a clue about storytelling, i.e. not me ]:

Setting: future, roughly 2050

Increasing need for fast deployment in small wars around the world has led to the development of the land-equivalent of the aircraft carrier: the carrier mech. These 500m high mechs can carry an entire army and all resources around with them, and their high velocity movement over any kind of terrain allows them to deploy a decisive force anywhere in no time. Some of the largest carriers even contain smaller carriers inside them, to be able to “fan out” an army quicker.

Within few years of their introduction, all the world’s armies became dominated by these mechs, countries started to fall apart as being part of a mech army became a more important part of survival than being part of a country. There were not enough resources to sustain the army’s continuous consumption. Chaos ensued, mech commanders became the new leaders of the world, and mechs struggled for domination against others mechs, to be able to claim the resources of the lands they hold, and those held by the mechs themselves. Excessive greed became the only survival strategy.

You command a mech carrier with little to no army or resources to its name, and will do anything to be the last mech standing…

Introduction / Goals

The number of characters that a player controls at once is a decision that has a very strong influence on a game design.

Controlling a single character greatly simplifies control, and makes for intuitive, direct, and fast gameplay. It also usually reduces the complexity of actions a player can execute, and thus often reduces gameplay to twitch or repetitive skills.

A game where the player controls multiple characters opens up to a rich variety of tactical and strategical gameplay, as different properties of characters can be exploited, positional play can become very tactical, and the economy of the game world can be more of a factor. Switching between many characters can however slow gameplay down an order of magnitude compared to controlling a single one.

GREED tries to unite the two by keeping the gameplay centralized around the control of a single character, and reducing the amount of control additional characters require to almost nothing on average.

Being turn-based or not is another vital game design parameter with similar consequences: turn-based allows more tactics & strategy to be implemented but slows gameplay down a lot, real time play is quick and exciting, but lacks control.

GREED opts for turn-based game flow, but in such a way that it is almost as fast as real time in the common case, and still allows for careful planning in more complex cases.

Game Mechanics

The player controls the central character (the carrier mech) using a 4-directional control. The mech (and every other character) moves with discrete steps on a grid. Every time the mech moves he thereby triggers a turn, which causes the progress of time in the game world. This mechanic originated in the game Nethack, and allows for very fast turn based play that feels almost like an action game. Alternatively one can see this game style as a real time action game which automatically pauses and resumes the game as the player stops and starts moving.

Game world time passing allows other non-player controlled characters to move, depending on their movement speed. If the player character moves at speed 100, then a character with speed 200 can move two squares for every turn the player takes, a character with speed 50 will only move every second turn the player takes, and so forth.

Some characters always perform more than one move at once, but this also means they generally have to wait longer before they can move at all. For example, a speed 135, 4-moves-at-once character generally has to wait for roughly 3 turns by the player, after which it can do 4 moves at once. This diversifies the tactical possibilities greatly, as now the “action range” of these multiple moves at once characters becomes a factor. It diversifies the kinds of attacks you can make, and the kinds of challenges the player faces.

Generally each character (PC & NPC) has an inventory which can contain other characters/units. These are not active and are just carried around. The containing unit automatically (randomly) picks units from its inventory to be made active and placed in “deployment slots” (if there are any empty ones) from which they can be placed in the game world at any turn.

Deployed units generally act autonomously, and have the very simple deterministic behaviour of attacking the closest enemy unit within its small vision range until either he dies himself or no more enemy units are alive. If this behaviour is sufficient, then the player needs to spend no time controlling the unit, alternatively he can give individual commands where more precision is required.

You can “collect” previously deployed units much like you can pick up any resource or item in the game by stepping on to the same square with them, at which point they become part of your deployment slots again (unlike new, inactive units, which go into your inventory first). This allows you to play large parts of the game where you are not directly confronted by enemy forces (or only by very few of them) with just the main carrier mech and no other units in the field.

Deploying and collecting units does not affect their stats, if you collect a unit that has lost HP, you have to heal it manually, otherwise the next time you deploy it will start out with the exact HP it had before (however, units heal a very small amount over time).

Structure of a turn

A turn, and thereby the passing of time, is triggered by a movement action of the player character. A move does not always result in a character moving from one tile to another, if a tile is blocked by another unit, the turn can be a more specialized action such as an attack, or triggering a switch.

  • Before the move, you can set up many additional supplementary actions that don't cost any game time. Possible actions include:
    • Deploying units / dropping items (same thing). The number of units you can deploy in one turn and the distance you can place them are limited by the level of your main character (starts as 1 and grows to about 3 for very experienced characters). Being able to deploy few units at once has several effects: not being able to overwhelm an enemy by brute force easily, not losing too many units when you die, but most importantly, it allows interesting RPS gameplay as you and your enemy try to counter each other every move depending on previous unit classes deployed. Since you are limited by the units that are in your deployment slots, you have to make your best choice given the current situation, and there is always the risk of having only a certain kind of unit available and being confronted with units very effective against them (as is often the case for AI enemies that tend to have more limited inventories than you do). There is a limit to the amount of units you can have deployed in the field, which again increases with experience. If you drop an item, dropping it on top of a unit in the field (including yourself) means applying the item to the unit.
    • Use items, such as triggering spells/powerups. Items work much like units, in that they have to make it into your slots from the inventory before they are available for use.
    • Consuming items (such as health), or giving items to the units in the field/slots.
    • target enemies for ranged (further than 1 square distance) actions of your own character, if you have any.
    • give additional instructions to your allies. You allies show the action they intend to make (with their current animation and the direction they’re facing), and if you wish to change their action you can simply select the character, followed by their new goal. If the new goal is an enemy, that will become their new target for attack. Otherwise, if it is a single step, that will just override the current move, if its more than one step it becomes a position to reach, after which it will resume normal behaviour. These allow you to tune actions at little UI cost, but very effectively. For example you can make a character wait in place instead of moving forward, to ensure first attack once it gets close to the enemy. Spotting these situations is very easy: 2 units with one space between them, both ready to move, is bad for you, same but with no space between them is good for you (for one move at a time characters).
    • Inspect stats and “current enemy” markings of any units in the world or in your inventory (just select them).
  • You press a movement key. This is your turn. Game time passes
  • If the square you move to contains an enemy, you perform an attack. Otherwise, you perform a ranged attack, if you are able to do so. Attacks are subject to height (dis)advantage, offensive bonuses if your victim borders teammates, defensive bonuses if you border teammates. Orientation is of no gameplay significance.
  • If the square you move to is empty (either because it was already empty or because the attack you made resulted in a kill), you actually move to the square. If the square contains an item/unit, you pick it up.
  • The time you require for your move is the time progressed in the game world: it gets added to the “accumulated time” of every character in the game world. Those whose accumulated time is bigger than what they require for a move, can make a move, the rest stays idle. Of those that make their move, the characters allied with you move first. Making a move involves similar steps to those of the PC. You can only move again once the other characters have moved. To reduce the time this takes, the game overlaps the animations of all actions to some degree. In most simple cases this means you can instantly move again.

Character design & stats

Character design will be based around mechs, tanks, planes, boats, hovercraft, and other mechanical creatures. They will mostly consist of 2 parts, the turret, and the base. This will allow a wide range of creatures with cheap art & data assets. Your main character is a large mech.

[ note: these are the absolute bare minimum stats, more to be added later ]

base static * speed In #of game ticks required for a move
* max HP
  moves at once 1..10
  Name/class mech, tank, plane…
dynamic   XP/level increases according to strength of enemies killed, items found/used etc. Level computed logarithmically from XP
  HP between 0 and max HP
  Accumulated time 0..
  Credits 0.. (for use in shops etc)
  Powerup / start time The powerup effective for this unit
  Inventory/slots 2 lists of game objects
turret static # attack strength relative to HP
  min, max distance usually just (1,1)
  effectiveness List of % modifiers when shooting a particular base
  Name/class machinegun, rocket, digger…
dynamic   #of shots left upgrade with ammo, or transfer from another turret

The (*) stats are subject to the “level” of the base, i.e. a particular type of tank base may have speed=10, but at level 5 it may effectively be speed=20.

Attack strength is increased only minimally with XP, as increased speed already means more attacks per time unit which effectively makes the unit stronger offensively already. It is further relative to HP, i.e. a unit with HP half of max HP only has half of its normal attack strength (this allows more tactics, i.e. one can try to arrange doing maximum damage to a certain strong unit in one turn to ensure that he can’t retaliate).

Any two units can exchange their turrets.

Two characters can merge. This can only happen if their base class is the same. The new unit will get the max level of the two, the summed hp (up to max HP), and the concatenated inventory. It will get the turret with the best attack strength of the two, and the shots left of the other is proportionally converted and added (there is no max to shots left).

Turrets can be special purpose weapons, i.e. a driller turret is most effective against walls etc.

There is a matrix of effectiveness of turret classes to base classes. I.e. a machinegun turret may have a -50% against a tank class base, and a +40% against a small plane base. These provide the RPS in combat, and are meant to be quite diverse to promote strategical rather than brute force solutions to confrontations. Because of the separation of base & turret this means you can have the weird (but interesting) situation that there are units that are very effective against their own kind, and some that are very ineffective against their own kind.

A turret has no HP, but if the base it sits on dies, it dies too.

There is no limit to inventory size, as the way slots get filled from the inventory gives enough incentive to the player already to keep the contents in the inventory balanced.

Naming wise things will just be a concatenation of level, turret class and base class, i.e. you can indicate a unit by “A level 5 heavy machine gun medium tank”

Some special kinds of units:

  • Traps and obstacles. A great variety of these allows the player to seek creative solutions to tough battles, and to leverage its tactical advantage over the AI. There are simple items which do nothing but block movement (i.e. have a lot of HP), or booby traps etc.

[ note: exact stats and units not specified, a lot of this depends on gameplay tweaking after a gameplay prototype has been made ]

Powerups

Powerups are game world items that can be collected and held in an inventory, but are not units/characters. Powerups are “deployed” into slots from the inventory in the same way as units, from where they can be activated. Some powerups have an immediate effect (“once” powerups):

  • Health. These come as packets of different strengths, and add up HP towards max HP. The player can apply them to his PC and units in the PC inventory. Additionally, if health is put in the inventory of units (rather than applied to them directly), then units will use these items autonomously when required in battle.
  • Ammo. Relatively rare in the game world, to the extent that you will often have to rely on swapping/merging turrets etc. to gain ammo for particular units rather than relying on a steady stream of ammo items.
  • Double turn (can do a turn that costs no game time)
  • Deployment frenzy (can deploy any amount)
  • Area hurt (does damage to all enemy units within radius)
  • Propaganda (makes enemy units change to your team)
  • Theft (grab random items out of the enemy inventory)
  • Revive (unit that just died returns to inventory at 1 HP)
  • Overrule (cancel an enemy powerup)
  • Keep (next powerup is kept in slots after it is used)
  • Push (pushes any entity by N squares)
  • Move to inventory (from slots, used to move either very useless or very valuable units out of play)

Other powerups have a set duration, and whatever change they make to a units’ stats is only valid in this time period. Possible durations are “short” (number of exact game time units to be determined), “long” and “permanent” (or until a new powerup gets applied).

  • Enhanced defence (less damage taken)
  • Enhanced attack (more damage given)
  • Hyper speed (your turns take less game time, thus every one else moves slower)
  • Heal (heals a bit every turn)
  • Health boost (more health)
  • Courage (removes the effect of HP limiting attack strength)
  • Confidence (temporary level up)
  • SlowMo (make an enemy’s moves take more gametime)
  • Freeze (pause an enemy unit)
  • SelfConsiousness (enemy unit reduces in level temporarily)
  • Mirror (enemy unit takes damage for all damage he does)

Each of these exists in a normal variety (for the unit it is applied to) and some also in a “mega” variety (rare) which applies the affect to all friendly/enemy units in a certain radius at once. Only one powerup can apply to a unit at once, if a new one is applied this immediately cancels the old one. The amount of powerups is intended to be vast, so as to give a lot of interesting tactical options. The list above is a mere sample.

Shops allow you to buy items & sell at 50% loss. Shops generally carry few and specialised items.

The entire world is 100% persistent, if you leave an item someplace in the game world, sold it to a certain shop etc., it will always be there when you get back.

Triggers

Besides units & powerups, a third kind of entity in the game world is collectively called a “trigger”. Generally, the player has to bump into this entity to trigger its function, which usually changes something in the game world. Triggers cannot be picked up, held in inventories, or deployed. E.g.:

  • Switches. These items trigger something in the world.
  • Computer terminals. These contain messages for the player, and can help in storytelling or player tutorials.
  • Shop.

Tiles

The tiles the entities stand on mostly have limited effect on gameplay. They either block (such as a tree) or don’t block (most landscape tiles), and can have a base height difference which affects navigation and attack advantage. Additionally, some tiles have special properties almost like a powerup, such as defense/attack advantages.

Visual representation & control

The game is suitable for mobile devices, it can potentially scale up to PC/console gaming too.

Mobile platforms

The game will be rendered in top down fashion with 1-directional flat perspective, much like the majority of SNES/GBA games (see e.g. the Zelda games). It should give enough of an overview gameplay-wise using 16×16 base tiles and a device resolution of around 160×160 and upwards.

The majority of gameplay can be done using just 4 buttons (the 4-directional control), as most common actions (attack, pick up, open) are triggered by movement automatically. At least one (ideally 2) additional buttons will be needed less frequently to switch to giving commands to other units, and to browse the inventory. On a mobile platform, gameplay will be balanced such that commanding other units is hardly ever needed. Any additional buttons present on the device can be put to good use to improve game flow.

The screen will automatically scroll around the player position, an attempt to show relatively more of the game world in the direction the player is walking.

PC/Console platforms

The game can scale up to make use of increased screen size, 3d hardware, and added controls these platforms provide.

The game will be shown from an almost top-down perspective: enough top-down such that the player has a strategical overview over the grid based world, and enough at a slant such that game objects are shown in a nice perspective to show off 3D rendering.

Movement does not rotate the view, but the view can be rotated manually in 90 degree increments (using 2 extra keys/buttons). This may be useful as the direction the camera is tilted towards (in to the screen) shows slightly more of the world and is thus preferred as the direction to be looking in for general movement and combat. An alternative control is selectable in “options” which rotates the view automatically with steps left & right: this requires fewer controls & actions, but may rotate the screen unnecessary often.

Giving commands to other units and navigating the inventory can be done using additional directional controls rather than switching. On the PC these can be done using the mouse, making the gameplay even more fluent.

Visual indicators

Units on screen will have several visual indicators of their current status: they will have 2 bars above their head, one for HP, and one for accumulated time (this shows how far they are from taking their next turn, and is subdivided depending on how many moves the character does at once). If the unit has a powerup applied to him, this will be shown above the character as well. Additionally, they will have idle animations which show their next intended action: slow walking when the unit can’t move in the next turn, energetic walking when he can. The direction the unit is pointed also indicates where he intends to move. All of this will help the player make tactical decisions on where to position himself and his friends. It allows him to quickly learn the speed & behaviour of various enemies.

The animation system is relatively complex, as it tries to express as best as possible in real time what happens in game time. Generally, in a round, the main character animation starts first, followed by allied animations then enemy animations, slow enough to convey the order of moves, but fast enough that it doesn't hamper the direct feel of a player who wants to go through turns quickly. Any attacks that influence the animation of the receiving unit can cause delays.

Allied characters are always rendered in a visibly different way (algorithmically) from enemies.

There is no fog of war, which is not needed given the limited view the player has of the world anyway.

Game progression

The world is one big map, there are no level-boundaries nor any loading in between. The world will be very non linear, linearity is achieved by a strong quest tree, going to areas which you are not supposed to for your current quest will usually simply mean that you encounter monsters which are too hard for you (as in many RPGs). The quest is presented mostly through dialogue with NPCs.

Finding characters/units will be a gradual thing throughout the game: initially you will find very few of them and most battles you will carry out on your own (you will be excited whenever you find a new one). Later on you will find lots, and more frequently have massive battles where you toss large amounts of them around just to be able to survive.

Game save/loading and dieing works along the lines of Diablo: at any time you can perform a “Save & Quit” operation which saves the entire state of the game and brings you back to the menu. From there you can continue by loading up any saved state. There are no normal Load & Save operations. If your mech’s HP reduces to 0 in game, you (the pilot) escape to the nearest safe village, where the local services have done their best to recover & repair your mech (only mechs receive this service, simpler units are simply destructed). You generally lose your units in the field (if they aren’t strong enough to survive on their own), and maybe some other units from your inventory that your attackers may have stolen. Generally, death means losing 5 to 10% or so of your possessions (credits, or inventory items if you are low on credits), but otherwise everything in the world stays as it was and gameplay continues. It is hoped that these rules will make the game exciting again (by not having endless quicksaving / loading), and provide a penalty for death that is appropriate yet not too frustrating.

Character balance

Some general hints on intended character balance, as they affect gameplay:

  • You are generally much more powerful than your inventory characters, and most weaker enemies. Small groups of enemies attacking you generally don't require you to deploy other characters, as you can kill them all in one strike. Your primary reason for deploying is usually to avoid taking damage from enemies attacking from multiple directions. Taking damage should be avoided as health is sometimes hard to come by.
  • Less powerful characters have much lower “speed” than you, meaning they only make a move every few of your moves. This makes it easier to plan it such that you slay them without taking damage.
  • All characters are equal in possibilities, i.e. each can hold others in its inventory, and each has the same RPG style stats. You may encounter boss enemies which deploy other enemies which themselves deploy others.
  • Characters are expendable. It is up to the player whether he lets all his characters die easily in battle, or whether he carefully saves them and lets them level up, to create more powerful companions. But in general the game balance will be towards them being expandable: they die easily in battle, you gain many new ones constantly, you can hold a large amount of them in your inventory conveniently, and it is relatively a lot of effort to keep any particular one always healthy (very unlike Pokemon, or any of the turn-based multi-character RPGs). The damage being done is generally a lot compared to the HP of most units, meaning many die 1, 2 or 3 hits. This is an important gameplay balance, because if HP would be higher across the board, tactical/positional gameplay advantages would be reduced.
  • characters generally have relative short sight ranges, meaning you can generally choose to engage or not as you see them before you trigger them. If you let them chase you, they will give up after a certain number of unsuccessful moves and return to their base area.
  • Spread around the landscape are resource tiles. The player can put special resource gaining units on here, which will then gather resources, but do so very slowly, meaning that the player will have to come back there after a long time of play to claim the resources. This has the effect that resources in the game are almost infinite, but not in a way that is easy, the player will have to work for it. Continuously mined resources are problematic for game balance. They also make the rush for resources most important, and require fighting on multiple fronts. Resources should therefore be a strong tradeoff: require an expensive mining unit, require long time to gather, and have limited capacity.
  • In the level design, many areas accessible only from areas already visited and cleared will only open up after a while when the player is much further, enabling further collecting when the player decides to backtrack in difficult times.
  • Arenas in villages allow the player to partipate in practically infinite amount of battles to increase stats, however this has strongly diminishing returns because of the relatively very low units encountered here.

Multiplayer

Multiplayer is always problematic in turn based games, as having to wait for other players turn can be prohibitive. But it is especially problematic in GREED because turns are normally short and fluent (and can be so thanks to the AI taking turns immediately).

GREED does not have a multiplayer focus, for this reason exactly. Here however are some rough ideas on how multiplayer could be made bearable, if it needed to be added.

To restate the problem: making multiplayer purely turn based would make it unbearably slow to play, to make turn purely independent would make it into an action game where speed/twitch is more important than strategy. The ideas below use independent turns, but try to compensate in different ways:

  • Limit multiplayer to cooperative mode, possibly only 2 player cooperative. This will still give the fun of playing with others, but is less problematic. Players can have independent turns, but the time in the world progresses on either of their moves. This means that the faster of the players would take more turns, but in coop this is not “unfair”. Monster turn timings would have to be scaled down a tiny bit, as 2 players are not twice as powerful as one player due to reduced available resources in the world. The biggest difficulty in this gameplay style for the players would be to be careful with turns when 2 players are together in intricate combat with the enemy, as having time progress can ruin things for the other player who is carefully planning an attack.
  • Have some measure that equals out speed of turns and reduces the advantage of those who take more turns than others. This could be implemented for example with, for want of a better word, BonusBar ™. The bonusbar fills up slowly for every fraction of time the player is not moving, and it reduces quicker than it fills up when the player is moving. The bonusbar would give an advantage in fighting (like added XP %, or strength %), and its extent would have to be tweaked by play testing. When players are just walking around, the bonusbar has little effect. When they are fighting monsters, the slower players will have a little extra bonus. This cannot really be abused by waiting excessively long for each turn in order to have maximum bonus, as taking so long will put you at a disadvantage to players that play quickly and thus conduct way more fights in the same time. Similarly it can’t be abused trying to ambush another player with a full bonus bar, as the other player can simply run away, because following him would deplete your bonus bar quickly. For player vs player, the bonus bar, if carefully tweaked, could hopefully even out a bit the speed of the turns taken (faster player can spawn more monsters and make more attacks, but slower players would be more powerful). Balance has to be careful to make sure not one strategy (play as fast as possible or as slow as possible) becomes dominant, if anything, the balance should slightly favor the fast player. Of course, the bonusbar can be implemented in reverse, as an “exhaustion bar” that penalises those that take many quick turns in succession. Monsters have their time progress according to the speed of turns of their owner, and likewise will gain his bonus. Independent monsters would have to have a set speed.
  • Something that would slow down the realtime minimum speed of turns depending on your current distance to any other player. This would allow resource gathering at any speed, and when in combat with another player, the slow speed of turns would equalise the time needed for people to think, but not be so frustrating. It’s like when the action starts, the game goes into slow motion, except that it’s a very gradual thing. The game could scale the animations so that really the entire game just runs slower. This would work with any number of players. Monsters would work as in the previous idea, but independent monsters can be given the speed of the closest player.
  • If all actions, including movement?, could be made dependent on selecting them from the “slots”, then the game can be made realtime by limiting the speed at which the slots get new items. This way, a fast player will empty his slots quicker and thus has fewer possible actions against a player who plays slow. But of course playing slow means less actions taken, and if slots fill up, actions lost. So a balance is required. In both cases, players can play certain actions very quickly, and take more time on others, retaining an import property of turn based gaming of being able to take variable time per “turn”. The update speed can be varied, with a fast speed making the game almost realtime, and a slow one almost identical to turn based, with everything in between.

One very cool thing of turn based multiplayer is that the bandwidth consumption can be made extremely low, which makes games with many players (not quite MMO, but certainly an order of magnitude more than in FPS) possible on single servers. If cpu time for processing incoming player commands and other world issues can be made minimal, there is even no advantage for using multiple servers vs a single server for really large numbers of players, given that they are sharing the same bandwidth. This reduces server complexity tremendously (though chunkifying the world is also easier due to its turn based nature).