Fukyuu is a third person multiplayer beat-em-up game. The game was developed as the 4th semester project in Digital Media. We worked in a team of four people. Markus Filsinger created environmental props, Matthias Trumpfheller was responsible for level Design and Stephan Pfisterer worked the animation for the main character. I was responsible for programming and adjustments of the game engine. We all contributed to the design of the game mechanics.
The Project
As a basic idea, we wanted to create a unique multiplayer game. Being influenced by titles like “Rune” (Human Head Studios) and the indy-game “Lugaru” (Wolfire Games) we decided to create a beat-em-up style game. We wanted to recreate the playing experience of games like “Streetfighter”, but in a 3D space. As a technological basis, we decided to use Valve Software’s Source Engine. With its decent graphics, good network support and a huge modding community, we thought it to be the best choice for our project.
The setting of our game should be Asian. Lost souls of fallen warriors should battle through hell to get back to life. This is also the origin of the name of the game “Fukyuu” which means “immortal” in Japanese (and, well, ok, it’s also a childish pun).
First Steps
Since no one had ever worked with the Source Engine before, we had to learn a lot. The basics, such as programming classes for new game objects and establishing an asset pipeline, were well covered by various tutorials. We quickly learned how to import models into the Source Engine’s Hammer Editor and use them for example as physics objects. Replacing the playermodel was just as easy. After having established the basic pipeline, we shifted our focus to designing the game mechanics. For this we established weekly meetings. Digital communication was also used, but we quickly learned the positive effect of working together face to face in the same room.
The combat mechanics
The main game mode is a classic deathmatch. As the main game elements we chose combinations of punches, kicks and blocks. The more powerful the attack, the more complicated the combination of moves to create it. Unlike other multiplayer action games, we decided against health powerups or regenerating energy. Instead the player should gain a bonus to attack damage proportional to the own health loss. An injured player plays more and more in a berserk style way. Killing streaks are rewarded by gaining a speed bonus to attacks.
UI elements of the game should be minimalistic. We decided to represent statistics like player health by visual feedback. The more injured the player is, the more the screen turns red at its borders. Other players see the health status of another character, as the player model is more and more surrounded by a dark aura as he becomes more injured. The killing streak bonus is represented by glowing arms. The glow spreads to the shoulders, as the bonus gets higher and the final state is a pair of glowing wings.
Motion Capturing
We had access to the motion capturing laboratory at our campus and wanted to use it for making the character animations of our main character. A higher semester student showed us how to calibrate the cameras, capture the footage and clean it up for further use.
The list of needed animations was prepared beforehand by a numeration of minimum needed moves for our combo-system. These were collected in our game design meetings earlier. Recording the animations was a load of work, but not too complicated. While Stephan Pfisterer started cleaning up the footage, we went back to creating the game.
Problems
The problems arose when I took a closer look at the animations system. Creating a new mod for Half-Life is quite straight forward, if your human characters run around shooting at each other. But our type of game required a completely different kind of movement.
Character animations for multiplayer characters in Half-Life are divided in the upper and the lower body half. A running animation is played, while the character is moving. The upper body parts are animated independently. So a character can have the same shooting animation, no matter if he is standing or running. For our kind of game, we mostly needed full body animation for every move. It was too late when I realized, that we would have to rewrite big parts of the animation system.
To add to this, other problems with the animation system arose. In third person camera, another animation routine was used for the players avatar than for the other players in first person view. This resulted in having all characters playing their animations except for the player’s. As the Orange Box update brought a completely new animation system, the project could be considered to be officially over, because we no longer had time to search through the animation system source code once again.
Other problems with the animations were, that the system to import them into the engine worked fine with the standard set of animations for a running and shooting multiplayer character. But the script files needed had to be heavily modified to import this completely new type of animation set. Unfortunately, Stephan Pfisterer struggled from start to finish of the project to script those files. This added of course to my problems to modify the character animations. I could not really test my code without our set of animations imported. The only animations I could use where those of the standard character.
Lesson learned
To sum it up, these problems added to the result, that our game was not even half finished at the end. We had decent character animations, we had levels and several props and a quite unique concept for a multiplayer fighting game. We just could not add these parts to form a whole.
The lesson from this project is easy, but vital: know your engine. You should never think, that you know how to use an engine unless you have tested exactly the things that you wanted to do with it. And even then, enough problems will arise.
Another important lesson is: never bite off more than you can chew. We maybe could have done a prototype. But hardly with the source engine. We had tried to make a total conversion. Three months were to short, if you had to put additional focus on lectures and exams while working on your project. We wanted to create the game with smooth animations and working multiplayer gameplay. Maybe we should have focused on a prototype using other tools. The results would not have been as good, but at least we would have had a finished game.
On the plus side
Although the game was in the end not in the state that we intended, we had nonetheless a playable version. It was a third person variant of the Half-Life² Deathmatch with melee weapons, which proved, that our main concept, 3rd person melee combat multiplayer, was actually fun to play.
We also learned a lot about working effectively in a team, writing and sharing design documents via a Wiki-webpage and using motion capturing for creating animations.
The project was not perfect, but it was a valuable experience.