I've had the idea of creating a FPS game with Irrlicht for a few weeks, but have had quite a bit of difficulty sorting my custom camera out. Being new(ish) to C++ really doesn't help. So I come up with the idea of creating a framework on which to base the game. Wondered if anyone would be interesting in the project. Heres a brief bit of documentation about how I figured it could work.
Cameleon FPS Game Engine (Working Title)
Brief Design Specification
Preface
When an application is designed it is hoped that it will become the next “Killer App”, one which will become hugely popular and is essential to have. However, some people will still see this application as “just another .... app”.
In the world of Open Source software, there are several of these applications that already exist. Mozilla (Firefox), KDE and Gnome are good examples of this. Some people prefer KDE over Gnome, some vice versa, and some people prefer Konqueror to Firefox. Looking closer at KDE and Gnome, one of the many reasons why they are so popular is because of the customisation they allow users to have. Themes can be changed, settings tweaked to user preferences and additional third party desklets installed to increase functionality. In essence they provide a platform on which the user can create there own customised desktop, tailored to the requirements and personal preference.
Argueably one of the greatest games of all time is Sierra's Half-Life for Windows. Years after its release it is still hugely popular because communities of users continue to expand on the original game, creating modifications and adding functionality to the original game. Counter-Strike, a modification for Half-Life, was one of, if not, the most popular internet games for a long time. Half-Life was not the only game to gain success from modifications, the Quake series, Far Cry and Call Of Duty are some others to name but a few.
The idea of the Cameleon FPS Game Engine is to create a framework on which FPS games can be created as easy as modifications can be created for games like Half-Life. By this it is meant that the game engine should feature all the requirements needed to be able to play a FPS game, such as the phyics engine, configuration system, 3D engine, event handler and an entity parser. The minimum that someone should have to do to create a modification is make maps and add entity information such as player starts and pick-ups. In order for this to be possible, an original game would also need to be created to create the default entities, and to test the features of the engine.
Analysis
The game engine will be required to do various tasks and as a result of this the programming required would be quite immense, something that a project based on volunteers would not be able to achieve due to time restrictions. As a result of this there are several possible ways to go about the task, this is the proposed plan of action.
Utilise the Irrlicht Engine for the 3D requirements
Utilise *.BSP files for mapping. Enables the use of lightmaps.
Utilise either Q3 entities from BSP files of create XML file containing details of entities.
Utilise either a physics engine OR code basic physics such as gravity only.
As can be seen from the above, some of the processes which would take a long time to code have already been completed. The physics of the game engine will probably cause most problems as there is the issue of speed to consider. Perhaps the initial release should only include basic physics in order to establish a code base on which additional features can be added a later date for a new version.
There are several Quake 3 entity parsers available through the Irrlicht forums, but there have been some issues with reliability due to the way different map compilers add the entity information. For this reason, the use of an XML formatted file containing this information could be more reliable. Below is a very quick example of how it could work.
<PLAYERSTART name=“player_start_1” orientation=“270” positionX=“180” positionZ=“200”/>
The XML parser would then be able to determine the entity type, “PLAYERSTART”, and create a new object using the details contained within. For entities like doors etc. it may be possible to load a model from a file using a path contained within the XML data.