UPC PostMortem

Ultimate Parkour Challenge Post mortem!

Published by Kienauer Rene

First prototype of the movement system. This was roughly 2 months before the submission deadline.

A Xbox controller is needed in order to play!



As part of my games programming education at SAE Vienna we where tasked to develop a game prototype in about 3 months. I had help from one of my colleague and friend Lukas Schuetzenhofer who was the second programmer on this project. The last week before submission we got some support from two audio designers who made some sound effects and a dynamic theme with the help of FMOD. We also got some feedback from Game Designer Alexander Grenus who provided us with his knowledge on game design. Originally we planed to have an animator on the team who would make the needed animations but sadly he was not available so we used free animations provided by Mixamo. Because this was not my first project we wanted do something quite ambitious.


At the time I was watching a lot of Super Mario 64 Speedruns and was completly amazed how much depth the game had in a proficient enough players hands. So the inital idea was to do a third person jump and run with an expresive move set that players could use to chain move after move.


The first few months were spent in the playground level you see above fleshing out the core move set. Very quickly we had a move set consisting of Run, Jump, Long Jump, High Jump, Wall Dash, Wall Run, Ledge Grab, Dashing and Swinging. One of the hardest things was to get the jumps to feel right. There was an very essential Gamasutra article for us which went into great detail on how to craft a good jump. We also realized that making a good enough third person camera in our time frame would not be possible, so we pivoted our initial idea a little bit and made all our levels as linear as possible. We started building the hard levels first because at that time we were not sure if our move set would work in practice. Building the levels involved lots of playtesting by ourself and other people. The tutorials were very hard to craft and nearly every tutorial level was at one point scrapped and rebuild from scratch. The last thing we iterated quite a bit on was the feel of speed. We realized very late in the project that the feeling of accelerating and speeding through the level were integral to the players experience. We played around with acceleration curves of the players movement speed, field of view effects and trails on the player.


I was quite suprised that lots of vector math was involved in crafting the players move set. In nearly every move somhewere there is at least one dot product hiding. After the project I felt quite proficient in my abilites to do all kinds of vector math. We also took a while to realize we have to use a state machine to be able to transition between the moves in code else we would have had lots of spaghetti. You have to consider that which move is triggered is greatly influenced in which state the player is, for example it is only allowed to long jump if the player is currently sliding and presses A. The animations were not as big as a problem as we where anticipating because our animations were triggered via the state machine and we did not have to build out the animation state machine and could just play animations when the player did enter a state. Because we did not have all animations we needed we sometimes just took one frame we thought would convey the move the best and did just blend to that frame and freezed the frame for the duration of the move. One thing that was particular hard for us was building an intuitive third person move set that controls well. If you try to rotate the character about 180 degrees you can see the issues we have when the player tries to do rapid movements. Luckily we realized that early on and at least changed the design so it does not get in the way all the time. The other usual challenge was managing the code architecture and ensuring that the projects code had at least some consistency and thought behind it. I dont think I can ever be happy with the architecture just because you have to make trade offs. It is not the goal to make clean code, the goal is to make clean enough code and make something fun along the way.

End result

All considered I am quite happy with the end result. We did lots of playtesting and there were quite a lot of people who said they liked it very much. The critcism we often got is that the controls feel off and I totally agree with that and believe if we had more time we could have polished them more. The second thing people always bring up is that even the tutorials are much to hard for them, I mostly blame that on suboptimal controls but acknowledge that tutorials shouldn't be hard. World 1 and World 2 were designed with very hard in mind because we wanted to take our move set to the hardest levels so we can understand how it would work in a SM64 Speedrun like context.