Capstone Production Post-Mortem

So our game went through, go us!

After 12 weeks(plus more counting the draft for new teammates) of iteration of our idea into a working proof of concept, here we are at the end looking back on what exactly was done to see what went right, and what went wrong, with me at least.

Better yet, what’s changed since the beginning of the project because of this?

As you can tell, I am just going to cut right to the point with this one, so hold on tight.

What went right? Well, I did in fact program the game, which is nice. There was nothing that was really a huge technical risk that I had to wrestle with the entire project. Everything that was needed, from the inventory system, to the adventurer manager, to even the boss fight, were relatively simple. Just the amount of systems that needed to be implemented in order to get everything to work was the issue. A better way to put this would be that it wasn’t the difficulty of the work, it was the amount of it that was the hard part. The positive part is that I got enough of it done to prove the concept of our game, so go me on that one!

Communication is a big aspect to working on a team environment. In this production cycle, I feel like I really excelled at being a communication monster. I kept everyone updated on the tasks I was under taking, I would explain reasons behind implementation of the systems in the order that I did them in, and I was able to articulate concerns and risks that I had about programming certain elements. With that, I was also able to act as a bouncing off point for many different game design, and art direction ideas.

Looking at the what went wrong part of it, there is one big thing that stands out to me, and that had to be the willingness of myself to take on more than I need to in order to get the project done. That’s a good thing right? Well, not really. See this was a problem I had in the beginning of the semester because I was trying to get all the work done quickly, I didn’t ask for help getting things done for the designers.

This was a huge mistake.

It was a lot to handle given the nature of the game, too much for one person. I needed to ask for help when it came to the tinkering of things to make them work. This was a lot of work that could have been split between the design team and myself so I could have focused on the implementation of other things.

Lesson learned.

With all that said, what’s changed? Personally, that is.

I am going to be honest here, the jumps that I have made since production 1 are astounding to me. I used to be very much in the mindset that I was just the programmer so I didn’t really need to talk to people about the project, except in the terms of programming, and that was that. Working in Montreal, with Production 2 and my Advanced Seminar being both heavy team based projects, I learned (mostly through fire here) that when it comes to this production environment that communication is key.

And not just communication is the “look at me, I’m talking to you” kind of way. I mean communication in the way that everyone on the team is aware of where everyone stands on the projects, what they are up to, and what can be expected of them at certain times. Communication in the way that if anyone has a question about the project, that the rest of the team should know the answer. Working in such a way that we make whatever project we are working on something that everyone wants to pour their passion into it, which means making compromises for the betterment of the team working environment.

Throughout this cycle, and the ones I’ve had in the past recently, I have taken it upon myself to not just be a programmer on the team, but to be one of the key pieces that holds the team together, someone who can communicate, and facilitates communication from others. I think that every programmer that is in the production setting should work to have these communication skills, because in-game development, they are indispensable. Of course it should take second fiddle to the raw skill and talent in programming that the programmer should have, but the second fiddle exists for a reason.

In my professional field, I am trying to take it upon myself to be the best teammate I can be, through getting the tasks done that need done in a timely manner, communicating issues and concerns, and taking and receiving feedback in order to better myself and others. In other words, I am trying my hardest to be a great game programmer, not just a programmer. Which is why I am glad I am able to go through the production environment multiple times through an academic setting, so I can make my mistakes now, and hone myself professionally.