So capstone has come and gone – it was a stressful bunch of weeks but we did it! Team Nitro Fist has managed to break the Champlain curse and get a honest to god fighting game through capstone, and I couldn’t be more proud.
We’re so sick.
It took a special combination of talents to pull of what we did in the time that we had – we definitely did a lot of things the right way. However, there is always room for improvement. Now seems like a pretty good time to break down our production, see what we did right, wrong, in between, and how we’re gonna take our lessons learned into next semester. It’s also worth noting that I will be mainly focusing on technical breakdown of things.
What Went Right
Communication – Making a good video game requires a delicate dance between design, art, and programming – that dance is what a good producer facilitates and keeps on track. After my experience however, I’m completely convinced that the communication level to make a decent fighting game has to be pretty high compared to making decent games of other genres. There were many pitfalls we faced throughout development that we avoided because our team was so open and honest with each other. As a programmer, I was always trying my best to ensure that the team was informed about the technical side of things, and informing them of what is feasible and what isn’t.
Tools – One the things my programming professor told the teams about four weeks in is that the programmer should be developing the tools the other team members need so they can make the games themselves. We were already on that mindset since week one. I knew that the amount of flexibility and tweaking a designer needs to make a good fighting game is huge – which is why my first few weeks were spent developing a flexible framework and design and art pipeline for the team. The move tool I made was really helpful in particular, and it allowed my designer to get the animations from the art team, and then add moves and techniques to a fighter without ever having to touch a line of code.
Refactoring – I’ve mentioned it before but, we don’t get a lot of time in capstone, yet things still have to get done. This means that sometimes things fall through the cracks. There were several instances this semester where I flagged some code I did earlier, and later went back and polished or fine-tuned a system I made earlier as soon as things calmed down a bit. I’m so glad I did too. As a programmer, I felt like I hit a pretty solid balance between prototyping and building a decent architecture as well.
What Went Wrong
2D to 3D – Before I go into this, I’m very glad we made the change to 3d, it was the best thing for the art team. What went wrong is our planning around it. We thought that since it was the same game logic things would be a relatively smooth transition, but we quickly found out it wasn’t. In particular, our game feel got thrown out the window, and it took us about a good week or two to find it again. As a programmer, I wish I prepared a bit more in advance for this process, but we did the best we could with the resources we had. In the future, we’ll definitely save more time for it though.
Reliance on Unity Animations – I tried to play nice with Unity’s animation transitions for our character animations, but it created way more headaches than it was worth. Not only that, but what with the sheer amounts of animation states and transitions, using Unity’s built in system quickly became a confusing spiderweb. Later on, I hard-coded some animation transitions to skip the confusion and bugs. One of the main things I want to look into as I refactor in preparation for next semester is updating the animation system.
Keep The Communication – We’re expanding our team to a whopping 10 people. Team dynamics are definitely going to change but we also have to make sure to keep the system that we have right now alive. Lucha Megadrive is a game born out of honesty, commitment, and passion, and those are the types of values we want to inspire in our team.
Update Tools – We were able to survive the hiccups we faced not only because of our communication but because of our pipelines. As our team doubles in size, workflows and needs will most definitely change. As lead programmer I want to do a revision of our pipelines to ensure that everyone has what they need, and that everyone is working optimally.
Coding Standard – I won’t be the only programmer anymore, so I think it’ll be a good idea to draft up a simple coding standard moving forward. As lead programmer I’m definitely going to take the time to draft up an architecture, assign roles, and get a solid technical game plan going.
In all honesty, our team did a lot of things right, and I think that’s why we pulled off what we managed to pull off. People are excited and passionate, and that personally couldn’t make me happier. I feel like all the skills I’ve been developing throughout college came together to this project, and I feel truly accomplished. I can’t wait to take the drive and passion into next semester.