Editing note: Italicized text is being considered for removal

Open Game Environment

Our project goal is to create an Open Source, freely distributable game engine for designing and playing Real Time Strategy games. Our engine will have 2D and (if available/compatible) 3D viewers of the battles. Maps will be 2D with 2D pathfinding, but can be linked together to provide a 3D simulated experience. (e.g. Travelling into a cave loads another map for those units, etc)

Resources, Units and maps will all be flexible. Our hope is that one engine can perform equally for Medieval, Fantasy, Sci-Fi, Modern, Mythical and 'strange' genres. With this engine, we can make similar versions of popular titles as well as our own creative titles. All components need to be LGPL, original works, QPL, open format, etc. MP3 sound and other components with patents must be approved before being included.

We are hoping to have all components of the game engine work on all major platforms: Linux, Win32, MacOSX(?). OpenGL will be our development library of choice for 2D/3D environments. The role will initially be single player and multiplayer games, but may later be extended to persistent, MMO or linked worlds. Some tricks with the planned environment may simulate or expand to those goals.

The planned scope of our game engine should be able to be implemented in ways that could recreate the environments, units and scripts of many popular and lesser known game titles. The planned scope of our environment supercedes the scope of environments used in games like: Total Annihilation, TA:K, Warcraft 1-3, Starcraft, Age of Empires 1/2, Civilization 1-3, Dune, Earth 2040, Empire Earth, Ground Control, HOMM, MechCommander 1/2, Metal Fatigue, Populous (all), Pharoah, Dungeon Siege (including creature possesion/exp levels), C&C (older), and many more. There are a few games that we cannot encompass the environment of without modification: XCom (indoor multilevel battles), Black and White (no creature learning), Conquest: Frontier Wars (Supply chain), and more that escape me at the moment.

Now, we obviously would not be recreating these games with the engine, we are supplying a tool to implement concepts in an easy to configure/script manner. Our efforts will not replace the ingenuity of paid developers across the world. Instead of allowing the same mistakes that haunted old games (unit AI in Starcraft) to haunt new games (Warcraft 3) perhaps this will raise the bar for performance (pathfinding). At the same time, all game developers will not have to implement a complete environment from scratch. Rapid developoment by existing mod communities and small groups of programmers will allow them to create new or similar games at a rapid pace. The change in market dynamics will allow the best and brightest (most paid?) to focus upon innovation and new ideas while avoiding old mistakes (pathfinding). All trademarks, graphics, logos and more are property of their respective holders be they developers, producers or publishers. (Does anyone know if artists own their work if it becomes incorporated in a game-style contract?)

So what do we mean by game environment if we aren't making games? There are some obvious technologies included in making applications: making output appear (display adapters, sound support, graphics engine), allowing input (keyboard, mouse, joystick, maybe voice), and accepting data (reading file formats, networking). Some other components we really only notice in games when they are lacking: pathfinding, artifical intelligence, command queing, interaction between objects, etc. These are the areas that we want to focus on particularly, mostly because other people are already working on the others. We will also need to include a framework or integration with the main components of applications in order to provide a test (and more interesting) playing environment.

One of the tools that we are going to bring forward is scripting within the environment. Rarely is this seen outside of AI scripting, but we want to allow all objects to interact. Allowing object to exist, giving them a means of interaction beyond basic engine functions and providing a means to do so with an engine will hopefully compel people to use them in new and interesting ways we have not thought of. This will eventually lead to both stranger universes and more realistic ones. An example of this is heat. In the movie "Evolution" heat made aliens grow, instead of damaging them. If we simply put a graphic that looked like fire and then gave it a damage rating describing this kind of interaction would not be possible. Instead we want to say "heat" with a potency of some amount, 15 for example. It is then up to the environnment to describe any effect heat has with an object. The engine then calculates and applies this effect to the object. Sample ideas include 15 damage, 15 health applied to maximum health, or 15 energy available for use in production. A well designed environment should be able to have other arbitrary effects applied, like making the object duplicate into two equal objects identical to the original.


The engine is unmodified QPL, and will always be available through open source. We cannot guarantee under which License the code will be actively developed because the enforcement of a license may be or become illegal in a jurisdiction. If a commercial developer would like to use the game engine in a retail product, we ask that our copyright to code (effort) be honored, and they license the engine in a mutually acceptable fashion.

The GPL was not selected for this project because commercial companies can simply rebrand, modify and distribute product under their name. Large companies can use more channels of distribution to reach a larger market and audience while taking credit for other peoples work. This is how Microsoft has been able to sustain product releases: theft. Many core components of Microsoft OS's since win95 (that I have confirmed) have been and probably always will be based on open source projects. Most of this code is legally reused from the BSD License. GPL code cannot be used in commerical software legally without distributing source. This is unsatisfactory to our project, as a commercial team can simply hide our efforts using the mod tools and options we will provide. One potential practice that may be legal (with the QPL) under the DMCA is a copyright holder (us) reverse-engineering and decompile any and all products released to market matching criteria in order to verify our copyright is protected. If companies are found using sections of (our) copyrighted code without proper (alternative) licensing in commercial products, they can be prosecuted under the Digital Millenium Copyright Act as federal criminals.

We wish the world were a simpler place, where citizens could follow the law simply, effectively and without undue fees, licenses, contracts, etc. We do not live in that place, sorry for being anal about something we just want to have fun with (while not supplying our code to DMCA supporting companies like Blizzard and monopolies like Microsoft).

Alternative licensing is important in cases where open source components can not be found and newer technologies are selected with different licensing requirements. (smoke engine, physics engine, particle engine, advanced 3D engine, etc). Compatibility with a prevalent technology (like proprietary team voice systems) may only be possible through licensing. Major contributors to the project will be able to influence licensing and decisions. Public feedback will always be important.

Environment Features

*Denotes a potential feature, but is not currently planned for implementation. These are listed so other people may contribute these features, and so developers don't do something that will later prohibit these features. We are focusing development on the core features, and then making extenions. Some of these extensions would require massive changes to engine, and may be implemented through modules or plugins. (Tides, terraforming, locational damage)

Game Loader

Distributes Units/Maps to all players (p2p)

Performs Checksums on Units/Maps/executables to verify integrity

Provide environmental settings (controlled by host)

Sets mission complete, loadable from scenario (campaign), map, but can be user defined in multiplayer
Provide initial resources
Set maximum resources
Set maximum unit count (*intelligent algorithm guesses appropriate number as suggestion)
set line of sight
assign arbitrary effects: 2x damage, 0.5x fire damage, 10x commander health, 5x experience, etc (campaign mode, challenge, tournament, speciality play)
permit only or deny specific certain units w/warning issued to players on how many of players units denied
assigned, random or selectable starting locations (important for tournament/team play)
Select a unit-pack, plugin or modification
assign starting units

Configurable predetermined settings for each player (color, race, etc)

Game Engine

Movement, Shoot, Build, Stuff

Unit Stacking controlled by AI, unit and environment
20 planes occupying same airspace, etc is selectable by AI, but can be enforced by unit properties or environment.

Real Time Strategy Engine

In game speed controls

Radar, Sonar, range (hotkey), alternate detectors (underground, invis, chance to detect hidden, etc)

Range can affect targetting (implemented by environment, map, or per unit)

Engine examines environment to find mission complete criteria

*Alliances can be formed/broken/negotiated (negotiated with objects, units, resources, etc) in game

*Alliance can force/request/grant tithe of resources (event or per tick for x tick)
"As long as you give me 40 metal/tick I won't attack."
"You focus on defense, I'll give us resources."

*Alliance can share LoS, map data, detection ability (but not AI detection script, it would assume control)

*Turn based engine

*Observation Mode

*General on Field (player) able to possess units
GoF able to customize unit name, etc

Network Engine

Host multiplayer session on LAN

Dedicated server supports more clients than p2p LAN host session

Dedicated server can force options (resources, map, etc) for tournaments

*Dedicated server remembers client (tracking, ranking, etc)

*Lag tolerance through predictive movement and AI (pathfinding precalculated, etc)

*Dedicated server game recorder (Replay plus cheat detection!)

*Dedicated server perform auto patching (from p2p net?)

*Autopatch, checksum on client and checksum test between client/server to validate game files (prevent cheating more)


XML Defined Elements, Layout, Window positions, etc

Hotkeys defined in XML

Themes and customizations supported by module

Dynamically created, user or GUI defined build menus

Select Groups by mouse or hotkey

Select AI and formation during game

(unable to write AI during game during initial release)

Sound Properties

Sound can be triggered by GUI (selecting units), scripts, AI, etc

Music owned by original artist

In our opinion, it makes sense for voice artists to contribute their work to the unit author for unit voices, but to be compensated for or donate for script reading, plot dialogue, etc

Sound format?

*Voice to teammates during multiplayer(Licensing?)

Map Properties

Tilesets stored in libraries, referenced in maps (using XML?)

Linkable (transfer between maps)

Embedded Objects
*Some objects can only be picked up by a certain class of units (quest, cargo carrying, hero, etc)

Embedded Units

Triggers/Scripting/Spawning support (resource/object/unit regen)

Objects are transportable, consumable, interactive (explosions, win condition, etc)
all objects can have properties
all objects can be the target of AI or script (called by name)

dynamic height can be altered during play (drawbridges, volcanos, etc)

terrain changes features to class of units
tiny units harder to target in forest
vehicles slower in mud
targeting confused by weather
elves invis at night
marines gain attack advantage in jungle

*Weather, Day/Night cycles

*alterable terrain (appearance, properties)

*Optional momentum, accelleration modifier (gravity illusion)

*Terrain affects move rate (up and down)

*Terrain type dynamically altered (roadbuilding! terraforming!)

*Gravity well accelleration, orbit patterns/velocities

*moving objects (planet, moons)

*temporary tracks left by units (invis unit detection?)

*arbitrary water level (seasons, tides, etc)

Tilesets are property of creating artist

Map Editor

Choose terrain types

Create random maps

XML based map layout (?)

designate environment variables (wind, delay for map transfers, etc)

Add objects and triggers

Add AI to objects

Game Viewer (2D)

Zoom in/out


Line of Sight


Fog of war

Game Viewer (3D)

Option of choosing 2d (performance) or 3d (game experience) at game load time

Different Views available

*Possession of units for first person (General on Field GoF)


255 resource types

production of resources by units

consumption of map objects for resources (trees)

attaching units to resource locations (mines)

resources accessed by event or by tick


Different states
running, walking, crouched, crawling, hover, transforms into submersible, carrying resources, transporting, being transported, etc
Properties of unit in each state

State would control move rate, ease to hit them, their targetting/range and how much dmg they take when they get hit

Geometric (maximum viewable) size

Arbitrary size (for fitting into transports, doors, etc)

Accelleration, Turn rate, Mass, Braking, Turn rate at speed(?), etc

Troop carriers/transports
with possibility of loaded troops active and firing while aboard (bunker, active transport)
unload with delay, unload all at once (AI will understand ferry concept from A to B)

Merge units during game
Compatibility matrix for merging is necessary.
conditions for merge (research, distribution center, slotted unit, empty slot on unit).
This has 'fusion' cababilities as well as creating arms, turrets, extra weapons, upgrades, etc permanently attached to other units

category, WeaponID, appearance, sound (Should weapons be separate objects from unit?)

category, diameter, length, width, tracking, color, etc defined by unit for weapon ID
no need for 30 different kinds of Laser weapon ID's. Create one ID for burst, one for rabid burst, one for continous beam and then define appearance for each unit

category, ArmorID, sound of weapon vs armor scripts (shield block arrows = metal ting)
One concept is to have armor as part of the unit, integrated into the wire frame
Another concept is to have optional armor that can be added as an upgrade and added to wire frame, like giving a swordsman a shield. this is much easier to implement as a separate unit.
Changing textures to change 'armor' should be fairly easy to implement (chain vs plate, color change)
Having external armor (force field) should be available as an upgrade

Ammo vs Armor configurable (healing, extra damage, immunity, etc. unlike Arrows vs Tanks in civ3)

hidden, invis, camo, burrowed, out of phase units
detection of all types supported in engine

Upgrades modify unit stats without graphic change
Max number of upgrades depends on multiple conditions: GUI's ability to display, 'upgrade slots', etc
upgrades through experience, technologies, environment (host defined), structures, triggers, plot, carrying objects (inventory!), unit combinations, aging, etc
to be applied per unit, all units of same type, using same weapon/armor, etc
units can steal, salvage or learn upgrades

*special vulnerability spots like sides/rear
The engine will need to allow for this several ways. 'location' of damage is not a field we are going to implement right away in order to work on more important aspects. If someone wants to work on this aspect of engine, then most of the work necessary will be completed. Conditional tests on units are easier to create after that.

*potential for flagging unit/structure as unique
This allows for heroes, unique weapons, special buildings as in Civ, etc
Listed as pending because engine would need to allow for illegal conditions and multiple production methods. Uniques may also have special unit properties not currently planned (ressurrection conditions, capture conditions, etc)

*Unit contact triggers
infantry could destroy tank if they reach it. I don't know if this should be a property of tank, special attack of infantry, combination of two or an ability that could be scripted by AI. I think the environment should support 'unit contact' in the future, and check each unit for interaction that can then trigger scripts. Other interactions like burrowing under siege units need to be examined a general. There are easier methods around this (like 0 range explosives for infantry that do extra damage) so I don't see many advantages in designing this system now.
Relational size comparisons to trigger scripts (big big tank squash tree)

*certain damage has potential to remove upgrade or attached unit
This could include arms if they were not part of the basic unit. In other words, components removed, but unit lives (Mechwarrior, etc). Make certain components free on construction (arms) and allow others to be added by upgrades (experience, object from map, picked up from wreckage, etc). Salvage would have more flexibiilty/uses, althoough this could also be done through separate weapons. Usually 'segmented unit' would be better implemented by having base unit, with combined unit in slot. Specifically attacking unit in slot would break off, destroy, etc depending on scripts and interactions

Unit Editor

Unit inspector/tweaker

Unit Wizard

Unit import tools (from 3d Studio Max, etc)

All art created for units is property of the artist. Unit creator, voice actor and artist should collaberate on licensing and agreements for distribution. Using wizard may not imply an 'original creation' unless additional work is done because textures, frames, voice would all be provided. GPL or QPL recommended.

*Suggests cost for unit for setting based on formula

AI (XML Defined)

Possibility of global AI overwritten through more specific settings (Group, then location in formation, unit based, the type of job performed for multiple units of the same time e.g. repairing vs building). Effective and selectable; AI's are going to be one of the main methods of removing micromanagement requirements from RTS games.

AI will be classes based

Types of AI:
Command based (non player characters)
condition (or environment) based
Group based
Formation based
Unit based
Job based

Selecting a group will allow a Group AI to be assigned, and then possible to choose a Formation

Selecting a formation will allow a Formation AI to be assigned (Multiple groups using same formation may have different Formation AIs]

Each unit will have a default AI assigned to it before the game begins.
Selecting a new AI will be possible for each unit once it has been created.
construction unit: build on discovered mines, construction unit: build energy facilities, etc

Selecting units with the same job (hotkeyed) will allow the player to select a new AI for all units with that job. This is useful when the same unit type does both building and repairing, but you don't want your repairing units on patrol to assist in building jobs.

condition or environment AI assignments important for changing state, underwater, land or flying, no atmosphere, based on gravity, detection of hidden/camo/invis/burrowed/outofphase units, etc

upgrades can alter AI routines, but versatile AI would be to control potential AI by conditions (if new weapon added, use it!)

AI Editor

Initially a stand-alone editor will be created, later on a user will be able to write AI's in game and store them for future use (build base defenses in this layout again). The editor should use drop down menu's during the creation process. Suggestions for GUI to manage in game AI changes welcome. This is only a feature if it is well implemented.

AI's will be condition aware [at 25% health retreat]
AI can trigger scripts [at 10% health do suicide charge & detonate when enemy in range]
can issue commands [at 25% health entire group retreat] [heal units at 50% health in group],
can be used to dictate movement in formation [row1 soldiers kneel, row2 soldiers kneel, row3 soldiers move to front, row1 soliders kneel, row3 soldiers stand, row3 soldiers move to front, row1 soldiers kneel] (sound like the infamous tank frogging?)
aware of formation job/location [artillery stop and fire when enemy in range, tanks skirmish to draw & evade fire, support group 1 heal tanks, support group 2 increase attack effectiveness of artillery, aircraft circle around artillery acting as spotters and provide cover fire but actively engage other aircraft]


Move Strict (parade formation), Move Loose (avoid rocks) or general (full pathfinding)

Can Change movement rates (stick together)

Formation can dictate weakened units retreat to rear of formation (to support units hopefully)

Formation can include movement patterns(stand still, opportunistic movement, search movement, skirmish to avoid fire)

Formation can include multiple groups (PINCER ATTACK!)


Factory (general production or low cost production of one unit)

Spawn point (larva have arrived)

Mass production (100 eggs hatch)

Sexual (combination of units to produce third unit sharing properties, one parent or random combo)

Asexual (two identical units spawned from one parent)

Worker unit creating buildings, units, factories, etc

Cost of production can either be Event based (*Craft), at rate (by tick like TA) or on demand

Can be assisted or standalone production (per unit producing)

Production pausing will be supported by the engine (implemented by unit)

abandoned production can either be paused, cancelled or fade (optionally replenish resources)


Please post in our forums or mailing lists for feedback at this time.