Projects - Start A Fight
Project Details
Language: C++
This game was created as a team effort in the final year at university. The team had three programmers and four designers. The game is programmed in 3 dimensions but presents in 2 dimensions and is played in 2 dimensions.
The engine built specifically for this project offers precise timing functions, scheduling, threading, state management, input systems, seamless networking, asset management, downloadable content, a plugin system, a remote terminal, multiple players, parsers for various file formats and network protocols, and support for platform specific hardware functions such as shaders and the Cell processor's SPUs.
It performs all of this in a platform agnostic manner. The engine makes use of the best functionality available on any particular platform. The implementation of an engine feature is transparent to the programmer. In the input system for example it is possible to use multiple modules simultaneously to support the widest variety of hardware possible. The input system is limited to a maximum of 255 input devices. It takes a specific input peripheral and presents it to the program as a standard interface unit. Each device type is profiled so key buttons and axes are in known locations. The input profile system also has the capability to name buttons so that in-game dialogue can refer correctly to the components of the physical device. The input system is able to use multiple libraries simultaneously allowing the system to seamlessly use a variety of input devices like keyboards, mice, controllers (xbox/sixaxis), joysticks, wiimotes, iPod touch, and networked input devices (controllers on remote hosts). The input system will be able to use the Playstation move devices when access to the PS3 SDK is acquired. The system is also capable of supporting more unusual input devices such as the eye toy.
The scheduler in this project has been used in other projects. In this project the scheduler is enhanced to support better timing, task management and automatic threading. Previous schedulers provided pseudo multi-tasking, but this scheduler provides true multitasking which scales automatically with the number of processor cores in the system.
The systems networking utilities allow the game-play programmers to implement the game with very little thought of players on remote systems, although it is necessary for the game-play programmers to issue sanity packets once every so often to synchronise the game across all remote players. The networking layer is also used in the assets manager to provide access to downloadable content.
The engine has a state manager in which state loading and unloading is handled by the new threaded scheduler to make the process of state transitions non-blocking. Loading screens exist as states which are perpetually loaded to provide feature rich loading screens. It is possible to have multiple states loaded and active simultaneously allowing for a split-screen between two players. If the user has multiple screens then the engine could assign each player an individual screen.
