#### Archived

This topic is now archived and is closed to further replies.

# Script Engine or Hardcode?

This topic is 6248 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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. =^)

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
Those are the technical terms for the subsystems. But they can be as simple as this:
  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;}
(Btw, this is totally untested code, just to illustrate a point.) The simpler your script, the less work it takes to make these things.
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.

##### Share on other sites
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?

##### Share on other sites
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

LOOP {
getCommand();
setLocation(getFollowing());
getCommand();
if (getCommand() == FINISHED) break;
if (lastCommand() == COMMAND) LOOP {
// Put extra commands here
} ENDLOOP
} ENDLOOP

No error-checking is used, nor the game engine. Writing that is part of your work...

##### Share on other sites
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

LOOP {
getCommand();
setLocation(getFollowing());
getCommand();
if (getCommand() == FINISHED) break;
if (lastCommand() == COMMAND) LOOP {
// Put extra commands here
} ENDLOOP
} ENDLOOP

No error-checking is used, nor the game engine. Writing that is part of your work...

##### Share on other sites
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.

##### Share on other sites
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.

1. 1
2. 2
Rutin
19
3. 3
4. 4
frob
13
5. 5

• 9
• 17
• 11
• 9
• 17
• ### Forum Statistics

• Total Topics
632604
• Total Posts
3007369

×