This class
has truly been one of the biggest learning experiences that I have experienced
thus far at Georgia Tech. Many classes
have claimed to teach how to code in a language, or how to work in a team, but until
each person is actually forced to put their learning's into practice, there is
no way to tell if anyone retained any knowledge. Through building an entire game with a group
of individuals with different skills, I have not only learned valuable coding
lessons, but also valuable lessons as to how to deal with a group
environment. The game we decided took a
unique approach on the idea of a interface in a video game. This presented many obstacles as well as
chances to really express our creativity. As for my specific role, I was the pure
programmer on the team. As such I was
forced to communicate with different aspects of the team as we progressed. Having to do this taught me how to interact
with different people, and get your needs across. This reached from design of the game in the
beginning to bug testing in the end, and is something that I can take away from
this to use in the workforce.
One of the
hardest part about this final project would have to be the evaluations we were
asked to do about our fellow team mates and ourselves. I find it quite easy to find errors in my own
actions, but speaking about others was very unnatural. In addition,
saying things that would be constructive rather than destructive was a
challenge in itself. It's too easy to
bash someone for not doing things they way I want them to be done, but finding
the solution to a mutual problem is something I have yet to master. Another aspect of the development process
that was a little difficult to me was trying to draw the line of accepting what
the group has chosen, and what I thought was best. Sometimes if art assets didn't quite look the
way I imagined them I was forced to take a moment and continue on with my job
on the team. Later if the opportunity
presented itself I would give my opinion, but since most projects done in other
classes were solo, it was a personal obstacle I had to overcome.
In terms of
taking readings that we have done over the semester and applying it to our
game, while our original games started with more of a New Games mentality, it shifted to be more of a talk about
representing space. Because of our
mechanic we were forced to have a set end state and a level system, which
strove away from New games mentality. Dekoven
I feel really wrapped up the idea of our game, "if making an exception
helps us have an exceptional game, anything is alright." I feel like this ideal is what we were
striving for as a group. We wanted to
create an exceptional game using mechanics differently than everyone else
did. Dekoven also speaks about how the
player can "become the author" through "their ability to change
the game". This was something we
had to consider when designing the game.
The flexibility of the user to be able to use the interface elements
would determine how the level would be solved.
Despite our limits on movement of said objects, on many of the levels
there are still multiple ways to win the level, which gives the user a
"sense of authority" as Dekoven puts it.
Dealing with
designing the player's character was a major topic of consideration when
developing this game. At first we just
assumed that the character would be male, a possibly byproduct of us having all
male team members. After giving it some
thought we decided to create two characters, one male and one female. The problem with this that we ran into was
that since the character would be small, the only defining feature that would
indicate you were playing a girl would be breasts. This wasn't really something we felt was
terrible appropriate. In the end we went
with a modified version of our original male model. We feel that at this point the character is
more gender-neutral, or at least is on a scale where the gender of the
character would not come up in analysis of our game.
One of the
biggest concerns in dealing with this task was understanding how the audience
would react to different things being thrown at them. Many groups were able to assume base
knowledge of how games work, but since we were looking to submit to IGF, we didn't
have that luxury. Constantly throughout
development of the game we were getting outside resources to test specific
aspects of the game in order to ensure that it made sense to everyone
involved. Even with all the precautions,
there still were many things that we had to leave up to the player to
understand, but we tried to leave hints along the way in the form of
signs.
Overall, the
way this course was organized helped the group understand how and when to make
pivotal design decisions which sculpted the shape of the game. As a programmer, being able to pick
designers/art people's brains allowed me to help bridge the gap between the two
spectrums of the gaming industry. I feel
like this class embodies the ideas that Computational Media try to convey, and
should be a must for anyone looking to leave Tech with this degree.
Word Sited:
De Koven, Bernard. "The Well-Played
Game: A Player's Philosophy." New York: Anchor Books. First Edition, 1978.
Comments
You can follow this conversation by subscribing to the comment feed for this post.