This post now follows two, intertwined projects: the Perception Interactive Fiction Engine (which does not have a lame abbreviation) and the first game built upon that engine, Seadome: Perception.
The Text Adventure Competition 2008 by MISoft Studios is running again, and the prizes and rules have been set. This year, I'll be entering a text adventure based upon a Game Design I've been talking about more often - a design that one almost sprung into reality were it not that it is too ambitious to take on for now.
But on the other hand, the riddles and story of Seadome is complex enough to contain a substory or a parallel story. This particular story , which goes by the name of Seadome: Perception, starts exactly 12 years before the events of Seadome, and ends a few moments before Seadome ends.
The story will follow three of the inhabitants of the Australia 4 Dome, a secret initiative of the United Space Program initiated in 2097. Testing both materials and the human spirit against extraterrestial circumstances, a number of closely monitored 'seadomes' is built. However, to create a true reconstruction of the situation on other planets, an additional seadome is built and more than twenty experts are selected to live in the dome for 15 years - no monitoring and no contact to the outside world.
For twelve years, everything goes well - however, during that twelfth year - something goes horribly wrong. In Seadome, players will learn who will survive the situation underwater, when twenty people fight for their right of survival - twenty people, no help, one submarine. In Seadome: Perception, however, the player learns how exactly the events of Seadome unfold and uncovers a potentially fatal plot.
The gameplay is parser-driven. A simple parser allowing single-line commands is the heart of the gameplay. Also, another core function and signature for the Seadome games is the including of realtime rising water. However, I felt realtime was not appropriate for a text-based game and thus, Seadome: Perception features what I now call semi-realtime gameplay. Per command, the time progresses in realtime for two minutes, after which it will keep to the maximum of two minutes per action. This way, you can choose to read through most passages calmly, but there will still be a time-pressing aspect in certain parts of the game, as sometimes seconds can be the difference between life and death.
The progress is rather good. By now, the engine is completed. The game is script-driven, allowing me to add levels in a easy and quite complete way. A quick list of functions available is located in the code-tag below.
With five seperate files, one can create a full act with advanced interaction and possibilities. Currently, the Prologue, which is the first act, is finished. There will be seven acts, proceeding in a linear fashion. Their names are set to be:
Quote: "
• Prologue: In Cold Blood
• Chapter 1: The Breach
• Chapter 2: Secrets Revealed
• Chapter 3: Submerged
• Chapter 4: Fatally Vengeful
• Chapter 5: Unlikely Truth
• Chapter 6: The Deceit Was My Own
• Chapter 7: Dead Men Cannot Drown"
That's what I'll tell for now, I think. More than enough. Oh, right, screenshot.
[quote][/quote]
Yes, I know, it's a cute logo
The Perception Engine manual
================== PERCEPTION ENGINE ====================
An interactive fiction engine by Rami Ismail aka tha_rami
By using this engine, you agree to the terms of the dis-
claimer, as described in section 3.
=========================================================
*********************************************************
i) CONTENTS
*********************************************************
i. Contents
ii. Introduction
iii. Credits
1. Scripting
- Format and Syntax
- Scripting the intro
- Scripting an act
- Scripting a location
- Scripting persons
- Scripting dialogue
- Scripting triggers and events
- Scripting credits
2. Multimedia
- Required multimedia
- Using images
- Using music
3. Terms of Use
- Disclaimer
- Limitations
*********************************************************
ii) Introduction
*********************************************************
Welcome to the Perception engine, a interactive fiction
engine created by Rami Ismail.
The Perception Engine is an engine that is built upon the
idea that Interactive Fiction should be accessible to
both play and create. Therefore, this engine allows you
as an (aspiring?) game creator to use a relatively simple
system, called Scripting (not to be confused with coding)
to create complex and flexible interactive fiction games.
Interactive Fiction is a bit like a digital novel, in
which the player chooses his/her actions through either a
menu-based interface or a parser. A parser means that the
player enters a command and the game 'parses' that into
something it understands, so that it can continue the
story accordingly.
Due to limitations of the programming engine used to
create the Perception Engine, it requires the latest
version of DirectX. This also means it will only run on
a Windows system. Windows Vista comes with a compatible
version of DirectX pre-installed.
Below the credits, you'll find a detailed manual that
goes over the syntax and commands you can use to build
your own game.
*********************************************************
iii) Credits
*********************************************************
- Perception Engine coded in DarkBASIC Professional by
The Game Creators.
- All code by Rami Ismail (aka tha_rami).
- All included media by Rami Ismail (aka tha_rami)
- Special thanks to:
Shawn Bower, for luring me into DarkBASIC.
Gil Galvanti, for extensive testing and support.
Suzanne Leeuw, for her support, love and care.
*******************************************************************************************************************
1. Scripting
*******************************************************************************************************************
To script, all you need to have is a story, imagination and a plan. For the first game made in the engine, Seadome:
Perception, I created a drawn out map of all locations on a sheet of paper, to then devise descriptions and ideas.
Finally, the program you need to script is any program that can open, read and edit .txt files. Any computer comes
with such a program pre-installed. In Windows, one can use "Notepad", in Linux, "gedit" will suffice. Just remember
to save the files with the correct extension and filename!
Although one can script in any desktop environment, the Perception Engine will only run under Windows.
- Format and Syntax
-------------------------------------------------------------------------------------------------------------------
The Syntax of Scripting is quite simple - there are three types of data: the Object, Command, Variable and the List.
An Object is the thing you're working on. These are written between "[" and "]" and follow certain rules. They con-
tain the commands that allow the engine to know and process what you want each Object to do. Do not confuse Script-
Objects with game objects, as they are entirely different terms.
A command is always encapsulated by the "<" and ">" symbol and a hard return, then followed by either a number of
variables or a list. A variable is a value you set, and depending on the command the engine interprets this value.
Some commands require lists. A list allows you to add multiple variables to a single command, but you need to keep
hard returns between each variable. Also, a list always ends with a "0" (zero). Do not forget this, as failing to
end a list with a 0 will yield either instabilities or a loading error.
| EXAMPLE
| Object: [Dialogue 1]
| Command: <Name>
| Variable: John Doe
|
| Command: <ObjList>
| List: 14
| 17
| 22
| 0
Each command has its own location and its own meaning. Below you will find a reference to each available command
and its purpose. Also, you will find some general rules to use these commands effectively and safely.
To script a level, the Perception Engine uses five files, all located inside the data subdirectory (data). These
files are named ScriptData files, and have a specific filename and extension. The filename of a ScriptData file
is always the number of the act for which it contains data. The extension is dependent on the type of data it
contains. Perception uses five types of data:
- Location (.sdl): These files contain information about the locations one will visit and what they contain and do.
- Objects (.sdo): These files contain information about available objects, interaction with these and usage.
- Persons (.sdp): These contain information about persons and their description or interaction.
- Dialogue (.sdd): These contain information about dialogues and their effects on gameplay.
- Info (.sdi): These hold all information about the current act, and contain triggers and events that can occur.
To be able to run the engine, you will at least need the files "intro.sdi", "1.sdl", "1.sdo", "1.sdp", "1.sdd" and
"1.sdi" in the data subdirectory. In fact, you can create a full game with just one "act", but to keep loading times
low and the game fast, it is recommended to make clear boundaries to either areas or specific events and to create
chapters. An 'act' basically is to the game what a chapter is to a book.
- Scripting the intro
-------------------------------------------------------------------------------------------------------------------
To script the intro, create a file called "intro.sdi" in the data subdirectory. In this file, use a single line for
each line of the intro. During the intro sequence, each line will fade in and out slowly. This will be accompanied
by the game using the file "introbg.jpg" in the images subdirectory and "intro.mp3" in the music subdirectory. If
you do not wish to have an intro, do not create a "intro.sdi" file. There is no limit to the length of the intro,
although it is recommended to keep the intro short and sweet. Using 15 lines as maximum would be considered doable
by most.
While there is no problem not having a "intro.mp3" file, not having the "introbg.jpg" file while having an intro
will result in a crash.
- Scripting an Act
-------------------------------------------------------------------------------------------------------------------
Scripting an Act is how we call scripting all the locations, objects, persons, dialogue and information that the
engine needs to create your chapter. To do this, you need to create and fill five files according to the rules set
forth later. To start creating an act. create a file called "#.sdi", where # is the number of the act you're creat-
ing. For the first act, this would be "1.sdi". For the sixth act, the filename would be "6.sdi".
Now, we need to define a Preload to tell the engine what the act is about.
|
| [1. PreloadStart]
| <SetActName>
| Fill in the name of the act here.
| <SetActorName>
| Fill in the name of who you are playing during this act here.
| <SetLocation>
| Fill in the general name of the place where this act plays.
| <SetHour>
| Enter the time this act starts in hours.
| <SetMinute>
| Enter the time this act starts in minutes
| <SetDay>
| Enter the day of the month this act starts. (Numeric value!)
| <SetMonth>
| Enter the month this act starts (Numeric value!)
| <SetYear>
| Enter the year this act starts (Numeric value!)
| [PreloadEnd]
|
Copy the above into your file, and replace all lines with the desired information. You can only use one line per
variable. Now, the game will know what the act entails - but there's no information about what will happen during
the act yet. Do not forget to save the file in the data subdirectory.
- Scripting a Location
-------------------------------------------------------------------------------------------------------------------
A location is any room, area or location in your game. This can vary from a simple hotelroom to a ventilation duct
and from a stadium to a planet, but a location is a spot in which things can be placed that the player can interact
with. A good design of locations is crucial to creating a good interactive fiction game.
Each location is considered an scripting object and thus is formatted as follows:
| [StartLocation #]
| ...commands go here...
| [EndLocation #]
It is recommended to keep an empty line between Location objects for overview.
Commands you can use are the following:
============================================
REQUIRED
<Name> : The name of the location. This should be a short, descriptive name of the location.
<Tutorial> : A single line of text that is displayed in a popup to inform the player of something.
<Description> : A single line of text that is displayed to describe the current location. A good description
mentions everything the player can interact with and every place the player can go to from the
current location.
OPTIONAL
<ShowOnce> : A single line of text only shown the first time a player visits a location.
<ObjList> : A LIST containing the object numbers of all objects available in the current location.
! THESE NUMBERS REFER TO OBJECTS IN THE .SDO FILE OF THE ACT !
<Persons> : A LIST containing the object numbers of all persons available in the current location.
! THESE NUMBERS REFER TO OBJECTS IN THE .SDP FILE OF THE ACT !
<Dest#####> : Replace ##### with North, South, East or West. The Object number of the location one can go to
from the current location.
<Door#####> : Replace ##### with North, South, East or West. The Object number of the object that is the door
for the relevant direction.
! THIS NUMBER REFERS TO AN OBJECT IN THE .SDO FILE OF THE ACT !
<DestCust> : The Object number of one additional location one can go to from the current location, only by
typing the name of the location. This Command uses two variables on two lines: the first line
contains the name of the custom destination. The second line is the location Object number of
the location.
<DoorCust> : The Object number of the object that will be used as door to a location set by <DestCust>.
! THIS NUMBER REFERS TO AN OBJECT IN THE .SDO FILE OF THE ACT !
<Trigger> : The Object number of a trigger that should be fired when the player enters the location.
! THIS NUMBER REFERS TO AN OBJECT IN THE .SDI FILE OF THE ACT !
============================================
Also, states can be used. A state basically is having one location that is able to change when a trigger is
fired. This means you can let a door collapse, or have an item disappear. The possibilities are endless.
To create a state, first create the 'normal' state. Then, create the state by using:
| {State1}
| ...commands go here...
| {EndState1}
Any commands used will change the original commands. However, if you do not add a certain command between the
state tags, the engine will assume it can copy this information from the original state. You can add up to 10
different states per location by adding a new "{State#}" tag after you close the previous one.
Save the file as "#.sdl" in the data subdirectory, where you replace # with the number of the act.
- Scripting Persons
-------------------------------------------------------------------------------------------------------------------
Scripting persons is important since persons are a valuable source of information. While you can in theory create a
full game without a single person, having them gives the illusion that the world is inhabited by others.
Each person is considered an scripting object and thus is formatted as follows:
| [StartPerson #]
| ...commands go here...
| [EndPerson #]
It is recommended to keep an empty line between Person objects for overview.
Commands you can use are the following:
============================================
REQUIRED
The only thing required is one or more of the following:
<FirstName> : The first name of the person. The player can use this to identify someone.
<LastName> : The last name of the person. The player can use this to identify someone.
<Nick> : A nickname for the person. The player can use this to identify someone.
OPTIONAL
<Description> : A description of the person - for example looks or things the player knows about the character.
<Dialogue> : The number of the dialogue that will initiate when the player interacts with this person.
! THIS NUMBER REFERS TO AN OBJECT IN THE .SDD FILE OF THE ACT !
<Item> : The number of the object the player receives when interacting with this person.
! THIS NUMBER REFERS TO AN OBJECT IN THE .SDO FILE OF THE ACT !
<Trigger> : The Object number of a trigger that should be fired when the player interacts with the person.
! THIS NUMBER REFERS TO AN OBJECT IN THE .SDI FILE OF THE ACT !
============================================
It is recommended to have a description for all persons you create.
Save the file as "#.sdp" in the data subdirectory, where you replace # with the number of the act.
- Scripting Dialogue
-------------------------------------------------------------------------------------------------------------------
Dialogue comes in two forms: written and oral. Oral dialogue is talking, written dialogue can be a book, e-mail or
basically anything. By using the "mailbg.jpg" image, you can change the image used as background for written dia-
logue to fit your setting. By using the "conversationbg.jpg" image, you can change the image used as background
for oral dialogue.
Each dialogue is considered an scripting object and thus is formatted as follows:
| [StartDialogue #]
| ...commands go here...
| [EndDialogue #]
It is recommended to keep an empty line between Dialogue objects for overview.
The Perception Engine will be made available for free after the results of the competition are in.
DEMO: PROLOGUE - IN COLD BLOOD | Link
A mod has been erased by your signature because it was larger than 600x120
