Delirium: A Postmortem
Roughly two years ago, I began work on a project that would later become known as “Delirium.” The project was intended to be a 2D horror platformer made in XNA, and over the course of its development, was featured in university publications and sponsored by our university to attend GDC in hopes of showing off the game. Despite the wonderful efforts of the team and all of the hard work we put into the game, it was never released past an early demo, and the project ultimately ended in May of 2012. Although this post is long overdue, I chose not to write up a postmortem until the realizations of our successes, failures, and what we learned had fully sunk in. The following write-up will examine what exactly the Delirium team did right and wrong, why the project failed, and what we can take away from it all, even a year later.
The Project Proposal
Delirium began, like most things do, as an idea. I had a very vague idea of what I wanted to do, but I knew what resources it would require and what I wanted the end result to achieve. Project proposal drafts discussed in length how I wanted to ignite innovation in the horror genre of games, and that was what I felt, at the time, was most important to the project. After working on several other projects throughout my time at university, I understood that minimizing scope would be crucial to the success of the project, and I felt that I had a good handle on how to handle things. I decided early on that I did not want to outline the entire story myself, and wanted to give freedom to my team so that the story and mechanics of the game could be influenced by everyone. Although this seemed like a great idea at the time, it eventually lead to major problems later down the line. In retrospect, I should have done more work on my own to establish the game’s core. That way, when I did bring in a team, they could make suggestions and help shape the game to what everyone wanted, rather than trying to mash a game together out of a million different ideas.
Recruiting a Team
I had noticed a trend on other game projects, where recruitment was largely instigated by word of mouth, and once you joined a team, it wasn’t always clear exactly what you were responsible for. With Delirium, I wanted to ensure that everyone knew their responsibilities before joining. I set up a simple blog that included a description of the game and its end goals, as well as a job postings. By having interested students actually apply for their desired positions, it helped weed out a lot of people who weren’t serious about the project. In addition, I scheduled casual interviews with those who did apply, just to make sure they were the right fit for the team. Even if someone is a great artist or programmer, that doesn’t always mean they will mesh well with your team dynamic – something I’ll discuss more in a bit. The recruitment process went well, and although we did not receive a lot of applicants, those who did join proved to be invaluable team members. Looking back, I think we could have made a bigger push for recruitment; keeping strictly to students at our school narrowed our talent pool, and we could have easily looked towards other schools and even other indie developers.
Lack of Direction
As I noted earlier, the game was very vaguely outlined, as I wanted to give the team the freedom to create a game we could all call our own. This became a problem very quickly which would haunt us until the game’s demise. Our first few meetings were merely brainstorming sessions, where I presented a sort of spine for the design of the game, and we would collectively try to craft a story that followed it. The design team also held our own meetings, where we would hash out more details, but without a clear direction for the game, it became very difficult. I was acting as project manager, producer, and lead designer at the time, and only had two other designers working with me. In one of my greatest mistakes on the project, I assigned one designer to flesh out the entire story, despite his want to work on the puzzles for the game. As I saw this designer struggle to craft a story from a slew of ideas, I decided to bring in a writer to help ease their burden, when what I should have done was sit down and finish working on the story that I began. The writer we brought in immediately added to our problems. He was late to meetings, if he showed up at all, and was merely rewording what the designer had already written, without adding anything new. We eventually decided to let the writer go, as it was clear that he was not very serious about the project, but at this point, it was already weeks into the project and we still had a mediocre story at best. Furthermore, with the lack of direction coming from the design team, the artists were unsure of exactly what they should be doing, and the programmers were busy trying to create a framework for a game that really didn’t have any features set in stone. Team members were beginning to grow uninterested, and I began to wonder if this project was going to last.
Rallying the Team
Just as things were starting to look rather bleak, we brought in a producer, and that was a major turning point for us. The producer was able to rally the team and help get everyone excited about the project again, as well as help ease my workload and better establish milestones and sprints. Things started to get back on track, and soon, we were able to crank out a working build of the game’s first level. There was still a lot of work to do, but with the producer’s help, and tangible evidence of everyone’s hard work, we were able to keep moving forward. The design team was a bit more coordinated, although the one designer was still the only one really working on the story; the art team was tweaking animations and creating art for the menus and items; and the programming team was growing in numbers and cranking out code for upcoming features. We brought on a sound designer, and began to prepare for our university’s GDC pitch, wherein teams would pitch their games to a panel who would decide who gets to go to the conference as representatives of the school.
The Pitch
The GDC pitch was our time to shine. We had worked extremely hard leading up to the pitch, and we now had a playable build we were comfortable showing off, along with a teaser trailer and a professional presentation. Our producer, who was an online student, actually flew out to help us with the pitch, and things went rather well, despite my sudden stage fright during the presentation. We were the smallest team there, and had a very different project from the others, but I have to say that everyone on the team did an outstanding job and the judges and audience really seemed to enjoy our work. I was admittedly nervous about our chances after seeing the other projects, but in the end, the school selected our team to go to GDC. It was an exciting time for all of us, and only boosted the amount of work we were putting into the game to make it ready for the conference.
GDC & Team Dynamic
During the time leading up to GDC, which was held in early March, the team pushed out a lot of work and polished up our current build. Things seemed to be going well, but it was still obvious that the early lack of direction from the design team was still haunting us. The game was not where I wanted it to be by the time GDC rolled around, but I was still pleased with what we did have and hoped that the comments and critiques we would receive from conference attendees would help us to flesh out the game more. As the university was sponsoring us, they created a few promotional materials for us, including team shirts with our logo on the back and DVDs with the game’s demo. We wanted to give out more swag, and decided to start a GoFundMe campaign to raise money. Although we fell short of our goal, we did raise enough (thanks for our generous friends and family) to order stickers with the logo to pass out.
The entire team arrived in San Francisco, ready to show off Delirium at GDC 2012. Overall, I think that the trip went well, despite a few complications. Although the university was sponsoring us, we did not have a booth to showcase Delirium, and setting up a table or anything like that was not permitted. Still, we tried out best with what we had, and handed out all of our DVDs and loads of stickers. We managed to get a few interviews here and there, but unfortunately, none of them were published. We may not have gotten the publicity or response we were hoping for from GDC, but the team dynamic skyrocketed. The team dynamic had always been fairly positive, but communication wasn’t always the best, and for the most part, we didn’t hang out outside of working on the project. The trip to GDC helped team members get to know each other more, and from this I realized that we should have been doing more of this during development. It was apparent that those members who got along outside of the project were better collaborators, and that’s something I wish we would have been pushing more early on.
Post-GDC & and the Disbandment of Delirium
We all came away from GDC feeling inspired, and the university asked us to present our experiences at the conference during Tech Forum, a bi-yearly event where various speakers come and talk about advancements in technologies and give advice on making it into their respective industries. It was an honor for us to speak, and you can actually view our slides or watch the stream of our presentation online. Overall, we were feeling good about Delirium, but then the post-GDC syndrome hit us. We had all had a great time at GDC and didn’t really want to get back to work. This, along with the fact that many of us were getting ready to graduate, caused the project to suffer. Some of us had left our motivations in San Francisco, while others became consumed with schoolwork and graduation. Communication dwindled, work loads all but disappeared, and members stopped showing up to meetings. It was a trying time for the team as a whole, and when the semester ended, so did Delirium.
Looking back now, I understand that this was something that had to happen. We had spent a lot of time and effort on the project, but it was becoming very difficult to maintain motivation and members. There were a few members who were upset to see the project fail, myself included, but I think that without Delirium’s failure, we wouldn’t have been able to learn what we did and use that knowledge to move forward. I am extremely proud of the team and what we did with Delirium, and although the project ultimately failed, it proved to be a worthwhile experience nonetheless.
A Year Later
It’s been over a year now since the disbandment of the Delirium team. We’ve all moved on in our own ways, and many of us are working on our own projects. Every now and then, I’ll see one of our stickers and think back on the experiences we shared. I think it’s important to note that the failure of Delirium cannot be attributed to a single person or problem, but rather, a culmination of problems we just weren’t prepared to deal with at the time. As I prepare for my next major project, I wanted to share a bit of advice for anyone out there who aspires to make their own game:
Making games is challenging, but if you can make it through the hard times, it will be well worth the reward. And even if you don’t finish your game, look back on it and understand that this was merely a stepping stone to something better. Even the greatest of companies have their fair share of hurdles. Keep learning, and keep making games, and eventually, you will get it right.
I want to extend a huge thanks to the entire Delirium team for your hard work and dedication to the project while it lasted. There were a lot of things we could have done better, but there were a lot of things we did right, too. I also wanted to extend gratitude to everyone’s friends and family who supported us during development, as well as the University of Advancing Technology for their support and sponsorship. It was a great run while it lasted, and although this postmortem is long overdue, I hope it cleared up a few things. Thanks for reading, and feel free to ask me any questions you might have about Delirium or running your own team.
Simply Design 
No trackbacks yet.