Intent
This was the last project we made for Forsbergs, both game design and art classes were to work on this project together for 2 months under supervision from a teacher. The requirement was to make a co-op game and a platformer was chosen after the whole team engaged in a brainstorming session with multiple different pitches.
Example of the different states of the player, white is idle, blue indicates running, oranges show different stages of wallgrabbing and walljumping, red indicates regular jumping and landing
What I did and how it went
My main task was gameplay programming. I made scripts that allowed for moving, jumping, wall-jumping, wall sliding and ledge grabbing. These worked pretty well with exception of the ledge grabbing.
I decided to have a main handler script that would determine the player’s state and then call the relevant scripts depending on the state. This allowed me to split up the different features into separate scripts that would only handle things relevant to itself, since I could assume any relevant checks for calling a method had been properly cleared by the handler.
This was due to an earlier project where I and another programmer made separate scripts that affected the same object. This led to lots of wonky communication between the scripts to determine who had authority over the object, but became real simple when I made a handler that determined who had authority depending on the information it was fed.
This also led me to be the one to setup the animation state machine. This was significantly harder as this was the first time both I and the animators had done anything like this. Whilst mostly functional, the animations did not look stellar. This was due to animators implementing root movement when the handler did not support it, keyframes being improperly handled during importing to support mirroring and in one case, just missing an animation clip due to a misunderstanding
A late addition I’m proud over is ramp traversal. I wanted to avoid slow awkward climbs and airbourne descents. The solution was to find a vector parallell to the ground and base the movement around it instead of the world’s X-axis.
Poor teamwork
The project was conducted under less than ideal circumstances.
Our supervising teacher quit after 2 weeks into the project with no replacement. The team had to switch locales around a third of the way in due to the school hosting an art gallery there, further splitting the team since we could no longer fit in the same workspace and had to spread out in the school basement. Personell kept diminishing as people left for internships. The team further fractured after it was discovered that the grade requirements did not actually need either co-op or the whole class’ participation and a small group splintered off to do a new project.
I also spent long stretches as the lone programmer available due to 2 others becoming sick at the same time. At one point I handled feature implementation, bug squashing, testing as well as learning how to import and set up the artists models, rigs and animations into unity for a week straight without support.
I spent the week after that at home as I had become burnt out.
Another movement example showcasing the ledgegrab. It was functional in my own testing environments, but proved buggy in the actual levels.
Initial info
8 designers initially. Between 15-20 artists initially. Both shrunk as time progressed. Development time 2 months.
Language C#
Engine Unity.
Platform PC.
Role: Programmer
Notes: Pressganged into assisting in model and animation imports. Character controller.
The animation state machine could easily be broken, getting the player stuck in wrong animation states.
