Adding the Framework to an Existing Project: Unity Bootcamp.

The final part of my dissertation was to show how easy it is to integrate the Survival Framework into a new or existing project.  I choose an existing project from the Unity Store, called Bootcamp.  The Bootcamp project was created by Unity to showcase and outdoor environment with new lighting functions; I thought it would be apt to add my framework to this.

Integration was fairly easy and took 5 minutes.  I only needed to make a couple of changes, first to create and Input for Sprinting and second to identify where the movement speeds were contained in the Bootcamp scripts.

First, I imported my package to the Bootcamp project.

(Click the image for a larger version)

Next, I located the Survival Prefab folder which imported from the package and dragged the _Environment prefab into the Scene, then set a weather preset; in this instance Clear (Cold).

(Click the image for a larger version)

As we can see from the following image, upon pressing play we have the Environment Control Script working as it should, by seeing the Debug Information on the upper-right hand side of the screen.

(Click the image for a larger version)

Once this feature had been identified as working, I went on to integrate the Player Control Script; turning on the Debug Information and adding the Input identifier I'd created earlier from Sprinting.

(Click the image for a larger version)

Now that everything has been set up in the editor, all that was left to do was to identify the variables for movement speeds in the SoldierController script, and modify them using our SlowMovement() function.

(Click the image for a larger version)

(Click the image for a larger version)

The framework has now been set-up and successfully applied to an existing project with no more than 5 minutes of work. All that is left to do is test functionality, you can try yourself by clicking the link after the image.

(Click the image for a larger version)

Try the Web build here:  http://goo.gl/OAjfic

The build size is 50mb, loading times will vary depending on your connection speed.

Functionality of Player and Environment Scripts complete.

I have now completed all scripts for my artefact, the Environment Control Script has a Debug Output much like that of the Player Control Script and can be seen below.

(Click the image for a larger version)

I will be posting links to Web Builds for the Final Artefact in the next few posts; one of which will be the package applied to an existing Unity project; which is not of my own making. 

Let's Talk: Weather Zones

This was mentioned in earlier posts, but let's do a re-cap. A weather zone, within the development of this artefact, is an area of game-space that can have a different weather preset than that of the one created globally; by the Environment Control Script.  When a player enters the area, which is a trigger, the script saves information such as the current weather preset and/or custom values set by the end-user.  It then alters them to those created for within this zone.  When a player leaves the zone, the script sends the previously saved information back to the Environment Control Script, thus restoring the normal weather settings.  I have created a Prefabricated Object from this, which is essentially a drag & drop object.

The Inspector View for this script is simple and did not require a custom Inspector View, as you can see below.

(Click the image for a larger version)

The script for this object can be seen below, along with the translated version to C#; in that order.

Translation Completed.

As mentioned in earlier posts, I have also completed translation of all scripts to C#.  There are minor differences, such as variable declarations and function layouts.

In order of appearance:

- PlayerControl.cs

- PlayerControlEditor.cs

- EnvironmentControl.cs

- EnvironmentControlEditor.cs

Environment Control Script - Editor & Inpector with Inspector View

The environment control script has now been finalized in Javascript.  A much simpler set of controls than the other script, but can still be quite powerful as it defines the global environment which effects the player physically.

I have created the script around some simple helper functions, so the end-user can set weather conditions via code from anywhere they wish during runtime.  They will also be used by the 'WeatherZone' prefab, which as described early is an area in which the environment variables can be different from those set globally, and override the global variables accordingly.

For now, here are the final scripts for the Environment Control; starting with the Inspector viewpoint.

(Click images for larger versions)

As you can see, the end-user can select from a handful of weather presets or create their own.  Now for the Environment Control Script and Inspector Scripts accordingly.

I have finished the translations for all scripts aswell, I shall be displaying those in the next post.

A Minor Deviation.

The development of this framework has been lengthy and time-consuming; as such I hadn't allocated myself enough time to gain user-feedback as I had originally intended, and will not be able to before the artefact has been submitted.  I have discussed this with Chris Janes.

On a much brighter note, development is coming to an end. I have learned a lot, and will reflect upon it in the coming week with my final posts, including how I plan to use my new-found knowledge in the future.

Player Control Script - Editor & Inspector with Inspector View

The player control script has now been finalized in Javascript.  I have avoided giving the developer finer control over the Hypothermia and Hyperthermia features due to their heavy link to the Environment Control Script.  I will be including prefabricated trigger objects that will work with the Environment Control Script to allow for multiple "Regions" of weather effects.  These triggers will effectively switch between weather presets on the Environment Control Script, and affect the player accordingly.

For now, here are the final scripts for the Player Control; starting with the Inspector viewpoint.

(Click images for larger versions)

As you can see, I have allowed a large amount of customization; in fact, nearly every variable related to the physiological effects can be altered by the end-user. Now for the Player Control Script and Inspector Scripts accordingly.

I will be posting the scripts for the Weather Control in the next few days.  It will also have a custom inpector, allowing the end-user to change variables in various presets.  I will then finalize the translation to C#.

Functionality of Player script complete.

I have now completed the script for the Player, where all of the physiological functionality is calculated.  It is currently represented as a blank screen with a Debug output showing real-time function.

(Please click the image for a larger version)

Movement is closely monitored by getting the float value of the Horizontal and Vertical axes, this was a decision to ensure that the developer wouldn't have to define their control scheme within this script.

Below is a link to a web build showing the above in action, use WASD or Arrow Keys to indicate movement and hold Left Shift whist moving to indicate Sprinting.

Web Build:  http://goo.gl/bSorfX

Provisional completion of Core & Extended "Player" Features.

As the title describes, I have provisionally completed the Core and Extended features for the "Player" portion of the framework.  The coding for weather and environment is under-way.  I will be doing some extensive testing over the next few days, as-well-as completing the UI/Inspector component that the end-user will be using to customize the scripts functionalities.

The results will be posted after I've thoroughly tested primary functionality.

Feature-ception: Features within Features.

In this post, I'll be showing my current progress and describing the headaches/issues I have faced with the features.

Currently the framework simulates Fatigue, Dehydration and Starvation as working features; and at an advanced time scale.  The player can become fully Dehydrated, for example, after 100 minutes.  I have also altered the Interface that the developer will see, as can be seen below.  I'm adjusting the location of certain variables and organizing them into a more efficient manner.  Rather than having to ask the developer to define a script for movement and then search it for a speed variable to check if a player is running or not, I have decided to simply ask them for an identifier for their sprint/run button; this way I can check if it is being pressed or not and adjust values accordingly.

I have also created additional menus, where the developer can fine-tune the features of the framework; in this case Fatigue.

(Please click the image for a larger version)

The current project code can be found below; playerControl.js and playerControlEditor.js

Good job, ol' chap!

Short and sweet, my presentation was a success; as nervous as I was and having to pause to catch my breath, I am happy with my work so far and so are the tutors.

"This promises to be a very good submission, you have a clear understanding of what you wish to achieve and you are making solid progress. The blogs are regular as I have commented below. Overall this is good work."

"After a little probing, I was able to garner a clear understanding of your intentions, and this project appears to be on track and promises to result in a highly relevant artefact."

Here's to the future of my dissertation and my career.

Presentation Prep. Part 2

A brief post regarding the functionality of Fatigue, Dehydration and Starvation.  What follows is a flow chart the describes how the aforementioned functions will work, as defined by the end-user.  The goal is not to create an inventory system that monitors the amount of food or drink available, for example, but to create a level of thirst or hunger that the end user can use to define when parent functions come into effect.  The end-user will be able to define their own inventory systems and branch out from this original code, as was my intention at the start of the project.

(Please click the image for a larger version)

As you can see from the flow chart, functionality of the three player-invoked features comes from variable customization, and no feature will be invoked unless checked against the variables set by the end-user.  Creating, eventually, what I'd originally set out to do; create a highly customizable code-framework.

This flow chart, as well as the other involving Hypothermia and Hyperthermia, will require tweaking before it is finalized. I am however, happy to proceed with code based on the flow-charts. 

Giving the end-user more control.

I am constantly thinking about what I would want out of this project as an end-user. Customization and full control over the variables that control the full feature-set are two that stand out the most.  Of course, there are many ways that you can give users this sort of control, but it needs to be simple to use and intuitive.  The image that follows is a result of my ongoing quest to give the end-user full control over the framework.

(Please click the image for a larger version)

As you can see, the user can enable and disable features as they see fit.  Two features are reliant on Fatigue to be an active component, and as such if Fatigue is disabled, so are Dehydration and Starvation.  This is because the research I have undertaken describes Fatigue as a symptom of both Dehydration and Starvation.

I have also created the initial selection process for the user-defined actions (see in an earlier flow chart).  The user-defined actions control the end result of the extended features; Fatigue, Dehydration, Starvation, Hypothermia and Hyperthermia.  I will be providing a code update in a later post.

Presentation Prep. Part 1

I have been preparing flow charts to visualize to others and myself how this framework will function, and more importantly how the weather and the levels it can be applied to will affect the player.  The following flow chart depicts how the weather variables and functions (depicted in blue) will affect the player and create the physiological effects described in earlier posts (depicted in orange).

As the main focus of my current schedule is Hypothermia and Hyperthermia, I have decided to show the workings of those first; all others will follow the same logic.

(Please click the image for a larger version)

The user has full control (as seen in earlier posts) over the minimum and maximum limitations of the players Heart Rate, Respiration Rate and Core Temperatures; of which for each of these the player can choose and outcome of Nothing, Blackout or Death.

This is what I have been working on post-new year, along with fixing previous problems with the code; discussed with Chris Janes prior to the Christmas break.