the black hole 
it all ends here. 
bhC login
name:
pass:
 
home
 
 the black hole's front page. all the latest vb rpg development and vbgaming news, as well as this week's feature rpg project!
articles
 
rpg theory (7)
directx in vb (3)
vb rpg programming (4)
miscellaneous (4)
files
 
rpg / tile engine source (23)
full vb games w/ source (5)
'helper' libraries and utilities (13)
effect samples (5)
miscellaneous (10)
rpg projects
 
 vb rpg projects under development by members of the bhC. show them your support, and check out their games!
message board
 
 a forum to interact with your fellow vb rpg programmers. you do *not* have to be a bhC member to post!
links
 
vb rpg programming (5)
vb gaming (14)
general game programming (6)
vb sites (6)
miscellaneous (2)
general rpg programming (2)
contact
 
 you want to contact the guy behind the black hole? here's where to do it!


 
 


<< Back to Category List

Simple Game Scripting Part 1:
Storing/Reading Your Scripts
- page 2


pages: prev | 1 | 2 | 3 | 4 | 5 | next


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.


pages: prev | 1 | 2 | 3 | 4 | 5 | next