Tank Battle AI – Planning


Now that the chaos of Capstone is finally dying down, it’s time to focus on my last project for the semester, artificial opponents. The goal is to write a tank battle AI that builds off of the movement system I developed a while back. Other students will develop their own tank AIs and they’ll face off against each other in the final. The guidelines are very loose right now, so I’ll cover the two main parts of the AI and some possible paths I could take with them.


Before each round, each player is given an amount of money to spend on tank parts. The amount we will be receiving is currently undisclosed so I have no idea how to appropriately plan for this, so I’ll either be doing one of two things. First, buy a bunch of cheap parts and make a squad of weaker tanks, or buy a small amount of strong parts and have one super tank. I wish I could get more specific about this process but the class hasn’t been informed enough to know more than that – rules could change at the last minute. Right now, for conveniences sake, I’m aiming towards purchasing one powerful super tank – It’s less AI to worry about and making an algorithm that buys the most powerful parts possible should be pretty straightforward in a flexible monetary environment.


So there’s one dominant strategy at the top of my mind that I think will give me the highest chance of winning – camping. I plan to have my super tank run to a corner of the map and just snipe anyone that rolls into its range. I know it’s pretty lame, but the assignment isn’t trying to make “fun” AI like typical game development, the goal is to win against other AI. If the tank game was actually playable by human beings and those human beings needed interesting opponents it’d be an entirely different story. Since it’s an AI battle royale, I feel that a lot of techniques that would make a conventional AI “fun” to play against would just end up being glaring weaknesses against other AIs. Therefore, picking a corner and holding my ground seems like a pretty powerful strategy.

campingThis spot seems pretty cozy.

Also, while it may be lame, there’s a lot of potential room to make my tank’s “lameness” even more effective. It’d be interesting to potentially write some sort of map analyzer so I could determine the closest and cheesiest spot to hide – I’ll see if I have the time for that, but with MIGS coming up I doubt it.


All in all, I’m not too excited for this tank battle, I think there’s a lot of ways this assignment could be improved, but I’ll cover that soon in my post-mortem.

Capstone Blog #10 – We Made It!


It was quite stressful and a bit nerve wrecking, but we made it! Lucha Megadrive will continue production onto second semester. I’m so immensely proud of my team and the work we’ve done. This post might stray away from technical stuff for a while, but I feel like I could use some reflection on our team flow and how the presentation went.


So… fighting games. They’re hard to make. Well, that applies to most games, but fighting games are truly a brutal beast to tackle. Through this experience I found out it requires a delicate dance between design, tech, and art. You could say the same about most video games, but I feel like with a fighting game, if communication isn’t at 100% – you’re dead in the water. It’s probably why Champlain faculty say not to do it! We even had one faculty member say “It’s your funeral”. That’s not to say it wasn’t all doom and gloom, many faculty were extremely supportive and our team received very valuable wisdom and insight from them, but it was a pretty lofty goal we had set for ourselves.

Making a good game wasn’t just it however, we needed to market our product too. We need to take a complex product like a fighting game, and find a quick and efficient way to clearly explain our mechanics, our goal, and why we should move forward with them.

The Presentation

Capstone consists of a presentation night and a demo night. On presentation night is where you pitch your game and a show a trailer to faculty and your fellow peers. Demo night is where faculty actually play your game and judge it from there. Since we’re making a complex fighting game, nailing our presentation was key so that faculty would know what they’re playing the next day. It was a tricky balance between explaining the concept of Lucha Libre, how it applies to our game, and why it makes our game special. So what better way to explain Lucha Libre than having an actual Lucha Libre fight?

lucha.pngI got punched in the face for this game.

That’s right, we rehearsed and perform a live Lucha Libre skit to show how cool Lucha is, and then use that as a bridge into our unique Lucha-themed mechanics. I’ll most likely be updating my portfolio page with the presentation soon – but it was real, and people absolutely loved it! People were cheering and getting invested like a real wrestling match. It was perfect way to showcase what exactly makes our game special and why we were so inspired to make it. All the rehearsals were definitely worth it.

Moving Forward

From a technical standpoint there’s a lot I want to revisit. Three months isn’t a lot of time, yet things still have to get done. Code wise that means sometimes some gross things have to slip through. I wanna use this break between semesters to clean up, optimize, and thoroughly comment my code base so we have a solid base to expand from starting second semester. We’re also going to be expanding our team very soon, so I really want to communicate with the new members and adjust our current pipelines as needed so we can continue to be efficient. There’s gonna be a lot of changes coming up, and I want to be ready for them.

I’ll be making a more detailed post-mortem post soon about how this semester went, but I’m damn proud of my team and the work we did.There’s a lot to work on and expand on, but despite that people are loving and having a lot of fun with the game. Personally, it’s so satisfying to see people having fun and getting invested – it’s why I’m dedicating my life to this profession.

Capstone Blog #9 – Last Minute Polish


As with any big showing, there was a lot of polish work to do on Lucha Megadrive before the big show senior show that would determine whether or not our game gets cut. As a programmer, I quickly realized I had to do some more boring quality of life stuff to get a proper game flow going. The whole semester was all about making tools and mechanics – now it was time to build some structure around that.

Main Menu

Of course, there’s the token main menu. Some options shown below are unavailable and are there as more of a “preview” for next semester.

mainmenuSimple, but effective.

All the basics are there, like credits, basic options with sound control, and an option to take you to the meat of the game.

Character Select

What would a fighting game be without a character select? This one I made without using Unity’s built in canvas event system because that only supports one controller right now.

charaselectI currently main purple Fuego.

It’s a fairly simple set up, so I added some simple scaling animations to the cursors that add some extra feedback. Sound effects add a lot as well. I think my favorite thing about this menu is your ability to select your fighter’s color! I made a fairly modular tool that allows for my designers or artists to dynamically add new fighter skins, while also modifying the colors that represent them in character select.


To compliment this, I also implemented a simple GameManager singleton that keeps track of very broad things that mostly every scene will need to know. One of these things is each player’s selected fighter and the color associated with it (so it knows what texture to load). Having a color select is a really nice piece of polish that I’m glad we got a chance to put in.

Spit and Polish

It was one busy week. Besides implementing all this menu stuff I also tried my best to find/fix any remaining bugs we had left so that I could insure that faculty would have a smooth experience playing our game. I also worked with the designer to implement and fix some sound effect issues, and add some feedback for our armor and unblockable mechanics. There’s a lot more we could’ve done – but for three months time I feel like our team had a solid vertical slice that represented our mechanics well.

Capstone Blog #8 – Combos


It’s been almost a month since I wrote my last capstone related blog post and a lot has happened. I meant to update this a bit more frequently but I’ve been incredibly busy as of late. I’m gonna try to play catch up this week, but for now, I want to go into one of the most integral concepts in a fighting game – our combo system.

What’s a Combo?

Fighting games are pretty deep beasts, so I’ll try to keep it quick. In a fighting a combo occurs when one player performs a sequence of moves in such a rate that the enemy is in hit stun the whole time and unable to block, meaning guaranteed hits and damage. Our game already supported basic combos in the form of links. A link is where the hit stun applied by one move is longer than the recovery of that move and the startup of another.

framedataIt’s a lot easier to visualize isn’t?

In the above example, Ryu could start a combo as long as the next move he performs starts up in at most 6 frames. Links however are quite limiting in terms of game design. Many other fighting games have also incorporated cancels into their formula. A cancel is when a move is performed mid another move, thus ceasing any recovery frames and proceeding straight into a new move. In Street Fighter, many of Ryu’s moves can be cancelled into his signature hadouken for example. The big step for Lucha Megadrive was to add cancels.

The Plan

Ideally, I wanted to extend my already existing tools to allow my designer to change what moves can cancel into what without ever having to modify a line of code. However, we plan to have a variety of fighters with different move-sets, so I wanted to keep the tool as vague and as modular as possible. The original implementation ended up being that the designer could input what general motions to listen for (for example, punch, kick, quarter circle punch, etc) and then to follow up by making a transition in the animation tree. At first this seemed feasible, however with the amount of cancels that were going into the games design our animation tree quickly become a spider web from hell. I was gonna post a picture but I’ll spare you all from it, but trust me – it was bad. Not to mention, becoming increasingly time consuming for the designer.

The Fix

I quickly foresaw the cancel system I had implemented becoming a very unpleasant part of the development process. As a result, I went in and overhauled the majority of the system. The new system would be more precise and not very vague, but end up being much more readable and not involving any sort of animation transitions. All the designer has to do is select what move should cancel into what and, bam, the move is now cancellable.


It’s as easy as that. You want light punch to cancel into super? Done in a second.

The compromise I had to make however is that I had to make some hard coded cases specifically to the character at hand to hard switch the animation state whenever the prerequisites for cancelling are met. I usually try to avoid this, but the benefits are definitely worth it in this scenario, and hard coding the other cases as we add new character won’t take too much time at all.


So we actually had combos working for quite a while now, but this is my first step in playing catch up. As I write this, I’m actually preparing for the senior show that is happening later tonight, where my team will have the chance to present our game and market it to the faculty. If we pull this off, and then they like the game after demos tomorrow, we can continue on to senior production.

Personally I’m very nervous, not because I don’t believe in our game, much on the contrary actually, but it’s a situation that could end up either way. Lucha Megadrive is a huge passion project for me, and I would probably be a bit devastated if we got cut in this stage. Regardless, the team and I have made something super cool, and I look forward to talking about what happened in the past month in future blog posts.


Tank Movement AI – Planning


Sorry I haven’t updated my capstone blog in a while, I’ll get to it this weekend, there’s a lot to talk about! On the AI end of things, we’re finally moving on to our next project, and it’s making squad based tank AI. I’m honestly a little wary – this seems a lot more difficult than some of the other projects but I’m looking forward to challenge!

The Goal

Right now the the game is a top down tank battle game. Our first goal is to write the movement part of our Tank AI so that it can maneuver around walls and mazes to reach its destination. Long story short, wherever the player clicks – the tank should be smart enough to get there.


The Plan

Off the top of my head, the plan hear seems fairly simple. Get the map data from the game, make some sort of graph out of the map data, and then perform a pathfinding algorithm like dijkstra or A* on the graph in order to get the path needed to reach the clicked point.

The tricky part is that these tanks are controlled by two treads, so I’ll have to experiment a bit to find the optimal values to give both treads in order to handle different situations in the path.


I’m not too worried, and I hope the tread part doesn’t end up being a huge headache. For an initial run I might just do 90 degree turns and then just moving forward. Once I get that ironed out, I can worry about optimizing the path traversal.


Gin and Rummy AI – Post Mortem


Well, the Gin and Rummy AI I’ve been posting on and off about for the past month is complete – and I’m pretty satisfied with how it did.


So my class held a double elimination tournament where we pitched our AI’s against each other in an ultimate showdown to decide the best Gin Rummy AI.  My AI got 7th place, so taking into account that there were 13 entrants, my AI got about halfway through. It definitely did better than before, and I think that’s because of a quick algorithm change I made.

Last Minute Changes:

In my initial valuing algorithm, the card with the highest assigned value is discarded. Any cards that were part of a set or run got a value of 1. Cards partly making a set or run got a value of 2. Garbage cards got a value of 3 + card value. The key issue with this system is that later into the game, my AI would sometimes hang on to several high valued cards that it would refuse to get rid of because it was “almooooost” there. The result was sometimes holding 2 kings, and 2 jacks, and then handing over 40 points to my opponent that I could’ve saved myself from. In order to alleviate this, I added an extra condition. If the deck is more than halfway spent (meaning someone is probably gonna knock soon), I begin adding the card value to the cards that make part of a set. The result meant that my AI would dispose of cards that are dangerous if too much time has passed.

This was a great change, my AI ended up playing a lot safer and gave out a lot less points to my opponent whenever luck wasn’t on its side.

In an Ideal World:

If I could add another thing to my AI it would be the ability to count cards. If my AI kept track of what cards have been discarded or picked up, I could use that data to modify my valuing system. This would mean that if a card is part of a set or run that I know would be harder to get because a certain card has been discarded – I can rate that card much higher than its fair game counterparts.

Card counting would also help with ensuring that my opponent doesn’t get a card that could help them. If the card I’m about to discard could possibly help with a set or run that my opponent is foreshadowing at with a card they just drew from the discard pile, I could simply hold on to that card for a while and discard something else.


I was pretty satisfied with my AI but it would’ve been nice to get in the top 3. I honestly believe that the card counting strategies I mentioned above is really what my AI was missing in order to outshine the rest. Regardless, I’m glad with the last minute change I made, and I like to think that if this AI were to be put in a game – it’d be fun to play against!

Capstone Blog #7 – From 2D to 3D


So these past two weeks have been some of the most intensive weeks of this production process so far. Long story short: Don’t believe you can make a 2D game 3D over night.

The Situation:

So I’ve mentioned before that our game will be a 2.5D fighter – like the recent street fighters have been. These past two weeks have been a trial in porting code, making adjustments, and proving the art pipeline. It’s been hardwork, but the entire team has been giving it 200% and I’m happy to say that we’ve made it to the other side! While the environment is still a work in progress, this is what our game is looking like now:


It feels so good to see Johnny Fuego fully realized!

As you can see – the camera is a lot closer now, and we have a more fully realized ring to run around it. I had also implemented some dynamic camera work so that the action is always visible – no matter how far away the luchadors are.


He’s probably not going to make that jump…

This makes the both the artists and the designers happy – artists can have their characters and screen proportions well represented, while we can still have a lot of freedom of movement and rope mechanics being displayed at will (Most fighting games block movement off at the camera boundaries).

Perspective vs Orthographic:

Since the game was purely 2D before, I was using an orthographic camera. In the big change, our artists requested to change to a perspective camera, so we could use 3D background and get more rich and easier to make environments. The main challenge this presented however, is how the characters are represented. Since it’s a perspective camera and the 3D characters now have depth, their width on the screen would change depending on their distance to the perspective camera. The issue is that this skewing wouldn’t accurately represent where the hitboxes of moves are – and even if it’s a minor thing, precision in a fighting game is vital.

This is the part where I talked to people and did a lot of research in order to find a good solution. My characters needed to be rendered orthographically while the environment was rendered in perspective. One option, was to write my own camera projection matrix, as explored here: https://gamedev.stackexchange.com/questions/86960/mixing-perspective-and-orthographic-projections. The other option, was to render out the 3d animations into sprite sheets, so that we could have our 3d looking characters without any depth. Both seemed like fairly costly endeavors, until my graphics professor gave me the simplest solution – scale the model’s z value.

flag fuego.PNG

For all intents and purposes, these are now Fuego sprites.

So yeah, we just flattened the models – angled the camera correctly and voila! Problem solved.


Our team found the game feel we really enjoyed and wanted to have with our 2D prototype. Despite it being relatively simple, people had fun – and that’s an amazing sign! During our shift to 3D, certain things felt clunky, and not as crisp and fun as it did in our 2D build. These past two weeks have been spent making the transition, and making sure our game feels just as fun as it did before. I’m happy to say that we’re pretty much there – and then some! We have a bigger environment to fight in, more moves, and I’ve also been implementing some new mechanics on the side. Right now you can currently quick rise, so you can adjust your timing when getting up in order to throw off your opponent. In the next weeks, I’m going to be focusing on the last core features like the parrying system and combo system.

After all that said is done, I’ll be polishing off mechanics and cleaning up whatever I can in order to prepare for the big presentation. I’m feeling extremely confident with our game right now. In my last post I talked about how proud I am of my team, and that definitely hasn’t changed. I feel like we’ve overcome a huge hurdle together, and I’m very excited for the future.