Insanity, sweat and a post mortem

Although the semester isn't officially over, it's a relief to say that in the end, everything worked out. It is a relief to be able to say we delivered the result of one (REALLY) sweaty year of work. It is a relief that the game did so well. And it is a relief it exceeded our expectations and apparently the ones of everybody who accompanied us during development.

Actually it is more than a relief. It is truly rewarding.

Screenshot from one of the rooms

For those of you who think post mortems suck have no intentio to read this Post Mortem and, luckily, learn one or two things about Insanitas and it's creative process, and just want a link to play, unfortunately I'll have to let you down postponing in a few days the download. Polishing and bug fixing never ends. :P

Crypt Entryway

To those of you who decided to proceed with the reading and have no idea what the hell I am talking about, a few weeks ago we presented Insanitas, a horror puzzle game developed as an interdisciplinar task at the Game Development course at PUC Minas University. The game was the result of a year's work that, after many problems, ended up being the project which got closer to the original concept we had.

And to those who have no idea what a Post Mortem is, click here.

That being said, I leave here my first (mini) Post Mortem. :D

But first of all, a short video to introduce the content of the project:

The game, whose development began at the second semester of 2012, is a horror escape where the player controls Lillian, an ex-nurse who wakes up on the asylum where she used to work. Lillian can't remember the circumstances that led her there and has to fight to survive in a claustrophobic environmet surrounded by mysteries.

The outside

During development I worked mainly as a programmer and eventually did some game design stuff. The game has three main levels and about 4500 lines of code (3000 written by us).

So, with no more delay, here's what worked:

• Starting over: The first part of the project began at last year's second semester and had a bad denouement. The lack of dedication of the group (including the one who is writting right now) and the non fulfillment of a very specific tasklist resulted in a poorly finished prototype stuffed with bugs. And building the rest of the game upon a system that didn't work or wating time trying to fiz it didn't seem to be good options. Restarting the project we "lost" six months of work, but we gained workflow and quality. Specially considering we already knew the problems we would have to face.
• Object Oriented Programming: Although highly concpetual, the subject revealed itself to be miraculous very useful during the planning and implementation of the gameplay mechanics in Insanitas. There are design patterns in the itens, interface, menus, quests.... Studying a little deeper about how object oriented programming works assured the creation of robust and reusable code (even ouside of the project), which was essential to guarantee the progress of the rebuilding the content that was supposed to be done six months ago.
• gGUI: Although Insanitas is a horror game, which demands a clean interface for deeper immersion, all of the interaction with itens is done through specific dialogue boxes. And those who have experience fooling around with Unity may know that their GUI system is the reason why God hates us horrible to work with, which was motivation enough por me to write my own GUI class based on MonoBehaviour, the gGUI. Inspired by an ex-co-worker (the "g" is a reference to him), each button, box, label and general interface element is a separate object whose size is calculated based on the parents percent size related to the screen. That implementation saved us a lot of time and made easier and faster the slow and painful task of programming all of the features of all of the screens of all of the interfaces.
• Project management: Do not underestimate it. Having someone responsible for milestones, documentation, meetings, whips and chocolate proved itself to be essential to the conclusion of the project. Most people underestimate the true value of a well organized group and end up having to make the entire game in the last two weeks. A well thought and followed tasklist  assured the situation from the last semester wouldn't happen again and Insanitas had a healthy conclusion, with some time for polishing, compensating our initial six months delay. 
• The second guy: A big group comes with big responsabilities. And unfortunately, my skills as a programmer were not enough to fulfill'em all. Having another programmer working to implemet the things I didn't know how/didn't have time to learn took and ENOURMOUS weight of my shoulders and secured that all the demands would be accomplished. Thanks to that I had time to focus on the details and polishing instead of being stuck with unsolvable problems.

Hallway

Crypt

And here's what went wrong/could have gone better:

• Starting over: Okay, we messed up and okay, restarting was the best option and improved several aspects of our game. But still ended up being a problem whenever we had to rush to reach a deadline. We ran brutally against time and had to adapt many details to accomplish our milestones, what would have been much easier if everything had been better planned and documented from the beginning. We would probably have a month or two more to polish, but instead we had some turbulent afternoons and nights.
• Integration: We may be a small team on the industry point of view, but considering other unitversity teams, we are kinda big. And each one producing resources at the same time. Which means eventually stopping everything to get our stuff together and, until we established a model that worked for us (an access log to the project and a some instructions for importing and exporting assets), we lost time, material and went through some bumpy deadlines. After we set up our wokflow, we kept a system that assured a smooth integration and avoid even further problems.
• No comments: The second guy's help was pretty awesome, but my AWFUL habit of not commenting my codes limited/delayed the integration of the resources made by him. Having explained my codes the systems would've been integrated sooner and we would have more time for polishing and testing. Lesson learned and, hopefully, taught.
• To much polishing: At 4:22 pm, Monday, on May 20th, I rushed in at tthe theater where the games were being held. The deadline was 4:30 pm. Moments before I almost puke my lungs out, we were still burning the DVDs and one hour earlier we were still improving the whole thing. Polishing did assure a high quality game, but knowing when to say "Enough, the game is done" would have contributed to a less brutal ending of development. Specially 'cause some last minute changes almost prevented the game from being delivered with all the demands. Reserving some time to polishing is necessary, but not exceeding this time is even more necessary.
• My human condition: Like a famous brazilian journalist says whenever he sneezes on live television: "I'm sorry, I'm human. For now.". I dot sick, got lazy, wasn't able to deal with some responsabilities. I am human (for now) and although that's not my fault, it still got in the way of development.

Darkness hides a few surprises

From a programmer's point of view, I think those are points worth remembering for future projects. To those who read till this point, I sincerely hope you have learned something somewhere above.

Spooky

And although I've thanked before and personally, I would like to send a special thanks to all the people who supported the project, both emotionally and pratically. Specially our mentors end the guys who basically lived in the lab with us in the last two weeks. And also Nery, our teacher, master, and Environment Artist. :D