Thread: Messy Content: Avoidable?

I think alot of games with alot of specific rulesets and base rules write the rules out on paper then make a scripting language out of it..

How do you make a scripting language? I guess lots of wrapper classes? Perhaps a class factory design?

Well, first of all I find myself cringing less now that I use Code::Blocks, because it makes it look small and very neat (plus everything else Dev-Cpp has).

I read that text files (or whatever type of files) are used constantly for game specific data (even gravity constant, etc).

I just started so my code isn't very messy (to me) yet.

Personally, I'm just making sure I use the right design patterns and structure so my engines (all together making the game engine) are completely seperate from my game specific code. e.g there is draw triangle, and rotate triangle, but those are seperate in the graphics engine and the two functions might be combined in one function in the game engine and that function called in the game-specific code (or through scripting).

Originally Posted by Shamino

I think alot of games with alot of specific rulesets and base rules write the rules out on paper then make a scripting language out of it..

How do you make a scripting language? I guess lots of wrapper classes? Perhaps a class factory design?

They still have to program the commands for the scripting language, so in his case the engine would still look messy because thats completely seperate.

Most games consist of many design patterns, and Factory Method is most likely one of them. One method doesn't make a scripting language though, just like even though you'd use a Stack for the scripting,so that's only one of a dozen of features youd use. Scripting language would be something like text commands that are processed in a Stack, and then depending on what is processed it calls functions from your game engine (which are functions from all other engines tied together).

Game content and rules are all in my mind while I'm designing the engine and the systems accompanying it. I always make sure my classes can work just fine in and of themselves regardless of what the data is.

A script is one example. It is designed for flexibility and ease of use. Your system should be robust enough so that it allows the game designer to 'create the rules'. Your engine is just running one of the systems that you designed. The 'rules' come from how the designer uses the system to accomplish the actual game logic.

So the more robust your script, the more control you hand to the designer and the less you have to hard-code the 'rules'.

I follow this method and it is very similar to Novalogic's WAC system.

1. Very limited amount of language elements.
2. Each function in the script is created to do exactly one thing and do it well.
3. Variables are allowed via specific script functions/keywords.
4. Functions usually require 2 params or 3 at most.

For instance:

Code:

'This is a comment

'Move unit with ID to waypoint list 1
IDtoWP(unitID,1)

'Turn unit 90 degrees
IDRotateUnit(unitID,90)

'Set alert status to green
IDSetAlert(unitID,0);

'Do a random one-time effect
'if this is true 1 out of 20 times
'and Variable at slot 1 is not 1
'and this event has never executed before
'then 
'do a flash of lighting
'rain to 100% in 20 seconds
'Set clouds to 100% in 60 seconds

if (Random(20) and VarNE(1,1) and Never())
  LightningFlash()
  Rain(20,100)
  Overcast(60,100)
endif

'Do a random repeating effect
'If this is true 1 out of 30 times
'and Variable at slot 1 (rain in our script) is 1
'then 
'do 2 lightning flashes
'Doesn't make sense to lightning when no rain

if (Random(30) and VarEQ(1,1))
 LightningFlash()
 LightningFlash()
endif

Check out Novalogic's NILE editor and Black Hawk Down (BHD) editors. The WAC language is awesome and quite easy to use and write for.

You can copy it at your leisure so long as you don't steal their stuff verbatim. But it's a good way to learn how to do this.

For the most part your game engine is ignorant of the game until you supply the data and the script. If the AI looks stupid, it's because it is stupid and only does basic reactions until the level editor breathes more life into it. This puts a lot of control into the hands of the designers and story people which is right where it should be.

My variable system is just a class that handles an array of 65535 values (DWORDS).

Some of the commands are similar to assembly language:

VarNE(A,B) - variable A NOT EQUAL to value B
VarEQ(A,B) - variable A EQUAL TO value B
VarA(A,B) - variable A ABOVE value B
VarB(A,B) - variable A BELOW value B
VarAE(A,B) - variable A ABOVE OR EQUAL to value B
VarBE(A,B) - variable A BELOW OR EQUAL to value B
VarSET(A,B) - variable A is set to value B
VarASSIGN(A,B) - variable A is set to value of variable B
...
...