Shogun: The Way to Power



Design Documents

Technical Documentation


Sourceforge summery page

Mailing Lists

Hosted By:
SourceForge Logo

1. Introduction

Shogun: The Way to Power is a full 3D real time strategy (RTS) game, which supports a full scripting and plug-in interface for extending the game through new units and new campaigns. New units will be encapsulated within "unit sets", which will be balanced within themselves. This is designed to ensure proper balance within a game. It is intended to be a very involved game, however it should be intuitive enough that someone with experience in other RTS games should be able to pick it up relatively quickly. In addition, enough of the game logic will be encapsulated within the game engine that using a new plug-in set will not require learning an entirely new game.

2. Gameplay Overview

Shogun: The Way to Power is a real time strategy game, oriented towards medieval style warfare. It is more fantasy than realistic, although there is a certain element of realism. Unlike many other games in this category, the chain of command will be simulated.

Army organization

Each unit in your army can have one (or more) function, which dictate what the unit can do. It is entirely possible that one unit will be able to preform multiple functions. For example, it is possible, even likely that the commander in a certain unit set will also function as a lieutenant, meaning that in addition to being able to command other units, he will also be able to lead them into battle.

The first type of unit is the commander. The commander is generally unique, meaning that there is only one commander on the battlefield. Every army must contain a commander, who represents the player. If the commander is killed, the game is over -- you lose. Within a certain radius of the commander, orders are transmitted instantly, representing the radius over which the commander can shout. While this radius might decrease during a loud battle, or during a rainstorm in real life, for simplicity this radius remains the same at all times in the game. If you try to issue orders to people outside this radius, a messenger will automatically be dispatched. Messengers are more fully described later in this sections, in the description of AI units.

The next kind of unit is a lieutenant. Lieutenants are responsible for grouping your units into different formations (see Formations ). Only fighters can be grouped together. Other lieutenans and the commander cannot be grouped even if they are also fighters; AI units can be grouped, however they will not preform their AI duties when grouped, but see the description of AI units for more information.

Fighters form the bulk of most armies, and are responsible for doing the fighting. These can be archers or footmen. These can be grouped with lieutenants, or commanded individually. It will be possible to command a group of "ungrouped" units to do the same thing, however these units will have no relationship to each other; they will simply be moving the same direction.

The last catagory of units are AI controlled units. Although these belong to your army, you do not control them directly. There are two three kinds of AI units: messengers, peasants and healers. Messengers transmit commands to your armies. When not transmitting an order, they hang around your commander. When they are transmitting an order they move to your units. When they reach the units your command will be delivered and the messenger will return to you. Peasants will build structures; you command that a structure be built, and then any free pesants will build the structure. Healers will move through your units healing any unit which is not engaged in combat. All AI controlled units will generally avoid combat, however if they are attacked, they may be killed. If a unit is both an AI unit and another kind of unit they will only preform their AI duties if they do not have any other orders. Finally, AI lieutenants can instruct units they command to help them preform their AI duties, at which point the commanded units will preform those duties for as long as their lieutenants are preforming them at half efficiency.


A group of units which does not contain a lieutenant may only have one formation -- no formation at all. The units will simply move around without much thought to formation. A group with a lieutenant may have a formations, which will be learned. Formations will also be implemented and customizable using scripts. The following are examples of formations which will probably be used with the default unit library:

  • Square -- The units form a square, with weaker units in the center and the stronger units forming the perimeter. Units in this formation get a defensive bonus because this is a defensive formation, however they can only move very slowly. Units in a square will never retreat.
  • Column -- This is marching formation. Foot units in this formation get a speed bonus, however they must break formation before attacking. If attacked they will automatically break formation
  • Wedge -- Charging attack formation. Units in this formation suffer from a slight movement penalty, but are stronger on attack. Units in a wedge will not retreat often.
  • Line -- A straight line, two or three units deep. Useful for archers to deliver maximum volume of fire.
  • Broken -- A spread out formation. If attackers are taking more damage than they are delivering, they will retreat. Units suffer no movement penalty in this formation. This formation is intended to lead to skimerishing
  • Flank -- The group travel in a wide arc, and attempt to attack the side of the enemy formation. The only bonus which is gained by using this formation is the standard bonus for attacking from the side of a unit.


A limited amount of building may be done, but this will consist mainly of building simple defensive fortifications, such as trenches, wooden barriers, traps, and clearing areas of forest. Unlike many games of this genre building up a big base will not be part of the missions, as this much too unrealistic.

The exact buildings which may be built are up to the unit library writers, but will be divided into the following groups:

  • Trench -- A trench, which small units may be placed in, and they gain a major defensive bonus.
  • Wall -- A wall which units may hide behind.
  • Traps -- Fixed traps, which, when triggered, will damage the units which triggered it

3. Target Audience

The target audience for this product is hardcore gamers, with well equipped systems. This game will be more of a thinking game than games such as Starcraft, and not having a fast mouse finger should not be too much of a disadvantage.

Source will be available, however binaries will also be available for Linux and (hopefully) Win32, so being able to make your own binaries will not be required.

4. User interface

The user interface for Shogun: the Way to Power will be similar to the user interface of Starcraft. This should make it easy to learn, as many people are already familiar with this kind of user interface. The main differences are that Ctrl-# command will group the units with a lieutenant, even if a lieutenant isn't part of the group (in contrast with Starcraft where Ctrl-# groups just the selected units). Also, rather than commands being issued through a lower panel, they will be issued through a popup menu. The panel will be used instead to issue more strategic commands, such as building structures, in the style of Dungeon Keeper 2.

5. Division of labor between game engine and unit libraries

The game engine is responsible for coordinating between the various units and unit libraries, and doing things like hit testing between the various units, and controlling the command structure. All the "laws of physics" of the world will be implemented by the physics engine, and all the properties of the units will be determined by the unit libraries. Default AI behaviour will be provided, but this can be overriden by the unit designer. This puts a lot of control in the hands of the unit library designers, and by extension a lot of responsibility in their hands as well.

To aid with this, a default unit libraries will be included. The first will be the "standard" unit library, which will undergo extensive balance testing, and will form the basis for the built in campaigns. Further units can be built by using either a subset of C++ or a scripting language. The final decision as to which option to use will depend on how critical speed is.

To prevent new units from upsetting game balance, all new units will be grouped into unit libraries, which will be used together. Scenarios can only be used with the unit libraries they were designed for, custom maps can be used with any unit library, although when playing multi-player the current unit library will appear in the game description.