Front-end & UX Designer
envirometals-icon.png

04. Envirometals

A carefully planned environment for the user to navigate & it's underling physics involved.


Introduction to in-game environmentals

To assist the psychological connection between player and simulation, I felt an accurate representation or near similar was needed to convoy the MAD from IO. To simply make the simulation into a text adventure (RPG old-school text adventure) would be akin to reading a book, and thus no real epithetic response would be felt. On the other hand, something too realistic like the 2013 game 'Skyrim' would become a distraction from the core intent of this game, where in users would expect exploration as the primary intent vs a teaching tool. A careful balance of mapping, scale size, environmental conditions and physics would need to be laid out for inclusion in the simulation.


An ethical dilemma

For weeks I debated on the ethical nature of the baked-in physics the simulation runs off of. Would I allow a user to commit suicide in-game by jumping off a 17-story building or being hit by a taxi, or remove such abilities; their in lessing the accuracy of the simulation? The simulation's core focus is MAD and as suicide is a prevalent possibility of such effects, it seemed logical to keep the ability in-place. However a counter argument to this is that this ability diminishes the simulations teaching intent and becomes more like Skyrim, a distraction by boosting its realism and lessing its core focus. A very philosophical argument.

The final decision I came to was a middle-ground of two options:

Firstly; the ability to commit suicide by direct player actions e.g. jumping off the 17th floor of a building would be blocked by use of higher than jumping ability construction (FPS Controller can only jump .5 meters vertical) or invisible boundary boxes on windows; their in giving the effect of a possibility, if only the window was open or a lower balcony railing. This trickery gives the illusion of choice, when in-fact it has been predetermined that you cannot commit suicide, as it isn't even programmed in. Car speeds would be reduced to give the illusion they are going too slow to cause harm, and later stop if you walk in-front of them.

Secondly however, this leaves to question: how do you lose in-game? For any game and/or simulation to be effective, their requires the ability to lose. This risk vs reward game theory forces the user to make choices to help progress themselves throughout the game; or simply try harder than they would if 'god-mode' where enabled. - Keeping in mind you cannot technically commit suicide, you could lose by maxing out your MAD percentage. The UI effects are directly tied to your MAD and exceeding 100% would force such excessive screen-effects that the simulation becomes unplayable. This unplayable effect would be explained as a nervous breakdown or panic attack, depending on how the user perceives it. The fact would remain that the game has now become unplayable and thus you lose; not by any conventional sense of modern games like death or 'game-over' but an explainable after effect seen in the neuropsychology of severe anxiety and/or depression can produce.


Simulation loss mathematical code example

if (player : MAD =< 99.0);
value = ((max - min) * percentage) + min
FPS Camera Shake == MAD : %

else (player : MAD >= 100.0);
FPS Camera Shake >= MAD : %
GUI.Content ("I've suffered a breakdown & don't have the desire to continue"));
Application.LoadLevel ("bedroom");
Debug.Log ("Player has lost game; restarting level now");

Extended simulation loss code example

// Example : JS ++ UnityScript += Unity3D
// Credit due @
// http://answers.unity3d.com/questions/163090/how-can-i-make-a-simple-camera-shake-.html
// http://docs.unity3d.com/Documentation/ScriptReference/Rigidbody.OnCollisionEnter.html
// http://docs.unity3d.com/Documentation/ScriptReference/GUI.Button.html
// http://docs.unity3d.com/Documentation/ScriptReference/Application.LoadLevel.html
// http://docs.unity3d.com/Documentation/ScriptReference/AudioClip.Create.html

// Shake
static var shakeInt = 50.0;
var decrease = 10.0;
var magnitude = 10.0;
// Taxi
var contact : Collider;

function Update () {
// FPS Camera shake logic here
if (shakeInt < 0){
shakeInt = 0;
}
if (shakeInt != 0){
shakeInt -= 1*decrease*shakeInt*Time.deltaTime;
}
var cam = camera.main.transform;
if (shakeInt > 0){
cam.rotation.x += Random.Range(-magnitude*shakeInt, magnitude*shakeInt);
cam.rotation.y += Random.Range(-magnitude*shakeInt, magnitude*shakeInt);
cam.rotation.z += Random.Range(-magnitude*shakeInt, magnitude*shakeInt);
}

function OnCollisionEnter(collision : Collision) {
// FPS Controller onTriggerEnter of taxi if/else player logic here
if (var contact : ContactPoint in collision.contacts)
Shake.shakeInt = 100.0;


// Play a sound if the coliding objects had a big impact.
(collision.relativeVelocity.magnitude > 2)
audio.clip = carCrash.mp3;
audio.Play();
function OnGUI ()
// Reposition FPS Camera on GUI string
camera.fieldOfView = 40;
GUI.Content ("That car almost hit me. I've had too much stress today & don't have the desire to continue. I give up."));
GUI.Button(Rect(10,70,50,30),"Take the day off & try again tomorrow?"));
// Simulation begins loading bedroom level again
Application.LoadLevel ("bedroom");
}

Mapping conventions

If the simulation is partly built off my own experiences, then should it not also resemble it in mapping? This hypophora was an easy answer, but not so simple in application. Luckily Philadelphia was planned and developed using a grid-system similar to Manhattan and thus laying out the in-game roads and building where only a matter of comparison and mathematics.

This isn't to say it wasn't difficult as I needed to construct everything of shaped shaped blocks, most often 1 square foot at a time. But it was predominantly a linear path:

Step 1: Call in new simple shape object

Step 2: Transform to comparison object pre-measured

Step 3: Multiply with other shaped objects

Step 4: Group hundreds of vertices objects

Step 5: Apply UV mesh & physics. Note FPS Controller for scale comparison. 

Simple enough but very time consuming. This is best expressed with the reconstruction of the University of the Art's 'Terra' building I rebuilt on a 1:1 scale ratio. I stated development of this building for the secondary environment for which the player would interact in. This would become far more complex then the initial start area because of the talking mechanics involved. Development of this area should resume once beta of IMS begins.

Terra shown here, pre UV mesh. Note FPS Controller for scale.

Different view of Terra with 17 floors, thus the physics ethical dilemma mentioned.

Then by taking into account the above, we multiply size by time. This is multiplied exponentially using the city's grid-system, less a few blocks to speed gameplay to the desired length. This was done to reduce predicted UX gameplay length but still keep the FPS Controller to building size at a 1:1 scale.

Wire-framed.

Textured-wireframe.

And when we overlay a map of Philadelphia on top:

A rebuilt Philadelphia for the simulation. Only now the sheer size of the simulation's environment become so apparent.


Technical terminology reference links

vertices
https://docs.unity3d.com/Documentation/ScriptReference/Mesh-vertices.html