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.
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.
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.
An increased Mechanical Aptitude allows players to place more
equipment on their Zans. High mech apt units tend to be stronger and
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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
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.
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.
(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.
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.
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 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)
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.
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.
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.
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.
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.