Raduprv,

Keeping in mind I’ve not used Small and only glanced at the website really so I may be (and probably am [grin]) talking out my arse!

Still the idea:
Can’t you basically just VM += new_scriptfile ? Which is to say load a new script into an existing virtual machine while preserving the existing VM’s environment?

For what little it is worth, this can be done with Lua and I believe Python as well.

Perhaps a ‘custom’ aux_LoadProgram().. not sure I understand exactly how Small works but I’ve little love for the PDF viewer so I’m not keen to learn more ;)

Quote:Original post by FeralOfEclecticWizard
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.

Well, yeah. I was speaking in terms of lone-wolf development. what I meant is, it's in-house.

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

And yet the mod community for Halflife is just as strong, despite the lack of good scripting support. It's C++ all the way.

Besides, NWN is something of an aberration, since it was specifically released _to_be_modded_. While modding helps sales of any game, it's usually not a major part of the bottom line.

Quote:Embed Lua. Job done.

True enough.

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

Again, true. If you were implementing some hefty AI though, the performance could start to be an issue.

Quote: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.

I know Lua already, and while I agree its simple enough to learn, I don't see the point of using it. I think you'll find that right now, more people know the C syntax than know the Lua syntax, with all the languages based off it that are around nowadays.

Quote:- Harder to make changes on the fly and keep them persistant (see my inbuilt script editor above)

Not sure what you mean by "persistant".

Quote:- 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)

I disagree. Programming is programming. If you understand the syntax, the same issues exist between pretty much all languages. He could just as easily cut and paste some C code as Lua.

Quote: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.

The way I'm using them, you give the filename and function name of the script for each object that calls one, so you can easily make a new DLL with one or two scripts for your one or two new enemies, and have the engine load and use those scripts without recompiling anything else, or even havint the source for anything else. With that system, I think it's just as extendable as scripts.

Quote: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.

I spent the last month looking into and thinking about scripting. I bought Game Scripting Mastery and read it cover to cover, and I thought long and hard about what I wanted my scripting system to accompilsh, how it would integrate with my engine, and what the tradeoffs would be between other things that I could do. In the end, I decided this DLL system was more appropriate for my engine.

Quote:Original post by Nemesis2k2
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).
...
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

I assume you mean in the host language, such as C/C++. You forgot the biggie: it's the wrong language. C/C++ is for programs, not for levels. And when I'm making the orc bust down the door just as the player swings his head around, I really really really do not want to care about thread safety, type rules, exception safety, inclusion guards, or memory leaks. For that matter, I don't want to care about for-loops or return types. I want to speak in the lingua franca of the game, using a programming language whose syntax is custom or customizable enough to help rather than hinder me. If that means compiling LISP code into a DLL, that's fine; I never found the whole dynamic recompilation thing to be especially compelling anyway. But C/C++ is the wrong approach for game code.

When building a completely interactive world which has millions of object types, you NEED a scripting engine. It has nothing to do with how many people are going to work on the project (although I'm sure it would be useful for them).

Imagine a world where you can turn on a TV, a radio, a ceiling fan with a wall switch, open a door with a card key where the slot in planted into a safe contained under a painting (where the painting must be "opened"). A car that can be started with a particular key, which has a lever to turn on the wipers. An oven which can be used to heat up some water to poor onto some paint which reveals a hidden opening in the wall.

Who in their right mind would code a game to have all of these objects? With a scripting language, you can sum it ALL up with one simple data type. ie: Object. The object has empty data variables which can be given names and manipulated via the script. Other objects send messages back and forth to each other. A specific door checks events from only a single key ID. The wipers in that car only wait for one single message to be sent from that lever, which itself waits for a "pull" command from the character.

I've been there. Scripting was a MUST.

Quote:I assume you mean in the host language, such as C/C++. You forgot the biggie: it's the wrong language. C/C++ is for programs, not for levels. And when I'm making the orc bust down the door just as the player swings his head around, I really really really do not want to care about thread safety, type rules, exception safety, inclusion guards, or memory leaks. For that matter, I don't want to care about for-loops or return types. I want to speak in the lingua franca of the game, using a programming language whose syntax is custom or customizable enough to help rather than hinder me. If that means compiling LISP code into a DLL, that's fine; I never found the whole dynamic recompilation thing to be especially compelling anyway. But C/C++ is the wrong approach for game code.

You've gone a bit overboard with examples there, but I thought the same thing at first. I dismissed the idea, but the more and more I thougth about it, the more I came back to it.

Look at it this way, how much of that "lingua franca" is handled by functions? How many of those game specific operations are going to be achieved by calling a function which does most of the work for you? When I worked through everything my scripting system had to interface with, from habdling entity AI, to collision between other objects, to special triggers and the like, I found that all that functionality was going to be achieved through functions anyway. The only difference was the syntax; the logic I used to control the calling and responce to those functions. I felt that C was sufficient for handling that.

As for the syntax itself, most of the stuff you mentioned doesn't apply in this case IMO, but I can see how you might find the syntax cumbersome in some places. I don't want my function definitions in these DLL's to be massively long for example, and include stuff like "extern". The person writing the script shouldn't have to worry about that stuff. That's where you use macros.

Quote:using a programming language whose syntax is custom or customizable enough to help rather than hinder me

I don't want to make an alternative to the english language just so I can better communicate with my team in the context of my game. English does the job, and we actually know english. Same goes for C.

Quote:Most of the players don't want to worry about pointers and such.

Then they don't have to use them, but if they know how to, they are available.

Quote:Besides, DLLs are not exactly portable (for non Intel platforms).

They're about as portable as the game itself. In fact, much more so. Besides, do you really need them to be? I can't exactly try out the latest Quake III mod on my DC very easily anyway, and how many games are released for linux or the Mac? If they are, how hard is it to recompile?