ZEQ2 : Interactive Anime Experience

Content

This topic is locked: you cannot edit posts or make replies.

About Document

Author	Message
Zeth ZEQ2 Programmer	Monday, February 27, 2006 _____________________________ PRETENSE _____________________________ [General] ZEQ2 is a interactive anime research experience that currently uses DBZ as it's base candidate. The project is built on a passion for accuracy and mimicry towards anime concepts at a level unheard of in any interactive software in existence. With graphics and mechanics alike, even the most trivial details have been preserved and escalated by unique, yet accurate methods. This document will grow as more information becomes available via updates. _____________________________ ENGINE _____________________________ [General] The Zios engine is application/game development engine with the wrapped core written in Python. The engine's primary goal is to serve as a means to create any form of application or commercial-quality game without coding a single line of code and without having any critical level of experience. [Modules] The Zios engine is reliant on pre-existant LGPL licensed individual modules for handling various processes. By default, Ogre is used for 3D rendering, SDL for audio/input/2D, ODE for physics, and a custom socket based module for networking. The modules are designed in a way that allows support for many future enhancements that cover a vast array of areas. Future addon plans exist for : Panda3D and Irrlicht for 3D rendering, OpenAL for audio, OIS for input, and so forth to keep the engine's capability fresh and diverse. Since Python is an upper level language, all modules that are intensive in any way are fully C/C++ binded to prevent very little loss in performance between the nature of the languages. This was EXTENSIVELY tested numerous times to confirm performance capability and penalty before the development process was too far along. Any module used in the engine can be swapped with an updated or completely different module of the same type without the need for any of the user's created applications/games to have their project's aspects changed in any way. In this way the user gets all the benefits of new, updated, or differing modules without the need to alter any of his/her project structure. [Configs] The engine's codeless attributes are accomplished through external config files. The config's syntax is FULLY driven by config rulesets. These separate files (configs themselves) have defined a new type of parser that essentially relies on definitions to operate, thus allowing any layout scheme to be present in the users configs : XML, Pseudo C++, user defined, etc. Not to be confused with traditional expression based scripts, the configs presentation is completely state based and relies on a very simple, but powerful tree scheme. Every aspect of the engine is tied into this tree based layout for organization, expandability, and simplicity. Tree branches offer a simple means of relation with keywords to store values, tie into actual binded API function calls, and hold other sub-branches, among other things. [Zios Editor] While the configs themselves are already at a level that even an individual with no coding experience can pick them up and accomplish real results in a simple way, we'll be taking the concept of external configs one step farther by introducing a very lovely editor application (which is incidentally, fully developed with the configs themselves). This application, in design, is quite unique in the regard that additional editors can be added from within the editor itself, even allowing you to quickly whip up a personal editor for streamlining your project's needs. The editor of course removes the need for manually altering configs, making the required age group, learning curve, and experience level drastically lower. [Zios Library] The editor comes closely coupled with a collection of resources known as the Zios Library. Initially, this library will be filled by the project team with a large manner of media ranging anywhere from 3D meshes, textures, 2D interfaces, materials, particles, and config templates ALL the way to sounds, animations, icons, etc. The library is intended to be community driven to offer an optimum selection of resources and encourage free use of shared media. [Development] With such a robust library included with the engine & editor, development modes can be governed in a number of varying methodologies. The template question design process has been created for the most inexperienced or time critical users wishing to quickly snap together a game without any hassle whatsoever. These templates would provide enough diversity within the answers to give a fresh sense of personal satisfaction on a simple project for users without a whole lot of time, or those wishing just to quickly get their feet wet and create sandbox ideas. While a standard template question interface would be using pre-defined media and configs from the library, there would still remain a level of uniquity without foregoing advanced effects or features such as full networked or professional grade capabilities. [Comparison] Most full development engines and platforms are typically designed in ways that target them solely towards application/software development, or solely towards game development. These programs can range in license fees in the thousands and thousands of dollars, require extensive training to use properly, and still entail long development processes with a full development team for project completion. With the advent of the Zios Engine/Editor/Library, a rapid development, easy to use, open expansion, and moderately priced platform becomes available. While the statistics are not final at this stage, the price tag is intended to be impressively placed in the approximation of $30 with full lifetime Zios Library access and commercial deployment. The engine on it's own without editor and project commercialization will most likely be offered completely FREE to users. [Availability] Before releasing the Zios line of products to other developers and end-users, a critical stage will be undergone. Several free and possibly commercial products will be designed using the engine/editor before offering it directly to consumers. This will give the opportunity for our project team to fine tune the tools in a way to be sure that they are VERY user friendly and practical for product creation. _____________________________ TIMELINES _____________________________ [General] Each segment server will have a starting and ending saga specified. The character and character potential available on that server is limited to characters available in the set timeline. Power levels, skills, outfits, general character personality, and other attributes are effected by what versions of the character are available. [Example] If the segment server had chosen a starting saga of 'Namek Saga' and ending saga of 'Cell Saga', new players to the server would begin with their chosen characters reflecting that of Namek saga versions. The maximum potential for that character would be limited to the Cell saga unless server 'accuracy' options were disabled. [Additional Timelines] Selecting an additional timeline such as those from movies and specials adds characters available and/or adjusts the limits of currently existing characters. Options will exist to allow server admins to control the strictness of enforced 'accuracy' settings pertaining to timelines in general. _____________________________ SEGMENT & WORLD SERVERS _____________________________ [Server Types & Travel] Any server available online in ZEQ2 is classified as a segment server. These allow individual control over many typical server settings. Segment servers also have the unique ability to be 'linked' to another server or set of servers, therein creating a 'world server'. By joining a 'world server' rather than an individual segment node, the player will be able to traverse the "world" as a whole. Segment servers will be able to access sibling segment servers in that world by means of map edge and other more "unique" methods. Typically each segment will represent one map from the maps available. Individual segment server joining can optionally be prevented if not a world server member. [Server Stats] Segment servers additionally have the option store player information in a virtual table. After a player had played for a long period of time, he/she would have most likely progressed tremendously in terms of power level. With the option of 'server stats' active on the server, that player could later rejoin the server preserving the power level of the character he/she played as. To authenticate with a server stat enabled server, a user account would be created along with password. The user account will hold information for each of the characters available in ZEQ2 uniquely for that player. Both world and segment servers can use server stat methods. The revealing of server stats brings a very 'progressive' approach to the game. [Official Servers] World servers may be "formally" established by a number of methods. To formally establish a world server, a central database needs to exist to store and relate data between all segment servers. A formal world server can further make itself 'official' by submitting and registering with ZEQ2's primary world server list. Without a central world server database to propagate data between segments of the world, the server may choose to store player information locally. These types of world servers are typically referred to as 'rogue worlds' since each segment is a unique member bound by its own separate rules. Rogue worlds can be created on the fly by individual segment servers allowing the option to be 'dynamically linked'. The segment server will specify this option along with several criteria he/she would like to be met. This data includes an interval that will check server lists for other dynamically link-able servers at the chosen rate. [Server Destruction] When segment servers are linked to form a world server, opportunities become available for literal segment server destruction. In the more rare event of a certain planet's destruction, all segments servers in that world containing regions belonging to that planet become un-joinable. Depending on 'accuracy' settings server-side, the server could be introduced with the situation of ONLY being restored by gathering dragonballs to make an actual wish. In the extremely rare event of a world servers 'complete' destruction, depending on world server options, a new world might be established alternately under a new alias altogether. This world is treated as a brand new world and DOES NOT preserve any stored player data! _____________________________ MECHANICS _____________________________ [Interfaces] None. See Perceptual Immersion. [Flight] Flight in ZEQ2 differs greatly in comparison to traditional flight methods. Studying the series closely, it can be easily discovered that characters not only have basic (vertical, horizontal, and thrust) movements, but rotation movements on EACH of the axis' as well. The term of using 4 components for 3D orientation is a quaternion. With this true 360 degree based system, all types of movement become possible in comparison to a lesser more rigid system. Barrel rolls, the act of of a forward momentum spiral are completely valid without hesitation of input. Additionally, coaster loops, the act of a full 360 degree vertical loopity-loop are completely plausible. Utilizing a combination of rolls and loops, the player can essentially achieve (and maintain) any position and form while in the air. _____________________________ INTERACTION _____________________________ [Sensing] Sensing in DBZ is the concept of detecting power level emanating from sources around you. In bringing this concept to the world of ZEQ2, the mechanics are completely preserved in the most accurate manner. The ability to sense in ZEQ2 is regulated by one of two methods. Automatic sensing is the most common type of sensing available. In such a case, the camera is typically focused on the character making the observation -- using expressions, small quips, or just general grunts. In matters relating to ZEQ2, this is done by using a PIP(Picture in Picture) display etched into the corner of the screen. The concept is reminiscent of "slice screen" techniques done throughout the series to proclaim an activity of drama. For example if Piccolo had suddenly came into proximity of Goku's auto sensing range, he might pause to say, "Huh? Piccolo!" with a vivid display of emotion in respect. Another example would be if Raditz were to suddenly notice Piccolo charging an attack beyond what he expected. A shock jawed Raditz with dramatic background might slice its way on the screen with Raditz exclaiming "What?! 1400?! I can't block that!". Given both a generic and precision example, it's easy to see how PIP or screen sliced auto-sensing can aid the flow of detection in a very natural and dramatic manner. The detection implies other players, incoming attacks, and even far off events (such as someone ascending to SSJ3 -- even on an entirely different segment server!). While the automatic range at which you are able to detect increases slightly as your power level increases, the range at which you are able TO BE detected increases dramatically. This comes into play heavily in regards of managing power level to prevent detection from manual sensing. Manual sensing is a less common process in which a character will manually search for a specific power signature. Power signatures are uniquely assigned to other characters only. The character's ability to use manual sensing, while also dependent on power level, is at MUCH greater distances than methods used in automatic sensing. While the strategic depth of using this type of sensing is primarily for locating a specific enemies power level, it can also be used as a method for locating wounded allies, or determining the location of a large fight. [Perceptual Immersion] With such a high level of accuracy maintained throughout ZEQ2's concepts, the innovation for an interface-less design seems only fitting. Since such interfaces were NOT present in the actual series, having them present in a piece of media relating would remove the splendid accuracy illusion we've worked hard to maintain. In favor of implementing heads up displays and other bars for monitoring character and world status, a full hud-less design has been invented. This design accounts for the primary types of relational connections. Each of the player statistics are handled in a unique, yet accurate, manner. Speed is perceptually read simply by judging how much distance a character is covering. When a player's speed far surpasses the visual capability of the viewer, he/she may not fully be able to follow speed movements -- which results in blinking fades, line jolts, or in more extreme cases complete lack of visibility. Strength is perceptually read generally by mêlée impact and defensive reactions to mêlée. This statistic can also be judged to SOME extent by physical size and muscle mass in regard to power level relations. Fatigue is perceptually accented by a character's breathing patterns. As a character becomes more fatigued, he/she will begin to breath more and more heavily until eventually collapsing visually. Power Level is perceptually read by camera reaction intensity, aura properties(size, spike flow, type), character transformation status, speed and strength factors, and environmental changes such as ground debris reactions, wind, weather, cloud movement, etc. Power level is one of the most difficult (yet vital) statistics to read correctly and depends on the most factors. When misread dramatically, the results can be devastating. Transformation readiness, which is the point at which a player may actually ascend to another level (SSJ, for example), is completely unreadable by perceptual means. Since most transformation status are completely independent of power level and more reliant on emotional events, the precise point at which a character may transform for the first time would be completely reliant on that particular characters personality and the surrounding current events. Characters that have previously achieved transformed states may do so at free will as long as logical series personality permits. See Personality Depth for more information. Other feedback components are also handled adversely to traditional systems. See Sensing as one such type. Skill selection, rather than be determined by a visual list in search for the proper icon or cue, has been replaced by a direct system of accessing any skill. The reasoning behind this is not only for ease of use, but for flow logic. Since DBZ and ZEQ2 are fast paced concepts, utilizing a 'scroll selection' system yields many penalties in terms of selecting the proper weapon and selecting it quick enough. These types of input mistakes are not plausible in terms of DBZ since such attack selection mistakes would NEVER have occurred. See Control Structure for more information. By creating the system in such a manner that the player has to actually watch and study his/her surroundings to act, the level of strategy and tactical nature of the result is enhanced greatly. While a difference in power level could still mean a great deal, the amount of natural skill a player may have on reading the situation, using previous knowledge of events, and acting on that information could be all the difference that's needed to remove the gap. [Flight] Reflective of its series counterpart, ZEQ2 features 3 flight movement types along with 'Air Idle'. These are : Hover, Air Dashing, and Full Flight. Air Idle is the most defensively tactical position in the air. While idle in the air, the character is able to perform a vast array of defensive maneuvers. This position is the second most tactical stance in ZEQ2, only being shadowed by ground idle. Hover is a slowest maneuver-based air movement type. While hovering, the character leans slightly in the direction desired and drifts. This movement is primarily used for non-combat or repositioning of the player to prepare for combat. During hover the player's ability to react defensively is greater than any other flight movement type -- although not greater than air idle. Air dashing is a fast combat-based air movement type. While air dashing, the character leans greatly in the direction desired with accented leg and arm positions in a manner identical to ground dashing. This movement is primary used for combat purposes such as rushing in with mêlée. During air dash the player's ability to react defensively is limited. Full flight is an extremely travel-based air movement type. This is the fastest type of natural movement available in ZEQ2. While in full flight, the character performs a full body shift with a forward momentum ONLY. From this rigid position, the effects of 360 degree flight take HIGH regard since a forward movement is only available. This movement is primary used for traveling purposes as going to another region or part of the map. During full flight the player's ability to react defensively is nil. [Tactical Manuevers] Keeping true to both DBZ accuracy and an involving interaction experience, ZEQ2 provides various options of advanced movement types to the player in order to enrich interactive elements and strategy. Please do note that like many defensive and mêlée maneuvers, some are strictly reserved for particular characters that would and actually do perform them in the series. The jump movement is (obviously) only available while the character has footing on a solid surface. This maneuver can be used to aid in the escape of large energy attacks, grant the player access to typically unreachable areas, provide a transition to flight movement types, as well as execute several varieties of DBZ traditional knockback and stun mêlée maneuvers that would otherwise only be usable in a type of aerial position. The rapid jump, corkscrew somersault, and ball flip movement types are only available from within a standard jump with the last two performable only during the ascension and descension respectively. The rapid jump, a much more hasteful variation of a standard jump, becomes possible if the user chooses to expend energy during a jump. Executing a rapid jump offers the single fastest method of movement while on the ground. The jump is started and completed in only a fraction of a second, leaving the player a distorted blur and the entire course of the path ridden with emphasized direction lines. However, due to the speed and rather sudden, burst-full nature of the rapid jump, there is some difficulty in precisely controlling jumps in succession to one another -- limiting the maneuver to a mostly forward linear path. No other maneuvers of any kind may be performed during a rapid jump. The ball flip is a type of movement that is only possible while descending in the air from a fall -- most commonly the latter part of a jump sequence. Performing a ball flip maneuver results in a variety of perks. Typically, during a fall sequence, the player is at the whim of the trajectory of the jump and standard DBZ physics. The ball flip maneuver, however, is able to overcome the trajectory boundary by establishing a vertical control on the fall, resulting in a perfect controlled landing. Using this technique the player is accelerated to the ground in a more rapid fashion and given a slight defensive bonus aiding to the reception of an otherwise opponent vulnerable falling duration. Considering the conditions for the ball flip to become applicable, this tactic is one of the best, yet very few types of maneuvers that is possible during a controlled fall. During the ascension portion of a standard jump, the player may opt into performing the corkscrew somersault. The corkscrew somersault offers the user great finesse while in the air -- additionally protecting the user from most types of advanced grasping mêlée techniques. Along with the previous perks, the somersault will result in a brief but extended vertical gain. If this maneuver is used during a mêlée confrontation, the player will land with a 180 degree face rotation, resulting in a placement directly facing behind the opponent. Due to the nature and form of the maneuver, the player does become somewhat succectable as it is performed much slower than a standard jump sequence. The ball flip may not be combined with the end portion of a corkscrew somersault due to it's consideration as a non-standard fall.

Author

Message

Zeth

ZEQ2 Programmer

Monday, February 27, 2006

_____________________________

PRETENSE
_____________________________

[General]
ZEQ2 is a interactive anime research experience that currently uses DBZ as it's base candidate. The project is built on a passion for accuracy and mimicry towards anime concepts at a level unheard of in any interactive software in existence. With graphics and mechanics alike, even the most trivial details have been preserved and escalated by unique, yet accurate methods. This document will grow as more information becomes available via updates.

_____________________________

ENGINE
_____________________________

[General]
The Zios engine is application/game development engine with the wrapped core written in Python. The engine's primary goal is to serve as a means to create any form of application or commercial-quality game without coding a single line of code and without having any critical level of experience.

[Modules]
The Zios engine is reliant on pre-existant LGPL licensed individual modules for handling various processes.

By default, Ogre is used for 3D rendering, SDL for audio/input/2D, ODE for physics, and a custom socket based module for networking. The modules are designed in a way that allows support for many future enhancements that cover a vast array of areas. Future addon plans exist for : Panda3D and Irrlicht for 3D rendering, OpenAL for audio, OIS for input, and so forth to keep the engine's capability fresh and diverse.

Since Python is an upper level language, all modules that are intensive in any way are fully C/C++ binded to prevent very little loss in performance between the nature of the languages. This was EXTENSIVELY tested numerous times to confirm performance capability and penalty before the development process was too far along.

Any module used in the engine can be swapped with an updated or completely different module of the same type without the need for any of the user's created applications/games to have their project's aspects changed in any way. In this way the user gets all the benefits of new, updated, or differing modules without the need to alter any of his/her project structure.

[Configs]
The engine's codeless attributes are accomplished through external config files.

The config's syntax is FULLY driven by config rulesets. These separate files (configs themselves) have defined a new type of parser that essentially relies on definitions to operate, thus allowing any layout scheme to be present in the users configs : XML, Pseudo C++, user defined, etc.

Not to be confused with traditional expression based scripts, the configs presentation is completely state based and relies on a very simple, but powerful tree scheme. Every aspect of the engine is tied into this tree based layout for organization, expandability, and simplicity. Tree branches offer a simple means of relation with keywords to store values, tie into actual binded API function calls, and hold other sub-branches, among other things.

[Zios Editor]
While the configs themselves are already at a level that even an individual with no coding experience can pick them up and accomplish real results in a simple way, we'll be taking the concept of external configs one step farther by introducing a very lovely editor application (which is incidentally, fully developed with the configs themselves).

This application, in design, is quite unique in the regard that additional editors can be added from within the editor itself, even allowing you to quickly whip up a personal editor for streamlining your project's needs. The editor of course removes the need for manually altering configs, making the required age group, learning curve, and experience level drastically lower.

[Zios Library]
The editor comes closely coupled with a collection of resources known as the Zios Library. Initially, this library will be filled by the project team with a large manner of media ranging anywhere from 3D meshes, textures, 2D interfaces, materials, particles, and config templates ALL the way to sounds, animations, icons, etc. The library is intended to be community driven to offer an optimum selection of resources and encourage free use of shared media.

[Development]
With such a robust library included with the engine & editor, development modes can be governed in a number of varying methodologies.

The template question design process has been created for the most inexperienced or time critical users wishing to quickly snap together a game without any hassle whatsoever. These templates would provide enough diversity within the answers to give a fresh sense of personal satisfaction on a simple project for users without a whole lot of time, or those wishing just to quickly get their feet wet and create sandbox ideas. While a standard template question interface would be using pre-defined media and configs from the library, there would still remain a level of uniquity without foregoing advanced effects or features such as full networked or professional grade capabilities.

[Comparison]
Most full development engines and platforms are typically designed in ways that target them solely towards application/software development, or solely towards game development. These programs can range in license fees in the thousands and thousands of dollars, require extensive training to use properly, and still entail long development processes with a full development team for project completion.

With the advent of the Zios Engine/Editor/Library, a rapid development, easy to use, open expansion, and moderately priced platform becomes available. While the statistics are not final at this stage, the price tag is intended to be impressively placed in the approximation of $30 with full lifetime Zios Library access and commercial deployment. The engine on it's own without editor and project commercialization will most likely be offered completely FREE to users.

[Availability]
Before releasing the Zios line of products to other developers and end-users, a critical stage will be undergone. Several free and possibly commercial products will be designed using the engine/editor before offering it directly to consumers. This will give the opportunity for our project team to fine tune the tools in a way to be sure that they are VERY user friendly and practical for product creation.

_____________________________

TIMELINES
_____________________________

[General]
Each segment server will have a starting and ending saga specified. The character and character potential available on that server is limited to characters available in the set timeline. Power levels, skills, outfits, general character personality, and other attributes are effected by what versions of the character are available.

[Example]
If the segment server had chosen a starting saga of 'Namek Saga' and ending saga of 'Cell Saga', new players to the server would begin with their chosen characters reflecting that of Namek saga versions. The maximum potential for that character would be limited to the Cell saga unless server 'accuracy' options were disabled.

[Additional Timelines]
Selecting an additional timeline such as those from movies and specials adds characters available and/or adjusts the limits of currently existing characters. Options will exist to allow server admins to control the strictness of enforced 'accuracy' settings pertaining to timelines in general.

_____________________________

SEGMENT & WORLD SERVERS
_____________________________

[Server Types & Travel]
Any server available online in ZEQ2 is classified as a segment server. These allow individual control over many typical server settings. Segment servers also have the unique ability to be 'linked' to another server or set of servers, therein creating a 'world server'. By joining a 'world server' rather than an individual segment node, the player will be able to traverse the "world" as a whole. Segment servers will be able to access sibling segment servers in that world by means of map edge and other more "unique" methods. Typically each segment will represent one map from the maps available. Individual segment server joining can optionally be prevented if not a world server member.

[Server Stats]
Segment servers additionally have the option store player information in a virtual table. After a player had played for a long period of time, he/she would have most likely progressed tremendously in terms of power level.

With the option of 'server stats' active on the server, that player could later rejoin the server preserving the power level of the character he/she played as. To authenticate with a server stat enabled server, a user account would be created along with password. The user account will hold information for each of the characters available in ZEQ2 uniquely for that player. Both world and segment servers can use server stat methods. The revealing of server stats brings a very 'progressive' approach to the game.

[Official Servers]
World servers may be "formally" established by a number of methods. To formally establish a world server, a central database needs to exist to store and relate data between all segment servers. A formal world server can further make itself 'official' by submitting and registering with ZEQ2's primary world server list.

Without a central world server database to propagate data between segments of the world, the server may choose to store player information locally. These types of world servers are typically referred to as 'rogue worlds' since each segment is a unique member bound by its own separate rules. Rogue worlds can be created on the fly by individual segment servers allowing the option to be 'dynamically linked'. The segment server will specify this option along with several criteria he/she would like to be met. This data includes an interval that will check server lists for other dynamically link-able servers at the chosen rate.

[Server Destruction]
When segment servers are linked to form a world server, opportunities become available for literal segment server destruction. In the more rare event of a certain planet's destruction, all segments servers in that world containing regions belonging to that planet become un-joinable. Depending on 'accuracy' settings server-side, the server could be introduced with the situation of ONLY being restored by gathering dragonballs to make an actual wish.

In the extremely rare event of a world servers 'complete' destruction, depending on world server options, a new world might be established alternately under a new alias altogether. This world is treated as a brand new world and DOES NOT preserve any stored player data!

_____________________________

MECHANICS
_____________________________

[Interfaces]
None. See Perceptual Immersion.

[Flight]
Flight in ZEQ2 differs greatly in comparison to traditional flight methods. Studying the series closely, it can be easily discovered that characters not only have basic (vertical, horizontal, and thrust) movements, but rotation movements on EACH of the axis' as well. The term of using 4 components for 3D orientation is a quaternion.

With this true 360 degree based system, all types of movement become possible in comparison to a lesser more rigid system.

Barrel rolls, the act of of a forward momentum spiral are completely valid without hesitation of input. Additionally, coaster loops, the act of a full 360 degree vertical loopity-loop are completely plausible. Utilizing a combination of rolls and loops, the player can essentially achieve (and maintain) any position and form while in the air.

_____________________________

INTERACTION
_____________________________

[Sensing]
Sensing in DBZ is the concept of detecting power level emanating from sources around you. In bringing this concept to the world of ZEQ2, the mechanics are completely preserved in the most accurate manner.

The ability to sense in ZEQ2 is regulated by one of two methods.

Automatic sensing is the most common type of sensing available. In such a case, the camera is typically focused on the character making the observation -- using expressions, small quips, or just general grunts. In matters relating to ZEQ2, this is done by using a PIP(Picture in Picture) display etched into the corner of the screen. The concept is reminiscent of "slice screen" techniques done throughout the series to proclaim an activity of drama.

For example if Piccolo had suddenly came into proximity of Goku's auto sensing range, he might pause to say, "Huh? Piccolo!" with a vivid display of emotion in respect. Another example would be if Raditz were to suddenly notice Piccolo charging an attack beyond what he expected. A shock jawed Raditz with dramatic background might slice its way on the screen with Raditz exclaiming "What?! 1400?! I can't block that!".

Given both a generic and precision example, it's easy to see how PIP or screen sliced auto-sensing can aid the flow of detection in a very natural and dramatic manner. The detection implies other players, incoming attacks, and even far off events (such as someone ascending to SSJ3 -- even on an entirely different segment server!). While the automatic range at which you are able to detect increases slightly as your power level increases, the range at which you are able TO BE detected increases dramatically. This comes into play heavily in regards of managing power level to prevent detection from manual sensing.

Manual sensing is a less common process in which a character will manually search for a specific power signature. Power signatures are uniquely assigned to other characters only. The character's ability to use manual sensing, while also dependent on power level, is at MUCH greater distances than methods used in automatic sensing. While the strategic depth of using this type of sensing is primarily for locating a specific enemies power level, it can also be used as a method for locating wounded allies, or determining the location of a large fight.

[Perceptual Immersion]
With such a high level of accuracy maintained throughout ZEQ2's concepts, the innovation for an interface-less design seems only fitting. Since such interfaces were NOT present in the actual series, having them present in a piece of media relating would remove the splendid accuracy illusion we've worked hard to maintain.

In favor of implementing heads up displays and other bars for monitoring character and world status, a full hud-less design has been invented. This design accounts for the primary types of relational connections. Each of the player statistics are handled in a unique, yet accurate, manner.

Speed is perceptually read simply by judging how much distance a character is covering. When a player's speed far surpasses the visual capability of the viewer, he/she may not fully be able to follow speed movements -- which results in blinking fades, line jolts, or in more extreme cases complete lack of visibility.

Strength is perceptually read generally by mêlée impact and defensive reactions to mêlée. This statistic can also be judged to SOME extent by physical size and muscle mass in regard to power level relations.

Fatigue is perceptually accented by a character's breathing patterns. As a character becomes more fatigued, he/she will begin to breath more and more heavily until eventually collapsing visually.

Power Level is perceptually read by camera reaction intensity, aura properties(size, spike flow, type), character transformation status, speed and strength factors, and environmental changes such as ground debris reactions, wind, weather, cloud movement, etc. Power level is one of the most difficult (yet vital) statistics to read correctly and depends on the most factors. When misread dramatically, the results can be devastating.

Transformation readiness, which is the point at which a player may actually ascend to another level (SSJ, for example), is completely unreadable by perceptual means. Since most transformation status are completely independent of power level and more reliant on emotional events, the precise point at which a character may transform for the first time would be completely reliant on that particular characters personality and the surrounding current events. Characters that have previously achieved transformed states may do so at free will as long as logical series personality permits. See Personality Depth for more information.

Other feedback components are also handled adversely to traditional systems. See Sensing as one such type.

Skill selection, rather than be determined by a visual list in search for the proper icon or cue, has been replaced by a direct system of accessing any skill. The reasoning behind this is not only for ease of use, but for flow logic. Since DBZ and ZEQ2 are fast paced concepts, utilizing a 'scroll selection' system yields many penalties in terms of selecting the proper weapon and selecting it quick enough. These types of input mistakes are not plausible in terms of DBZ since such attack selection mistakes would NEVER have occurred. See Control Structure for more information.

By creating the system in such a manner that the player has to actually watch and study his/her surroundings to act, the level of strategy and tactical nature of the result is enhanced greatly. While a difference in power level could still mean a great deal, the amount of natural skill a player may have on reading the situation, using previous knowledge of events, and acting on that information could be all the difference that's needed to remove the gap.

[Flight]
Reflective of its series counterpart, ZEQ2 features 3 flight movement types along with 'Air Idle'. These are : Hover, Air Dashing, and Full Flight.

Air Idle is the most defensively tactical position in the air. While idle in the air, the character is able to perform a vast array of defensive maneuvers. This position is the second most tactical stance in ZEQ2, only being shadowed by ground idle.

Hover is a slowest maneuver-based air movement type. While hovering, the character leans slightly in the direction desired and drifts. This movement is primarily used for non-combat or repositioning of the player to prepare for combat. During hover the player's ability to react defensively is greater than any other flight movement type -- although not greater than air idle.

Air dashing is a fast combat-based air movement type. While air dashing, the character leans greatly in the direction desired with accented leg and arm positions in a manner identical to ground dashing. This movement is primary used for combat purposes such as rushing in with mêlée. During air dash the player's ability to react defensively is limited.

Full flight is an extremely travel-based air movement type. This is the fastest type of natural movement available in ZEQ2. While in full flight, the character performs a full body shift with a forward momentum ONLY. From this rigid position, the effects of 360 degree flight take HIGH regard since a forward movement is only available. This movement is primary used for traveling purposes as going to another region or part of the map. During full flight the player's ability to react defensively is nil.

[Tactical Manuevers]
Keeping true to both DBZ accuracy and an involving interaction experience, ZEQ2 provides various options of advanced movement types to the player in order to enrich interactive elements and strategy. Please do note that like many defensive and mêlée maneuvers, some are strictly reserved for particular characters that would and actually do perform them in the series.

The jump movement is (obviously) only available while the character has footing on a solid surface. This maneuver can be used to aid in the escape of large energy attacks, grant the player access to typically unreachable areas, provide a transition to flight movement types, as well as execute several varieties of DBZ traditional knockback and stun mêlée maneuvers that would otherwise only be usable in a type of aerial position. The rapid jump, corkscrew somersault, and ball flip movement types are only available from within a standard jump with the last two performable only during the ascension and descension respectively.

The rapid jump, a much more hasteful variation of a standard jump, becomes possible if the user chooses to expend energy during a jump. Executing a rapid jump offers the single fastest method of movement while on the ground. The jump is started and completed in only a fraction of a second, leaving the player a distorted blur and the entire course of the path ridden with emphasized direction lines. However, due to the speed and rather sudden, burst-full nature of the rapid jump, there is some difficulty in precisely controlling jumps in succession to one another -- limiting the maneuver to a mostly forward linear path. No other maneuvers of any kind may be performed during a rapid jump.

The ball flip is a type of movement that is only possible while descending in the air from a fall -- most commonly the latter part of a jump sequence. Performing a ball flip maneuver results in a variety of perks. Typically, during a fall sequence, the player is at the whim of the trajectory of the jump and standard DBZ physics. The ball flip maneuver, however, is able to overcome the trajectory boundary by establishing a vertical control on the fall, resulting in a perfect controlled landing. Using this technique the player is accelerated to the ground in a more rapid fashion and given a slight defensive bonus aiding to the reception of an otherwise opponent vulnerable falling duration. Considering the conditions for the ball flip to become applicable, this tactic is one of the best, yet very few types of maneuvers that is possible during a controlled fall.

During the ascension portion of a standard jump, the player may opt into performing the corkscrew somersault. The corkscrew somersault offers the user great finesse while in the air -- additionally protecting the user from most types of advanced grasping mêlée techniques. Along with the previous perks, the somersault will result in a brief but extended vertical gain. If this maneuver is used during a mêlée confrontation, the player will land with a 180 degree face rotation, resulting in a placement directly facing behind the opponent. Due to the nature and form of the maneuver, the player does become somewhat succectable as it is performed much slower than a standard jump sequence. The ball flip may not be combined with the end portion of a corkscrew somersault due to it's consideration as a non-standard fall.