Finishing off strong…

Very excited to say that the game has shipped. Everything fell into place these last couple of weeks, and I’m thrilled with the result. We pulled through and were able to get all the features that we wanted, minus one map. The final product is thanks to the fantastic team that took on my vision and brought it to life. They all should be incredibly proud of the work they put in because we could not have made this without them.

In this blog, I’m going to talk a bit about the process of what went wrong, what went right, and what we might try again. After completing a development cycle, it is essential to look back and take away the strengths and weaknesses.

What went wrong?

Feature reworks were not planned out enough.

Starting this development cycle, we went through a series of changes that I did not consider before then. I was still planning on working on the original trapped, ironing out all the issues, and continuing with that dev cycle. That was not the case. After speaking to a few individuals, I decided to make some drastic changes to the game. I had to rewrite the whole dev log, which took me three weeks, putting us slightly behind on development.

Too much game building vs. design planning.

I always seemed to stick my grubby little hands in everything. I was modeling and programming for my team as well as designing. At times I could tell it was way too much. I should have dropped more of the tasks I could delegate to others on the team and stuck with the design tasks that only I could complete.

Vision felt like it got confused at times.

Sometimes it felt like the vision of my game was not making it to certain people on my team. It took me way too many tries to try and find a way to relay information to team members successfully, and I learned a lot from this experience. I now know how important it is to check-in and practice multiple strategies of relaying information.

What went right?

Solid Design Document.

Having a comprehensive design document was extremely helpful during the development cycle. I could reference it to any team member asking questions. I could also use it to remind myself how certain features were supposed to work together.

Strong Idea

Using the +1 strategy, I took an idea from a successful game(one of my personal favorites) and added a new element. I added in a skill tree element which I felt complimented the other aspects of the game well. Using this as a jump-off point was super helpful to build a quick design doc based on currently existing features.

Features complement each other.

All the features in the game come together to make a cohesive product. The skill trees and the achievements help with the progression of the player. Having these elements give the player a reason to progress through the content.

What would we do differently?

 I think I failed on is not spending enough time on design decisions for my game. I spent way too much time working on the game instead of designing it. This lead to many issues in development where the vision of the product would get hazy and confused. If I had spent more time firming my vision, I would respond to team members faster when they have issues or confusion about the game.

What would we do again?

Taking risks was a massive part of this development cycle, and it worked out for the better. I was nervous to try it and worried it wasn’t going to work out, but I took the plunge. Overall I think it came to be a success; I was very thankful I was willing to take this risk because I don’t think the game would have come out as well as it did on its own.

 What did we learn?

  The biggest thing I learned is the importance of mechanic design. Figuring out how all your systems work can be much more complex than one thinks. For instance, I understood how the skill tree mechanic would affect the characters. But I didn’t know how the augments and the skill trees would interact with each other. I learned that direct influences and indirect influences to systems that I did not initially consider.