Lucha Megadrive – Trials Mode UI and Bug Catching

Standard

This week was another week of steady progress for Lucha Megadrive!

Bug Catching and the Smaller Things

For me, this week was comprised of a lot of smaller tasks that added up. I implemented a main menu layout, implemented pin magnetization which works in tandem with the dynamic camera angles, and worked on several bug fixes that have added up in the past couple of weeks.

pinYou’ll look cool no matter where you pin.

This ensures that the pin will look natural no matter where you pin from and no matter what orientations the characters are at.

New Trials Mode UI

We implemented an initial trials mode last week, but the UI was most definitely lacking. Luckily our awesome UI designer drafted up a new UI plan and I got to work on implementing that. Now there are two styles to demonstrate what trial you are on, the old text style (which some players prefer) and a more intuitive visual style that shows buttons and motions. I spent some time setting up the system that would dynamically make the UI depending on what moves the trial is composed of – this is the result.

trialsuiMuch better – in my opinion.

Now our designer can make whatever trial they desire and the UI will automatically be made to fit. It’s not completely finished, but all the basic functionality is there. For the most part we just need some art assets to spruce things up.

Team Dynamics

Last week I mentioned some worries I had about our team’s current state and communication structure. I’m extremely happy to say that we’re well on the way on fixing those issues and bringing morale back up. The entire team is behaving and handling the situation very professionally as well. As a result of some of the issues the past couple of weeks, we’re cementing leads roles a lot more in order to facilitate communication and structure, which means a couple more lead responsibilities for me.

Lucha Megadrive – FMOD and Trials Mode

Standard

This week was a bit of a doozy, but we still managed to get a lot done!

Integrating FMOD

We have a guest audio designer that will be contributing to our team by making sound effects. I set up a sound manager before that did the job in the time we had, but our sound designer requested that we integrate FMOD into our project, saying that it would greatly increase their workflow. After taking a look at FMOD with our sound designer, I agreed and made plans to gut our old audio engine.

It was a learning process, but FMOD is fairly easy to work with. I got a basic workflow set up so that our sound designer could path the appropriate sounds to the right events. From there, it’s up to me to fire those events in their appropriate situations in the gameplay logic. The system is also flexible enough to easily add new events and sounds as design requirements change moving forward. Since we don’t have replacements for every sound implemented thus far, I made a dummy scene to prepare and test the architecture, so implementing what I’ve done won’t take too long once we have enough sounds to work with.

fmodNow our sound dude can hook up all the events they need to!

Trials Mode

Trials mode in a fighting game consists of set combos that a player has to perform in order to move on to the next. This can range anywhere between badges of accomplishment earned by doing cool things or even teaching the player some decent combos they can use in an actual match.

trialsTrials can get pretty hard

Duncan and I tag teamed this one, we both made the architecture for our solution and implemented different parts. He handled a lot of the core implementation while I’m working more on feedback and UI options. The main goal was to come up with a tool that would allow our designer to easily make, and modify trials at ease. Happily, the systems I had made in the previous semester greatly aided us in this endeavor. By exposing inputs and motions to the editor, our designer can make and test trials on the fly, while on our end we just read the current input and state of the character and check if it matches the current move in the trial. Trials mode is working and ready to be expanded on as we move forward!

Conclusion

It was another fairly productive week for us programmers, (beyond these things I worked on typical things like bug fixes and tweaks). Team wise, things were a little more tense than normal this week. Right now our game is undergoing a bit of an art revolution, so there’s a lot of stress on the art team. Unfortunately, our art lead had to leave for the week, and I feel like that combined with several other factors has resulted in some miscommunication about art progress and art plans moving forward. As systems lead I’ve been supporting as best I can from the programming side… which means I can’t do much. Despite all this I feel like our team is almost past this hurdle, and after that I know it will be smooth sailing.

Lucha Megadrive – Training Room and the Birth of Winter

Standard

It’s the third week of development and we’re about to challenge our green light conditions. Things are going well and the game is definitely moving forward at a good pace. On the programming end my main tasks were to begin the implementation of the coveted training room and starting to work on Nuclear Winter’s initial implementation.

Training Room

Duncan and I have been tackling the training room together. I set up a simple architecture to build off of and added some new events to allow for an environment where you can freely practice combos and different positions. Duncan handled showing inputs pressed and showing damage UI for the trainee to analyze as they test different combos. Right now, training mode is at a base state where the core functionality is there, but there are some more in depth training features we are planning to add in the coming weeks.

trainingTraining Mode is definitely on the way!

Nuclear Winter

Although the model isn’t finished yet, there’s a lot of animations to get done so our animators have already started to crack down on them. In order to test them in engine, I already started using the framework I set up last semester to begin the implementation of Nuclear Winter. I’ve started beginning the new animation tree and going through the initial set up of making a new character. I’m happy to say that the pipeline is still working great and that our animators are doing a fantastic job so far!

winterWinter will look sicker soon.

Moving Ahead
I feel like these past few weeks the programming team has been tying up loose ends and adding smaller features. We realize that during this lull between art implementation we have more time than we thought we had to add more features, so we’re currently talking with the design team to see how we could best spend our extra time. Right now, it’s looking like we might be getting a trials mode in, which is another fighting game must have.

Lucha Megadrive – Input Reworking and New UI

Standard

This week was a bit of a lighter once since most of the team had plans for the weekend, but a good amount still got done!

Input Reworking
Something that Lucha Megadrive has been missing is special move variations. For example, in Street Fighter, you get a different fireball depending on if you press light punch or heavy punch after your quarter circle input. That has been missing in Lucha Megadrive until now, I had to do some reworking into how the animation transitions and input management is set up but now my designer can make special move variations with their own move properties. I also did this while retaining the simplicity of the cancel tool I made earlier. While special move variations are treated as different moves, when it comes to setting up cancels, if you input a quarter circle forward punch input for a cancel, it was automatically detect both fireball variations as a cancel for that move.

Lastly, up until this point Megadrives have been performed by specific Megadrive shortcut buttons. My designer has been wanting the option to do specific super inputs alongside of the super macros, and I got that working too!

Aerial Interactions

Last week I mentioned that I reworked how aerial interactions work in Lucha Megadrive, and I’m happy to say that I finished implementing the last of those systems. The rest is up to the designer to give the moves appropriate values – we’ll probably need some air specific animation states in the future as well.

UI Prototyping

UI wasn’t a focus for our team last semester, but now we have a designer specifically focusing on that to pick up the slack on that department. Since I wrote the initial UI code, I helped her with prototyping and initial implementation of the new UI.

luca                                                           One of our UI examples

We’re trying our best to make the UI lest intrusive, more readable, and more intuitive and stylistic. I’m really excited to see where it ends up!

Conclusion

Among other things, my programmer partner in crime has been working on developing a dynamic camera system so we can get over the top dramatic angles during pinning, and possibly during different moves as well, he’s also been working on getting fluid mat bounce system to work to really give our game some visual flair and feedback.

The entire team is working hard to meet our initial conditions and so far it definitely seems like things are on track.

 

 

Console Programming – Core Concept

Standard

This year I am taking a console programming course, which is pretty much a class that gives us the freedom to program a cool portfolio piece before we graduate.

The Project

If you’ve been reading this blog, you know that I have been pouring my blood, sweat and tears into making Lucha Megadrive. Fighting games are a huge passion for me, and programming wise I’ve always had a huge interest in artificial intelligence. My proposed project is that I develop fighting game AI for Lucha Megadrive. This AI would incorporate some machine learning techniques in order to adapt and learn from it’s opponents to increase its chances of outsmarting an opponent.

How It Shows my Skills

I believe that pulling this off would be an amazing portfolio piece, and would showcase my ability to architect complex systems while showing my understanding of game AI and deeper AI techniques like machine learning. It’s a win win for me because I get to learn more about one of my favorite programming fields while also making my already awesome game even cooler!

What I Need to Do

The biggest risk and unknown involved in this undertaking is implementing the machine learning algorithm that would make the AI learn and adapt to its opponent over time. While I’ve developed some AI systems here and there, I’ve never done anything close to machine learning, so it’s going to be a huge but very interesting challenge to overcome!

I would also need to program some base AI for my fighting game to start with and build off of. Luckily, the fighting game is there, so I only need to worry about the AI side and making it deeper and function-able.

Lastly, I will have to make a significant amount of planning to develop an architecture that efficiently handles the machine learning algorithm while applying the results to live matches. Luckily, I know the architecture to my game like the back of my hand, so I shouldn’t have trouble extending that and working around what I already have in place.

Since I don’t have much experience with machine learning, I will most likely be paying visits to the CSI faculty on campus to discuss strategies and algorithms that would best suit my specifications.

Conclusion

I’ve always wanted to learn about deeper and more complex AI systems and I think this is the perfect opportunity to do it. Although the core concept is a significant risk and a big unknown, a lot of the other programming tasks surrounding it (architecture, basic AI), is definitely not out of scope, which gives me plenty of time to implement and iterate on an adaptive AI system.

Lucha Megadrive – Getting the Groove Back

Standard

The school year has started again and it’s time to take Lucha Megadrive into full production! This week was a mixture between getting acclimated to the new team and getting some work done.

The New Team
Our team went from five people to nine, which changes the dynamic pretty dramatically.  We got 2 more artists for animation and environments, a designer for UX and UI design, and a graphics programmer to help out with the new visual changes we will be undertaking. The team is fantastic, passionate, and inspired. I couldn’t be happier with our new members and I’m extremely excited to take Lucha Megadrive to the next level with our team.
My New Role
As the sole programmer of the original team, I’m the one whose most comfortable with the code base, which gives me a pretty big responsibility to make sure the new members follow standards and feel comfortable when working in engine. My new title is Lead Systems Programmer, since I will be the one expanding the tools and underlying fighting game framework as we move forward. I will be accompanied in this venture by Duncan Carroll, our Lead Graphics Programmer, who will be focusing on shaders and graphical effects and optimization. We’ll definitely be bouncing off each other a lot but it’s going to be nice having someone to share the load with.

What Got Done
So one thing the team was kinda unsatisfied with at the end of last semester was how our air to air interactions work. When fighting on the ground the game feels pretty good, but some air interactions were missing weight and strategic depth. Our Lead Designer crafted an air to air exchange doc and I got right into giving him the tools he needs to make air to air interactions feel weighty and responsive. Here are some of the values I’ve added to each move:

juggleTool

Our designer can now customize how far a move launches when hitting an airborne opponent, grounded opponent, whether a move puts the user airborne (like shoryuken for example), and whether a moves puts the enemy in a juggle state. Although these changes seem small, this vastly changes combo flow and custimizability our designer has with moves, resulting in a deeper and more free form game. I look forward to what cool combos come out of these changes to the system.

Moving Forward

It’s been a busy first week, but I’m excited for the weeks to come. I’m going to continue to fine tune and debug systems, and hopefully get started on an in depth training room. A lot of the hefty system work is complete, now it’s all about polish and making what’s currently fun, even more fun.

Capstone – Post Mortem

Standard

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.

titleScreen.PNGWe’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.

Moving Forward

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.

Conclusion

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.