you compile you're scripts? for testing? [wow]
Are we talking run time compile or compile time compile?

Quote:Original post by Sneftel
...
Understand: a scripting language is for you, not for other people. ...

/me eye's slide to a stop.

I have to disagree. The major reason for a scripting language is for other people. People such as the level designers you mentioned, the moders and so on.

Why is Morrowind still going strong in the user community? Same with Neverwinter nights? .. because the mod community can do something with the programs.

About the only use for a script language for me for my game is ease of configuration file parsing. For my end user.. they can configure the game to their liking (though most such options should have a GUI front end, but I digress.) and extend the game (new models and such like).

As I see it 9 times out of 10 it is easier to do whatever you want to do directly in code, scripting is for the end user, or the level designers and other developer side content creation folks. To agree with thoughts above, when you want to separate game(content) from engine. A nice thing about working with scripts is the lack of dev side compilation. Fwiw, with the example rpg wizard above if you wanted to avoid scripting throw the code related to him in a DLL or the like perhaps..

As an aside I tend to think making a new script language just for your game might be overkill, consider Lua or the dozen other existing script languages perhaps?

Quote:Original post by Raduprv
Compile time compile, of course. I am not masochist enough to wait 1 minute each time I start my server.
Do you know a better way to load test my scripts without compiling? ^.^

Well, if compiling them really is taking that long i'd and you cant deal with waiting for them to compile on server startup I'd probably write a small tool to compile or not compile a script based on its changed date vs the changed date of its compiled version, however as to if thats possible would depend on what you are using for scripting, how you build the script files and other things, it would probably work well for say using Lua as a scripting system as all the compiled files are independant of each other anyways.

There's an alternative that has a lot of the advantages of scripting, but not as many disadvantages (and best of all, it takes virtually no time to implement). Basically, make your "scripts" functions in a DLL. Load them dynamically, and make a uniform interface you can use (a message system works well for this).

I'll be using this system for my engine. It's got a lot of things up on a scripting system, namely:
-You don't have to write a compiler or a VM (thank god)
-The scripts are 100% machine code, and can be optimised much better than any compiler you'd write or find open source chances are.
-You can code in C++ rather than another language (Personally, I prefer this. I don't see how having to learn/make another language helps me develop the game. Most of the dirty work will be taken care of by provided functions anyway.)

There are a few disadvantages, which are:
-Less secure. People can put in whatever code they choose. (I don't think this is a biggie. People download executables all the time. You expect that someone isn't going to put something malicious in something like this.)
-Harder to debug during development


And that's about it as far as I can see. Personally, I think the DLL solution would work better for most games than a full blown scripting system.

Quote:Original post by Nemesis2k2
...And that's about it as far as I can see. Personally, I think the DLL solution would work better for most games than a full blown scripting system.

Busy thread :)

A DLL based script system only works when you have code literate content creation folks. This I think is the largest problem with this strategy. Compile time could also be a factor for a large program, I’d think.

Still, it is nice to DL a nwn module and know it can't format my HD... I do doubt most users have a clue nor care about such things though as most modules and other such mods are often acquired from reputable DL sites...

Quote:Original post by Nemesis2k2
-You don't have to write a compiler or a VM (thank god)

Embed Lua. Job done.

Quote:
-The scripts are 100% machine code, and can be optimised much better than any compiler you'd write or find open source chances are.

Shouldnt be using scripting for time critical sections of games anyways so this isnt that important.

Quote:
-You can code in C++ rather than another language (Personally, I prefer this. I don't see how having to learn/make another language helps me develop the game. Most of the dirty work will be taken care of by provided functions anyway.)

Something like Lua can be learnt in an hour or so, its very light weight and frankly, if you've learnt C++ it would be a breeze to learn. You still access your provided functions, just via the script instead of hardcoding.

Quote:
-Harder to debug during development

This is potentialy a biggy.
You can also add
- Harder to make changes on the fly and keep them persistant (see my inbuilt script editor above)
- Harder for others to expand (not so important in a one man team i guess, but if you ever get a mapper who want to mix fucntionality X and Y in a game it will be much easier for him to work with something simple like Lua and cut and paste the code then for him to explain to you what the want and for you to go away and hardcode it and debug it)
- probably others but i'm getting too tired to think atm [wink]

Quote:
And that's about it as far as I can see. Personally, I think the DLL solution would work better for most games than a full blown scripting system.

It totaly depends on the scope of the game and if you plan on making it extenable in any way then scripting is a much better direction to head in than a hardcoded system.
For example, when making a HL mod there were times i wished things were scripted so that I could quickly make a change to some code and distrube the changes to the testers to get on with things while they were still about instead of having to load VC++, fiddle, compile, test locally, distrube, wait for ppl to download, upload changes, compile linux code, update server, restart server, [fix crashes in linux code for god knows what reason], get everyone back on, play test, repeat until everyone gets bored of waiting for updates and goes away.

End of the day, its upto you, I didnt see the value in scripts myself until I looked into them a bit more, saw how flexible they were and took a bit of time to learn to intergrate the use them.

My first test was a work project, scripting is used to dynamically allocate off objects in the main code based on a gameid and passed it in data needed to parse the data retrived from said server. Could have hardcoded it but the old system was like that and it was a pain to update and change and intergrate new games properly. Could have put everything in a data file but it wasnt as easy (i'd have to parse the data file, setup internal tables, setup function pointers, deal with all kinds of mappings), instead a script with a bunch of game id tokens and a function which is basical alot of 'if' statements and a fucntion call back to C++ and the job was done. Easy for me to maintain. Easy for others to maintain and pretty easy for another program to generate based on a database (which never happened, slight case of losing job).

Quote:Original post by Raduprv
I am using Small, not LUA. And all the scripts are compiled in one single file (I don't want to have different virtual machines for each script).

Hmm well that probably knocks my idea on the head then, and i dont know owt about Small to help further [smile], thought i would say it was more a of limit of the scripting system than scripting in general which are causing you the problems [wink]

btw, you dont need to have a virtual machine per script with Lua, just load the scripts into the same VM and its all done [smile]