Design Document!2012

By Kenneth Gardner,2014-06-24 17:33
16 views 0
Design Document!2012 Design Document!2012

Project Y Design Document

    Version 0.1 (Last modified 6/24/2012)


    In 2176, the human race exhausted all the resources Terra had to offer. Their constant thirst for power and land sucked the planet dry of all its natural resources. However, this didn’t stop the war. With technology converted to almost entirely solar energy, fierce battles raged on for the last few caches of resources left on the dying planet. As the dominant faction sucked the last bit of life from the planet, there was a loud crack, and the tectonic planets began to shift. Earthquakes raged over the planet’s surface, as the core slowly came to a painstaking halt. The planet was dead.

    Using all the technology left, the warring factions banded together to launch mankind out into the stars, in hopes of finding a suitable replacement for earth. Of over 100 capsules launched, only one landed on a suitable planet. This specific solar system was host to a series of habitable planets, much to the delight of the pilgrims. The first planet was settled, and with the settling process, four cities were erected equidistantly from the planet, and it was divided into 24 territories. Each city began rapidly advancing their technology, in hopes of mastering the planet before the others. Cities became capitals, capitals became states, states became nations, and finally, as their borders met, nations became factions. Each one not wanting to give up the resources of the planet, they quickly resorted to war.

    Due to extreme limitations on the population, human lives were too precious to be wasted. The faction leaders each agreed to a series of rules to follow in each territory. These rules were to be followed at all cost, as failure to comply could result in the annihilation of the human race.

Game play

     Project Y is a mixture between an MMO RPG and an RTS. As a valiant

    Commander of your faction, you have earned the credits to own your own military drones. These drones, called “Zanimals” (Zans for short), are unmanned robots designed for combat. The hero commands his Zans in combat telepathically, producing a finite number of controllable units. Each battlefield allows a set number of commanders per team. (If the battlefield supports 10 players per side, and each player can control 6 Zans, that’s 60

    Zans per faction, 120 total).


     The goal of each battlefield varies. The gameplay methods vary and are

    outlined below. The basic mode of play consists of three control points (CPs). The

    CPs are evenly spaced on the map. A faction must have at least one Zan on a CP

    for a set amount of time (Generally 60 seconds) to gain control of it. Once a

    faction has control of all three CPs, they win the battle. If time runs out, the

    faction with the most CPs at the end will win.


     Domination is the basic gameplay mode. Teams must fight for

    control of a set number of CPs. The first faction to control all CPs, or the

    faction with the most after 20 minutes wins the match.


     In the middle of the map, a bomb is placed. Zans can pick up the

    bomb, which grants them greater defense and regenerative abilities. To

    win, a faction must carry the bomb to the enemy’s control node three

    times, destroying it. If the game ends early, the team with the most

    damage to the enemy team’s node wins. Normal attacks damage the node,

    but at a significantly lower rate. Bombing is the quickest way to achieve



    Each team gets points for killing enemy units. CPs are placed on the map;

    control over them acts as a multiplier. (One kill = 1 point, control of 2 CPs

    = 2*1(+1)=4). The first team to hit the map’s score limit wins the match.

    Player development

     As players fight in battle, they gain experience. This experience translates

    to levels, and each level adds a talent point to the player’s pool. These non-

    refundable points can be placed in one of four catgories to strengthen the player’s

    abilities. A player’s level acts as a base for all stats (Level 20 with 5 points in

    tactics = 25 tactics)


     As a player’s tactics increases, he gets greater precedence over

    being the battle’s commander, as well as slowly increasing the maximum

    number of Zans he can control in combat.

    Mechanical Aptitude

     An increased Mechanical Aptitude allows players to place more

    equipment on their Zans. High mech apt units tend to be stronger and

    more durable.


     A player’s Intelligence determines how advanced of technology

    they can place on their Zans. High Intel units tend to deal more damage.


     Prestige allows players access to higher level Zans, and more

    advanced upgrades not otherwise available.

Zan development

     As Zans fight in battle, their organically enhanced AIs learn from their experiences, and become stronger. Zan level acts as an additive to all stats (A level 20 player with a level 10 Zan with 5 points in Intelligence has an effective intel of 35 for this Zan)

     As Zans reach higher levels, they can be upgraded to more powerful units. Upgrades are expensive, and often totally change the abilities of the unit. However, leveling a Zan is often the only way to access more advanced Zans.

     Zans can be upgraded after a certain mixture of prestige and unit level are met. Upgrades along the same path will increase the model number (M3-901 would upgrade to M3-902, etc). Some units can also be upgraded to similar models, for instance the Wolf may be upgradeable to a Stomper at a certain level. Planets

     Each planet is its own server. All players start on the same planet, and can work their way up to more advanced ones. Each planet has a level cap, to level the playing field.


     Each Zan has its own specialty. A diverse selection of Zan squads can make or

    break a battle. For instance, if players are all fighting with anti-ground units, and

    someone brings in an air to ground attack unit, there would be little resistance. Ground

    On the ground, weight restrictions be damned. Ground forces tend to deal more damage at the cost of speed. While ground units often overpower air units, they are restricted by the terrain and will fall behind their aerial counterparts.

    M3-901 Zipper

     The Zipper specializes in high speed recon. Its lightly armored

    body is home to a small weapon, allowing it to assist in battles. The light

    armor and weak damage of this unit makes it ineffective for small battles,

    but it excels at taking CPs early in the battle.

    M12-A31 Stomper

     The Stomper, much like the name implies, is a heavy unit. Literally.

    The Stomper armor is rivaled by few, and its weapons pack a powerful

    punch. The main problem with the M12 Beast is its slow crawl across the

    terrain. The Beast is ideal for taking CPs under enemy protection, able to

    take several hits before failing.

MA-C1 Wolf

     The Wolf employs a high speed Vulcan cannon to defend itself. While the Wolf is unable to target other ground forces, it can tear Air units to shreds with its powerful weapon.

    MX-CL4W1 Claw

     The Claw originally had a different name, but users fondly gave it the name “Claw” after its model number. This swift unit has light armor, but packs a powerful melee weapon that can shred enemy forces in close range.

    MX-A1 Badger

     The badger is an artillery shelling platform with an attitude. Its slow movements are halted by a conversion to a mortar, able to launch shells at a distance down on un-suspecting forces. The badger is defenseless in close range combat.

    L-X1 Tiger

     The Tiger is known for its versatile combat abilities. It can be equipped with a large variety of equipment to meet the owner’s needs. Some armor allows for melee combat, other armor focuses on medium armor, light damage high speed combat, and some armor systems allow for heavy damage. (Too powerful? Adjust…)


     Air units are nimble and often pack powerful weapons. Able to traverse

    any part of the map, Air units often find themselves in a tactical advantage over

    ground units. However, armor is severely sacrificed to allow these units to stay up

    in the skies, and any properly armed unit can easily fell them. A-11 Hawk

     The hawk is a nimble and versatile unit able to quickly explore the map. Its light armor makes it impractical for heavy combat, but it excels at scouting and picking off weaker ground forces unable to shoot back. AC-F1 Falcon

     The falcon is a complete re-write of the hawk. Sporting powerful air to air or air to ground missiles, it is able to quickly bomb targets and move away before drawing too much enemy fire. Its faster, but still suffers from weak armor.

    A-S1 Vulture

     The vulture has one purpose: Death from above. Its relatively strong armor and powerful anti-ground weapons make it ideal for bombing medium armor ground encampments where offensive power is weak.

    AX-A1 Pelican

     The Pelican is an aerial artillery unit. The pride of military shelling,

    this unit is able to hover in mid air, launching shells at unsuspecting

    ground forces. Equipped with a weak stealth system, it is invisible to

    ground forces and can only be spotted by radar or a nearby air unit. The

    Pelican is defenseless in close range combat.


     Special units come in all shapes and sizes, but carry out specific goals. Most special units do not have room for weapons, but achieve other important tasks.

    XR-81 Bat

     The Pinger is every battlefield’s best friend. Its powerful radar is

    able to detect units across the entire map. The power required to achieve

    this is extreme however, and it can only be done in individual sweeps.

    Pingers can also be equipped with jammers that reduce the field of vision

    and radar abilities of the enemy faction.

    XA-BY1 Stingray

     The stingray is long, slow, and every ground unit’s worst enemy.

    Able to dig mines underneath the ground, the Stingray excels at laying

    traps and defending areas. The stingray can also burrow underground to

    hide itself from enemy forces; however this trick is revealed if a ground

    unit comes too close. Its tail can also be used to sweep the ground for

    enemy mines, and equipment can be installed to remove them. The

    stingray hovers, and thus cannot take a CP. However, it also is not affected

    by mines.

    XA-Z1 Shrimp

     The Shrimp is small, fast, and able to repair allied units in a snap.

    The Shrimp is handy, but easily destroyed due to its lack of any real

    weapons or armor. It can be installed with equipment to stun enemies for a

    short time.

    Game play modes

     In normal situations, the player can walk around a map and interact with it. Cities and some maps have areas to repair your Zans, upgrade them, hone your skills and participate in faction politics. In RPG mode, you will see yourself and other players as humans.

     During a battle, all avatars are hidden and the map turns into a battlefield. All players evacuate and prepare their units for combat. Players in a territory while its being attacked will only have 60 seconds to set up and deploy their units before they are transported back to the faction capital

    RPG mode

     After a battle, enemy Zans may leave behind parts or pieces which

    can be collected by players to for faction rewards. In this mode, you will

    see players in the same overhead view Zans were displayed, but now you

    see players instead. Players in this mode have the ability to move around

    (Note: Player location when a battle starts dictates where their units start,

    giving the defenders strategic advantage). Players can also use facilities.

    Battle mode

     The victory conditions are pre-set based on the map. (Revise?)

    During a battle, players not already in will start at one of the portals

    located in the map. Defenders will have off of the map revealed, but not be

    able to see anything outside their FOV (Darkened fog), where attackers

    only see what their teams units have revealed (Black fog). When all of a

    player’s Zans have been destroyed, they may retreat from the battle, or

    deploy another set of Zans after 60 seconds. A player can also have his

    Zans retreat back through one of the portals to deploy new ones (After 60


     If a player attacks a territory with nobody defending it, the territory

    is instantly won. The player gets no experience.

    Non-PVP quests

     (Under revision/removal; scope issues) Players can band together

    to fight challenges against the planet’s own life for rare and powerful

    rewards. Many territories have caves which house powerful creatures that

    refuse to be beaten. Killing such creatures may earn you access to special

    equipment for greater power.

Territory ownership

     In a battle, the territory owners get the edge on winning conditions. If neither faction meets the minimum victory conditions, the original holder keeps the territory.

     Territory ownership directly reflects upon a faction’s benefits. Higher ownership results in a better pay, and more rare minerals. Rare minerals can be spent on special weapons and equipment.

    Game Design

     This section details some of the detail not mentioned elsewhere. Graphics

     Graphics will be entirely 3D. Using the impressive Ogre3D engine, Project Y will attempt to create beautiful scenery while sticking to more cartoon-like objects exist using cell shading.

    Map design

     Map terrain will be generated using height maps. Included are

    three maps: Height map (256 color greyscale) defines terrain structure;

    Collision map (256 color greyscale) defines what areas are traversable by

    which units; Structure map (rgb interleave) defines which objects are

    placed where. (RG defined object ID (Placed from the upper left corner),

    B defines height). Terrain multi-texturing will be sorted later. (todo)

    Map objects

     Maps will contain various objects. Many are useless decorations,

    some are functional. For instance, artillery can hide behind walls to shell

    in a more protected area. Some maps also contain areas to repair your

    damaged Zans. This can only happen outside of a battle, while in RPG



     This section details concepts and stuff.

    Net code

     Everyone’s favorite subject. The netcode is simplified in that we only have to manage two dimensions. The game Is played top down. Ground units snap to the ground and air units are snapped to a height determined by the client (Adjusted to prevent collisions) Unit update frames should include all changes since the last update, and will leave the client some creative license. Basically, the client is informed that: Unit with an ID of X is moving to location Y,Z, and is currently at A,B. The client will then replicate the movements, since the environment is the same. Any discrepancies will be adjusted with the next update, which will ensure the client’s copy is moving correctly. Data on each unit’s speed will be set when it enters (or a client enters), and status effects will be applied and removed by the client when the server informs it of an attack with that status. Effectively, the client does many of the calculations as a local cache of the server’s work. The server still is the master, determining what units die, when they fire, etc, but the client removed reliance on the server by attempting to re-create things on its end. This reduces visible latency and network overhead.

    Adjusting for latency

     Lag is any MMO’s greatest enemy. While game isn’t directly

    affected by lag, the client will notice the jumps in unit location. To reduce

    this, the client will compensate for mismatches in data. If the client moved

    a unit to 24,24, and the server says it should be at 26,26 right now, the

    client copy will speed up or slow down slightly to compensate until it is in

    line with the server’s calculations.

    Design concepts

     This section outlines various possible schemes for data flow and code layout. The

    idea is to find one that best matches the average load without resulting in too much code

    inflation reduces complexity. Keep it simple.

    Multi-thread solution

     This model places the sound, network, logic, and 3d each in their own threads. This prevents any one thread from blocking, and reduces issues with slow GPUs

    Sound thread setup

     The OpenAL thread will have a global mutex stack that it uses to

    determine what other threads want it to do. For instance, the game logic

    thread may want to play a selection sound. The sound thread’s stack is

    locked, push()’d with the new command, and unlocked. When the sound

    thread runs, it will look at its stack, pop() off a command and execute it.

    Logic and Ogre thread playing nice

    Each thread will have a local copy of the logic thread’s data structures,

    and a global copy will also exist. The logic thread will, after completing

    its calculations, lock the global thread and copy its data over. Ogre will

    lock and copy the global thread to its local copy for rendering.

    Logic/Ogre data structure

     Both threads need to workable from the data structures. Ogre will

    have its own data subsets, but the Logic thread will need to accommodate

    Ogre’s needs. Specifically, Ogre will need to keep a secondary structure

    that links the logic classes to Ogre’s own nodes and entities. Since the

    logic thread can’t wait for Ogre to finish rendering, Ogre can’t be allowed

    to write to the global class copy. To facilitate this, the Ogre thread will

    need a linker class. This class will be used to perform pending actions (left

    in a queue class by the logic thread) such as creating and animating


    Idea: Why not run Ogre on the driver thread? Everything in Ogre should

    be globally accessible and this would be a headache otherwise. Later

    investigation into this method proves it won’t work. C++ threads are

    independent. At best, I can stop/start child threads (“Child”, since the

    concept is more of a theory than actually correct)

    Two thread model

     Realistically, the client has almost no work to really do. Barring some path finding and simple projectile calculations, almost all of the client’s duties are graphic related. Estimating a CPU:GPU use ration of 1:3, I’d say its probably safe to put the game logic in the sceneManager’s pre-scene code. The only child thread

    that would be needed would be the network thread, which can easily and safely be

    split off with little effort. This would probably be the best solution, as shared data structures slow down all threads as they wait for the global copies to be unlocked. The only potential failure of this model would depend on how much load is placed on the system with large numbers of complex path finding calculations. Research will need to be placed on this.

    Three thread model

     The basic idea here is the same as the two thread, but it splits off the graphics into their own thread. This is a contingency plan if the pathing calculations are too CPU intensive and affect framerates.

    Model issues

     The logic and graphics threads are highly reliant on each other.

    While this method would increase the framerate, its almost entirely useless

    since nothing changed between execution of Ogre’s thread. Why bother

    re-rendering the same scene? The only way around this is to move the

    pathing ONLY into its own thread, which then creates large scale blocking

    issues and synch issues. You can’t win.

Pathing and AI

     Unit pathing is achieved by a series of placed path nodes. Each node stores a linked list of attached nodes. To get to a location, a unit will find the closest node, then follow it to the closet node to its destination. Each node will also have a variance value, being the maximum distance a unit can stray from the node and still not hit anything. This value will be used to move the node on the unit’s path to give a more straight route, as well as prevent units from traveling single file.

     The unit AI is quite simple. See enemy, shoot enemy. It doesn’t need to get any more complex than that. Unarmed units or units with no more energy will simply pick a random direction and run a short distance to move out of direct fire.

Report this document

For any questions or suggestions please email