A high speed turn-based strategy action game
By Wouter van Oortmerssen
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.
[ 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…
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.
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).
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.
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|
|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|
|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:
[ note: exact stats and units not specified, a lot of this depends on gameplay tweaking after a gameplay prototype has been made ]
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):
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).
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.
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.:
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.
The game is suitable for mobile devices, it can potentially scale up to PC/console gaming too.
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.
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.
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.
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.
Some general hints on intended character balance, as they affect gameplay:
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:
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).