Project Proposal
Motivation
The Adventure Game
An adventure game is one in which the player plays a character, and goes about the game world solving puzzles and interacting with other characters, usually following some plot. The continuance of the story being the reward for solving the puzzles. This is a generic description of the adventure game and there are multiple permutations of configurations. The most recent commercial games tend to be 3D, although 2D games are still favoured in the amateur development community. In both commercial and amateur games, the perspective that the player sees the game can be from a 3rd or 1st person perspective.
These are the major differences between the games, but other than that they remain quite generic. The game can be broken down into three components; characters, the game world and items in that world. The player character is just another character in the 3rd person perspective and there is none in the 1st person perspective. The game world consists of different scenes, which contain characters and items. The player moves from scene to scene interacting with these characters and items. Characters can be conversed with or items can be used on them, items can be used on their own or with a number of other items to do something, for example to create a new item or to solve a puzzle.
Current State of Affairs
For the past 5 to 7 years, the traditional adventure game, (ie. A game which does not use action elements, such as fighting, to advance the player in the game, relying solely on the player's mind to solve the puzzles and hence advancing in the game.), has been a genre of game that has been left by the wayside. Once holding a majority stake in the market share, it has been pushed aside by the emergence of 3D 1st Person Shooters, such as Quake, Unreal Tournament, Half Life etc. The list continues ad nauseum. Other genres have also grown but they all centre round the idea of action, a modern reflection of brawn over brain.
Some of the attributes of adventure games have been incorporated into what would have been classified as a platform game in the past, to create a new hybrid. Games such as "Tomb Raider" and "Indiana Jones and the Emperor's Tomb" would be good examples of this hybrid.
In that time however, the Internet has been host to a growing community of amateur developers who wish to create their own adventure games in the same vein as the games that were once the largest sellers on the PC game market, in the 80s and early 90s, such as "The Monkey Island" games, "Simon the Sorceror," "Myst" and "Gabriel Knight". A number of free engines have been developed to provide this community with the tools to create their own games. This has led to a profusion of amateur games being made.
Not only is the adventure game alive and well in the underground, but there is a number of companies who have new adventure games in development. LucasArts, the makers of many adventure games in the past, have a number of titles in the works, and another company, Revolution are about to release their latest installment in the "Broken Sword" series this month. Other small companies are also emerging with "Syberia" being an example of a game which was a huge success last year. It would appear that the adventure game genre is being looked to once more and it is an exciting time for fans of this kind of game.
Shortcomings of Current Development Tools
There are multiple development tools available already on the Internet for making adventure games. However I find a couple of problems with them.
The most critical of which is that the developer is required to learn a scripting language to create a game. This is unfortunate many of those who wish to create a game have no experience of programming. It limits the number of authors because of the steep learning curve for many. There should be no need in my mind for the developer to have to code anything to create a game. There is one exception to this that I have come across called Visionaire.
Next, almost all of the tools are not cross platform. There are a few tools whose runtime engines and compilers have been ported to Linux from Windows, but these are exceptions to the rule and often the development tool's other utilities have not been ported.
Thirdly, very few provide an integrated development environment from which you can create your game from start to finish. For the most part the development tools consist of a scripting language, a compiler and some miscellaneous tools. Most include some tool to define what parts of a scene can be walked on by a character. My problem with this approach is that it can appear to be quite technical especially to people who have never programmed or have tried anything quite like this. A fully integrated graphical development environment presents an easier tool to conquer, since it is only one tool that needs to be understood instead of many. It can also hide away some of the background processes, instead of the current set of tools which need to be run manually by the developer. Visionaire again does not have this shortcoming.
Lastly, the development tools require, with again only a few exceptions, a runtime engine. Whilst I can see the benefits of having an engine, which one uses to run the data files and scripts, there are other disadvantages. Primarily this being that with new versions of an engine, the older data files often no longer work correctly. This results in an end user required to be running multiple versions of an engine to run different games if a developer does not release a new version of the game. It is also not always a simple process of recompiling for the developer, as the engine's features may have changed and thus the game will require some porting to the new engine. With that in mind, I would prefer if a development tool provided a single executable at the end which would be run by the user, compiled specifically for that game. Visionaire once again does not have this problem.
I have mentioned Visionaire a number of times at this stage, and one would think that it covered all of my problems. However it is in the case of cross-platform compatibility that it falls short. Its IDE is for Windows only and the game it creates uses DirectX, which seriously curtails its portability. A truly cross-platform development environment and runtime environment is needed.
Objectives
No Technical Expertise Needed
My tool should be easy for anybody to use, with this in mind it will have an integrated graphical environment and no scripting will be needed to make the game. Instead the developer will describe the entities in the game, their names and what happens when they interact with other entities. These interactions will be selected from a list of possibilities. Entities in the game consist of items and characters, there will be no confinement of possible interactions with this approach at looking at a game.
Seperating Design From Implementation
As far as possible, I will try to seperate the design of the game from the actual implementation of the game. The game will be described in the IDE, which will store the information in XML files. The developer can take this XML description and translate it into a game that will run. This translation will be specified using an XSLT stylesheet. This seperates the description of the game from an implementation. It will also allow the tool to be used with multiple implementations such as C++ code or the scripting language of an adventure game engine. These implementations could include the various engines already available or another new implementation. It should be easy for a new implementation to be added to the IDE, with a specification of the translation from XML to the implementation using an XSLT stylesheet. I will create a sample translation to a current adventure game engine called AGAST as a proof of concept.
Cross-platform
The IDE will be cross-platform allowing it to be used on a variety of operating systems and architectures. This is a principle, which I strongly agree with. To complete the cross-platform nature of the tool, RAG'D will need its own implementation. This however is viewed as a much later phase of the project.
