Script Engine or Hardcode?
Author
Would it be easier to write your own script engine and go through making your own compiler, or is it easier to hardcode some functions and put them in a library?
For example, script engine does
#move char1 13right 4up; // moves character 1 13 squares right
// and 4 up
But can you hardcode a function that can be refrenced buy this call:
Move(char1,13,0,4,0);
and it''s prototype here
int Move(DWORD character, int right, int left, int up, int down);
Which one would you prefer? Which one is easier for that matter! =^) I think I''d go with the hardcode, since I''m 13 and I don''t have the guts to tackle a script engine... Maybe after a semester of CS. =^)
If you have people working with you that can write scripts but no code you should use a scripting engine. Otherwise I would just write everything in code, using a library.
It depends. For most projects I would prefer both. Certain things scream to be scripted. Others should be coded. Your scripting language should be very simple, otherwise you risk having bugs appearing in the game because of major bugs in your scripting language (ie, if your scripting language starts looking like a programming language, you''ve gone too far). An example of things that should be scripted are cutscenes. Some advantages of scripts are
1) People that can''t program can change how the game works.
2) Changes can be made at runtime, without recompiling. (unless you compile your scripts)
Anyway, just my opinion.
1) People that can''t program can change how the game works.
2) Changes can be made at runtime, without recompiling. (unless you compile your scripts)
Anyway, just my opinion.
Author
I always thought that scripts needed a lexer, parser, and a compiler... That's what the tutorial's I've read say, anyway.
Edited by - Dismantler on August 13, 2001 3:12:09 PM
Edited by - Dismantler on August 13, 2001 3:12:09 PM
Those are the technical terms for the subsystems. But they can be as simple as this:
Note that (a) you don''t need a compiler. Instead, you just interpret the code as you go along, and (b) you still have to do a little processing on the parameters that you pass to a function. It''s easy enough to pick apart a string, though.
void Lexer(String script_line, String& command, String& params){ // Use a stringstream for easier processing istringstream ss(script_line); // Read the 1st word, which is the command ss >> command; // Read the rest, which is the parameters params = ss.str(); return;}void Parser(String command, String params){ if (command == "MOVECHAR") MoveCharacter(params); else if (command = "KILLCHAR") KillCharacter(params); else cout << "Bad command ''" << command << "'' to parser." << endl;} Note that (a) you don''t need a compiler. Instead, you just interpret the code as you go along, and (b) you still have to do a little processing on the parameters that you pass to a function. It''s easy enough to pick apart a string, though.
Author
Would that be the program, or would it be in your game? If it''s in your game, do you just write strings as commands of your script? Is it just as easy to implement?
As Thrump says, it depends on your program. Small programs need only hardcoding, while HUGE worlds probably need scripts.
Hardcoding isn''t that hard, I suppose.
The script-files are constructed depending on your application. Say you''re making an adventure game (I wrote something similar a while ago):
#LOCATION:woods
#BACKGROUND:bg0.tga
#COMMANDS
#IF
blabla...
#ENDIF
#ENDCOMMANDS
// not part of file! Extra stuff can be put here.
#FINISHED
Reading this script-file would go like this (pseudo-code):
// Gets the command (#...) at the current line
char *getCommand();
// Returns the rest of the line from above
char *getFollowing();
// Loads an if-statement from file into an if-slot into the game engine
void loadIf();
LOOP {
getCommand();
setLocation(getFollowing());
getCommand();
loadBackground(getFollowing());
if (getCommand() == FINISHED) break;
if (lastCommand() == COMMAND) LOOP {
if (getCommand() == IF) loadIf();
// Put extra commands here
} ENDLOOP
} ENDLOOP
No error-checking is used, nor the game engine. Writing that is part of your work...
Hardcoding isn''t that hard, I suppose.
The script-files are constructed depending on your application. Say you''re making an adventure game (I wrote something similar a while ago):
#LOCATION:woods
#BACKGROUND:bg0.tga
#COMMANDS
#IF
blabla...
#ENDIF
#ENDCOMMANDS
// not part of file! Extra stuff can be put here.
#FINISHED
Reading this script-file would go like this (pseudo-code):
// Gets the command (#...) at the current line
char *getCommand();
// Returns the rest of the line from above
char *getFollowing();
// Loads an if-statement from file into an if-slot into the game engine
void loadIf();
LOOP {
getCommand();
setLocation(getFollowing());
getCommand();
loadBackground(getFollowing());
if (getCommand() == FINISHED) break;
if (lastCommand() == COMMAND) LOOP {
if (getCommand() == IF) loadIf();
// Put extra commands here
} ENDLOOP
} ENDLOOP
No error-checking is used, nor the game engine. Writing that is part of your work...
As Thrump says, it depends on your program. Small programs need only hardcoding, while HUGE worlds probably need scripts.
Hardcoding isn''t that hard, I suppose.
The script-files are constructed depending on your application. Say you''re making an adventure game (I wrote something similar a while ago):
#LOCATION:woods
#BACKGROUND:bg0.tga
#COMMANDS
#IF
blabla...
#ENDIF
#ENDCOMMANDS
// not part of file! Extra stuff can be put here.
#FINISHED
Reading this script-file would go like this (pseudo-code):
// Gets the command (#...) at the current line
char *getCommand();
// Returns the rest of the line from above
char *getFollowing();
// Loads an if-statement from file into an if-slot into the game engine
void loadIf();
LOOP {
getCommand();
setLocation(getFollowing());
getCommand();
loadBackground(getFollowing());
if (getCommand() == FINISHED) break;
if (lastCommand() == COMMAND) LOOP {
if (lastCommand() == IF) loadIf();
// Put extra commands here
} ENDLOOP
} ENDLOOP
No error-checking is used, nor the game engine. Writing that is part of your work...
Hardcoding isn''t that hard, I suppose.
The script-files are constructed depending on your application. Say you''re making an adventure game (I wrote something similar a while ago):
#LOCATION:woods
#BACKGROUND:bg0.tga
#COMMANDS
#IF
blabla...
#ENDIF
#ENDCOMMANDS
// not part of file! Extra stuff can be put here.
#FINISHED
Reading this script-file would go like this (pseudo-code):
// Gets the command (#...) at the current line
char *getCommand();
// Returns the rest of the line from above
char *getFollowing();
// Loads an if-statement from file into an if-slot into the game engine
void loadIf();
LOOP {
getCommand();
setLocation(getFollowing());
getCommand();
loadBackground(getFollowing());
if (getCommand() == FINISHED) break;
if (lastCommand() == COMMAND) LOOP {
if (lastCommand() == IF) loadIf();
// Put extra commands here
} ENDLOOP
} ENDLOOP
No error-checking is used, nor the game engine. Writing that is part of your work...
If I had a bunch of people making levels, npc''s, or something like that, I''d use scripts or datafiles. Otherwise it''s easier just to code everything.
quote:Original post by Dismantler
Would that be the program, or would it be in your game? If it''s in your game, do you just write strings as commands of your script? Is it just as easy to implement?
This is hard to answer, because it''s not clear what you''re asking... a script is just text. You need something to change that script into things that your program can understand; this is what the lexer (short for lexical analyser) does. Then you need something that looks at those bits and decides the actions to take; this is what the parser does. The lexer and parser are part of your program, and are the interface between the scripts and your game logic. Their complexity (especially for the parser) is totally dependent on the complexity of your language. If you can make it look like assembly, where every script command is just an operator with a parameter or two, then writing the parser is trivial. If you need blocks and function calls and different levels of scope and lots of other complications, the parser is going to get more complex. You still have to do a lot of hard coding, because the script can only tell your program which functions to call: it can''t replace functions entirely.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement