So the team decided to move forward with the three concepts I discussed last week. Out of all them, we thought that the Luchador themed fighting game would be the hardest one to conceptualize and prove – so I spent pretty much all my time on that prototype, while our designer handled the other two.
Out of the many challenges that come with developing a fighting game, our team singled out perhaps the most crucial of issues to get out of the way early – solid production pipelines.
Since our game is most likely going to be 2D, for now the art pipeline will be ensuring that our artists get all of their animations nice and packed in a sprite sheet and put in the project. Since fighting games are so frame dependent on their game play logic and balance, a lot of the process I worked on was geared towards our designer.
The two main issues are that fighting games are extremely animation intensive, and there are several bits of game play logic that are specific to frames in that animation. The other issue is that a character in a fighting game has many moves to choose from, and each and every one of these moves has different hurtboxes and hitboxes. My goal was to make a smooth and easy pipeline so that my designer could tweak and balance on the fly – without ever having to touch a line of code.
The Design Pipeline
As time is crucial and limited in Capstone, my solution was to work with the engine (Unity) as well as I could to streamline the whole process.
For getting animations in and having different hitboxes become active depending on the frame of the animation, I decided the most cost effective way was to work with Unity’s built in animation tools. In the picture above, the diamonds represent different keyframes, which our designer will place in from the spritesheets our artists provide. The little white ticks on the timeline represent animation events, our designer simply has to line up these animation events to the keyframes that corresponds with a move’s startup, active, and cooldown frames. From then on, he can just select the functions that I’ve already coded, and work universally for each move. With this method, I don’t have to spend time making our own animation tool, and our designer can easily tweak moves frame by frame if he sees fit.
In terms of collision boxes, the solution is a little less elegant – but it works!
Please excuse the programmer art…
So as you can see to the left in the object hierarchy, the player has several child objects that share the same names as the moves that are defined on the right. These child objects simply hold collision boxes. Upon loading the scene, the fighter object cross references its list of moves along with the names of the child objects it has in order to make a dictionary of collision boxes and moves.
From here on out, whenever a move is executed, the program finds the name of the move that was executed, and uses that name as a key in order to seamlessly change the collision boxes of the player. Once a move is complete, the player goes back to using the default “Idle” hit boxes. With this method, as long the names of the child objects and the moves are the same, the designer can easily dive in and tweak collision boxes on the fly as well.
With these pipelines set up, I feel much more comfortable about proving the feasibility of this game. As long as animations are coming in – I can work on implementing new mechanics and polish while our designer tweaks and balances the game. Despite the huge challenge ahead if we decide to go with this, I truly believe my team is up to the task.
Other things I did this week is do basic prototype-y stuff, like win states, getting collision and damage to register, and so forth. Next week I’ll probably be putting the finishing touches on our initial prototype, and I’ll be diving into how that went then.