Ron Gilbert talked about Maniac Mansion in a classic game postmortem at GDC. I’ve watched the recording for a second time now. Aside from the obvious fact that Ron is an excellent story teller, there’s a few learnings and notes that I took away again. Some of the things he learned and mentioned were processed in his manifesto of Grumpy Gamer – Why Adventure Games Suck. Some, however, stood out for me this second time I’ve watched.
Some 9 minutes in, Ron mentions they wanted to make a game but they didn’t have a story – and they formed ideas as they went along. It sounded a little bit like they were tinkering around for a few months, before they really had an idea or sorted a plan to move forward.
That revelation is kind of sweat inducing for many PMs – how would you move ahead with an idea or a product and start coding and tinkering, if you don’t have a plan or good idea of what your product should look like or what it solves or for who it is.
Now the sweat usually comes from the pressure of business, customers, users who demand that your product evolves – the bills have to be paid after all. So you better deliver a good story of what you want to solve and show a way forward for the product so Engineering can build meaningful stuff. Take the financial pressure away, and the sweat goes away as well – and you may find time to tinker, explore, see where the winds take you.
I suppose that’s somehow what the setup at Lucas Arts back then – no financial pressure other than “don’t lose money” – and try and make fantastic games and tell wonderful stories. Imagine a setup like this: you actually could spend your sweet time, do some market analysis, look at the competition, see where everyone else is headed, find a good story you want to tell, and the tone you want tell it in ( – the product that customers will want to buy), and – most importantly – in the innovative way you need it to be built, so customers love to use it, buy it, play it.
That’s also the world in which a lot of entrepreneurs find themselves in – not actively looking for building a product and getting inspired by a problem or challenge, solving for it and getting it out on the market. Without the pressure, there’s more time to find the right problem to solve, and then solve it right.
There’s great power in being able to channel your inner innovator as a PM and find the problems and solve them right – especially if your product area is scoped and you’re not free to invent anything you want – but your company has this portfolio they want to stay in line with, to be able to sell it to established customers and markets, possibly in conjunction with other products they want to sell. So it’s hard to find your wiggle room in innovating, exploring, creating a net-new product – and finding yourself to an extend that’s comparable to what Ron mentions in the video.
Still, if you can pull it off, it can give you great freedom in figuring out what your next moves with the product should be – and move towards these goals. You may not be able to completely build a new product or work counter your company’s direction and portfolio – or convince the company to build your idea. Yet, you could use that entrepreneurial thought process and see where it takes you and your product responsibility.
Another impressive learning was that they got to take their time to build the right tooling for the game they envisioned making. Only in the process of building Maniac Mansion, they built the SCUMM engine, that allows for scripting the rooms, the environment and actions the player takes with surroundings and objects. The engine would later be used in other games such as the Indiana Jones games, or Monkey Island – with enhancements and improvements.
I had thought they had the idea of building SCUMM going into Maniac Mansion – but it sounds Ron got the idea from a new colleague of theirs. I like the idea of making it so that you have the right tools and the right foundation to build upon. Building this scripting engine that allows for easy scripting of scenes and make fast progress in building out the game without creation of complex code or re-compiling the whole game, allows for a lot more flexibility.
It’s a story of: build your foundation right, and you will be able to benefit from it later. Making slower progress in the beginning, but getting your backend, APIs and scale under control, rules out ugly changes or fixes that your users will suffer from later. I can only imagine how many bugs along the way were easier to solve through changes in the script, as opposed to having change the underlying machine code. It also allows for divide and conquer: you could give a broader team of developers and designers access to the scripting environment and scripting language, and get them to build out the story in a broader team effort. The hurdle to get them to use the scripting language, if done right, is lower than teaching them semi-machine code or the programming language – or the the way you want them to program so it fits your needs, including the dependencies to which libraries, etc. to use.
The way the SCUMM engine was used after, justified all of the development work: the system was used in a lot of other games after – Indiana Jones, Loom, Monkey Island, … the model certainly was a success, and by leveraging the engine in more games, focus could shift from having to think about how the program code and story will be facilitated technically, to design, art, story itself: other things that end users and customers will enjoy.
That doesn’t mean that the v1 of the engine was perfect – It underwent changes along the way. First generalizing it for other games (getting rid of hard-coded Maniac Mansion references) to game-specific changes such as for Loom that used a different, innovative user interface. Clearly – over time, resolution, hardware restrictions and technical capabilities changed, such that there were other changes to support the next game and make customers happier – but these changes could be made on the engine, without affecting how developers worked with the script.
Test and validation is another one of the learnings that I noted down. Being able to test and validate very fast, trying different things out and see if they work or not, is vital. The SCUMM engine provided for a fantastic toolset to very quickly introduce smaller changes to the script and story, adjust nuances in the dialog, and try them out and see how they work – and whether or not they support and carry the story forward. If there are major code changes need to turn an idea around and try it out, give it to testers to try and see, this will prolong your development process – and stop ideas and experiments from being “just tried”. Give yourself the framework and the toolset to quickly iterate on changes and ideas – and don’t artificially lock yourself in, because deployments can only happen every month, or the process requires a fully approved spec by multiple parties and be signed off by PM, Dev, Test and Design before progression can happen.
Whatever you do – don’t punish the user. This sounds like a no-brainer, but can happen a lot easier than you think. Being able to progress to a specific configuration, but then not being able to save the progress thus far – or forcing the user to complete all dependencies, without telling them what these dependencies are, except for throwing error after error that tells them. Don’t trap the user or let them delete something they can’t restore or re-create themselves. Nothing is more frustrating than starting a wizard or a configuration, and not being able to progress, because you didn’t follow the seemingly artificial pre-defined order of satisfying the dependencies.
FRICKELSOFT 