ASAE - Description and Milestone Goals
Written by Benjamin Anderson
This document is to outline the goals and capabilities of ASAE [Pron: az-ehy]. This is not technical documentation or an API reference for developers but a general outline of abilities and the reasoning behind them. Please note that the phrase "Adventure Game" within this document will reffer specifically to the Point-and-Click sub-genre.
The Anderson Scriptable Adventure Engine, ASAE, is a 2D Point-and-Click Adventure Game scripting engine designed to be cross-platform and simple for non-programmers to pick-up and utilize in the creation of interactive, context based video games. Its strict adherence to "Classic" adventure game formula, including but not limited too, the concepts of "Rooms" and "Verbs" as core gameplay mechanics reduces its scope to avoid both bloat and creep. This in turn lends itself to simplified syntax when defining a game script, as many object properties are replaced with a cascading list of pre-determined attributes.
1. Definition of classic adventure game formulaThe following chapter is to outline what a "Classic" adventure game is by the elements within it.
A Room within the context of an adventure game is a playable area with properties dictating its interaction. The reason it is called a "Room" and not The World, is because each Room should be seperated from each other in scope. Specifically, there are two properties a Room must possess; hit-boxes and objects.
Hit Boxes determine where the user is permitted to explore, and creates boundries alluding that a physical obstruction exists, such as a wall or potted plant. Unlike other video games, a hit-box in an adventure game is never used for enemy interaction, and is not to be confused with proximity to an enemy; IE they see you on the other side of the Room, therefore triggering a game over. Each Room is also contextually bound to its contents; For Example, an object defined as a Tool-Box within a Room will lead the user to assume that the room based on context is a workshop or other such workspace.
Objects have two modes of operation, which can be defined as "Descriptive" and "Necessary". Descriptive objects do not require user interaction to allow the game to progress. Descriptive objects are World Building in story telling; to give the user a valuable clue, or to engage the user in banter to help enforce believability and suspension of disbeleif. An example of a Descriptive object could be a painting hanging from a wall, whereby the Player Character makes an off-the-cuff remark about the owner's poor taste for comedic purposes. This in tern informs the user a little more about the Player Character's personality, that the Room they are in belongs to someone whom may collect art, and that the world as a whole has an appreciation for the arts if the characters within the world can create, buy and sell paintings.
Necessary objects are those which require user interaction in order to progress, and their object permanency is defined by the object's context. If, for example, a user requires a key to open a door, the key object will not have permanency as once the user interacts with the key, logic dictates that you grab the key and put it in your pocket. The object no longer exists in the room as it is now wihin the user's inventory.
Necessary objects with permenancy, however, are those which logically cannot be moved from their original location. You cannot take a light switch off the wall and carry it in your pocket, but you can interact with it in a way that is necessary to advance the game.
Within an adventure game, user interaction with an object is not contextual in the sense of containing a defaul based on the circumstances leading to it, with the exception of the afformentioned object permenancy. In other video games, especially those which are event driven, an object's interaction is entirely based on the most obvious contextual use. You open a door, you eat bread, you watch a television programme. These actions are performed with a single action button, such as the left mouse button on PC or the X button on a PlayStation controller.
Within these types of games, the verb is intrinsically bound to the object as per the examples above. In an adventure game you are allowed to choose the verb rather than resort to a default. So rather than opening a door, you have the option to open, look at, and in more esoteric games, even lick and smell the door.
The choice of verb opens up unique interaction possibilities, either for purely comical reasons (smelling a fig could trigger the player character to go on a long-winded rant on why they do not like figs), or as a solution to a puzzle (a door could have a tongue scanner, therefore requiring you to lick the door).
iii. Dialogue Trees
Adventure Games are predominantly story driven, albeit driven by user interaction with characters or Descriptive objects, with narration from a 3rd person perspective appearing infrequently (only in cut-scenes or at major milestones within the game) or not at all. Many so-called "Classic" Adventure Games tend to use the latter (no narration at all), although this may have simply been a limitation of late 80s to early 90s personal computer memory; but as with all limitations they lead to creativity, and a lack of narration has now become the Defacto standard for Adventure Games.
Dialogue Trees are a Tree Structure of potential choices given to the user when interacting with other characters within a Room. The use of Dialogue Trees started with the first Graphical Adventure Games of the mid 1980s and have become a standard method in Adventure and Role-Playing games for character interaction.
Prior to Graphical Adventures, some form of complex Natural Language Parsing was required when programming Text Adventure games, as the only method of interaction with the game was by sentences typed in via the User's keyboard. The reason for parsing was that a user could potentially type anything into the input prompt. If you needed to look at a scrap of paper, the computer needed to understand a vast array of potential commands, including:
$ look paper
$ look at paper
$ look at scrap of paper
$ look at the scrap of paper
$ look scrap paper $ view scrap paper $ read scrap paper
Dialogue trees allow simple interaction and simple implementation. A user can still gleem character personality and traits, as well as valuable world building from a dialogue tree without any difficult and costly Language Processing. It also removes user frustration, as they may not know what sentence the computer is expecting in order to progress.
2. Minimum Viable Product
With what has been defined in Section 1, we can determine the absolute minimum required to develop what can be defined as an "Adventure Game". Parsing and Rendering of game scripts, complex music and graphics and other such items are not required for the Minimum Viable Product.
The basics needed are the abilities to:
- define a Room as a collection of physical boundaries (hit boxes and/or masks) and objects.
- define a player character.
- position the character in the Room via keyboard and mouse input.
- interact with one descriptive object.
- interact with one necessary object.
- render basic graphics.
Goals for Pre-Alpha 1
In order to be considered ready for Pre-Alpha, the following would have to be implimented:
- All items in Minimum Viable Product.
- Script Parsing and Rendering using AGD Script.
- Render Minimum Viable product using only AGD Script
i. Definition of AGD Script
ASAE Game Definition Script (AGD Script) is a plain text file to load into the engine with which game developers can define their game in full using easy to read and easy to write syntax. The purpose of AGD Script is to allow developers with limited programming knowledge to write Adventure Games in their entirety. At no point should a developer using ASAE see any components of the underlying engine once version 1.0.0 is released.
The purpose of an AGD Script is to allow the game to be ported to any system and remain playable, so long as said system has an appropriate ASAE engine implimentation installed.
With an AGD Script in Alpha 1, a developer should be able to define the Character (sprite graphic, hit boxe, Unique ID), Descriptive Objects, Necessary Objects, and a Room in which objects are collated. A potential AGD Script (syntax subject to change) is as follows:
// define character
// define objects
// define room after objects
[hitbox]:10 10 50 50
// final global game properties