Game Scripting

That's not a bad thing though, you probably want to limit the interface that your scripting language has with your codebase, rather than just allowing it to call anything. There's not much to be gained from the latter.

Don't feel that you have to go for a scripting language just because it's a popular thing to do though. It's probably quite unlikely as a hobbyist, that you'll make something complex enough to really benefit from a scripting system.

Personally, if I had to use a scripting language in my C++ game, I'd probably go for C#, provided it met the project requirements.

For a small single-person project you are correct that it doesn't make much sense. You can have your code data driven, but it doesn't need full access to the underlying source.

When you have a medium program with a 15+ programmers, 5+ level designers, 2+ game designers, 10+ animators, and so on, you want to allow all those other people to write data scripts that interact with the source without actually touching the game's source code.

When you have a large program with a hundred or more people working on it, you want scripting languages with their own compiling and debugging (which Lua offers) to help reduce the risk of non-programmers breaking things with their scripts. Lua's ability to operate as a stand alone system is great in allowing build scripts and test scripts to validate the data.

I'd say there's an argument for not having non-programmers programming at all, even in a scripting language. In my experience, designers are designers, they want to be designers, they don't want to be programmers. This is especially true if you're using Lua in an object-oriented manner, something which a lot of people just don't get at all. To be honest, using Lua as an object oriented language is hard enough as a programmer, never mind as a designer, as it's a bit of a kludge in my opinion.

There are ways to allow them to express themselves in a data driven manner, without them having to use a scripting language.

In my experience, designers working in a scripting language never use the full flexibility of the scripting language, and just piece together the pieces the programmers give them anyway, something that doesn't really require a scripting language.

"just piece together the pieces the programmers give them anyway, something that doesn't really require a scripting language."

...but do you, the C++ programmer, want to be the one who will do that? Isn't one of the big points about scripting to let someone who doesn't know C++ to also participate in developing the game? You are not going to write mission logic, et cetera, in C++ or are you? I think that would be horrible.

As I say, you don't necessarily need to give the designers access to a script language in order to allow them to create content. In my experience, the power provided by a language like Lua is wasted on (and not wanted by) designers. Coding and debugging generally isn't what designers are good at, and they shouldn't really have to be.

I'm not suggesting that missions should be created in code, just that designers can be provided with tools for content creation, that don't necessarily involve writing code in a scripting language.

Something like Unreal's Kismet is an example of what you can do without requiring the designers to program.

In my experience, having designers using more powerful scripting languages like Lua just results in lots of programmer time being spent helping them debug the scripts, or writing more complex scripts for them.

I don't claim to be right or wrong on this, it's just my personal experience. Obviously the right decision will depend on the project, the team, etc.

It depends upon the game. Simple tools for simple games. If your game is just a run and gun FPS with a few trigger spots to explosions and enemy spawn, then yes a graphical tool with simple pre-scripted object library will suffice.

If your game is an open world roam anywhere dynamic quest type game, making a pre-canned object library and toolkit for such a dynamic game would be more trouble than it's worth. In that case you're better off just giving the designers the scripting tools and help them debug and organize it best you can.

Designers who do learn to script and script well are far more valuable in the long run than those who are limited to just placing canned objects and tweaking the limited variables exposed by the programmer, imo. I've had the privilege of working with extremely competent designers/scripters who translate their ideas into working code far more efficiently and creatively than most programmers.

This doesn't mean you can shirk your responsibility as the programmer. You'll still have to provide them with the tools, intelligently designed framework, high quality API which is as error proof and stable as you can make it (nothing worse than spending hours debugging a script to find it was in ur C++ code), and don't forget performance (scripts are notoriously slow).

Good Luck!

-ddn

i dont like scripting languages.

i prefer to expose "blocks" of functionality for designers to play with, like lego blocks.

but, beside the point, if its just you working on a game, and your a programmer, why introduce more complexity, more bugs, for no real benefit, if your a programmer, just code the damn thing. at least youll get proper debugging for free.

seriously, the "but i might want to change it" answer doesnt fly, your code base wont be big enough to cause 45 minute recompiles.

I have written an engine, and plan on doing ALL game logic in lua.

My interface to my C++ code is very minimal, and I provide a finite number of functions as my Engine's Lua API. I use this as the middle man between my editor and my engine.

This allows me to not only develop a COMPLETELY different game in the scripting, but it also allows me, in the editor, to not only define data for objects in a simple manner (drag and drop of files and storing the path in a lua table), but also allows me to create behaviors on the fly, in a manner that is easier than C++ (for me).

Messy? It's as messy as you make it. Lua gives you a ball of clay, and you can mold it to do OOP or just about anything you like, if you make it messy, so be it.

For me, this architecture works. But lua is SO flexible that you can use it as much or as little as you like... not using it at all though? thats no fun =)!

Are there really game designers that have no idea how to code? =O

Quote:

Original post by AverageJoeSSU Are there really game designers that have no idea how to code? =O

Coding/scripting is not necessarily part of a game designers job. Generally though, in my experience, it's not so much that there are designers that can't code at all, more that they're not particularly suited to coding, and coding gets in the way of them doing their job and expressing themselves fully.

This is especially the case with languages like Lua, when you're attempting to use it as an object-oriented interface to C++. Something which can be painful enough for programmers, never mind designers. That and object-oriented programming is one of those things that a lot of non-programmers find difficult to understand.

It's fun to read the responses, because it tells a lot about each of your backgrounds. ;-)


@ Stab-o-tron, others

Having worked on large teams, it is extremely important that you have a compilable scripting language that designers can use well, even if most of them are not programmers.

You are right that there will be programmer time spent with those designers. Fortunately a large team can spare a developer (or two or three or more) for them. Only a subset of the designers will use the scripting tools regularly, and only a subset of those are actually good at it. Some of them will have prior experience with Lua and similar tools, others will struggle with basic programming concepts. The programmer assigned to them can help when necessary.

The less-skilled and unskilled designers can copy/paste and otherwise figure it out by following simple steps. They can make changes to the existing scripts without much difficulty. While it sometimes will slow that person down a little bit, it prevents them from slowing down a lot of people. Their work will be harder, but the total game will have more development time.

Designers aren't the only ones to use it: Artists will use the tools to adjust positions aesthetically. Animators can take advantage of scripted data if you let them. Audio guys can more easily synchronize their sounds to data. Producers will use the tools for tuning the game. Internal testers can find and fix data errors.

There is a cost to putting it in, but the benefit far outweighs it.

For a large team, Lua and similar languages are an absolute necessity.



@ Matt_D, ddn3, etc.

Having worked on small and medium size teams, it is nice to have scripting languages that work as building blocks as you described. We use a few simple GUI tools to work out layout, positioning info, and similar designer stuff. We have simple text files for constants that designers can adjust for tuning.

For a small team this situation is risky either way. You can choose how much time and effort to put into the tools and scripting. You can take advantage of ready-built editors and tools for Lua, or you can roll your own. Since balancing your financial budgets and time budgets are both critical, you need to understand the benefits and drawbacks of both approaches.

For a medium team having some sort of scripting tool is very important. It can be simple (the building blocks) or complex (full Lua support) but they will need something or it will break the backs of the programmers.




For a homebrew or one-man-shop? It really doesn't matter what you do, as long as you actually do it.

Most designers have some level of understanding of scripting and exposure to writing code these days. Alot of them work with tools which keep them insulated from the coding part directly, but behind the scenes it is usually a scripting engine driving it all. I don't think anyone writes their back end logic in hard coded C++ anymore, it's all very data driven now (be it with scripts or some meta-language which they made in house).

Designers are for the most part technically inclined and have no problem picking up concepts of OOP from my experience. Writing small code (like a script for opening a door when a barrel falls off of the roof and spawning a 1000 clowns etc..) doesn't require mastery of OOP or large scale software engineering techniques. It just requires basic understanding of the given API and following the coding guidelines.

It's the large scale scripting which you want to limit to only the most experience scripter/programmer, but there are designers which can do that and they are the most in demand.

It's very much so defined by the tools you give them, the framework you build and the API. If you give them poor tools and API you can't expect great results.

Good Luck!

-ddn

Quote:

Original post by frob It's fun to read the responses, because it tells a lot about each of your backgrounds. ;-)

oh really? and that would be? ;)

in all the games ive worked on, and in the business world too, scripting language use trends towards infinite complexity. Ive seen games where the entire networking layer was written in script.

this is one reason i like the building block approach. it stops people who arent programmers writing code ( im not a modler, or an artist, and I would never be expected to do one's job. so why expect people who arent trained as programmers to code? ). it also gives you the ability to re-factor the "blocks". if patterns are being re-used over and over. coalesce them into a single object. (eg: if/else blocks for switches). Having non-programmers cutting and pasting code all over the place doesnt lead to good, or debuggable code.

which is my next gripe with scripting languages. most of the time debugging support is woeful (printf's are not debugging). if i had written it in code, i could easily debug it. the network layer in script is a prime example of total craziness, and debugger hell.

you only really need scripting languages if your game has seriously complex interactions (eg an RPG). for a racing game, or a FPS, a scripting language is a bit of a waste of time.


[quote
For a homebrew or one-man-shop? It really doesn't matter what you do, as long as you actually do it.[/quote]

its like multithreading, people adding complexity (and all its associated bugs, frustrations, race conditions, extra work etc) for no real reason other than everyone else does it isnt going to make things easier, or better. unless you really want to learn how to integrate scripting languages.

unless you really need it, its easier to just avoid it until you have a need for it :)

Do you have actual designers to work with? If so, have you tried asking them what they want?

For what it's worth, my own projects are done entirely in script (in Python, as it happens), and when I need more performance, I can take the inner loops and convert them into C modules (or just use Cython). This seems to me to provide the benefits of scripting -- malleability and rapid prototyping -- with the performance benefits of compiled code. Obviously it's not a perfect compromise (it's harder, for example, to enforce limits on what scripts can do), but I like it for the hobbyist projects I work on.

You can also make your own bytecode interpreter specialized for your game. I think there is a tutorial that explains how to do that. It looks hard, but it is simple, really. Adding a new instruction is as easy as adding a case in a giant switch structure, and link to your functions. (Or even add the code in the switch/case.)

For your designers, instead of letting them mess with a script editor, you can also make a very nice editor with dialog boxes like the Starcraft map editor, since bytecode is really easy to read and to write.

If you really want flexibility, you can also make your virtual machine a stack machine, so you can put variables, functions, or litteral values as arguments. However, for having done that, I can say that it is not really required in most ways, and you can always add an instruction that does the same thing as another but takes variables as argument instead of litterals. Or you might just use LUA at that point.

For what it's worth, my own projects are done entirely in script (in Python, as it happens), and when I need more performance, I can take the inner loops and convert them into C modules (or just use Cython). This seems to me to provide the benefits of scripting -- malleability and rapid prototyping -- with the performance benefits of compiled code. Obviously it's not a perfect compromise (it's harder, for example, to enforce limits on what scripts can do), but I like it for the hobbyist projects I work on.

Quote:

Original post by Bearhugger You can also make your own bytecode interpreter specialized for your game. I think there is a tutorial that explains how to do that. It looks hard, but it is simple, really. Adding a new instruction is as easy as adding a case in a giant switch structure, and link to your functions. (Or even add the code in the switch/case.) .

while nifty, i cant really recommend this approach, as debugging two layers at once (ie your VM, and your script code) can be a royal PITA. and using a large switch statement will more than likely introduce a cache miss..woo..

it is a common way to implement a in-game console though. which can be handy.

Quote:

Original post by Matt_D while nifty, i cant really recommend this approach, as debugging two layers at once (ie your VM, and your script code) can be a royal PITA. and using a large switch statement will more than likely introduce a cache miss..woo.. it is a common way to implement a in-game console though. which can be handy.

Agreed. I've used two engines where the programmers thought they would be clever and would implement their own VM and scripting language. It was a nightmare to develop for. You had either a half-broken, brain-dead compiler or a leaky, buggy VM.

I'm not saying the OP isn't smart and skilled enough to pull off a VM and language from scratch successfully, but Matt has a point -- You're just adding another area that you'll have to actively develop. It's just easier and saner to use a pre-existing, proven technology.

These days, for my hobby games, I am using a Python based engine with C++ backend. (Panda3d) It's been a blessing with writing Python code all the way through for almost %99 of my project.