Diana Calistru
Robot Wipeout
Robot Wipeout is a 3rd person beat-em-up game(show) where you fight against hordes of nasty bots and dodge deadly hazards, all for the entertainment of the gullible public. Smack your way up to the top, where Buff Marley, Heal Armstrong, Steve Knocks a.k.a The Bosses, are waiting for you to give them a beating!
Lead Programmer
21 people
Unreal Engine
About Robot Wipeout
Robot Wipeout is a 3rd person beat-em-up game(show) where you fight against hordes of nasty bots and dodge deadly hazards, all for the entertainment of the gullible public. Smack your way up to the top, where Buff Marley, Heal Armstrong, Steve Knocks a.k.a The Bosses, are waiting for you to give them a beating! Fight through a variety of challenging stages and become the ultimate Wipeout champion! ...at least until the next instalment of the show.
Project Roles & Responsibilities
Lead Programmer
-
Involved with planning and managing the programming team.
-
Cooperating with the Lead Designer and Lead Artist to ensure productivity and good interdisciplinary communication and organization.
-
Agile Project Management through Atlassian Jira.
Gameplay Programmer
-
Implementation of gameplay systems such as Dynamic Stadium Audience, Saving and Loading, Player Scoring, Gamepad Support.
-
Set up Jenkins server with continuous integration and building.
-
Profile and optimize the code.
Lead Programmer
As Programming Lead, I attended production meetings weekly and reported on the Programming team's progress, also noting down if everything is on track. I spent time reviewing tasks, as well as grooming the backlog and having an active role on what gets prioritized or if needed, scrapped.
UI Programming
I worked together with the UI/UX Designer to implement the game's menus and player HUD.
Main Menu
HUD & Scoring System
Robot Wipeout features a diegetic 3D Main Menu where the camera moves and focuses on different menus while the player transitions through them.
The player scores based on chaining attack hits on enemies, which is also tied to a grading system that multiplies the earned score.
Audience System
Since the game is about a beat-em-up gameshow, it was important that there was an audience inside the stadium that would make the levels feel more alive. I worked on the implementation of the dynamic stadium audience system.
In the beginning, the audience was supposed to show up at certain points in the arena and watch the player up close. This is a prototype of that system:
I made a simple and easy to use blueprint for the designers, accompanied by a video explaining how to use it.
Then, the team decided the audience should sit on the sides and possibly increase and decrease in size based on the player's score multiplier. I created 3 presents for audience density: Low, Medium and High.
Upon profiling the game with different audience setting options in a test level full of audience actors, I realized there is no significant change in performance between the Low, Medium and High density options. Therefore, I decided there is no need for an audience density setting in the game.
My teammates decided the audience should visually be the same during a level, so I decided to implement a custom audience density setting in the video settings instead:
The audience is seen and heard on the outside ring of the stadium, cheering the player on based on how well they are doing:
Profiling and Optimization
The game was running at a very low framerate, even though the levels were relatively small and there weren't a lot of entities on screen at once. So, I used the Unreal Profiler to figure out what is slowing the game down.
During profiling, it became clear that the game was slowed down by the scene rendering thread.
The render pipeline was slowed down significantly by the dynamic shadow setup.
And indeed, there was a noticeable difference in framerate when all the unnecessary stationary lights were turned to static.
Stationary vs static:
I also checked the shader complexity and noticed 1 material that was a bit heavy, but mostly the materials used were good.
Removing overlapping light sources and building lights left the game running at about 40 fps.
Unfortunately, optimization was a last minute priority and the visuals ended up suffering for the game to run at a playable framerate. ​
In the game's postmortem document we reflected on this and acknowledged framerate should play a more important role during asset creation and set dressing, not an afterthought.