Overview:
The premise
of this game is really interesting. It is 2.5 D worms style game where you play
as the antagonist, a cave dwelling monster that is trying to protect itself
from the explorers, by freezing them and trapping them. You must avoid light
throughout the game and since the explorers carry flashlights, being near them
for too long depletes your health. So your goal is to come up with tactical and
sneaky ways of freezing them, before they find you and kill you.
My contribution:
- I developed
a Player controller script from scratch, which essentially manages the core
mechanics of the player like moving around, jumping and climbing.
- While
playing around with the physics of the player, I implemented this really cool
infinite ( yes, not double or triple, but infinite) jump mechanic which I am
really proud of. We obviously had to set the maximum jumps to 2 for the game.
But, this is something that I thought was really cool and I will probably use
this in some of future projects.
- I integrated
Alice’s 3D model for the monster into the game and with the player controller.
- I
integrated the main camera with the player and fixed a lot of camera
synchronization issues.
- I designed
the lighting system for our level.
What I learned from this prototype and the positives and
negatives of the process:
Positives:
- I got to
work with an artist and for the first time ever got to add a completely
textured 3D model into my game.
- We set up
a SVN server for managing our code, which I think is a must have for every
prototype.
- Alice’s
model looked really cool and fit well with the theme of our game.
- All the
programmers spent a lot of time working together in the lab, which was really
productive.
- Our
communication was great.
Negatives and What I would have done
differently:
- Our game
mechanics were pretty ambiguous and no one was willing to sit down and discuss
them in detail, thinking it was a waste of time and that we should start
working and then see how they work out. I pointed this out a lot of times but
gave up in the end. This led to a lot of problems later when we had to merge
the mechanics together, because everyone had different ideas about how the
mechanics worked.
- Our
producers thought it was a good idea to divide work based on roles ( UI
programmer, mechanics programmer, etc ), which did not work out very well.
Things got messy as some features overlap roles and we did not know how to
split them. So we decided to divide the work based on features from further on.
- Unity is
not really programmer friendly and when working with a team of 6 programmers,
it can cause disasters. Merging the .scene files in Unity was a task in itself
and caused a lot of issues.