quote: Original post by frostburn
Malware: Won''t you have that problem with other solutions as well?

The scripting languages usually come with a virtual machine, which sandboxes the code, so it can''t do bad stuff. A DLL contains native CPU code, so it is possible to do bad stuff.

quote:
Yuck factor: My point exactly.. keeping the libraries statically linked removes clutter (but it might cause other problems?). Script source could be available to modders (on cd or something).

You don''t want to give your users the access to the ORIGINAL game script, because it''s totally unfun if they can see the entire game logic. Instead, you just provide the moding community with a SDK and examples on how to make mods, while keeping your game scripting code secret (offerign only the compield script version).

quote: Original post by Raduprv

quote: Original post by frostburn
Malware: Won''t you have that problem with other solutions as well?

The scripting languages usually come with a virtual machine, which sandboxes the code, so it can''t do bad stuff. A DLL contains native CPU code, so it is possible to do bad stuff.

Yeah.. I thought as much ("Of course if the entire mod is just a new script then it''d be hard to cause destructive behaviour (I assume that any disk access etc. must be handled by the engine)" ). My point is that if malicious users can create patch or a "install" program that can do as much or possibly more damage than by changing the DLL. I''m not advocating DLLs or anything here, just pointing out that it''s hard or impossible to stop someone hurting someone who doesn''t know it''s dangerous to use unofficial software..

quote:

quote:
Yuck factor: My point exactly.. keeping the libraries statically linked removes clutter (but it might cause other problems?). Script source could be available to modders (on cd or something).

You don''t want to give your users the access to the ORIGINAL game script, because it''s totally unfun if they can see the entire game logic. Instead, you just provide the moding community with a SDK and examples on how to make mods, while keeping your game scripting code secret (offerign only the compield script version).

That''s one way to do it. I guess you''re then using two script files - one overriding the other.. I''m not sure what is normally provided in the SDKs.
I think Morrowind provided the entire script source, but not everything was scriptable. I''m guessing that it was hardcoded (it might be compiled script, but I don''t think so). As I said, I''m don''t know too much about modding.. The only time I''ve tried was to improve the levelling system in Morrowind, but it was impossible.

I think wether or not it''s good to release the original game script depends on what type of game it is, and how they can get it (internet). If they want to do it to cheat then it''s unfun, but if they want to mod the game, it''d be better if they saw the entire game logic (the scripted part that is). That way they could make a better mod without being restricted by what the designer intended. If it''s a commercial game it''s not like you could loose money by allowing someone to make a TC of the game (except maybe with the sequel or add-in packs). History has shown that companies (*cough*Valve*cough*) has made a lot of money off the modding work of others (*cough*CounterStrike*cough*). Granted I don''t know how much of the original script they did or did not release...

quote: Original post by frostburn
Yeah.. I thought as much ("Of course if the entire mod is just a new script then it''d be hard to cause destructive behaviour (I assume that any disk access etc. must be handled by the engine)" ). My point is that if malicious users can create patch or a "install" program that can do as much or possibly more damage than by changing the DLL. I''m not advocating DLLs or anything here, just pointing out that it''s hard or impossible to stop someone hurting someone who doesn''t know it''s dangerous to use unofficial software..

Of course, if the mod comes with an install program then many bad things can be done. However, if the mod comes as a zip that contains a single file (like, say, a pack file that includes new levels, art, the overriding script, etc.) then not much can be done. besides, it is easier to detect if a script hs replaced the exe file than some hostile, hidden code in a DLL.

As for distributing the code source of the script to the game, it depends. I wouldn''t do that because there is no benefit in it. Instead, just provide a SDK with examples, so people will be able to make their mods by reading the SDK, and compiling the small examples. It''s usually bad to mess with the original script, because of you distribute a modification of the original plot, then other players might have troubles (not expecting your modifications), which translates in tech support calls, etc.

Just some random comments....

For what it''s worth, if you use something that''s LGPL you have to dynamically link it to a closed source program (DLL). Using the GPL for a library is so shortsighted that it''s insane.

Lua is nice but I haven''t gotten the "cure for cancer" vibe from it. I *have* gotten that vibe from Python (even in this thread, *gasp*) and I hate it. If there''s one thing that will keep me from using Python for as long as possible, it''s overzealous fans who think it''s their job to pimp Python on every message board in existence. Just a rant, sorry.

Python is a little slow but I think it''s faster than you give it credit for. It''s generally not lightweight though, compared to Lua or the language you found. And the syntax is annoying.

Did Max Payne 1 really use Python? Maybe that''s why it performed poorly on the PS2. I actually wouldn''t be surprised if they ripped out the Python for the PS2 version... only a couple of PS2 games have used it and most studios have determined that Python is a little big for the PS2 (but not the XBox or GC).

I hope you get along well with SMALL, but there''s no single scripting language for all tasks. Even if it works well for you in your current project, there might be a better choice for your next project.

This looks very good. Can you do any type of OOP with it?

quote:
And for two, its a beautiful language. Clean syntax, somewhat standardized formatting.
I cringe to hear it called slow (What would that make java then? ... Frozen molasses?)

Python **is** slow, you should try and benchmark it sometime. It includes timers in a module, you can get a basic idea of how to profile things with them.

Perl is waaaay FASTAR than python at everything but objects, but integration with C sucks and the language is quite hard to master. It would also probably be a nightmare to use Perl in your game as it is the most hackable language the world has ever known.

Script languages for games are exceedingly simple, I do not see the problem of rolling your own. For a simple language with functions and basic data types you could roll your own in a day and not have to fear a zillion security problems.

Gad, I am thinking of making a tutorial for Gamedev to show people that making a basic script language is a 1-2 day task.
It is really very simple. The hard part is figuring out what is the best way to *design* it, which is relatively fast, but which will allow a JIT to be built under it.

quote:
This looks very good. Can you do any type of OOP with it?

No, it''s a procedural language. If you want OOP, then use LUA. But I don''t think it''s a good idea to have an OOP scripting language for a game, because OOP is harder to learn than procedural programming, so you''ll have less users to make mods for you.

quote:
I hope you get along well with SMALL, but there''s no single scripting language for all tasks. Even if it works well for you in your current project, there might be a better choice for your next project.

I know that. But for what I need, Small is the perfect language. I think I will use it for my future projects as well, since it doesn''t lack anything I need

quote: Original post by Raduprv
Well, the problem is, a lot of people, including me, don''t like the fact that you have to obey some strict allignment rules, or else your code gets messed up in various unfunny ways.

That was my initial reaction as well, but once I actually started using it I found it to be very intuitive, and my code stayed readable. I now prefer the standardization of significant whitespace over the arbitrary flow of block-delimited languages like C (and braces are ugly).

quote: Second, it is slow, I seen a Phyton script exporting an MD2 out of Blender, and it took like 6 seconds to do that, on a XP 1.7 GHZ

The Blender script could have been extremely inefficient. Many Blender users aren''t exactly expert programmers...

That said, Python has a larger overhead than more compact offerings. That overhead becomes increasingly negligible with higher workload, until the break-even point. Comparing Python head to head with, say, Lua, the break-even point for Lua is lower, but the utility cap for Python is far, far higher. Python is not appropriate as an extension language (scripts called from main program), but it is an excellent choice as an aggregation language (main program calling libraries), a point which you made in closing.

quote: Original post by Raduprv
Well, the problem is, a lot of people, including me, don't like the fact that you have to obey some strict allignment rules, or else your code gets messed up in various unfunny ways.

As for the obeying alignment rules - thats simply preference, and if you were to apply a logical mind to it you can see quite a few benefits exist too this constraint. (But I understand how this still might not be 'your thing')

And in any case, not obeying the rules results in errors: the _exact_ same sort of errors as omitting { and } on an if statement in C++. Nothing magical here.

quote:
Second, it is slow, I seen a Phyton script exporting an MD2 out of Blender, and it took like 6 seconds to do that, on a XP 1.7 GHZ...

Python is a scripting language, so by definition is SHOULD be slower then an optimized, compiled language such as C++.
So, that aside - its up to the user to:
I) Decide where the language should be applied. (Obviously not performance critical application bits.)
II) Implement the code in an effecient manner. (As mentioned above, you can write slow exporting code in any language.)
III) To profile their code, and optimize as necisary.

Using a scripting language (or any high level language in fact) is a trade off. You save programming time, in exchange for adding a bit of run time to the application.

quote:
I need all the speed I can get,...

Then a scripting language is the incorrect choice.
You should re-asses your requirements (to see how much speed is really required) or look elsewhere then scripting languages.

quote:
I also heard that it's kind of complicated to embed it in your host, and that phyton is meant more as a programming language which you expand with external modules than as a glue language (which is what most of the games need)

Finally here you are hitting upon some truth! (Other then misusing the term 'glue language')

Python is _not_ an ideal language for embedding into a game.

The only reason it came up is that the original message did not specify that it was crucial the language be easily embeddable into a game.

So all that said, you seem misinformed, mistaken - but your conclusion may very well be correct- embedding python in your MMRPG might not be the right choice. BUT it is quite possible to use, and not unheard of:
The article 'Python for Massively Multiplayer Virtual Worlds' is an article covering exactly this, in detail.

http://www.asbahr.com/paper2.pdf
It would be definately worth reading.

Anyway, It was not my intention to flame,
just trying to get rid of some misconceptions.

[EDIT]
I forgot to copy and paste in a quote from another MMOG:

"Python enabled us to create EVE Online, a massive multiplayer game with a scale never before seen in the industry, in record time. EVE Online server cluster, servers close to 10.000 simultaneous players in a shared space simulation, most of which is created in Python. The flexibilities of Python have enabled us to quickly improve the game experience based on player feedback," said Hilmar Veigar Petursson, chief technology officer of CCP, the developers of EVE Online.

Anyway, there is some merit in researching a language a little bit via there website before disregarding it completely
[/EDIT]
Cheers,
- Jacob

[edited by - Kevlar-X on May 13, 2004 4:11:02 PM]

Actually, scripting languages can be fast. Small even has a VM written in ASM, which is, according to the author, 5-10 times faster than the ANSI C version. Furthermore, it even has a JIT p-code->machine code compiler, which makes things even faster. Unfortunately, the JIT thing appears to work only for Windows machines, and my server is hosted on FreeBSD.

And yes, you are right, I should have specified that Phyton was not the right language for my SPECIFIC problem. Since it''s used in so many places, I''m sure it is a good language, it''s just that I don''t like it (a personal preference).