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.

Clean code is efficient code.

This is going to be a brief post.  I have taken the time to go through my existing code and clean it up, making it more efficient; making sure not to repeat sections of code like I previously had.  So, after taking not of Chris Janes feedback last week, the cleaned code follows.



I have run in to a few issues where Javascript refuses to acknowledge some of my Serialized properties, and will have to find a workaround for this in the coming week.

Milestone One: 1st December.

Code; it's a beautiful thing.  I've been thinking a lot about user-friendly interfaces and making the scripts easy for the end-user to implement, and stumbled upon EditorGUILayouts.  These are just parts of Editor based scripts which allow the customization of Inspector Elements.

So, to create a highly customizable script and set of interfaces for the end-user, I've created an editor script that coincides with my playerControl Script.  The outcome of which can be seen below.

Now, the Editor script essentially organizes my variables in a fashion that is incredibly explanatory; rather than just being greeted by a list with which the end-user has no clue as to the function.

The actual playerControl script is very simple, and will have extended function very soon in regards to fluctuation in _heartRate, _respirationRate and _coreTemperature.



The playerControlEditor script is a little more complex, and took a little research to get right; but I am very happy with the results.  Ease of use for the end-user is key in a project such as this, the script can be seen below.



The scripts are still very much a work in progress, as the project continues it will become a lot more advanced.  So far though, I am happy with the results.