Rocket Powered Hippo - Technical Design Document by Rocket Powered Hippo

A Rocket Powered Hippo Production

Ascension The Awakening Technical Design Document Document Author Steven Matthews

Contents 1.0 Introduction ............................................................................................................. 3 2.0 Technical Overview .................................................................................................. 3 2.1 Target System Requirements ............................................................................... 3 2.2 Tools and Programs for Development ................................................................. 3 2.3 DropBox File Solution and Storage Program: ...................................................... 5 2.4 Crysis Wars Mod SDK v1.0 ................................................................................... 5 2.4 1 About the Crysis Wars Mod SDK: .................................................................. 5 2.4.2 Mod SDK Requirements ................................................................................ 6 2.5 Mod SDK Content................................................................................................. 6 2.5.1 Code .............................................................................................................. 6 2.5.2 Tools .............................................................................................................. 6 2.5.3 Plug-Ins.......................................................................................................... 6 3.0 Engine & Middleware .............................................................................................. 7 3.1 Polybumpâ&#x201E;˘ 2 ...................................................................................................... 7 3.2 Next Generation Real-Time Renderer ................................................................. 7 3.3 Sound and Music .................................................................................................. 8 3.4 Advanced AI System ............................................................................................. 8 3.5 Other functionality ............................................................................................... 9 4.0 Console Commands ................................................................................................. 9 4.1 Important Details: .............................................................................................. 10 4.2 General Gameplay Commands .......................................................................... 10 4.3 System Information / Diagnostic Commands .................................................... 11 4.4 Cheat Commands- Testing purposes ................................................................ 11 5.0 File Formats............................................................................................................ 12 5.1 Coding Areas .......................................................................................................... 14 5.1 Flowgraph .......................................................................................................... 15 5.2 Lua ...................................................................................................................... 16 5.3 Flash ................................................................................................................... 18 5.4 C++ ..................................................................................................................... 18 6.0 Programming Pipeline............................................................................................ 20 7.0 Technical Asset Overview ...................................................................................... 21 8.0 Development Plan .................................................................................................. 22 8.1 Development Specifications .............................................................................. 22 8.2 Singleplayer Metagame ..................................................................................... 23 8.3 Inventory ............................................................................................................ 24 8.4 Custom Player Character ................................................................................... 26 8.5 Transporter System ............................................................................................ 27 8.7 Puzzles ................................................................................................................ 29 8.8 Traps................................................................................................................... 31 8.9 HUD .................................................................................................................... 31 8.10 Quests .............................................................................................................. 32 8.11 Weapons .......................................................................................................... 33 8.12 A.I ..................................................................................................................... 34

8.13 Amulet .............................................................................................................. 35 9.0 Milestones.............................................................................................................. 36 9.1 GDD and TDD complete ..................................................................................... 36 9.2 Asset List and Development Plan Complete ...................................................... 36 9.3 Prototype ........................................................................................................... 36 9.4 Alpha .................................................................................................................. 36 9.5 Beta .................................................................................................................... 36 9.6 Gold .................................................................................................................... 36 10.0 Software Architecture .......................................................................................... 37 10.1 Directory Structure .......................................................................................... 37 10.2 Build Process .................................................................................................... 37 11.0 Coding Standards ................................................................................................. 38

1.0 Introduction Ascension is a single-player, total conversion (mod) for Crytekâ&#x20AC;&#x2122;s CryEngine. The iteration of the engine that we will be using comes packaged with Crysis Wars. The SDK provides access to all levels of modding control, from C++ source to Lua Script and a robust level editor. The Game itself can be classed as a survival adventure, with the focus of the mod being on exploration and survival in a harsh environment. The gametype itself represents a complete break from any gametype found in vanilla Crysis and will involve unique survival and combat mechanics alongside a robust physics system, gravimetric and environmental effects. In Ascension the overriding objective will be to ensure the continued survival of Antare your village home whilst also uncovering the truth of your planets history (Aurora). The story will be presented through the use of a quest mechanic, divided into a main storyline and side quests.

2.0 Technical Overview 2.1 Target System Requirements Ascension will be developed for the PC platform. In accordance with this, Crytek lists the following system requirements for Crysis Wars: CPU: Intel Core Duo E7300 2.66Ghz 3M Processor RAM: 1GB (1.5GB on Windows Vista) Graphics Card: Nvidia GeForce 6800GT, ATI Radeon 9800 Pro (Radeon X800 for Vista) or better VRAM: 256MB of Graphics Memory Storage: 10GB free HDD space Sound Card: DX9 Compatible OS: Microsoft Windows XP with service pack 2 or Windows Vista Optical Drive: DVD-Rom (unneeded for digital versions) DirectX: DirectX 9.0c or DirectX10

2.2 Tools and Programs for Development All members of the development staff will have access to personal development workstations with standard office programs such as Microsoft Word and Excel. In addition, all members will have access to the robust development tools that accompany Crysis Wars and the Crysis Wars SDK pack v1.0. For programming and base software solutions the main workstation with the most up-to-date source code will be that of the lead programmer. Each department will then have the relevant software required for production of content and for quality assurance testing.

Users

Programmer

Tool

Workstation and

Use

Dell XPS Gen 2 laptop

base software All

Crysis Wars

Retail version of the game

All

Sandbox 2

Level Editor, Package Editor

All

Crysis Wars SDK 1.0

Resources and tools required for modding

Programmer, Level

Notepad ++

Lua Script Editing package

Visual Studio 2005

C++ Source Code editing

Designers Programmer

Professional Programmer/Level

Adobe Flash CS4

Designers

HUD Content creation; Flash assets; Flash Coding

Artists, Level

Autodeskâ&#x20AC;&#x2122;s 3DS

Character meshes and animation and

Designers

Max 2009

static meshes

Artists

Exporter for Crysis

Export to Crysis formats

Level Designers,

Adobeâ&#x20AC;&#x2122;s Photoshop

Textures and other 2D art

Artists

CS2

Level Designers,

Adobe Illustrator

Textures and other 2D art

Programmer

Notepad ++

Source Control and Browsing

All

Dropbox

File Distribution and Backup

Programmer,

Adobe Flash CS4

HUD creation using flash

Sound Engineer

CuBase

Sound and Music Creation

Sound Engineer

Reason

SFX

Sound Engineer

Sonar 7

Sound Mastering Suite

Artists/Level

MaxExporter

Exporting software included with SDK

Artists

Scripters

Designers

development kit

Artists/Level

Polybump

Designers Programmer

Exporting software included with SDK development kit

Maxscripts

Exporting software included with SDK development kit

Artists/Level

CryTiff

Designers

Exporting software included with SDK development kit

2.3 DropBox File Solution and Storage Program: Dropbox is a storage application and service operated by Dropbox, Inc. The service enables team members to store and sync files online and between computers. While Dropbox functions as a storage service, its focus is on synchronization and sharing. Dropbox synchronization uses SSL transfers with AES-256 encryption, and it supports revision history so files deleted from the Dropbox folder may be recovered from any of the synced computers. Dropbox's version control also helps users know the history of a file they may be currently working on, enabling more than one person to edit and re-post files without complications of losing its previous form. The version history is limited to 30 days. There is no limit to file size for files added via the Dropbox application, but files transferred through the web interface are capped at 350 MB. Dropbox uses Amazon's S3 storage system to store the files and SoftLayer Technologies for their backend infrastructure. For the purposes of our project the team has purchased the 50GB limit for Dropbox, allowing us a large capacity for projects files that is both safe and secure. Dropbox allows for an unprecedented amount of control and distribution of our project files and its real-time access allows ease of use. One inherent problem is when team members open the same file at the same time they can inadvertently copy over another personâ&#x20AC;&#x2122;s work. In order to avoid this, team members are required to place a document in the folder they are working on detailing what file they presently have open. This is obviously not required for work that is not a joint effort.

2.4 Crysis Wars Mod SDK v1.0 2.4 1 About the Crysis Wars Mod SDK: The Crysis Wars Mod SDK essentially performs the same functions as the Crysis Mod SDK. It contains tools, assets and game source code to help modders in creating their mods for the Crysis Wars and Warhead engine. It also features the brand new and improved release of the Sandbox2 level editor so that modders can once again

design maps for the latest release in the Crysis franchise. Just because the SDK is named Crysis Wars does not mean that no singleplayer support is available. The engine allows for AI and singleplayer within the Wars (and Warhead) engine, so both singleplayer and multiplayer levels and mods can be made for the engine, identical to the Crysis modding process.

2.4.2 Mod SDK Requirements    

A full version of the Crysis Wars Game with Patch4 (does not work with versions below 1.4, Crysis Warhead or Crysis) You will require 70MB of free disk space to install the tools included in the SDK. The 3DSMax Exporter Plug-In and Polybump require Autodesk 3DS Max version 9 or higher. The XSI Add-On requires the XSI ModTool or a XSI full version.

2.5 Mod SDK Content 2.5.1 Code 

Game Source Code (patched to Crysis Wars v1.4)

2.5.2 Tools          

CryENGINE2 Sandbox2 Editor Resource Compiler (32-bit only) CryExport plug-in for 3DS Max 9, 10 and 11 (32-bit and 64-bit) Polybump plug-in for 3DS Max 9, 10 and 11 (32-bit and 64-bit) Polybump application (32-bit and 64-bit) CryTIFF plug-in for Adobe Photoshop (32-bit only) FMOD Designer Tool (32-bit only) Rigging, Artist, Animation Tools for 3DS Max CryExport plug-in for XSI Engine Settings Manager

2.5.3 Plug-Ins Installing the MaxExporter, Polybump, the MaxScripts and the CryTiff is normally done by the installer. The installer software should automatically detect your actually used version of 3DS Max and installed Photoshop and integrate the plug-ins there. You can also add multiple versions of 3DS Max if you have multiple versions installed and work with them. If the automatic installation fails team members need to follow the following steps:  

Copy the plug-in file (CryExportX.dlu) to the plug-in directory in the max install folder. Create an empty file in that directory using a text editor (such as notepad) and save the file as CryExportX.ini. The system will fill this file with information itself.



Next time that you start Max, the plug-in should be automatically loaded. To check, open the Plug-in Manager by selecting the menu command "Customize">"Plug-in Manager" and look for the file "CryExportX.dlu" in the list. (X is placeholder for the 3DS Max Version).

3.0 Engine & Middleware Since Ascension is a total conversion mod for an existing game, the actual game engine source code will be utilized along with a third-party middleware solution, namely Visual Studio 2005 Professional. The code will be written using three programming languages, C++, Lua script and Flash and compiled with the Visual Studio compile, Lua Compiler and sandbox editor that accompany the retail version of the game. The following details some of the functionality of CryEngine 2.5. This list is far from comprehensive and details only specific functionality as it pertains to the development of Ascension.

3.1 Polybump™ 2 This program allows users to extract detailed model information from the standalone program or in conjunction with 3DSMax. The extracted information can be used to render Low poly models with surface detail almost making them look like the high-poly models but it will render much faster. Very high polygon counts (e.g. 10 million triangles) are processed quite quickly. The engine supports all video and hardware currently on the market. New hardwar support is constantly added as it becomes available.

3.2 Next Generation Real-Time Renderer Provides support for indoor and outdoor environments on the DirectX9 and 10 platforms. Also capable of supporting next-gen consoles such as the Xbox360 and PS3 

Real Time Lighting and Dynamic Soft Shadows: CryEngine 2.5 features natural looking light sources, and creates soft shadows that dynamically respond to natural movements. The shadows and light sources will hopefully add an extra layer of polish to created assets and will increase the immersion of the gameplay experience that is Ascension.



Volumetric, Layer and View Distance Fogging: Used for the creation of clouds, weather effects and fog banks. This functionality will be excellent for the creation of the required dust storms and weather systems inherent to our desert planet of Aurora.



Normal Maps and Parallax Occlusion Maps: Used for adding increased contours to lower poly models or increased depth to

assets. This functionality will provide the art team with increased flexibility in the production of assets, allowing them to produce either stylized or realistic models. 

Screen Space Ambient Occlusion: Provides a real time simulation of ambient light occlusion, this essentially creates a more realistic look by adjusting how light interacts with and is altered by objects. CryEngine 2.5 also does this in a way that does not have hugely increased overheads. For the purposes of our night-time level this feature will add depth and atmosphere to the experience.



Subsurface Scattering: Simulates the diffusion and diffraction of light transmitted through translucent objects, like ice and jade; it can also be used to create natural looking skin or vegetation. As Ascension takes place on an alien world the ability to create life-like yet original models is a great reason for using the engine.



Advanced Shader Technology: CryEngine is renowned for its graphic quality and in turn Shader technology. This will allow for a large amount of flexibility with the art team and the creation of asset to a varying standard and of different styles (not necessarily photorealistic).



Terrain LOD Management Feature: Due to the potential size of some of the levels in Ascension this feature is needed in order to reduce overheads when the player has a large viewing distance.

3.3 Sound and Music -Covered in the Sound Brief.

3.4 Advanced AI System CryEngine 2.5 has a very flexible robust and easily customizable AI system based largely on LUA script and within Sandbox 2.0. This will allow not only the programming department access to A.I alteration but the level designers, making for decreased production and testing overheads. 

LUA Script Driven AI System: Allows complex AI behaviors to be created without requiring new C++ code. This will hopefully provide access to the A.I for certain team members (namely level designers) on a small scale basis. Responsibility ultimately rests with the lead programmer.



Dynamic Path Finding: Path finding can be created and altered in real time. This is a very important feature as it allows adjustments as content is created, ultimately making for a much more believable A.I system to be included in Ascension.



Smart Objects: Smart objects provide easy customizable access to animations for the level

designers, allowing them to intelligently link animation to the correct triggers and in a natural way.

3.5 Other functionality Modular C++ Design The entire Crysis Wars source code is written in modular C++, fully documented and commented, and divided into logical separate DLL's. For the purposes of the project the team has access to the game source code, not the engine source. The game source code is structured in a way that allows code to be used as-is, with modifications being made only when replacing/adding functionality. Ascension will ultimately will be a mix of the existing code base with any new and altered functions added and commented where necessary. Multithreading Support â&#x20AC;&#x201C; For increased performance and overhead leeway CryEngine makes use of multithreading. Performance Analysis Sandbox provides the user with powerful instrumentation features that allow the team, especially level designers and the lead programmer to analyze engine performance in real time. These tools also create detailed memory usage reports and can even provide and run detailed automated walk-throughs of each custom level. This should allow our testing phase to progress smoothly as the team will get consistent test results from build to build. Offline Rendering Creating streaming videos or still images from within the game is made easier by the inclusion of specific console commands which can output a scene at any arbitrary screen resolution and/or aspect ratio, including generating auto stitched panoramic views for use on 360 degree projection video displays. This feature will be incredibly useful for the making of in-game cut scenes and trailers for promotion purposes.

4.0 Console Commands Crysis has over 1,600 Command Variables (cvars for short) which can be altered for testing and functionality purposes. These variables can be changed by either using the game's command console, via a command line, or in .cfg files. Such commands can be particularly useful to the development team during testing and troubleshooting bugs. The following section details descriptions for some of the relevant Crysis cvars that could be useful with the production of Ascension in conjunction with a brief summation of their use for the production team. They have been tested and grouped by function. Commands that have noticeable visual, gameplay or performance tweaks are the focus of the following list. The list itself is far from comprehensive as it would be impractical to cover all 1,600 cVars.

4.1 Important Details: 1. You must set con_restricted=0 to get out of restricted mode before most commands will work in the console; only 12 cvars work when restricted mode is enabled. 2. Some command variables can only be altered at startup - these are marked with (system) at the end of their description. You must insert them into your System.cfg file, or more often, insert them into an original Crysis system file such as one of the difficulty files (e.g. diff_normal.cfg) for them to work. 3. Default values are not provided; they can be different from system to system, and also depending on what settings are. It is suggested that you check the default value first, by typing the command without any alteration variable and hitting enter. 

To see a description of each cVar just enter the command name followed by a space then a question mark (e.g. r_DisplayInfo ?).

4.2 General Gameplay Commands map [mapname]- loads a map located in the default directory for the loaded mod or default Crysis Wars map files. E.g \Program Files\Electronic Arts\Crytek\CrysisWars\Mods\Ascension\Game\Levels Directory. This command will be used by the team extensively. capture_folder [path] – The path where screenshots are kept, can be altered manually, e.g. capture_folder C:\Temp. The default output folder is the \Program Files\Electronic Arts\Crytek\CrysisWars\CaptureOutput directory. This can be set to our default mod directory or possibly Dropbox for ease of use by the team. time_scale [value] – Controls rate of time. A value below 1 slows down time (0 freezes everything), and a value above 1 speeds up time. Can be used for testing purposes, timed quests etc. r_CustomVisions [0,1] - If set to 0, disables custom vision effects, e.g binocular view. Will be useful for troubleshooting vision errors. cl_fov [value] - Determines your Field of View (FOV) in degrees. Higher value=more screen, Lower Value=less screen. Default of 60 degrees, alteration will affect fps rate. Possible use for in-game movie captures. cl_hud [0,1] – 0 is false, 1 is true. If set to false the Heads Up Display (HUD), and suit menu will be removed. Useful for screenshots. cl_hitblur [value] – Blur when hit. Higher values increase the blur effect, 0 disables it. Needs to be evaluated (may not be included in Ascension). cl_hitshake [value] – Screen shake. High values increase the shaking, 0 disables it. Needs to be evaluated (may not be included in Ascension).

4.3 System Information / Diagnostic Commands r_DisplayInfo [0,1,2] – This value only works when set to 1, 0 or 2 disables this display mode. Shows a wide range of information about the current scene; FPS, Triangles in scene (Tris), indicates how complex the scene is, and if the scene is DX9 or DX10 mode. This will be very useful for testing and troubleshooting bugs, although Ascension will most likely not be pushing the engine in terms of scene assets. sys_enable_budgetmonitoring [0,1] – Set to 1 to display a set of sliders showing how close system resources are to their 'budgeted' maximum. Used for testing the impact of adding various resources. ai_DebugDraw [0,1] – Provides a wide range of information regarding each AI (Artificial Intelligence) unit on screen. This can be used when testing AI responsiveness, especially the pathing and response of the boss fight. Note: If you cannot change an ai_ command, even after altering the relevant .cfg file, make sure to set this =1 first (system).

4.4 Cheat Commands- Testing purposes ai_IgnorePlayer [0,1] - If set to 1, this option makes the player effectively invisible to enemy AI. sys_AI [0,1] - If set to 0, disables AI updates, which in effect makes AI unresponsive to anything. ai_ForceStance [-1,0,1,2,3] - Forces all AI to take a particular stance: -1 disables forced stance, 0 = Stand, 1 = Crouch, 2 = Prone, 3 = Relaxed (system). g_godmode [0,1] –Set to 1 to enable 'God' mode. i_noweaponlimit [0,1] – Set to 1 to allow for an unlimited weapon inventory. i_unlimitedammo [0,1] – Set to 1 for unlimited ammo, weapons ammo counters will also not decrease.

For a comprehensive listing of all Crysis cVars visit the website below: Note: There are no descriptions of each console command just the command itself. http://www.wegame.com/guides/crysis-console-commands/

5.0 File Formats The following table lists the file formats and corresponding programs used in the development of Ascension: File Types

File Extensions

CryTek GMBH CryEngine 2 .cry .bak / .pak .cal .cdf .caf

Level File

.dlg

Compressed Files Animation Script File Character Definition File Animation File Scriping File Scripting File Database File Flash File ? Entity File Dialogue File

Autodesk 3D Studio Max 2009

.max .cgf .cga .chr .mtl .caf

Scene File Standard Mesh File Type Animated Mesh File Character File Material File Animation File

Adobe Photoshop CS3

.psd

Photoshop File

Adobe Dreamweaver CS3

.html

Hyper-text Markup Language File

Adobe Flash CS3

.fla .swf

Project File Flash File

Adobe Premier Pro CS3

.prprog

Project File

Autodesk Mudbox

.mud

Project File

Pixologic ZBrush

.ztl

Project File

Microsoft Word 2007

.docx .doc

Word 2007 File Word 1997 - 2003 File

Microsoft Powerpoint 2007

.pptx .ppt

Powerpoint 2007 File Powerpoint 1997 - 2003 File

.xml .lua .cba .gfx .ag .ent

Microsoft Excel 2007

.xlsx .xls

Excel 2007 File Excel 1997 - 2003 File

Microsoft Project 2007

.mmp

Project 2007 File

QuarkXPress 8

.qxp

Project File

Steinberg Cubase 5

.cpr

Project File

Image File Types

.png .jpeg .dds .tif .bmp

Audio File Types

.ogg .mp3 .wav

Video File Types

.avi .wma .mp4

5.1 Coding Areas

5.1 Flowgraph The Flowgraph is a high level coding method incorporated into the Sandbox editor. The existing flowgraph functionality is extremely powerful and allows for a huge array of gameplay mechanics to be created, including many that have no original functionality in Crysis (e.g NPC store). Flowgraph complexity can range from simple mechanic functionality (see figure 1) to very complex and powerful flowgraphs (see figure 2). Examples: Teleporter creation, Quests and various gameplay mechanics

1 Example of a simple camera positioning flowgraph.

2 Complex inventory system flowgraph.

5.2 Lua Lua script is a lightweight functional programming language used by Crysis Wars for game logic and methods. Examples: Player modifications, gametype and weapon functionality to name a few. The following is an example of one section of a modified player.lua file for use with Ascension: -------------------------------------------------------------------------Crytek Source File. -Copyright (C), Crytek Studios, 2001-2004. -------------------------------------------------------------------------$Id$ -$DateTime$ -Description: GameRules implementation for Death Match --------------------------------------------------------------------------- History: -- - 22/ 9/2004 16:20 : Created by Mathieu Pinard -- - 04/10/2004 10:43 : Modified by Craig Tiller -- - 07/10/2004 16:02 : Modified by Marcio Martins -11/12/2009 16:02 : Modified by Steven Matthews (CVG Salford University) ------------------------------------------------------------------------SinglePlayer = { DamagePlayerToAI = { head = 50.0, torso = 1.2, arm_left = 0.65, arm_right = 0.65, hand_left = 0.3, hand_right= 0.3, leg_left = 0.65, leg_right = 0.65, foot_left = 0.3, foot_right= 0.3, assist_min =0.8, }, DamagePlayerToPlayer= { head torso arm_left arm_right hand_left hand_right= leg_left leg_right foot_left foot_right= assist_min

= 20.0, = 1.4, = 0.65, = 0.65, = 0.3, 0.3, = 0.65, = 0.65, = 0.3, 0.3, =0.8,

}, DamageAIToPlayer= { head torso arm_left arm_right hand_left hand_right= leg_left leg_right foot_left foot_right= assist_min

= 1.0, = 1.0, = 0.65, = 0.65, = 0.3, 0.3, = 0.65, = 0.65, = 0.3, 0.3, =0.8,

}, DamageAIToAI= { head torso arm_left arm_right hand_left hand_right= leg_left leg_right foot_left foot_right= assist_min

= 20.0, = 1.0, = 0.65, = 0.65, = 0.3, 0.3, = 0.65, = 0.65, = 0.3, 0.3, =0.8,

}, tempVec = {x=0,y=0,z=0}, playerDeathLocations = {}, lastSaveName = "", lastSaveDeathCount = 0, hudWhite = { x=1, y=1, z=1}, Client = {}, Server = {}, -- this table is used to track the available entities where we can spawn theâ&#x20AC;&#x201D;player spawns = {}, } if (not g_dmgMult) then g_dmgMult = 1.0; end if (not g_barbWireMaterial) then g_barbWireMaterial = System.GetSurfaceTypeIdByName("mat_metal_barbwire"); end --------------------------------------------------------------------------------------------------function SinglePlayer:IsMultiplayer() return false; end --------------------------------------------------------------------------------------------------function SinglePlayer:OnReset(toGame) AIReset();

End

File Structure: Lua script are packaged in .pak files and can be extracted for use and modification/research. Pak files: Animations.pak, GameData.pak, Music.Pak,Objects.pak,ShaderCache.pak, Shaders.pak, Sounds.pak, Texture.pak, Zpatch1.pak

5.3 Flash Flash is a high/mid level code method used for the implementation of the HUD within CryEngine. Examples: HUD assets (Flash movies) File Structure: Flash code is attached to the relevant flash movies and can be implemented in classes.

5.4 C++ C++ is a low level coding base that will be used for the modification of core game mechanics and engine functionality. The C++ source code has been provided in the Crysis Wars SDK and has been combined with a release of the Flowgraph plugin system. Flowgraph plugin system: Code base created by the modding community and providing new flowgraph nodes and functionality useful for the production of Ascension. Examples: Modifications to the camera or other core mechanics such as menus and the Nanosuit. File Structure: Not a comprehensive list as there are hundreds of .cpp files and headers, it is however the general file structure. 

Solution ‘Ascension’  CryEngine Common  CryEngine Interfaces  CryCommon  Plugins  Entity screen  Flash  Ascension  Actor Files o Aliens o Grab o player  Expansion o weapons



   



      

  

FGPlugin o Extended o Modules Flash Game Files o Environments GameRules HUD o Main o Tweaks Item Files o Items o Weapon Files LCD o Pages Menus Nodes Resources Startup Files Utility Vehicle Files o Action Files o Damage Files o Movement Files

DLLMain.cpp StdAfx.cpp TypeInfo.cpp

6.0 Programming Pipeline

7.0 Technical Asset Overview Programming Tasks

Steven Matthews

Category

Task

Singleplayer Metagame Single Player Menu's Save/Load Functionality Singleplayer Level Load Inventory

Combination System Usable Inventory Tech Pickup Health Pickup

Custom Player Character Custom Model Remove Nanosuit Function Remove Health Regen Remove Energy Regen Create Shield Mechanic Transporter System

Transport Nodes Control System

3rd Person Camera

Viewpoint Remove First Person View No Clipping; Zoom Function Crosshair

Subject to change Asset Requirements

Coding Areas

Additional Notes

Custom Menu Screens

Flash;C++ C++ C++

FlashMenu.cpp

Item Model Item Model

Flowgraph C++; Build into Crysis Wars Flowgraph;Lua Flowgraph;Lua

Using placeholder asset Using placeholder asset

Player Model

Lua

Using placeholder asset Nanosuit.cpp Nanosuit.cpp

Need tech/health assets

C++ C++ Flowgraph

SFX Transport Node

Flowgraph Flowgraph C++ C++ C++ C++

Puzzles

Puzzle 1 Puzzle 2 Puzzle 3 Puzzle 4 Puzzle 5 Puzzle 6

All puzzle assets All puzzle assets All puzzle assets All puzzle assets All puzzle assets All puzzle assets

Flowgraph Flowgraph Flowgraph Flowgraph Flowgraph Flowgraph

Traps

Proximity Trap DOT Trap

SFX; Trap Model SFX; Trap Model

Flowgraph Flowgraph

HUD

Inventory Mini map (Compass) Health (Compass) Quest popups Conversation Boxes Custom Menus

Inventory Screen Map Health Metre Quest Box Dialogue Box Other Menus

Flash; C++ Flash; C++ Flash; C++ Flash; C++ Flash; C++ Flash; C++

Quests

Quest goals Quest NPC's Progress Save State Quest Log/Journal

Weapons

Weapon Combat Ranged Weapon Combat Melee Weapon Select Machete Spear Blunder Buster Bow and Arrow

Journal (Flash)

Flowgraph C++;Lua C++;Lua C++;Flash

Weapon Model Weapon Model Weapon Model Weapon Model

Lua; C++ Lua; C++ Lua; C++;Flash Lua; C++ Lua; C++ Lua; C++ Lua; C++

NPC Models

Dialogue

Audio Drops

Audio Item Model

Lua

A.I

NPC A.I Creature 1 Creature 2 Creature 3 Creature 4 Boss Fight Hint System

Creature Model Creature Model Creature Model Creature Model Boss Model

Lua; C++ Lua; C++ Lua; C++ Lua; C++ Lua; C++ Lua; C++

Amulet

Swaps back to 1st person GOC code to hopefully solve this GOC code to hopefully solve this Platform Puzzle Switch Combination Puzzle

8.0 Development Plan 8.1 Development Specifications 1. Singleplayer Metagame

2. Inventory

3. Custom Player Character

Single Player Menu's-Flash HUD assets Save/Load Functionality- Need to create Singleplayer Level Load-Add in code Combination System-Inventory in flowgraph Usable Inventory-Inventory HUD Tech Pickup- For shield regen Health Pickup-For health regen

Custom Model-Replace Crysis model Remove Nanosuit Function-Nanosuit.cpp Remove Health Regen Remove Energy Regen Create Shield Mechanic-Amulet.cpp file

4. Transporter System

Transport Nodes-Flowgraph nodes Control System-Art asset needed

5. 3rd Person Camera

Viewpoint- OTS camera Remove First Person View-Disable No Clipping; Zoom Function-Zooms in instead of clips Crosshair-Enable in 3rd person

6. Puzzles

Puzzle 1 Puzzle 2 Puzzle 3 Puzzle 4 Puzzle 5 Puzzle 6

7. Traps

Proximity Trap-Use Triggers in flowgraph DOT Trap-Use triggers and Damage: Actor Node

8. HUD

Inventory-Flash movie assets Mini map (Compass)-Art asset needed Health (Compass)-Removed

Quest popups-Create flash node Conversation Boxes-Create flash node Custom Menus- Easily done in AS3 and Flash CS 9. Quests

10. Weapons

Quest goals- Flowgraph, need objectives also Quest NPC's- Need a method to â&#x20AC;&#x2DC;saveâ&#x20AC;&#x2122; quest progress Progress Save State Quest Log/Journal Weapon Combat Ranged- Bow and Arrow, Blunderbuss Weapon Combat Melee- Spear Weapon Select Machete- Use fists damage class from Crysis Spear Blunder Buster Bow and Arrow

11. Dialogue

Audio Drops- Use audio triggers already in Crysis

12. A.I

NPC A.I Creature 1 Creature 2 Creature 3 Creature 4 Boss Fight- Difficult to code in lua

13. Amulet

Hint System

8.2 Singleplayer Metagame Problem: The functionality for savegames, the singleplayer A.I and the singleplayer menus are disabled by default in Crysis Wars as the game is multiplayer in nature. This functionality will have to be re-enabled for Ascension to be a viable project. Solution 1: Creation and coding of flash movies (HUD assets). Write the C++ and Lua Script code in order to create a functional A.I. This method would be time intensive and possibly very difficult yet allow for a large amount of customization. Modify the flash menu functions to add custom HUD assets. Solution 2: Creation of flash movies (HUD assets). Search through the existing Crysis C++ source code to re-enable the default Crysis A.I. Modify the flash menu functions to add custom HUD assets.

Final Implementation: Due to the inherent robustness of the Crysis A.I and time constraints the A.I will be re-enabled instead of re-created. Flash menus will be modified through the flashmenu.cpp file in the base C++ source code project. Code will have to be added to the flashmenuobject.cpp file in order for the game to execute the correct gametype by pointing to the modified gametype that includes a functional A.I. The cVar ai_systemUpdate is by default disabled, this variable will need to be renabled for the system to process the AI. This can be done by creating a function in the flashmenusingleplayer.cpp file, re-enabling the A.I for this specific gametype. Any A.I logic can now be created solely through the use of Lua script and the existing A.I functions. The A.I scripts are located in the gamedata.pak file and are categorized logically to create ease of use for any added assets. CryEngine divides the A.I functionality into behaviours and personalities.

8.3 Inventory Problem: Crysis has a player inventory, the main coding will be in the creation of cursor context sensitive system and transmitting the variables back and forth from C++ and flash. Solution 1: Extensive coding will be required in the flash menus and cursor classes of the source code. Extensive custom flash menus and assets for each inventory item. Solution 2: Use flowgraphs to create an inventory system that will be easier to implement yet much less robust in its functionality. Final Implementation: Due to the fact that Ascension does not use a huge amount of items, a point and click inventory is not required. However due to the nature of the game, using a flowgraph would not really be sufficient by itself. Crysis Wars itself already has an internal inventory system built into the C++ source code and all the required features for Ascension can be implemented through Lua script, namely in the player.lua file. The default player inventory can be scripted in this manner, along with items gained/lost from specific gamerules and major events dealt with in the lua code. For standard quests, ammo and many other drops the flowgraph in sandbox will be used to add/remove items from the playerâ&#x20AC;&#x2122;s inventory. It will however be necessary to pass variables and arrays back and forth from flash to both C++ and Lua when presenting the player inventory on screen. It is necessary to do this in order to correctly display the items in a playerâ&#x20AC;&#x2122;s inventory. The play flash movie node will be utilized in the flowgraph to open the inventory initially. The inventory itself will be a scrolling flash movie that contains reference images detailing what items are being carried and how many of each.

The following is Sample code that has been researched and tested that will be used for Communicating with Flash via Lua script and C++;

Sending variables to Flash: for (int i = 0; i<1000; ++i) { // MyFlashLoadedFile is type of CGameFlashAnimation MyFlashLoadedFile->SetVariable("iCounter", i); MyFlashLoadedFile->Invoke("TextfieldOut"); } function TextfieldOut():Void { myTextfield.text = iCounter; // myTextfield is a simple dynamic text field

The variable "iCounter" is set to a specific value in Flash. If the variable does not exist it will be created.

Function declaration: bool CFlashAnimation::SetVariable( const char* pPathToVar, const SFlashVarValue& value // value of the variable );

Sending arrays to flash: const char* arMyArray[] = { "testString1", "testString2", "testString3" }; // MyFlashLoadedFile is type of CGameFlashAnimation MyFlashLoadedFile->GetFlashPlayer()>SetVariableArray(FVAT_ConstStrPtr, "arTestArray", 0, &arMyArray[0], 3); MyFlashLoadedFile->Invoke("TextfieldOut");

Sending arrays to Lua: function TextfieldOut():Void { for (var index in arTestArray) { // myTextfield is a simple dynamic text field myTextfield.text += "arTestArray[" + index + "] = " + arTestArray[index] + "\n" } }

Function declaration: bool IFlashPlayer::SetVariableArray( EFlashVariableArrayType type, const char* pPathToVar, unsigned int index,

const void* pData, unsigned int count ) const = 0; // // // // //

type of the array name of the array in Flash the target index of the array the source array the length (how many elements will copy)

8.4 Custom Player Character Problem: For the purposes of Ascension the standard Crysis model will need to be replaced with a custom player character and existing Nanosuit functionality needs to be removed from the game. Solution 1: Alter the nanosuit.cpp class and disable various functions. Extend the player.lua script change the character variables and add functionality for gameplay mechanics. Replace the .cfg art asset file in the player.lua script (replaces the player model) Solution 2: Replace the nanosuit.cpp with an empty class and create a new player.lua script. Replace the .cfg art asset file in the player.lua script (replaces the player model) Final Implementation: Due to the interdependency of the nanosuit.cpp file it is prudent to alter various variable and functions within the class in order to quickly disable nanosuit functionality. In order to correctly do this, the flash calls will be commented out, preventing the player from accessing the various nanosuit modes. The suit itself will therefore be set to the default functionality. For the creation of the custom player file, the player.lua script will be heavily modified to reflect the various functions of the main character in Ascension. GameParams, Ammo Capacity and Properties are structs that contain many of the variables that will need to be changed for the purposes of Ascension. The following variables need to point to the relevant custom art assets, in this case the .cdf files present in the mod folder.

fileModel = "Objects/Characters/Hippo/Hippo.cdf", clientFileModel = "Objects/Characters/Hippo/Hippo.cdf", --fileModel ="Objects/Characters/Hippo/Hippo.cdf", fpItemHandsModel ="Objects/Characters/Hippo/Hippo.cdf", --fpItemHandsModel = "Objects/Characters/Hippo/Hippo.cdf", objFrozenModel="Objects/Characters/Hippo/Hippo.cdf",

This variable on line 391 can be set to 0 in order to remove certain nanosuit functions. self.actor:ActivateNanoSuit(1);

The following variables need to point to the correct directory for the assets in order for the player model to display. Upon creation these will automatically point to the correct location, however should the directories change these variables will have to be altered. .cdf BoneName="" Binding="mods/Ascension/game/objects/characters/hippo/hippo.chr" .mtl <Texture Map="Diffuse" File="mods/Ascension/Game/Objects/Characters/Hippo/H1.dds">

8.5 Transporter System Problem: A transporter system needs to be created, allowing for instantaneous travel around the map. Solution 1: Use flowgraph nodes to teleport the player from point A to point B. The Sandbox editor has specific nodes to reference a playerâ&#x20AC;&#x2122;s location in the game world and a node to move the player to a specific location. In order for this to work, a reference object will be placed at the destination, the 3D co-ordinates will then be entered into the flowgraph and the teleport will activate based on a variety of triggers. Solution 2: As this functionality is relatively easy to implement it would be unwise and time consuming to look at creating a teleporter outside of the flowgraph. Final Implementation: After conducting research using both Lua and C++ to build the mechanic directly into the mod, the flowgraph method is the best way with the least overhead on the engine. The following flowgraph, displays the specific nodes that will be used for the creation of the base teleport graph. Most important are the GetPos node (finds the 3d location of the attached actor) and Beam Entity node (moves to actor to the inputted location). More advanced and complex teleporter networks will be based off of this node structure.

8.6 3rd Person Camera Problem: An over the shoulder 3rd person camera needs to be implemented with clipping prevention, crosshair enabled and zoom feature. Solution 1 : Due to the difficult nature of this task I will look at re-enabling the Gears of Crysis Camera and modifying it. The variables are in GameCVars.cpp. The functions will need to be created and modified in the playerview.cpp file. Solution 2: Create a fully distinct and original camera system, extending from the base view.cpp class, coding all functionality and requirements. Final Implementation: After researching the code and searching through the existing functions it is prudent and time efficient to use some of the Gears of Crysis Logic combined with some modifications. In addition it is advantageous to create a new flowgraph node for use with the sandbox editor. The requirements therefore are the creation of a brand new node class, extended from the G2FlowBaseNode.cpp,base class file. CryEngine allows for a simple and efficient way to create new nodes with various functionality. It is important to remember to register the flowgraph node so it displays correctly in the editor. This is done with the following Code: REGISTER_FLOW_NODE("Crysis:GOC", CFlowGOCNode);

The Third Person View has to be enabled by default, the following function within the Crysis Code toggles the Third Person camera view. For the purposes of the camera this function will need to be altered to prevent the camera from switching back to default 1st person. pClientActor->ToggleThirdPerson(); The following code will also be very important and will be placed within a configuration function (void) and a static construct InputPortConfig<bool>("Enable", false, _HELP("Enable/Disable GOC")), Enables the Camera These three values do not need to be adjusted in the code as they will be sent directly to the engine via the actual flowgraph node, this will allow for easy tweaking of the camera and will be useful for the creation of cutscenes and in-game video. InputPortConfig<float>("Target_X", 0.5f, _HELP("XOffset")), InputPortConfig<float>("Target_Y", -2.5f, _HELP("YOffset")), InputPortConfig<float>("Target_Z", 0.2f, _HELP("ZOffset")), The crosshair needs to be enabled by default in 3rd person. InputPortConfig<int>("TPCrosshair", 1, _HELP("ThirdPerson Crosshair")),

8.7 Puzzles Problem: Various logic and physics puzzles will need to be created in conjunction with the level designers. At present the team intends to create a minimum of 8 separate and distinct puzzles. Solution 1: The vast majority of these puzzles can be done in the flowgraph with the existing functionality of the various nodes that are readily available. Solution 2: Create some puzzles in the flowgraph and code some functionality in C++ and Lua for more complex and original puzzles. Final Implementation: A huge amount of customistation for gameplay mechanics can be conducted through the flowgraph. For this reason and also to allow access to the level designers the majority of the puzzles will be created in the flowgraph. Any additional functionality will be coded as a new node in C++ using the G2FlowBaseNode.cpp as a class base. The following flowgraph images represent some quick mockups and tests of the functionality available to the team via sandbox, done when evaluating the method for implementing the puzzles.

Figure 1.1: Simple switch flowgraph puzzle; Unlocks a door when switches 1 and 3 are flipped.

Figure 1.2: More complicated proximity trigger flowgraph; triggers a condition based on the correct sequence of â&#x20AC;&#x2DC;pressure platesâ&#x20AC;&#x2122; that are pressed.

8.8 Traps Problem: Dangerous traps need to respond to the playerâ&#x20AC;&#x2122;s presence. These traps will have variable damage types and effects. Solution 1: Achieved using conditions and logic in the flowgraph editor. Solution 2: Custom traps will be created in Lua script as individual weapons with the relevant art assets. Final Implementation: Varied. The complexity and type of traps will be dictated by time constraints and feasibility.

Figure 1.1: Trap flowgraph. It is important to make use of triggers and the Game:Damage Actor node.

8.9 HUD Problem: A completely custom HUD needs to be implemented. This will be quite time intensive due to all the flash assets that need to be created. Final Implementation: A combination of C++ coding, Flash coding and flowgraph creation will be needed to get all the HUD assets functioning.

In order to successfully implement this functionality sending variables back and forth between Flash and C++ is necessary. The coding will be similar to that done for the inventory system, specific code examples can thus be found under the inventory heading here. Creation of a flowgraph node for the loading of flash movies in game will be needed for ease of use. This will be coded in C++ and will allow the level designers to have a large amount of freedom when using HUD assets. Header files that will most likely be needed: #include #include #include #include #include #include

"stdafx.h" "Nodes/G2FlowBaseNode.h" "ExtendedManager.h" "../Common/IGameFlashAnimation.h" "../Common/IGameFlashAnimationFactory.h" "IFlashPlayer.h"

After researching the requirements for the flowgraph node on CryMod and asking for help on the forums, the following code snippet has been determined to be essential. This loads the relevant flash movie from the mod directory. Obviously the actual .cpp file will be much more extensive string sFile = GetPortString(pActInfo, EIP_File); if (!sFile.empty()) { m_pFlashAnim = g_pResources->pGameFlashAnimationFactory>CreateGameFlashAnimation(); CRY_ASSERT(m_pFlashAnim); const bool bLoaded = (m_pFlashAnim && m_pFlashAnim>Load((string("Libs\\UI\\")+sFile).c_str(), eFD_Center, eFAF_ManualRender)); m_pFlashAnim->SetFSCommandHandler(this); ActivateOutput(pActInfo, EOP_Loaded, bLoaded); if (bLoaded) { m_pFlashAnim>RepositionDock(static_cast<EFlashDock>(1<<Ge tPortInt(pActInfo, EIP_Docking))); m_pFlashAnim>SetVisible(GetPortBool(pActInfo, EIP_Visible)); } }

8.10 Quests Problem: A new quest gametype will need to be created based on the singleplayer mode.

Solution 1: Create a singleplayerquest lua script file with all the necessary requirements, player damage and stats, objective (quest) goals and so forth. Solution 2: Solely create quests in the flowgraph editor. Final Implementation: Quest objectives will be created in the flowgraph, when conditions are met they will be detailed in a custom .lua script file containing all of the gametype code, called Ascension.lua.

8.11 Weapons Problem: Four distinct weapon types are needed for the game. They will be based off of existing melee and ranged functionality in Crysis and modded to suit our games needs. Solution 1: Create custom Lua scripts based off of Crysis weapon scripts. Modify the various values and adjust them to match the gameplay mechanics. Solution 2: Modify values of existing Crysis weapons to match the functionality of the weapon requirements of Crysis. Final Implementation: Each weapon in Crysis is detailed in an .xml file and is based off of the item.lua script file that is the default base .lua file for every item in-game. For the purposes of the weapons required for Ascension it is the values and parameters in these .xml files that need to be changed to suit the needs of each individual weapon requirement. Spear-Derived from a melee class 2 separate upgrade Blunderbuss-Derived from a ranged class 2 separate upgrades Bow and Arrow-Derived from a ranged class 2 separate upgrades Sword- Derived from a melee class 1 separate upgrade The following code example details some of the important functionality that can be modified. Parameters: Details some of the standard mechanics of the weapons as follows. <param <param <param <param <param <param <param

name="giveable" value="1" /> name="selectable" value="1" /> name="droppable" value="0" /> name="pose" value="nw" /> name="mass" value="1" /> name="melee_attack_firemode" value="melee" /> name="raiseable" value="true" />

Firemode: Allows the various different types of fire methods to be detailed, including things such as physics impulse, fire duration, damage and so forth. This will be useful for the various upgrades that are available <firemode name="punch" type="Melee"> <melee> <param name="helper" value="Collision" /> <param name="damage" value="10" /> <param name="impulse" value="180" /> <param name="delay" value="0.15" /> <param name="duration" value="0.055" /> </melee> <action name="jump_start"> <animation target="firstperson" name="jump_start_right_01" camera_helper="camera_helper"/> </action>

Custom ammo pickups will also have to be created for each weapon and are also done in an xml file.

8.12 A.I Problem: The A.I in Crysis is very intelligent and can be utilized by our custom creatures (four of them) in order to effectively engage and hunt the player. Solution 1: Most of the A.I responsiveness is completed in the game editor; Lua scripting is required for getting the custom entities functioning. Solution 2: Code an extensive and original boss fight for the end of the game including all functionality from solution 1. Final Implementation: Crysis has a very robust and effective A.I that can be implemented through the sandbox editor http://wiki.crymod.com/index.php/Sandbox_SimpleAI- This website has a step by step guide for setting up many of the A.I behaviours in Ascension. Due to the inherent difficulty of coding A.I for a game of this nature, I will be focusing any original code and gameplay mechanics on the boss fight from the Aiur temple level. For that level a custom Lua script file will be needed along with a custom entity. The script file will define the creatures parameters and the entity will define it as a custom asset. How the entity is setup in the level is dictated by the available parameters defined in the lua and C++ files. The difficulty with the boss fight will be effectively coding the progression of the fight, as specific conditions will have to be met before the fight advances (e.g attack the legs first). This should be able to be completed as Crysis already detects what areas of the body the A.I takes damage. It will then be a case of using the flowgraph and lua logic to make a convincing boss encounter.

8.13 Amulet Problem: An Amulet device is needed for the player character that has the power of a protective shield and acts as communication device. Solution 1: By altering the exisiting nanosuit functionality we can then create functions to adjust the rate of recharge for health and energy. In the gametype we are creating damage calculations that will need to be present to accurately represent the amount of damage a player receives compared to the energy level present in the amulet. Solution 2: Create an amulet.cpp file similar in function to the nanosuit yet original in its execution. Final Implementation: The removal of nanosuit functionality needs to be done in the nanosuit.cpp class. An additional class called amulet.cpp will be created to deal with all of the values and changes present due to the amulet. This class will have a function determining the amount of damage the player receives based on the following formulae: Damage Taken=(Damage Dealt-(Damage Dealt/100) * (Shield Value *.40)) The amulet class will need to make us of external header files such as: #include #include #include #include #include #include #include #include #include #include #include #include

"StdAfx.h" "Game.h" "GameCVars.h" "Player.h" "GameUtils.h" "HUD/HUD.h" "GameRules.h" "NetInputChainDebug.h" "BulletTime.h" "SoundMoods.h" "WeaponSystem.h" "OffHand.h"

The following functions will need to be present in the amulet.cpp class: void CAmulet::Reset(CPlayer *owner) -Resets variables and values of the Amulet void CNAmulet::SetParams(SmartScriptTable &rTable,bool resetFirst) -Defines the parameters of the amulet such as energy void CAmulet::Update(float frameTime) -Updates the values of the amulet every frame

void CAmulet::SetSuitEnergy(float value, bool playerInitiated /* = false */) -This function will need to be called when setting the suit energy for a variety of reasons. void CAmulet::Hit(int damage) -Damage Calculations will go here

9.0 Milestones 9.1 GDD and TDD complete Both documents are complete. The TDD contains coding practices and at least a general outline of how to implement the gameplay elements described in the GDD in addition to coding practices, tools, and risk analysis. Source control and bug tracking methods (Notepad++, Error Logging) have been proposed.

9.2 Asset List and Development Plan Complete An asset list with all assets and completion dates has been created. Source control and bug tracking solutions have been implemented.

9.3 Prototype The code for essential Game mechanics is complete and the main character has been added in some form. The gametype has been implemented, but may have place-holder art or animation.

9.4 Alpha Major bugs in Ascension are being tested and resolver. The behavior of each individual mechanic has been coded and any relevant static meshes and animations have been implemented and added to the game. The GUI and HUD have been implemented, including all art assets. The mod is installable / un-installable on test platforms.

9.5 Beta All assets are now included. Bug testing is proceeding apace as all bugs need to be resolved during this phase.

9.6 Gold Final gameplay balancing has taken place. The game is totally compliant with the TDD and GDD. The TDD and GDD have been updated if necessary. All bugs have been fixed. Mastered versions of the game have been burned to disk.

10.0 Software Architecture 10.1 Directory Structure All art, level, and code assets will be placed under one subdirectory called Ascension that lies in the ‘Mod’ subdirectory of the CrysisWars installation. Assets will not be located across the default directories. This method keeps data organized and simplifies installation and un-installation. The list below shows the directory structure: 

‘Local installation path’  Crysis Wars ->  Mods ->  Our Mod ->  Bin 32  Code (C++ Source)  Game  Animations – All mod animations  Entities – Game Objects  Fonts – custom fonts  Levels – map files  Libs - XML files  Localized- Game files (Core)  Materials- Art Assets  Music- Music Files  Objects- Art Assets  Prefabs- Art Assets  Scripts- Game Logic  Shaders- Art Assets  Sounds- SFX  Textures- Art Assets

10.2 Build Process The mod will built using Visual Studio Professional 2005, Notepad ++, and the Sandbox Editor. The sandbox editor was created by Crytek and packaged with Crysis Wars SDK, Visual Studio is the premier program for programming in C++ (the source code base of Crysis). This program will automate the process of compiling the source code and generating the .dll files. Notepad ++ will be used for scripting in Lua with the compiler included with the SDK used for bug testing.

11.0 Coding Standards 1. All of the Lua Script classes developed by the software team will start with ‘as’. For example, asSpear.lua will be used. 2. Flowgraphs will be structured in a logical manner and should not get too large or unwieldy if possible. Should a flowgraph become complex it will be broken into distinct groupings/sections. 3. Correct formatting will be maintained by all parties across all code bases. 4. The master versions of the source code will be in the domain of the lead programmer. Any changes done without prior consultation with the programmer may not be added as they may conflict with existing code. This mainly extends to the C++ and Flash code bases as Lua is a modular drag and drop design that can easily be reverted to default settings. 5. Flowgraph functionality is in the domain of the lead programmer then level designers. Any issues with the flowgraphs should first be taken to the level designers then to the lead programmer. 6. Proper indentation will be used for braces. Beginning and ending braces will be placed on their own lines. Indents will be standard tab size within the editor. 7. Variable names will have their second word letters capitalized like ‘ammoPickup’. 8. Each alteration to the Cryengine 2.5 source code will be commented with /* SM */ before and after the alterations. This will allow anyone to quickly and easily use the search function to locate any changes. 9. A general effort will be made to keep the code as readable as possible using helpful comments.