Contents  Introduction  Getting Started  Loading Your  Scripts  Conclusion  Printable version     The Series  Storing/Reading  Doing Something  Control Structures

Getting Started

The basic idea behind a custom scripting 'language' for your game is so that you do not have to hard-code every single possible event and conversation into your game. It also avoids the need to recompile the executable for the game each time you wish to slightly alter the storyline or for example the effects of drinking Potion X on a character with a 'Good' alignment.

For this first article in the series I will be explaining the general structure of your scripts, and how to store your scripts on disk, then read from them later.

Warning!

The method to read/write discussed in this article will leave your scripts easily editable by the end-user of your game. This is usually not desirable, so I suggest changing these later to implement some sort of custom resource-file setup that you should use for your graphics and sounds as well.

Script File Syntax/Format

Your scripts will be plain text, formatted with a very simple syntax:

CommandName (Parameter1,[Parameter2],[...])

Each line will have this simple format. There is an exception, though. You will want to be able to define blocks of these commands (I will go into why later). So, to define such a block:

*Block* BlockType BlockName
...CommandsHere...
*EndBlock* BlockName

For example, if there is a block type called 'Event':

*Block* Event Foo
Bar ("asdf")
*EndBlock* Foo

All commands must be contained in 'Blocks', even if there is only one of them. The reasoning for this will become clear later; for now just accept my words as the truth :)

This is the simple structure of your scripts. It may not seem very useful/extensible right now, but later on you will understand. You will just have to trust me about this, just as with the rule about commands having to be within blocks.

Next : Loading Your Scripts