Igor Ivanić

Version 1.1
February 4th 2010


Name of the game engine is “Perpetual warfare“, symbolizing importance and continuing existence of wars in human history. Name of the example game is “Perpetual warfare: Unity of effort” as “Unity of effort” is one of United States Military Principle of war (refers to “US Army Field Manual FM 3-0”)


Perpetual warfare (PW) game engine based games are multiplatform games (PSX, XBOX, PC, and Mobile platforms).


PW games target audience depends on the implementation of the specific game (level design, logic design and difficulty). But it can be anywhere from casual gamers to hardcore RTS/RTT/TBS players.


PW is innovative tactics game/engine concept with light platform requirements, flexible and with rewarding game experience. You can call it hybrid between Real Time Tactics (RTT) and Turn Based Strategy (TBS) games


Product suggested in this document following properties:
  • It is real time game, not turn based – of course, in the game there may be option to speed up or slow down time.
  • It is tile or region based game.
  • It has no unit building, resources gathering, no technology trees – this is Real Time Tactics (RTT) element. Player needs only to manage units provided by the computer at the start of the level and beat the opponent, although, strategic elements can be easily added, as described in last chapter: Complex example of a game: “Perpetual warfare - Unity of effort”. Fog of war may also be considered.
  • Each game level runs on battlefield (gameboard). Battlefield can be bigger than screen, scrollable and zoomable. Battlefield space is divided in regions (tiles). Regions can by any shape, including hexagons, squares or more complex polygons. In some cases regions can represent whole continents or states (see Picture 1)
and in some small hexagonal tiles (see Picture 2),
or anywhere in between (see Picture 3),
however the level designer wants. Player can move units from one region to other in real time, and attack other regions via long range weapons or invasion (moving to region occupied by enemy).
  • Each region has set of properties that are defined by level designer. For example: How many units can region contain. How fast can units move from or to that region. If region represents hostile environment (very dry, or toxic) then it can have property how much damage it makes to units over time. Vice versa, if it is fertile region, it can raise unit energy over time. For instance, height property of the region can be used to calculate range of the weapons. This is at the core of the concept: Every level can have regions of completely different shape and set of properties, giving great diversity of levels to players, and support creativity of level designers.
  • Units also have range of properties specific to level or region set in which they are used. How strong they are, how fast, how much damage they make, how much damage they can take, how much they are susceptible to cold and etc. Units are made as animated sprites, and can have many animations linked with state of unit (value of property, for example low energy units can bleed.). Since they are specially created for specific region set or level, great balance of units is not required. It is important only that they make sense and work well in that specific scenario/level.
  • Game should support 1-8 players, depending on level design, Network play would be big bonus.
  • Scripting is technology that logically connects regions, units and levels. Scripting is based on events. Game engine raises events for every important thing that happens in the game. For example: “Player Moves”, “Player start battle”, “Time passes” and so on. Level designer write code for events and in that way creates game. Most of the events are basic math; add, subtract, multiply and divide of properties of regions and units. There can be simple interface in Level editor for that basic math so that level designer does not have to write code. But in some cases, level designer can choose to write few lines of code to create desired effect. Scripting language should be JavaScript or something similar. Scripting should be able to access complete object model of application. For example this can be used to enforce that units can attack enemies only with weapons that have ammunition (of course, only for units that have property “ammunition”).
  • Artificial Intelligence (AI) is needed for player vs. computer mode. AI in the game does not have to be very complex, but should be assisted with hints from level designer. These hints are saved with level. For example: how to weight properties and regions to play better. Hints can be even programming code written in scripting language. Depending on difficulty level there can be separate hints for AI for every difficulty level (easy, medium, hard, and expert).
  • For gameplay it is important to mention visual display of regions properties - Layers. Since every level can be different, user have all properties listed somewhere on the screen. She or He can turn on one at a time. Layers are in fact coloring of the regions dependable of values of the properties. For example, height property of region is displayed in colors from white to black dependable of value of height property. This is intuitive way for player to explore level rules and logic.
  • Another important gameplay element is unit grouping and dividing. It should be done in intuitive way, similar to create table option in latest generation of text-processors (Picture 4)
  • Level editor tool would be essential for this concept. Level Editor should have following features:
    • Support for editing regions shapes (hexagon, polygons) and draw them over im-ported graphics
    • Import of bitmap graphics and animations and trace tool to convert them to vector format
    • Unit and regions designer
    • Scripting IDE and debugger
    • AI helper designer component for designing hints for better play of AI


This concept has potential to have lightweight demand on computer resources. It is suggested use of 2d vector graphics. Multi platform technology is also recommended (Java, Flash, and Silverlight 2.0+, C # - Microsoft.Net 2.0 /Mono 2.0)


  • Innovative concept – no real time tile based tactics game on the market
  • Great diversity and rewarding gaming experience – every level can be different, with different logic and required tactics for winning. This will allow game designers to come up with fresh, creative games
  • Avoided long, expensive testing – no need for fine balanced units and detailed testing of that balance. Every level can be tested independent one of another.
  • Multiplatform potential – can be done in “slower-running”, “faster-to-write” multi platform technology because it should not be too demanding on hardware resources – single release for Windows, Linux and Mac. It can be done for mobile platforms.


Main menu allows player to explore interactive timeline from 1945 to 1991. Big global political map is displayed.
The map changes (countries appears and disappears) as user drag slider on timeline. On the timeline are marked events like “Cuban crisis” etc.
Great examples of interactive timelines are:

Non interactive Cold War timelines:

Political map of the world is the main battlefield. As user changes timeline she or he can explore countries and their properties by hovering mouse over or turning property layers on/off: Player also sees Units placed on regions divided in unit groups: Planes, Ships, Soldiers, …
It is important to notice those types of planes, tanks, ships and their quantities changes with timeline. For example in year 1970 in SSSR appears few hundred units of MiG-25R. Year after quantities increases, later in 1972, a new variant of MiG-25 (MiG-25P) comes to service. This is in fact comprehensive political and military historical database.
Player can start game by choosing side, opponents (AI, Network, number of players) in any year.
After start player can start attack, if opponent does not start battle first. At this level player plays battle until the end, or sometimes, with help of scripting technology, game attack is stopped, and player is switched to lower level of map (for instance, Europe) and there the same thing can happen to take him to even more detailed situation. It can go even to battle for small village. Depending on the result of the battle, scripting system changes properties of parent battles.
Strategic component can also be added to the game. One way is following:
  • Some regions property “Manufacturing unit potential” is greater than zero.
  • Scripting event “Time passes” calculates sum of all regions “Manufacturing unit potential” values and based on that number and passed time automatically increases unit numbers. These region acts as unit factories.
  • Enemy can decrease or even erase (set to zero) “Manufacturing unit potential” values of regions by attacking it.
  • Effectively, player now has factories to defend.

Last edited Feb 4, 2010 at 10:50 AM by x_iga_x, version 8


No comments yet.