7 replies to this topic

[Mephs]

One thing I'm unclear about (more on the pipeline side of development), I see a lot of people saying write just the basic game code in a language like C++ but do all the logic in Python or Lua, or the like.

What exactly does this mean? By game logic does this mean writing story driven events or other non-standard events in the scripting language?

I.E. the basic game code would consist of things like how certain procedures happen, like movement while the scripting language would handle spell sequences or "story" events?

I'm a bit lost on how to organize future code, as right now I've been writing everything in the base language.

[Mattias Gustavsson]

Depending on your situation, you might not want to integrate scripting at all...

If you don't need non-programmers to be adding content to your game or make mods for it, and it's just yourself who will be writing the game, I would say don't bother with it. It's just going to slow you down and be a pain to work with compared to writing in a proper IDE, with a good compiler/debugger.

If you're convinced you need a scripting language, it should be a custom one which is specifically tailored to the needs of your game. Remember, you want the scripting to make your life easier, not harder.

One thing you can do to make things easier, is have some of the game data specified in text-based data files (.ini files, XML files or whatever you fancy), and have functionality in your game to reload the data while the game is running. This can be really handy while you're tweaking and balancing things, but the key here is the dynamic reload - without that, there's not much point having external data.

[monjardin]

Mattias Gustavsson said:

It's just going to slow you down and be a pain to work with compared to writing in a proper IDE, with a good compiler/debugger.

There are IDEs and debuggers available for Python and Lua, but your mileage may vary. Values or logic that need to be tweaked heavily would be an exception since you can avoid repeatedly recompiling with an interpreted language, but that brings us to the next point below.

Mattias Gustavsson said:

One thing you can do to make things easier, is have some of the game data specified in text-based data files (.ini files, XML files or whatever you fancy), and have functionality in your game to reload the data while the game is running.

Lua is really good at exactly that. It's original intent was to eliminate the need for writing yet another configuration file parser (YACFP). I choose it over XML these days even when I need a tree structure. For INI type files, just replace [section headers] with table declarations. Let Lua do the parsing and then pull the variables out of the Lua state by name. You can even use Lua to parse CSV files* if you wrap the text into a table declaration.

* There are exceptions (e.g, strings must be enclosed in quotes), but if you are controlling the input it's passable.

[monjardin]

Mephs said:

I'm a bit lost on how to organize future code, as right now I've been writing everything in the base language.

To get more on topic, I would say keep writing everything in the base language until you get to a point where say to yourself, "I sure wish there was a more efficient way to adjust logic and add more content without rebuilding". If you don't know where you need scripting capability, then you would probable waste time unnecessarily at this point.

[Mattias Gustavsson]

monjardin said:

Lua is really good at exactly that.

Too good in that case :-) I've seen lua used exactly for that purpose, but the team was quite large and kept changing over the year or two it took to finish the project, and you wouldn't believe the mess the lua thing had grown into by then... It seemed as if the fact that you could write code in it encouraged some people to do just that, when defining data would have been quite enough...

I'd say keep it simple. If you need to define data, use a data definition format, not a programming language. If you need a scripting language, make a simple one that does just the thing you need, and nothing else. In this case, as in so many other, flexibility is not a good thing :cool2:

[Mephs]

Well, I was thinking I could use Lua to make scripting certain non standardized "events" work easier, like say, the animation sequence for a spell, or something that requires obscure one-time specific animations (like a cutscene). They'd utilize things hard coded in the engine but not necessarily have to be hard coded in.

Also I do want a means to let other people help develop these things that need to be adjustable on the fly without a huge amount of coding required. I think that's all I'd use scripts for.

Then keep references to what all the spells do, range, damage modifiers, and then also store the lua scripts which create the particle effects and other things on screen in a client database (ODBC?)

Right now the base code of the game stores things like animation parameteres (which UV range to use for what classification of animation, such as An.WALK, An.JUMP, An.FALL, An.CUSTOM [which would use a lua script to define it's animation paramters). But in this sense basically the base code would take a script saying "Play the CAST animation for 3 seconds, then spawn a particle effect with these parameters, and then make a giant bird come down and eat whatever is on that tile when this spell is cast". This is how I *Think* it should work in the end result, but what is standard practice I don't know with Lua just yet, I've only downloaded the library so far ;p

That sound logical to any extent?

[Mattias Gustavsson]

In that case, I think monjardins advice is spot on:

monjardin said:

I would say keep writing everything in the base language until you get to a point where say to yourself, "I sure wish there was a more efficient way to adjust logic and add more content without rebuilding". If you don't know where you need scripting capability, then you would probable waste time unnecessarily at this point.

[Mephs]

Mattias Gustavsson said:

In that case, I think monjardins advice is spot on:

Makes sense. It seems like a really practical way to edit my sprite's list of animations instead of relying on a hard coded thing which I progressively have to update all the time every time the spriteset is changed. It also means I have to change parameters on 2 other classes to keep things in check.

With a Lua script it seems like I can just plug the frame coordinates into a series of arrays and everything works itself out in the animation code.