Software and s/w Development

Oct 31, 2013 (4 years and 6 months ago)

138 views

Jesse Ingman

CSC227 3D game Programming

12.4.2012

Postmortem

Cave of Unimaginings

This has been a good, long ride making this game. Starting out, the idea was to have a strange maze that
made the player feel like they really were in a truly unique
place, strangely taken from their comfort
zone. Being thrown into this world, the player was to guess that the goal was, ultimately, to get out and
back to freedom. I wanted elements in the game to put the user into this experience, like spooky
sounds, uni
que areas and telltale signs (metaphorical and not). I didn’t want the user anywhere near
their comfort zone, so that they would be projected into this environment by proxy.

What went right

Its hard to say, in hindsight, what really went “right”. The maze

was both trivial and unique in
that it could be arranged mathematically, but there were still inconsistencies with how to manage all of
the space. On paper, with the initial designs, space between walls and the negative space in general
didn’t have to be
measured; it could have only been thought as a 20x20 grid twisted into a maze.
However, dealing in 3D changed that on a dime since I wanted the walls to be realistic (not pencil thing)
but still accomplish what I needed to easily. I was able to make apps i
n java, standalone to the game
itself, that calculated all of the coordinates which made it much easier to do. It became a sort of pattern;
I would go through each row (relative to the camera) and, referencing the design on graph paper, find
which columns
had a wall and which wouldn’t. The pattern could be turned into numbers, ie 5, 4, 2, 7, 2
would represent a row that had 5 walls in a row, followed by 4 blanks, then 2 in a row, then 7 blanks,
then finally 2 at the other end, and this made it really easy t
o make the maze itself.

Another area that turned out really well was the design of the mechanics, in particular the
linking of trigger points and their walls, as well as the other techniques used to unlock more of the maze.

Knowing the methods I used came

in handy very much, such as using sendmessage with the walls that
needed keys to unlock, and requiring different keys for different doors (getting 1 key opens one door
and not the other, and visa versa).

A really fun part of the game that, to my surpris
e was useful and added value to the game, was
the lightmapping. I used lightmapping only secondarily to save on performance, as I was more focused
on getting the game primed and the mechanics in and functional. The primary use for lightmapping to
me was to

us it as a theme for each level. As you progress through the 3 difficulties, each maze gets
progressively darker, making the hidden bonus’ within the maze worth that much more to the player,
and enticing the user to explore the maze, which adds to the exp
erience.

What didn’t quite go right

One of the first issues I encountered, although trivial, was associated with the animations on the
various objects for show. For example, the final diamond that you must get to complete the maze,
hovers up and down in
place instead of hovering in a single spot, motionless. In Unity, making a curve on
any 1 transform element, such as translate on the Z axis, would also lock in the other axis’, regardless of
if you altered their values or not. This meant that for each lev
el, if an item moved to a different spot in
the maze (such as the door opening animation or the final diamond animation mentioned above) it
needed its own unique animation per maze. In the end, there were 4 diamond animations; 1 for all 3
levels for a hidd
en diamond that lights your path, and 3 for the final diamond; 1 for each level. This
made debugging quite confusing as in the editor an object would start in the first frame wherever I had
put it, yet it would instantly translate to the same spot it was i
n the last level, which made it a nightmare
to figure out why it was doing what it was doing.

Another element that impeded development was the creation of prefabs. For example, the frst
time I ran into this issue is with the intro where the user walks do
wn a creepy, valley
-
esque aisle. I have
a single prefab that’s sole purpose is to hold a collection of textures, used for cryptic messages that
show up throughout the scene. I used a script to manipulate them, so I had none instantiated in the
game world t
ill I needed them. If I ever ran into an error with even 1 of these prefabs, it meant I had to
take the prefabs and instantiate them in the editor, change what was broken, delete the old prefab,
recreate the prefab with the updated objects, then go through

all the scripts in the current scene and
reattach all the respective objects. This made testing laborious in that it involved this long process to
change each object and get it to work in a way that allowed me to progress.

What I learned

I learned many m
ethods of how to prevent delays in the development cycle. I learned that math
is a very useful tool in layout and design, as its consistent and can be derived from patterns, algorithms,
anything that can manipulate numbers.

I learned the importance of usin
g various (sometimes fine
-
grained) planning processes to ease the development and prevent errors, such as the issue described
above with altering prefabs. This showed me the importance of putting everything on paper and making
a physical or symbolic protot
ype before jumping into the technical design and implementation. In
designing the maze, it taught me the importance of taking every design element into account, especially
when it comes to 3D layouts and design considerations. I learned how Unity deals wit
h animations and
curves, as well as how to manipulate various objects/components in a script, and what can and can’t be
done through simple means. This project also showed me the importance of iteration and play
-
testing,
as well as how a team can divide it
s focus between the parts of the game. As well as design within Unity,
I got some valuable information about design outside of Unity, such as the 3D models I made in maya.
The main issue there was that as of now, theres no direct translation between textur
ing in maya, or
other 3D modelling programs for that matter, and the materials. I had various issues taking a model
from maya, with the correct UV mapping and materials to suit my needs, and translating it correctly into
Unity. Things like the diamond mode
ls transparency, reflectivity and color properties cant directly
translate from maya to unity, so it took some clever tricks (such as special lighting per object) to get
what I wanted.