No More Monkey Business
No More Monkey Business is a fun tower arcade game where you play as an angry monkey who was just fired and decided to destroy the whole office. Of Couse, the police do not like the idea, so they try to put the raging player in custody. The player's goal is to break objects and unlock the elevator to progress to the next level and not get killed by the police in the process.
Responsibilities
I developed the user experience and visual feedback. Additionally, I fully implemented chaos physics features into our game project and profiled the performance of the game to solve bottleneck problems
Project info
Role: Programmer
Span: 6 weeks
Team Size: 14
Engine: Unreal 4
Chaos
For breaking the objects and making a mess in the level, we used the new Unreal Chaos Destruction system. My main reference point became Chaos Demo from Unreal Asset store which I analyzed piece by piece and learned all I could from it. All the usage cases documented online were not suitable for us, because they did not consider a huge number of objects that would need to behave independently and be easily placed in the levels.
​
The whole workflow with the system felt very hacky and instead of using it as a tool that would make it easier to achieve desired results we had to adapt to the flaws and find new solutions which were not documented anywhere. It would have been great if I was more proficient in reading C++ and understanding the engine code which hopefully would’ve helped me to implement everything in code but due to lack of time and knowledge, I have decided to use only blueprints for the breaking objects which had some downsides. Overall, breaking objects consumed the most time in the project and required me to get out of my comfort zone and look for solutions beyond Google.
​
With the Chaos Destruction came another challenge - Chaos Physics. We ran into lots of different issues like breakable objects flipping or breaking during level loading. We found some unimplemented functions on the engine side and weird physics behaviours like objects falling asleep in the middle of a throw. Overall, the whole system felt unfinished and hard to work with which led to the conclusion we should not have used experimental systems in the first place.
UI and menus
For UI I chose to use blueprints. The main downside was that I had to deal with Widget animation curves while I would’ve preferred doing it with the easing in code. But I managed to make a fully customized UI with lots of animations to convey different interactions and improve the overall dynamic experience and lead the player through the game.
I used the widgets in the world space for word pop-ups. This system became part of the health component due to a lack of time. I usually avoid using text in such simple games but in this case, all the dynamic animated texts simply added a lot to the game.
In addition, I made a filter for the words to display censored or uncensored swear words just to make it more dynamic and allow the player to have some preferences. It was one of the more fun tasks in the game I did because I got to animate many different elements and put them together to make a nice addition to player interactions and a more chaotic feeling in the game.
Performance issues
Our game had lots of different performance issues throughout the project. I took responsibility to at least attempt to fix some of them. Often we thought it was the physics but every time it would end up being some other systems not being optimized. I investigated lots of different optimization methods, learned to use a profiler and learned some interesting quirks of the engine.
​
Though we never fully fixed physics acting weird or the fatal crash in the game, because both of those issues are from the engine side, and we cannot do anything about it. Overall, that was a great experience and I have learned a lot of dos and don’ts. If the game would’ve been perfect without any of those issues, I doubt I would’ve ever cared to learn those tools.