FPS Reference

(Difference between revisions)
Jump to: navigation, search
(Stat System)
Line 28: Line 28:

Revision as of 19:39, 29 February 2012



Advanced Customizable Character Controller

A key feature of any FPS is how the character moves around in the world. The default Heroengine ACCC is setup well for a mmorpg character but not for a FPS character. The first step to that goal was that a new character model and animation set were developed. Then we overrode certain server scripts to make sure characters start with a FPS character controller rather than the default one.

The character controller then needed to turn inputs from the user in to specific animations and behaviors for the new character model. The basic ACCC was gutted of most of its features to be more streamlined with our needs. In some cases this just meant deleting large sections of code that just were not relevant to FPS,for example swimming logic was taken out. There is no water in our game design so there is no need for the character controller to know how to swim. In other cases code need to be added for new behaviors. One of the things that needed to be added was a way of telling the character that you were firing or reloading your weapon.

Another major concept that the character controller needed to handle was the fact that character rotation would no longer be dictated by the direction the character was moving. In the HeroEngine default controller depending on where your camera is facing your character will animate and turn toward that direction. In a FPS movement almost never controls where you are directly aiming. This took handling of the character rotation out of the controllers hands.

In most cases you do not want the ACCC to be involved in game logic. The ACCC should sit between your game logic and animating the character. This means that the ACCC should react to commands from your game logic and interpret all the different signals its getting in to one final action. There are cases of where the FPS ACCC does not do this. While it technically works it means that there is tight coupling between different game systems and the character controller.

Scripts Involved:

Server - Client Communication

Weapons and Attacking


Stat System

Modern FPS games track stats for many different actions. Those things can range from bullets fired, accuracy, steps taken, head shots, and the list goes on. We centralized stat tracking in to a system node that would get updates on the server for players various actions. In this implementation for simplicity stats are not persisted and we only track kills and deaths. The stats system could be easily extended to include more stats via the observer/listener pattern and adding in more fields on the stats node.

The way it works right now is when a player joins the match they also register themselves with the stats system. Once registered their account ID is added in to a lookuplist on a statnode on the server. The stat node is tracked by the stats system. When updates to the node happen the stat system is notified and then sends out messages to any systems any or clients that care about the update. Most notably the leaderboard on the client tracks stats and displays the proper information in real time.

The main drawback with the current implementation of the stat system is that it is not persisted. Stats are tracked for the duration of a player being in a match and then discarded if the player leaves the game ever. To implement a system that will permanently keep stats the server would need to write out files to the repository or make a arbitrary root stat node that is associated to the account root node. Since a system like that was beyond the scope of our demo we did not go with that implementation and kept it simple.

Scripts Involved:



Personal tools