The initial scene where the player is placed does not give
any direct instruction but suggests a certain behavior (fig.1). There is a
statue on a podium that seems very attractive to pick up but there is no voice
or direction to actually do so. This lets the player have full control of when
do initiate the game; a voice with instruction, background music, sword
dropping, and monster spawning all only start once the player has decided to
pick up the statue. This design makes the player feel like they are the origin
of the story to come because all the chain of action only started with their
own action. Once the player has picked up the statue they are told to protect
the curse within from those that want to release it. By giving the player an
explanation of what they have just done, it gives them a goal for the story
ahead as well as a better understanding of what is to come. The rest of the virtually
reality experience, including the logic of the world and the interactions the
player is capable of, then continues to play wholly off the premise of
protecting the statue.
The spawning of monsters as well as the dropping of the
sword from the sky make sense in the world because it is a situation in which
the player can protect the statue from those that want the curse released. If
the player drops the statue the logic also agrees because the statue was broken
when I touched the floor. The player has the opportunity to either defeat
monsters that appear using long range stone throws or short range sword swings
(fig.2). If the player is capable of protecting the statue from enough
monsters, by killing enough, then the curse is cured and the statue disappears
from the player’s hand and the surroundings become bright and peacefulness is
restored. On the other hand, if the player fails to protect the statue, the
surroundings become dark and grim and the player is given a possibility to go
back into the past and retry in protecting the statue by grabbing a mystical
orb. Giving a change in scenery along with two possibly endings to the
narratives convinces the player that their actions had a consequence on the
world and they either succeeded in curing their mistake or failed in protecting
the world.
Since we knew that our game was going to be fundamentally
based on the spawning of monsters randomly from four directions, in order to
use the VR world to its fullest, I started the development of the game by
making a rough design of the area. I placed the player in the middle of the
world and placed from gates out of which the monsters were going to spawn
(fig.3). Once I had the monsters spawning and moving to the player correctly I
then added in the remaining features. The next part to come were the method to
destroy the monsters, meaning the sword and stones, then came the logic of the
world. The logic meant the detection of winning and losing conditions as well
as respawning of weapons or deaths of monsters. The environment was built in independently
of the logic because they didn’t necessarily interact with the logic directly. We
knew that the environment and game mechanics were going to follow the
foundations of games and scenes we had previously seen so we had a good framework
for our development. The environment was largely based on the idea of Indiana Jones
and the classic old ruins and temple scenes seen in movies and games (fig.4)
while the game mechanics were mostly based on simple hack-and-slash games (fig.5).
We wanted to make sure the player felt a sense of urgency
for the actions that they made so we implemented several features that enforced
such emotions. Surrounding the player with monsters from all sides and having
them spawn at random imposed panic and stress. Changes in scene, which only occurred
with a certain action taking place, occurred alongside a change in sound and lighting
which also imposed awareness on the player (fig.6). Making the player realize
that their actions actually have an effect on their surroundings both made the
player feel more immersed and responsible for what they have done. A successful
game in my opinion is one in which a player feels like they have done
something, thus having truly experienced something, after they are done. Our collection
of features and plotlines were all created with the goal of giving the player a
purpose and reason for something they have done and have to do.
With the goal of giving of giving the player a new experience, possibly fundamentally based on panic and fear for an action they have caused, a successful result should be obvious. We expected players to be a bit frightful when playing the game and to want to continue until they have won. This meant that when they played the game we wanted them to be making certain actions displaying panic or fear, such as backing away, screaming, constantly looking around, crouching or determination. Not only was there a desire to impose emotions but we also wanted the final piece that was reflective of an obvious narrative, this meant having a beginning, middle, and end. Our final project did indeed succeed in both of these aspect, players would scream and be afraid of monsters and would also know if they lost of won. Another unexpected result that occurred sometimes with players was that they would continuously attempt new ways of winning, whether this meant switching the hand the statue was in or relying solely on stones or a sword, if they lost often. This result showed that players were indeed determined to win and since they were human, and intelligently wanted to adapt, they would try and find the best method to win. All in all, our final product has replay value and makes players feel like they have gone through an experience, which is fundamentally all we wanted and that means a successful project (fig.7).
Something I absolutely understood after experiencing the VR
Park is that involving reality with a VR experience can lead to either great
success or horrible failure. When the reality plays a part, either as a moving
platform, physical walls, or wind effects, it can make the user feel immersed
or completely disjointed. The reason for the drastic effect is solely related
to the sync between the experience and the reality.
One of the roller coaster rides moved along in such a way
that the flying through the sky felt real, this was because the center of
gravity and the inertia moved as expected. In another movement-involved
experience, there was slight lag between the video and the physical shakes
which made the user absolutely understand that this was all fake. The last
experience also had a storyline that was so incredibly unrealistic, which didn’t
help with the immersion at all.
The sound was helpful in making an immersive experience as
well. This worked because sound was used as a form of attention control; sound
from behind or to the side would make the user move and thus involve them well
in the story line. When sound was used in conjunction with some slight physical
interaction from reality and a good storyline, such as in the maze game, the
experience was enjoyable. Having some sound but not too much is an important
factor as well. Some of the experience generated a mildly chaotic environment
by having constant sound and movement involved, such as with the arcade
shooter.
Ideally, an experience would draw you in with a strong story
and then push you along with mild actions and developments. Some of the
experiences didn’t involve a story and instead focused solely on the physical experience,
such as falling from a tower or flying through the sky, but that made the user
feel more like a passenger than a participant. Naturally all the different
roles could be targeted but the most successful experiences all shared the
active participant interest.
Boulder following the player, have to constantly move
Skydiving
Starting in an abandoned location
Expanding on Protecting Egg/Item Idea
Instead of falling with gravity, objects run from in front of player
Instead of protecting item, protecting self
Indiana Jones sort of scenario
Player has stolen an item, now has to protect self and item
Evil doers are coming for the player
Survive a certain amount of time or monsters/evil doers
3 possible outcomes
Drop the item
Release the curse
Evil doer gets to the player
Releases the curse
Survive a certain amount of monsters
Item transforms
Final location, nice scene
Final Idea – Cursed (Protecting the Statue)
Initial scenery (first scene)
Large open sky area
Cave not so prominent
Nice lighting
Light green
Bright yellow
Sky blue
Outside
Large old tree
Old run down brick walls surrounding player
Mystical statue on a platform closeby to the player
Throwable rocks around the statue
Picking up the statue (second scene)
Lighting changes
Nice lighting changes to darker and more evil like
Red lights appear above 4 caves, each at a cardinal direction
Caves become prominent
Statue has a glow
Platform lowers
Sword falls from above (can be picked up)
UI message appears
The curse has been released
Tells player to protect themself (logic to use sword and stones)
Monsters slowly start to appear
More start to appear faster
Localization of monsters is random
Appear behind cave and move towards the player
Monster hits player or player drops statue (losing scene)
UI message appears
The curse has permanently taken over
In order to restart
Grab another object
Maybe no restart
Automatically restart
Lighting al turns off except for the statue’s glow
Destroy X number of monsters (winning scene)
Statue is replaced with animated “god” or something
UI message appears
You have defeated the curse
You have destroyed all the monsters
Lighting becomes merry
Involved scripts
Changing lighting
Initiating sword
Throwable sword, rocks, statue
Lowering platform
Moving monsters
Collision detector for destroying monsters
Collision detector for monster touching statue
Sound effect
UI messages
Score in top left/right
Potential animation of monsters
Animation of final scene statue
Restarting game
Initiating monsters (randomly) (increase amount with time)
Moving of monsters towards statue
Possible Scenery Inspiration
April 13
Today’s goal was just to set up the testing area and prepare the Unity file for the project. In order to do that I downloaded all the necessary assets for the project (fig.1). This included all the building blocks for the dungeon, the statue, the sword, the lights, and the stones. After obtaining all the assets, I went ahead and started placing some into the “Dungeon” scene (fig.2). I found a suitable platform for the for the dragon statue, floors that looked decent, and gates that matched. I tried to scale everything to an entertaining size and then tested it out. It is all looking pretty nice, I can see with lights, trees, accessories, and blocks added it, this scene will look a lot like a fully-fledged dungeon room (fig.3). The only issue is that the statue is a bit out of style (too shiny) but that might be useful in catching the player’s attention.
April 14
Today we paper player tested the concept of our games.
Cassie fabricated the basic items that were going to be involved in the game
and then we gathered a friend of ours to test out the scenario. The items
included: the head mounted display (fig.1), the monsters (fig.2), the statue
(fig.3), the rocks (fig.4), the sword (fig.5) and the lights, and the podium for
the statue.
From the testing (vid.1 & vid.2), we gained some insight into the changes and improvements we needed for our game. The important ones had to do with the voices and narrative structure. It was suggested that we clearing state the goal of the game with a phrase such as “protect the statue” instead of keeping the goal too ambiguous (but don’t go too detailed by saying exactly how). Also more monsters and large ones if possible would be desired. Lastly the idea of being able to place the statue down would make it easier to both throw stones and fend with the sword at the same time. The last idea might not be followed but it was good advice.
April 16
Today, a lot of work was put into the project in order to
develop a fundamental basis to continue work off of. Stones were added and
scripts were added for each of the object that will need a function (fig.1
& fig.2).
Next, a bunch of work was placed on the monster. The monster
came from an asset pack that also involved its animations. The animator was
removed just for now, just to keep everything simple for now. A rigid body was
added to the monster as well as the script (fig.3).
The monster script was quite simple, it caused the monster
to move forward one value every second as well as making it vulnerable to any object
that has the tag “HurtMonster” (fig.4). The next script that was worked on was
for the statue. This script simply kept the statue still and unaffected by
gravity until it was moved, at which point it would no longer be kinematic and
would also trigger the “hasMoved” Boolean to be true (fig.5). This was used by
the control script as an indicator to spawn monsters.
The control script had many parts to it as well (and will have even more with time) (fig.6). It requires the prefab for the monster that is going to be spawned as well as the connection to the statue. Once the statue has been moved, the script will start spawning monsters every 2 seconds. This parameter will eventually be changed to spawn monsters more often as the timer float increase more. The spawning of the monster is also random (placing randomly out of 4 possible gates). This was quite annoying to set up being it required the accurate position and rotation of the monsters to be correct (so that it would walk towards the center). Ideally another script would eventually be added in order to have monsters randomly appear from the diagonal directions as well (just to make it so that the player can’t just move out of the way of the monsters to protect themselves.
April 21
Today a lot of the project and its foundation were worked
on. Many scripts were written and many object placement and game testing took
place. I continued working on the control script, the statue script, and the
monster script but also added scripts for the sword, stones, and podium
(fig.1). The two prefabs that were created, with the appropriate scales,
details, scripts, and components attached were the monster and sword (fig.2)
Four major additions were made to the environment. The 4
types of stones were placed around the podium in a circular manner and brought
down in scale from before. The terrain was flattened out a bit because it was interfering
with the monsters movements. A suitable light source was found and placed were
it will be visible and blend it with the gate. The gates and monsters were
scaled up in size to give a larger affect; this required some rearranging of
objects as well. (fig.3)
The prefab for the monster had a few features that were
worked on in detail. The animator was turned back on and the walking motion was
placed on loop (fig.4). I tried turning on root motion to use as more aesthetic
walking behavior but it didn’t move the monsters so the previous code to move
was retained. The rigid body also needed to be played with a bit in terms of
parameters being locked because the monster occasionally would bump off
something and start walking into the sky.
The sword prefab also had some features worked on. The original
sword was taken from an asset pack and edited down in terms of scale. It was also
made intractable and throwable using the SteamVR asset pack’s scripts. A
collider was added and made convex so that it could interact with other object
in the game. It was important to mess with some of the boxes in the throwable
script because the sword would fall out of your hand slowly as it was being
held due to gravity not being turned off. The same issue occurred with the stones,
this was an easy fix to apply to everything. (fig.5)
The monster script was kept simple. Since root motion didn’t
work the moving forward script had to be kept. A collision detector based on
tag names was also implemented. Now items could either have the “NoHurt” or the
“HurtMonster” tag that permitted the object to either destroy or damage the
monster it hit (fig.6). For now this would be used solely on stones and the
sword (at specific times when they were being used).
The sword script was created with several features. The original
position and rotation was recorded so that the sword could be respawned there
if the game were to restart. Also the alternating tags (between hurting and not
hurting the monster) was coded for. This was important so that the sword could
not hurt the monster when it was on the ground (fig.7).
The podium was finally given a script that permitted it to disappear
out of sight when necessary). The script recorded its original position and
rotation so that it knew how to move and also so that it could be brought back
if needed. The podium only moved down (at a reasonable speed one fourth of the
scale per second) if the statue was moved (fig.8). It would also not move
further than -1.5, just to keep it relatively close and not cause lag to the
game.
The script that was written for the stones required a good
deal of work and thought. First their original position and rotation was
recorded. The stones were also originally set as kinematic so that they didn’t
move. If the stones were moved, the kinematic was turned off and a timer would
start counting down to respawn a stone at the original location. The respawning
doe was written in such a way (that was kind of crude) that it would respawn a
new stone only once (this was necessary because otherwise stones would start
overlapping and cause the game to have serious lag and issues. The script also
check every update to see if the stone could hurt the monsters, the parameters
to allow such behavior could be easily altered (for now it had to be at a
certain height). Another parameter could be based off of the location, if it
was still close to its original location then the stone would not be able to
hurt the monsters (meaning it hasn’t been thrown far). There is currently a
glitch that I don’t know how to resolve: the first stone that is spawned doesn’t
gather any velocity from the hand when it is first thrown (so it doesn’t fly
forward but drops down) but once picked up it works normally (fig.9). The
stones that then spawn from that stone all behave normally. Also, every now and
then the stone loses gravity and just flies away once thrown or bounced on
something. These are glitches that could either be maintained to cause
difficulty to the player or worked on later on.
The last script that was worked on was the control. I just
added some code to this script to spawn monsters more logically and spawn the
sword. Once the statue has been moved, a sword will spawn from overhead (the
prefab) 3 seconds afterwards (after the podium has gone down) and fall down. This
relies on a Boolean variable to not spawn the sword repetitively. The script
will also start spawning monsters. It will start spawning monsters every 5
seconds (not shown) but then after half a minute it will spawn monsters every 4
seconds, this will continue increasing till after 135 seconds (about 2.5 minutes)
where it will spawn a monster every 2 seconds (fig.10). This mean that after 3
minutes about 60 monsters would have spawned. These times and frequency of
spawning can all be easily changed but for now these seem ideal. The spawn frequency
cannot go below 1 a second because that is how long it take for the monster to
move entirely forward (don’t want monsters spawning on each other).
Lastly in addition to the tags, the layers were played
around with a little bit. Two layers were created to make the game more
efficient in coding, a “seeking statue” layer for the monsters and an “avoiding
monsters” layer for the objects that should not interfere with the monsters movement
or behavior (fig.11).
Finally, some important code that has to be worked on: fixing any glitches that were discovered, changing the lighting once the statue is picked up, animating the death of the monster (this should also place them in the avoiding monster layer so it doesn’t interfere with other monsters), having a start or end screen, and implementing a winning and losing condition. Up to this point a lot of work has been put into the project and it looks like a bunch more will have to be put in (especially solving glitches), hopefully it works out!
April 27
Today was another successful day of coding, a substantial
amount of progress was made. I started off by tackling the monster movement issue.
The very first thing I did was move everything around the monsters trajectory, including
the terrain, into a layer that wouldn’t interact with the monster (fig.1). Since
I did this, I had to make sure the monster wouldn’t fall through the ground, so
I fixed the y position (along with the x and z rotation to keep straight) of
the monsters rigid body. After getting the monster’s movement fluid and without
stopping, I wanted to animate the dead when hit by a rock. I did this in the
animator component of the monster’s prefab. I added a new action (called “Dead”)
to the current walk and made a Boolean parameter (called “isDead”) that had to
be turned on in order for it to occur. When the monster is hit by something
that has the “HurtMonster” tag, then the Boolean within the script for death
would turn on as would the Boolean in the animator (fig.2). The falling monster
would also be moved to the layer that doesn’t interact with other monsters (“Avoiding
Monsters”) as to not inhibit the movement and trajectory (fig.2). A really cool
effect of this is that the corpses stay present after their death. An issue I
came across was that the dead monster still interacted with other, to fix this
I inputted a script I found online that would change the layer for all the
children and grandchildren within the monster prefab, function called “SetLayerRecursively”,
which worked in the end (fig.2).
Since I noticed that the monsters would be blocked by the
stones that were newly spawned (thus not reaching the middle or the statue) I
added to the code to fix the issue. I made it so that newly spawned stones were
placed in the layer that didn’t interact with monsters (fig.3). I also lowered
the time for the stones to respawn since it seemed to take too long. If the
player threw the stone at a monster before a new one respawned then it wouldn’t
respawn, this was a way to punish the player for using stones at a close
distance.
To add to the convenience of the game a bit I made a
function that brought the sword back to the original position if it was thrown
too far. Since the stones respawned I thought it was only fair that the sword
does too. I did this by using the math library and making it so that the
position of the sword, along with its rotation and velocity, were set to
original if thrown further than 2 in any x or z direction (fig.4).
Finally I attached a losing behavior for the game to the
statue’s script. Currently, only if the statue fell below a certain level (on
the ground) would the player lose (fig.5). I gave room for the possibility of
cheating the system, you could make a platform of stones or place the statue on
a dead monster and you would not lose.
I made a change in scenery for the when the player
supposedly lost. With a lot of difficulty I found the main camera within the
player and found a way to alter the skybox so that it became black when the
player lost. I found this through trial and error. Turns out that if you change
the “Clear Flags” of the main camera from “Skybox” to “Solid Color” then the
beautiful skybox would be turned to a single color quickly (fig.6). This gave
off a strong effect for when the player lost. I also made it so that the
ambient light intensity would be set to very low when the layer lost, which
turned a lot of the environment dark (fig.6). I found out that this would only
work on non-static objects. Ideally, I would find a way to turn everything
dark.
The control script is getting a bit hectic because I am slowly realizing how inefficient my coding is (stating things more times than they need to be and writing too many lines). It is a bit too late to fix this because it would take a lot of time to redo but it is a good learning experience. I think so far the game is looking good. The next few steps necessary for the coding is: adding more losing conditions, fixing the losing condition, making a winning condition, counting the number of monsters killed, and making a method to restart the game (perhaps with SceneManager.LoadScene(SceneManager.GetActiveScene().name).
April 30
Having in mind what I wanted to do today, I created 2 new
materials and a new prefab that I was going to use (fig.1). I created a dark looking
material for the planes from which the monsters will emerge (fig.2, naturally set
in the “Avoiding Monsters” layer as not to interact with the monster) and a
glowing purple material for the respawn sphere that will let you restart the
game if desired (fig.3).
I then went ahead and made it so that the player could
indeed restart the game if they lost. I did this in a roundabout way, when the
player loses everything turns dark but a sphere will appear. This sphere (which
is glowing) can be interacted with. A voice will tell the player that they can
try again by grabbing the sphere. Grabbing the sphere will then reload the
scene (fig.4). When I first tried running this code I noticed that some objects
would be carried over into the reloaded scene. This caused issues because some
of the scripts would malfunction due to there being multiple objects with the
same name. Also, there would be too many statues, swords, and stones, which
made the game very different. I added a section to the code that deleted the
sword, player, and statue before reloading but I decided to keep the stones
(fig.4). I think this would be enjoyable because it would give the player a bit
more of a head start and would also allow them to strategize their placement of
stones ahead of time (simply gave a bit more character to the game). I noticed
that in the reloaded scene the stones and statues would have the issues of not
taking velocity from the hand after being thrown (the first time). I don’t know
how to fix this but I think it might be reasonable to keep it in the final
version of the game because it is a disadvantage that balances out with the
advantage the player obtains from restarting.
I also noticed that the monsters would continue to spawn and
walk towards the player once they had lost (or won) which seemed aesthetically displeasing.
There was also the issue of them (and the corpses) being reloaded to the next
scene after a restart. To fix this I made a very simple addition to the code
for the monsters. I simply made it so that when the player lost, the monsters
would delete themselves (fig.5).
Though I didn’t actually code for the winning scene I wrote the code that prepared for it (as well as the losing scene entry way). If the monster collided with the statue or the player (depending on the name of the objects) the player would lose (fig.6). I might have to change this later on so that it is only the statue because the monster can quite easily collided with the player (even when as a corpse). I also made it so that the player would gain one point every time a monster is killed and will win once they kill 60 monsters (fig.6 & fig.7). As I am writing this blog I noticed an error in the code that needs to be fixed; currently the sword will get destroyed once it interacts with the monsters because it has the “HurtMonster” tag. This needs to be made into an if condition. Also the current if condition needs to have the “or’ operator turned into an “and operator”; currently the player could win simply by hitting a corpse repetitively with the stone or sword.
I think the coding for the game is getting close to its end point. To finalize, I think I need to code the winning scene and fix some bugs with the reloading and the throwing. If necessary, I can also make it so that monsters spawn form the diagonals every now and then. I like how the game is looking so far.
May 5
I started off by fixing something that I thought was made
the game unnecessarily inconvenient. I made it so that the losing condition
only took into account when the statue touched a monster and not when the
player touched a monster (fig.1). I also placed the player in the “Avoid
Monsters” layer. This made it so that the monsters would walk through the
player to reach the statue.
Another aspect I wanted to fix was the difficulty level of
the game. From player testing I understood that the game was a bit too
difficult because monsters spawned too quickly. To fix this I decreased the
spawn rate. I started at every 7 seconds then 6, 5 and finally 4 (fig.2). This
meant that after 2 minutes close to 25 monsters would have spawn. This is the
amount of monsters to kill to win.
Next, I wanted to add a blood effect to the monsters. I made
a particle system that looked mildly like blood splatter and attached it to the
chest of the monsters (fig.3). I found the right parameters mostly through
trial and error. I then added code in the “death of monster” section so that it
would play the particle system when the monster died (fig.4). This meant that
the blood continued inevitably till the player won or lost. Also, the particle
system didn’t collide with anything which fixed a few bugs I had in the
previous project.
I fixed the losing condition from dropping the statue.
Originally it was based on the y position of the statue but do make the system
more accurate I based the touching on collisions. Now, if the statue collided
with an object named “Terrain” (the ground) then the player would lose (fig.5).
This also permitted me to add into the game a small Easter Egg which I do
later.
To balance the losing condition, I added a winning
condition. Now if the player did indeed kill 25 monsters then the previously
turned off directional light would be turned on (fig.6). This made the scene a
lot brighter and does indeed feel like success. I had to destroy the statue in
the winning scene or else the player would still lose when dropping it. I made
it so that there was no more replaying after winning; that is the end of the
game.
Finally I worked on the Easter Egg portion. I first made it so almost all of the objects were not static. This made it so that I didn’t have to deal with the baking of light maps and so that everything turned dark or bright with the change of light (fig.7). This is not a perfect method but since there are not too many objects in the game there won’t be much lag. There is one hollow shape that doesn’t turn black when the player loses (fig.7). If when the player is defending themselves, they can throw the statue in the hole and not lose. This makes it so that the player doesn’t have to worry about the statue when fighting. I am thinking of making it so the player automatically wins when they throw it in there.
So I think all the coding for the game is pretty much done. Now all that has to be done is the addition of sounds and a few touch ups.
May 10
I spent way too much time trying to fix the glitch where the
stones would not fly after being thrown (only after the scene reload). I found
out that it had nothing to do with my script though a lot of trial and error.
In the end I found it to be a problem with the throwable script. I just had to
prevent the script from turning the object kinetic when it was being picked up
(fig.1). This was done in the “Attachment Flags.”
I then went ahead and corrected the blood splatter particle
system. I found out that adding an animation to a character doesn’t move all
the objects within the prefab. I order to make it so blood came out at the
right place when the monster died I just placed the particle system where the
chest would be when they fell (fig.2).
Lastly I added a flat sphere (since there are no circles) to
the bottom of the statue (fig.3). Originally the statue was see through at the
bottom so this fixed that issues.
Zenboo was based on the concept of a Zen environment with a
simple yet endlessly executable action in place. Originally, the plan was to
have flowers that could be endlessly grown but then the idea of bamboo came up.
Since, in reality, bamboo grows incredibly quickly and is aesthetically attractive,
we decided on this vegetation instead (fig.1). A positive addition was that
bamboo inherently already had some connection to the idea of Zen. We wanted to
place the user in a comforting environment that presented them clearly with a
task which they could continuously do in order to relax for the daily stresses
of everyday life. All the artistic choices behind the environment were directed
towards this comforting attitude. The interaction were also kept simple and
obvious. The interactions involved the picking up of the two objects and the
using of the two objects. A watering can could be picked up and used to pour
water on the bamboo, which would make it grow, and the sickle could be used to
chop the grown bamboo, and make it disappear (fig.2).
Knowing that there was a lot to be done, we split the tasks
evenly into two groups: scripting and designing. One individual was responsible
for the designing of the environment, another in charge of the music and sound effects,
and two responsible for making all the desired actions feasible. I was
responsible for scripting actions and did most of my testing in a separate scene
than where the environment was being designed. Since the actions had to be explainable
without any description, we made sure to use everyday objects and code for recognizable
physics behind them. This meant that the watering can could be lifted up and
that water would only appear when poured at a certain degree, or that bamboo
would grow upwards when water interacted with it. The testing area was modeled
around what the final scene would encompass for the user. The tools were placed
near to the spawn point of the user and could be used on the bamboo that was
close by (fig.3-4).
The behaviors of the objects were expected because they were similar to reality and this made them seem like everyday actions. This meant that tools could be lifted, thrown, dropped, and act the correct way when coming into contact with other objects or when being poured. The only area where an unexpected result appears is when bamboo grows (fig.5). It was discovered, during testing, that bamboo balancing on itself was a lot more attractive and brought more comfort to the user, similar to stacking stones (fig.6), so it replaced the regular straight growth of bamboo shoots. Having the segments of bamboo fall to the ground after they reached a certain height was also a feature of this balancing. This brought new possibilities to a used behavior and also prevented clutter by having the segments disappear after a moment. After all the objects were designed and equipped with their respective behaviors, they were made into prefabs and placed in the final scene, in similar coordinates (see Cassie’s blog). The environment was designed to have warm sunset lighting, comforting wind, grass, and hills in order to bring ease to user. A small oddity observed was the floating rocks, though these objects are not following our reality’s physics they look incredibly mesmerizing and thus were maintained in the environment. Generally, having a few quirks that brought personality to the area, was expected to give the user more reason to desire realizing in this world.
Our expected world was a place a used could freely spend
their time in with the goal of alleviating stress. This was achieved because
the user had a simple task that could be endlessly continued and a surrounding
that promoted comfort. With more experience and time, the world could
eventually be expanded. There could be more tasks for the user to indulge in
and more scenery that was intriguing to look at and enjoy. Expanding is always
a possibility to entertain the user but keeping them in a roughly enclosed area
was a solution too. Keeping them enclosed and with only a few tasks to focus on
lets them possibly enter a form of meditation, which is by far the best stress
relieving method. Better designing of the current scene could have involved the
matching of asset styles and consideration for certain behaviors. Making the
bamboo that falls intractable by hand and making it so that tools were always
held in the correct method would have been logical. Making a better match of
the tools’ material with the design style of the environment would have been
more attractive. After showing the project in class I also noticed that some of
the music could have been worked on to be less hostile and the water system
needed some tweaking. Simply, there were a few factors that made the objects in
the project seem unworldly and made it harder for the player to immerse
themselves.
Though there were several factors that could be worked on
there was also a sure sign that the project was a success. This is evident in
three behaviors, players would want to place the controller on the stump after they
were done, players tried to move out of the way of falling bamboo, and players continued
to water the bamboo endlessly without tire. This shows that players were about
to connect their reality with the world we created to such an extent that they
the lines between the two existences became blurred.
In molecular and cellular biology there are two three dimensional aspects that are often portrayed in two dimensions, these are molecules and their interaction within pathways. Molecules are usually drawn as simple blobs or shapes in order to better visualize the different domains that have specific functions (proteins have very complex shapes). With these simple shapes, their interactions are usually connected with a vast map of arrows and inhibitions which form the pathways that biologists study and use to develop function specific drugs or site specific research. This decision to go simple and 2D has made studying and using biology a lot simpler but it has taken out a very important factor, molecules and pathways have movement. This movement, which is important in the interaction of proteins, depends vastly on size and surroundings which are all three dimensional. Naturally, to model this mathematically is quite complex and requires a lot of prior knowledge and computational power but once achieved has great benefits. If these pathways could be brought into a dynamically moving intractable three dimensional world, then there would be the possibility of better research and understanding into medicine. By better understanding what happens when certain interactions are “physically” and “visually” removed there would be less wasted effort in pathway structure and experimental design.
We started off with some brainstorming for our interactions and actions:
Initial Ideas:
Throwing crumpled paper into a basket
Implement points based on how far back you are → makes you move around
Obstacles (desk, etc.)
Crumpling paper
Classroom, library
Putting food onto tray- cafeteria
Washing face
Taking care of plants
Zen
If you cut the plants they just float around
Twisting knob motion to speed up time → plants grow, lighting changes
Drawing
Slingshot
Flipping coin into fountain
Something could pop out, you have to catch it
After deciding on the plant idea we enjoyed, we decided to go more into details:
Taking care of plants:
Time
Lighting changes
Sun/moon
Plant growth
Environment ideas:
Dorm room
Windowsill
Small cottage
Outside garden, fence
Interaction
Watering
Cutting
Picking fruit/flowers
Growing bamboo
With a solid idea in mind, we went ahead and designed our storyboard:
–Step 1–
Clump of bamboo in front of you
To your side: tree stump with watering can + cutting tool
Surrounding mountains and other bamboo
You’re inside a circle of rocks
Butterflies are flying around
It’s golden hour
–Step 2–
You have the water picked up
Water is gone from stump
–Step 3–
Bamboo is taller
–Step 4–
Replace water with axe
Now the water is back on the stump and the axe is gone
–Step 5–
Show the particles of the bamboo disappearing
–Step 6–
Now an empty spot of bamboo
Our storyboard:
Mar 6
After our group roles were self-assigned, of which I got the responsibility of scripting, I thought it would be important to start as soon as possible. Since I knew very little about C#, Unity, and scripting, I got to practice immediately.
The first goal for the day was to play around with some scripts from SteamVR and the online unity manuals. The first script I created was heavily dependent on what I found online. I assembled a script that caused an object to turn into a new prefab once it collided with a sphere. In order to make this functional I had to make sure the sphere and the cube both had rigid bodies and colliders. I also made sure that I could throw the sphere, by using the components from SteamVR, so that I could pick it up by using the back button of the remote. The prefab the sphere turned into was a cup from another asset pack. This was quite a hilarious scene but very beneficial because it taught me how to identify a specific prefab to use as a transformation and to prevent the same effect when touching any other named object.
The next project was to a script that would imitate the
effect of bamboo disappearing when hit with a sickle. I used a capsule in place
of the sickle and I made the movement occur by placing a public variable. The
movement could be in any direction, it would just add that amount to the
current position. The cylinder I attached this script to needed to have a rigid
body and a collider in order have effect. I also made sure gravity was
activated because whenever I hit it with the capsule I wanted it to fall back
down to the floor. The large issue I found with this set up was that the
cylinder could fall out of reach really easily and there was no way of
reobtaining it.
Realizing how easy it was to make effect occur on object I brought in several prefabs for similar experiments. I brought in a sickle and stacked bamboo cups (to imitate a bamboo shoot). The script that I created this time was a lot simpler. Whenever the sickle made collision with the bamboo it would simply destroy the object. This is very effective it making it look like the shoot was being shopped at different areas. If many cups were stacked then I believe it would be quite entertaining to see all of the fall down or have some separate effect. This could be played with a bit to obtain the desired result, I will have to discuss with the group a bit. Overall, today I have found a way to make tools able to be picked up and come in contact with bamboo shoots that could either be blown away or deleted.
Mar 8
Today I started off by recreating a really crude
representation of the environment. I did this so that I could start writing
scripts that would be realistic of the area that the object will be placed in
at the end. This are included a table, the 2 tools to be used (sickle and water
can), and a patch of soil with bamboo.
I worked relentlessly on the script responsible for the
function of the watering can. My goal was to make a raycast that would detect
the bamboo and then return then return it. I also wanted to make it so that the
object knew when it was being poured and when it was not, this depended on the
tilting of the object. Past a certain z rotation, as could be seen in the
scene, it looked correct to be pouring water. I could not get the raycast to
work (couldn’t even see the debug line that was supposed to show up) but I
succeeded in making the program know when it was pouring.
In the end I was very frustrated because the line wasn’t working and I didn’t know how to make the tilting of the can have any function. I placed a child object Particle System on the can when I thought the water should come from and then left the work for another day.
Mar 9
Today I work specifically on three scripts that I thought
would be quite vital for the comfort and enjoyment of the final product. These
three were: one that got the bamboo to be cut by the sickle, one that brought
items back into range if thrown too far, and one that was responsible for the
can’s particle system and detection of the bamboo.
I started off with the bamboo script. I ended up keeping it
quite simple and basing it off a previous scrip that I talked about a few days
ago. I made it so that the object that could cut the bamboo was not definite. A
certain name for the cutting object could be listed.
I noticed a large issue with the script when I was trying to
hit the bamboo. Only when the sickle was dropped on the bamboo would it make it
disappear, this is because there were some problems with the interaction script
from SteamVR. The Attachment Flags had to be altered so that the sickle could
not clip through items. This also made the entire system a bit more realistic.
Next, I worked on the script to bring the items back from a
distance. This took a lot of time but in the end I found out that you had to
reset the rotation and the position of the item before bringing it back or else
it would fly away. The final product looked very good. It would just drop back
on the table once thrown too far. I also made it so that the distance it was
being thrown and teleported back from could be altered. I found 2 to be good in
the z and x direction. I attached this script to both the can and the sickle.
Finally, I tried working on the watering raycast issue but I ran out of time. I found out why the raycast debug line wasn’t seen though. I noticed that you could only see it in the scene editor. It was pointing the wrong way so I changed its direction (in a quite annoying method) and moved it up so that it aligned well with the nozzle (this required some testing since the scales are so messed up).
So much research, video watching, and web scrolling was required to get even here. It makes the final products feel so good when they work…
Mar 11
I noticed that it was difficult to know exactly when the
watering can was pointing directly at the bamboo (causing it to grow) so I
decided to add a pointer of sorts. Initially I tried to work with line
renderers but this very difficult. It required the position to be continuously
updated and the hit position (or end position of the line) could not be
infinity. After not resolving the issue I found an extremely solution simply using
a cube. I created a long thin cube oriented to way the raycast was and colored
it orange just to make it more appealing and fitting with the environment.
Next, I worked heavily on the growing of the bamboo. I found
the growing-flower script from SteamVR and worked off that. I first made two
different kinds of bamboo shoots, bambooOG and bamboo, which essentially are
the stump the bamboo will grow out of and the bamboo that actually grows out. I
did this because I noticed it would make the entire system easier. I could make
solely the bamboo vulnerable to the sickle while keeping the bambooOG
permanent. I added the growing script from SteamVR to the bambooOG.
After trying to grow the bamboo I noticed 2 large problems.
The first is that the bamboo would spawn way too fast because as long as the
can was pointing at the bambooOG the growth would occur (so with every update).
In order to resolve this I set a counter that would increase with every frame
till 60 and then restart along with running the script. This meant that if the
update occurred 60 times a second, then the bamboo would grow 1 per second. Next
to tackle was the issue of the bamboo staying on top of each other after
growing (and pushing the top ones up). The bamboo did not want to go any higher
than 2 shoots tall, they continuously knocked the top one away. This occurred regardless
of the position where you spawned the bamboo.
While doing trial and error with spawning positions and
checking/unchecking all the boxes in all the scripts attached to the bamboo, I
came across something wonderfully beautifully. You can lock the position and
rotation of the spawned bamboo shoots by altering their prefab’s rigid body.
What I tried first was freezing the y position but then I realized how that was
incorrect (all the bamboo would just fly sideways. Next I increased the mass
(for more stability and bounciness) and locked the x and z positions. I came up
with a wonderfully appealing result. The bamboo would grow in an amazing way that
looked like the individual segments were balancing on each other. Even better
was the fact that the bamboos could be interacted with by the can (spinning them
and bouncing them up and down). Cutting them down with the sickle was even more
relieving too because you could see them quickly destroy (without any effect
yet though).
Naturally, I could have locked the rotations and it would really look like the bamboo was growing straight up but I didn’t think the results was nearly as appealing. With this constant balancing, the used was way more pleased (user tested with Max) and wanted to keep making them grow because it was partially random too. I also realized that the used wanted to keep growing the shoots endlessly so I decided to attach segment to the bamboo script that would release the freezing of the rigidbody when a certain height was reached (public int). The final step would be perhaps to make the bamboo disappear after a while once their height of x position was at or lower than ground level (to prevent cluttering).
Mar 12
Today I made finishing touches to the coding. The first
thing I worked on was making sure that the segments at the top of the bamboo
sprout would fall off after a desired height and eventually disappear after
some time on the ground. I did this by making two functions, one that took off
all the restraints at a desired height (before when I did this there were still
some problems) and another that waited a period of time to delete it. The first function was relatively simple but
the second one required a counter. I tried using WaitForSeconds() but
apparently that can only be use in a enumerator. I suspected update to run
roughly 60 times a second so I made a counter based off that.
The next part I worked on was cleaning up the code of the teleporting-an-item-back script. I noticed that this code was not originally very lenient on placement. The items had to be close to the origin of the environment. I fixed this simply by changing some of the math operations. In the end everything worked wonderfully! The next step is to combine this with the environment!
Mar 17
Today was the final day. We all grouped together to make sure everything was working and to make sure that the last day of project development could go successfully. When I came in there were still some issues with the colliding of the water and the execution of the growing commanded. After three of us worked on the code for a while we finally got it to work. The large issue had to do with layers. In the end the terrain had to be placed in a different layer along with the can because the water particle system was constantly colliding with it. We go the physics and action to work efficiently. The environment looked good and the objects worked well.
One of the few first-person-shooter games that I truly enjoyed and thought was brilliantly made is “Borderlands 2.” The bold-line-style artwork, huge collection of different forageable loot, and funny collection of quests makes the game endlessly enjoyable to play but what makes the game truly beautiful are the characters. The first NPC you interact with in the game is this robot named CL4P-TP, or Claptrap for convenience. The robot is, as the name ironically implies, overly enthusiastic and an endless talker. Claptrap has this iconic post-apocalyptic WALL-E similarity to it which just adds to the story and the artwork in general.
What makes the robot a true artwork
is its personality. Constantly spewing comedy and dark satire makes it
absolutely not seem robotic at all. The voice is kind of artificial but what is
be said really give Claptrap the personality of a real character, truly an
ideal NPC. The first interaction with the player is right after waking up in
game. The player doesn’t really know what to do and just explores the frozen
wasteland surroundings a bit, just to find this chatterbox robot come up to
them. Instantly chatting and cracking jokes about be lonely and being a dysfunctional
robot, immediately snaps the player into the present. Without any prior
background, the player is placed into a comfortable scenario where they are
being guided to the right location and helped with instructions.
Usually the initial instructional segments of games are blatantly
obvious and boring. They are usually filled with simple tutorials and tasks
that the player probably already knows. This tutorial is completely different,
the player doesn’t even realize that they are being taught the controls and
rules of the game because the hilarious robot is talking the entire time.
Making jokes about the surroundings and about the player’s actions, being
incredibly self-deprecating about being a lonely robot, talking about its
intent to join the resistance so that it can get back at the villain who stopped
its production line (making it lonely because it now has not friends). The
chit-chat that seems totally nonsensical and like blabber actually turns out to
be incredibly informative about the game’s storyline and background.
The NPC immediately, without question, states itself as the player’s friend and helper. Additionally Claptrap talks about itself and its history of creation. Topics that are obviously only possible for a non-human being but at the same time feels oddly personal. Claptrap helps, chats, cracks jokes, instructs, his informative, and has a personality which all do not match to its flimsy little robotic body. The character continues to stay by the player’s side for most of the game but the first interaction is what really gives a connection and convinces the player that there is a deep storyline within the game.
The location that I place the user in is a desert surrounded
horizontally with objects representing a dry world but juxtaposed with objects,
found in the sky, that complement the dehydrated environment. The identity used
as a basis for the project was complementary,
an adjective that explains how two parts can come together to “mutually supply
each other’s lack.” The desert is composed of dunes, mountains, rocks, and
logs, all familiar objects that one would expect to find in a desert. The sky
on the other hand, is filled with floating spheres covered with vegetation and
trees as well as floating blue cubes, representing the water that is supporting
the mixed environment. Not only do the orange-red colors of the desert
complement well with the blue-green colors in the sky, but the dehydrated world
also complements with the hydrated world. The four core elements are all well
presented as well. The earth and fire in the desert and the wind and water in
the sky. In our reality, there is some impossibility in having organic spheres
and cubes floating above a lifeless environment. This alternate reality on the
other hand, has other laws governing physics; this permits a natural yin yang of
elements to form.
Most of the prefabs I found were originally from a free
asset pack. The terrain was skillfully pieced together with scaled desert tiles
in order to give the user a perceived view of infinite dunes. Making sure that
the user couldn’t see the edge of the tiles gave a more realistic feeling since
deserts usually are quite large. In one corner a mountain range was set up with
differently scaled mountains to give the perception of depth. Other rock
monuments were also placed around the user to further reinforce the feeling of
depth in a large desert. Finally, a collection of stones and logs were placed
all around in different formats to gives the environment a bit more meaning.
Before adding in the complementary objects in the sky, the desert looked
essentially like one humans would be used to.
The feeling of being in an alternative world really started
with the placement of floating objects. Everything originally looked “normal”
but once the user started looking around and seeing things in the sky that were
not the sun, then their perception changed. The objects in the sky were also
populated by prefabs that were specifically rotated and scaled in such a way to
give the user a new experience. Some of the floating spheres and cubes were
placed far away and others nearby, once again to promote depth, but they were
also designed to all be unique in order avoid pattern recognition. A few were
also designed to have huge trees on small spheres in order to further inhibit
the user’s original basis of logic. By altering the user’s perception of
physics, this world that combined four elements in a harmonizing manner could
come to exist. This coordination would not normally be found in our reality so
it was necessary to convince the user that they were in a different reality.
In order to force the user to think a bit more, since that
usually helps a player connect better with a new world, some small details were
hidden in the environment. Some of the collection of logs and stones were
gathered in a formation that promoted purpose, perhaps urging the user to
develop a story. This is evident in the stones encircling a log, maybe
supporting the hypothesis that some creatures lived here and camped, or a group
of dead logs packed together next to a shadow, as if they fell from somewhere. These
details asked the user to perhaps look into the sky and seek out the source of
the logs or seek out the unknown creatures. After looking into the sky, maybe
the user would even discover that there were only 5 water cubes in the sky but
6 floating spheres. The last cube was at the foot of the user, buried in the
sand, perhaps for some unknown reason. My final goal was for the colors and
objects on the ground and in the sky to complement each other in such a way
that was usually impossible in our reality, all the while also giving the user
a story to explore and formulate hypotheses about.
I believe I did develop a story and an environment that came
together smoothly. Using prefabs from an asset package naturally limited my
possibilities but I feel that I achieved with what tools I had. Naturally,
there is always room for improvement, especially in a 3D world. Using low-poly
objects made it easy to pay less attention to details. Ideally the objects used
would have been a bit more realistic. This would have been more effective
because there would have been more room for storytelling and connecting with
the user’s experience. This would have required a much greater time commitment
which was not available for this project. This would have been time consuming
because the spheres would have to be carefully populated with even more well
picked vegetation and the entire desert environment would have to be designed
to better give the sense of sand and depth. Better representation of fire and
wind would also be done by implementing wind drafts and scorch marks in the
sand. I expected there to be more presence in this world but after designing it
I understand where the fault is. There is no movement in the environment,
giving the user the feeling that they are stuck in place. This could have
possibly been achieved by rotating the sphere and cubes and implementing some
sort of sandstorm. In general, the desired effect of this world on the user was
achieved but not nearly to the extent that was originally anticipated.
VR Minecart is one of those games you have downloaded on
your phone that you decide to play when you have nothing else to do. These games
usually have a very simple premise to them, they are incredibly simple, repetitive,
and addictive. The goal of the game is to collect gems and then use those gems
to upgrade your luck and life so that you can play each round with hopes of
collecting even more gems over a longer period of time. The rounds are quite
simple too, you are in a moving mine cart and you have 4 options of movements:
tilt right, left, stay center, or duck. There are blocks you have to avoid,
bombs coming at you, and gems of different gems scattered across. Naturally,
the longer you play the faster your mine cart goes, the more value the gems
have, and the easier it is to get hit and lose the round.
Your surroundings are all in sync with the idea of being in
a mine shaft that has to be abandoned quickly. You have saves and tunnels
surrounding you, the railroad is old and rusty, and the mine cart you are in also
seems to be running on its last wheels. The things that are flying at you make
sense too, you have bombs, boulders, pretty gems, and blocks with red crosses.
Keeping all the graphics in line with each other, at least in terms of theme,
make it so that the story is more believable. You are not incredibly immersed
but the constant theme at least makes the game more enjoyable by soothing any confusion
the player would have with the situation.
To add on to the effect, you can almost feel the mine carts movement. This effect is possibly through the constant shaking of the screen, almost as if you were truly on an old rackety mine cart. As you speed up the movement becomes worse and you start to become more stressed. The emotions present themselves in the necessity to act quickly in a scene filled with confusion. The good thing about such simple repetitive games, is that each round ends up giving you more thrill because you always end up progressing further and always want to maintain your highest score. The environment complimented well with goal of the game by providing simple obstacles and benefits that both scaled with time achieved per round.
In order to make an environment that truly feels alternate I
believe there are certain aspects I have to choose from to incorporate. The
first would be disrupting one of the earthly laws of physics. This would mean
removing something that ultimately makes up our logic. If this would be removed
something wouldn’t feel right which would give this environment an alternate
world feeling; a world that is perhaps in another dimension with different
rules. Some of the interesting laws to remove would be gravity or size. Objects
should not be able to float in the air without movement or be too large for
example. Second, I could give the environment a history or something that
preludes to something that has happened in the place. This would make the
camera or user feel like this is another world because there is an alternate
history that has taken place. To do this would require some creative planning.
Finally, having objects that are new or uncommon in our own world. This would
contribute to the alternate world feel because it would feel discomforting due
to the unknown surrounds. These objects could be weird shapes or illogical
buildings.
Different Laws
Floating spheres
Large orthogonal cylinders
Upside-down houses
Floating platforms
History
Walking individuals
Houses or villages
Forests
A desolate world
Uncommon Objects
Spheres will holes cut out of them
Infinity stairs
Impossible shapes
Fences that are placed horizontally instead of
vertically
Feb 12
After thinking about specific identities I decided on a few
to choose from: trapped, impossible, quiet, and calm. I slowly realized, as I
was working in Unity, to make something seem like it was going on forever
required a lot of work. It was also very difficult because it required you to
try and not make things appear in patterns since those were easy to identify.
I worked heavily on the terrain of my world today. I took from a prefabricated forest terrain and tried to copy, paste, and rotate to expand it. My idea was to make a large grassland tile that could then be repeated into the infinity to make it look like a long calming plane. As I was working on doing this I started to play with rotation. I realized how interesting it would be if the walls of the world slowly started to curve upwards. Almost making it seem like a trapped location. Finally I ended with a work in progress version of an upwards slanting grassland world.
Feb 14
After working around with terrains and grounds I understood
that it wasn’t always so easy to put different pieces together without
something poking out and disrupting the fluid feel. Especially with the
grasslands that I wanted to make curving up and around the player because you
could obviously see the dents where two pieces are combining. Because of this I
decided on a new approach to make it seem like the land went on forever
(without actually needing to repeat forever).
I restarted with the desert pieces instead of the grassland
pieces and I pieced together the same pieces 5 times to make a cross (with the
camera in the middle) (Pic 1). Because the enlarged desert had many hills which
repeated but all looked only slightly different, it was possible to hide the
edge of the world. Adding in a few mountains at different scaled sizes (and
rotated so that they didn’t look copy and pasted) also gave the impression of
depth (Pic 2). These two things together took away the need for a lot of labor
in piecing the ground pieces together.
The dunes and mountains alone didn’t give enough of a story,
so I added in some stones and logs to make the environment seem more like a
desert (Pic 3). On top of that, I found a few different terrains that I could
add into the world to give even more background. These terrains had different
color sets that didn’t fit in though so I had to apply to material from the
dessert in order to make a clean fit (Pic 4).
Feb 15
Now that I have a vaguely “normal” looking desert, it is
time to add “abnormal” things in. Since the desert had only non-living things
within, including the logs which all seem dead and dried up, the next step
would be to have something living. The goal was to involve these living objects
with either the identity “separated” or “impossible.” To do this I designed
floating spheres (very impossible) with vegetation and greenness all around
them (Pic 1). This seemed very abnormal because there were two colors that
deeply contrasted, the dry-desert-dead-orange and the alive-vegetation-green,
and two things that should not be found together. I designed 6 of these
different spheres and placed them all around the map in the sky. I made sure to
place different trees and plants on the spheres and also have them at different
sizes to once again mimic the depth in the map.
In order to further the impossibility, I decided to place
vaguely reflective cubes in the sky as well. I made on cube for each
tree-sphere. I made the cubes blue to mimic floating water which would make
sense, since each tree-sphere would probably need source of hydration (Pic 2).
After placing five cubes around in the sky, once again keeping in mind the depth and height, I decided to embed one into the ground. This would be close to the player in order to formulate a story or mystery. “Why are there cubes floating in the sky?” and “why has one fallen down, is something going to happen to the trees?” where the questions I was trying to formulate. The final map that I ended up designing had a lot of pieces to it which made it quite an interesting landscape. It also kept some room for mystery, making the player wonder what exactly is going on (Pic 3).
Feb 18
Just final touches were made to give the area a bit more logic. The water block at the foot of the player was made gigantic in order to correlate well with the huge size of the cubes in the sky (Pic 1). Similarly, the logs in front of the player were also made gigantic in order to relate to the size of the spheres they were falling from (Pic 2). Finally some of the mountains were changed in size and some darker colors were given to the logs to give them more of the “dead” look.
