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.