Ghostbusters: Sanctum of Slime
Year:
Platform:
Genre:
2011
XBox Arcade
Top Down Shooter
Role:
Level Designer
Game Overview
The Ghostbusters are back! As a very long-sighted prequel to the reboot film to come out in 2016, five years later. The idea was to make the Ghostbusters brand relevant again, reusing assets from the PS4 title Ghostbusters: The Game, to make an arcade top down shooter for Xbox Arcade. As a team, we were kind of in disbelief that we'd be working on such a high profile IP. Everyone likes Ghostbusters, and saw it as a kid from the team's generation.
Up until this point, we'd been a original IP company, and this was one of our first experiences with IP tie-ins and Work For Hire.
Design Objectives
The company was recently acquired by Behavior / Artificial Mind and Movement / A2M and this was the first title made after a change in creative leadership.
This had a domino effect to changes in the team organisation one of which was me as level rather than game design.
I went back to what I knew from Wanako Games; building levels, enemies, bosses and weapons and vfx for all of that.
A new state machine AI system which was planned to make enemies smarter and more interesting to fight. The game designer wanted a paper scissors stone system for the player weapons and enemies, which I set about populating to create engaging gameplay.
We'd never had an AI system exposed to the design team before, just behaviour selections with configuration from within Tongas, so this was something else that got us excited to work on the project.
Successful Features
The visual effects were great. The Tongas engine was still going strong. Lots of advanced shaders, particle and beam effects on display here. Things that the fledgling Unity engine couldn't yet dream of, although Unreal had them in spades. Meshes tended to look black because of the vertex density and normal mapping, but that was an unfortunate side effect of the source material we were using.
The state machine as a whole, especially it's interface, got off to a rocky start but improved towards the end of the project - we would later use this in the Voltron: Defender of the Universe to great effect.
The story was well written told through a series of comic pages, although they could have had an animated presentation.
The paper / scissors / stone idea is something that's since become very common, and for good reason.
Conclusion
Unfortunately the game was under a lot of strain from the very start. What was envisioned as a time saver, taking assets from another game, proved to be a major time sink for the art team. All the 3D assets where hirez and needed downsampling and then re-rigging which took longer than making new meshes from scratch would have.
The highly anticipated state machine did work, but had a byzantine frontend which worked like a time trap for the designers trying to use it.
The team was expanded grew to try and solve the issues, but this solution proved counterproductive - the most productive team member became swamped with meetings and training session to bring the new people up to speed.
Within level design things were complicated as well - all the planned levels existed as mounted by the art team (not design) but many were either empty, filled with copy paste gameplay or just incredibly difficult.
After going through and fixing a lot of the issues, I didn't have much remaining time for adding cool and unique game play to the levels. The core gameplay consisted of locking the players in room after room until all enemies within it were dead. This would have worked if the state machine AI had been mature before starting the project, but it was just ready too late. Towards the end, I did a major pass on all enemies, reconfiguring and in some cases rebuilding from scratch as well as changing the distribution within levels and the accompanying Lua scripting to make everything as fun as possible... and not crash.
The ECTO-4WD levels were kind of confusing since they switched from a top down view to a front on within the same level.
Aside from the practical decisions about how we worked, which were mostly out of my hands, I realised I'd not been a good advocate for how the team had been functioning up until this point.
My initial proposals for the core game design were rejected, but then partially accepted after the fact, resulting in what turned out to be a too-simple core loop backed up by features that just weren't ready yet.
If I could go back and do this again, then I'd give a lot more ground within the team, then constructed a cohesive plan of how to get the game built to specification.
As it was, there were too many chefs and not enough cooks.
