Hey guys, I''m thinking of writing a few articles about scripting languages. The idea of the articles is to start from stage one, design of the language, and work right up to building a virtual machine. The overall goal is that by the end of the articles we will have a fully working and usable scripting language - hopefully not a toy language. So I''d like to fire off a few questions: 1. What general concepts would you like to see in a game scripting language? Things like strict-typing, classes, exceptions, ability to call native C/C++ methods etc. 2. What kind of game would you like to see a scripting language incorporated into? RPG, RTS, TBS, FPS etc. 3. Would you like to have a virtual machine and therefore a compiler that would turn your code into byte-code or should the language by interpreted? 4. What variable types should the language support? Examples, integers, floats, strings etc. 5. Would you like to see native support for threads and synchronization? 6. What about incorporating the notion of "events" and "state", very much like UnrealScripts implementation? Let me know and I''ll see what is feasible. Best regards, Dire Wolf
www.digitalfiends.com

Everything said in this post is meant as constructive criticism.

If you attempt to create a system like this as a VM-Compiled Bytecode scripting language, you are going to end up with a LOT of opcodes. On the other hand, if you try to interpret a script written with all of these things, it will be sooooo slow. I would recommend toning it down, and simple going for a C-like implementation.

In my own scripting language(psudo ASM/compiled bytecode), variables are restricted to simple two letter combinations (easy, fast, variable indexing), and the language interfaces with the game/engine through function pointers (int opcode in script, passes the current stack to a function defined in code). And, I must say, I have yet to find a use for it.

I would say that, for a useful scripting language, the only really special things you should include would be basic arrays, and structures. Variables could be restricted to a DWORD, and possibly strings. I see NO reason to include threading, unless you are attempting to create a new programming language. States and events would be great to see though =).

Z.

Here''s what *I* think.

1. My only vote is ability to call native C/C++ functions

2. RPG

3. Interpreted

4. Integers & Strings

5. Not really

6. Not really

That''s what I think would be the best kind of language for a scripting artcile.

1. ability to call native C/C++ methods

2. RPG

3. VM + compiler

4. Integers, floats, bytes

5. Nope

6. Would be nice

First of all let me say thank you to those of you who responded.

Well I agree to some point with Oluseyi. Using an already developed and tested scripting language is a very viable and cost effective solution. Unfortunately that is not my goal.

I''ve talked to Tim Sweeny (Unreal/UnrealScript creator/head programmer) via email a few times regarding compilers and his implementation of UnrealScript. He actually wrote the parser/lexer by hand which surprised me. He found it very enjoyable to write and design UnrealScript. We''ve also spoken of programming languages in general and their shortcomings.

In my opinion it boils down to: most programmers really enjoy control. Being a professional programmer I''ve often looked at someone elses code and said, "Ew." Even though that code might be valid, I didn''t write it and it may not be as robust or usable as I might like. I''m sure many others have experienced this before when taking over a project.

The best way to learn a system is to tear it apart; get down to the nitty-gritty details. Learn the program piece by piece and understand the multitude of relationships between the classes. Don''t confuse this with black-box code reuse. I''m all for reusing code. If someone writes a memory manager that works and I inherit it, I''m not very likely going to rewrite. As long as it works then so be it. On the other hand, compiler and language design is a very personal and rewarding experience. Sure we could all go out and learn Python and add it to our "game" but where is the fun or satisfaction in that.

Therefore it is my goal to not only show others how to write a compiler/language processor but I also seek to make it fun and enjoyable. This undertaking will be to my benefit as well. I''m not a compiler writer or language designer by trade. I''ve studied and learned about compiler design for awhile now and have built a few toy compilers. Now I want to work on something more concrete. Something more complete. Reusing an existing language is not my goal. Sometimes reinventing something helps you to understand why it was invented in the first place.

So that is why I want to do this article. BTW It appears that another fellow here, RedLeaf wants to work together, which is fine by me.

Keep the "votes" coming.

Best regards,


Dire Wolf
www.digitalfiends.com

Since it is for "fun", go for the jugular, and throw it all in there. I would love to see an effective way of calling C/C++ functions (other then the one I am currently using). Also, add functionality so that native C/C++ functions can call script FUNCTIONS, and not just an entire script. Again, I stress the VM/bytecode approach, as it speeds up execution times... a LOT.

I much agree, that writing a scripting language is a very enjoyable experience. There is nothing like the feeling "I did that".

Z.

quote:Original post by Dire.Wolf
1. What general concepts would you like to see in a game scripting language? Things like strict-typing, classes, exceptions, ability to call native C/C++ methods etc.

Strict-typing is handy because it will probably make for faster code when working with ''primitive'' types. Classes would be good, particularly if the game was also written using classes. Native method calls are essential.

quote:
2. What kind of game would you like to see a scripting language incorporated into? RPG, RTS, TBS, FPS etc.

Er. All of the above?

quote:
3. Would you like to have a virtual machine and therefore a compiler that would turn your code into byte-code or should the language by interpreted?

Bytecode is easy to multi-thread in software. An interpreted language (operating upon, say, a decorated syntax tree) is more difficult to multi-thread, but may be slightly faster.

quote:
4. What variable types should the language support? Examples, integers, floats, strings etc.

ints, floats, strings. Perhaps chars, although char could just be a synonym for int. A fixed type may also be useful.

quote:
5. Would you like to see native support for threads and synchronization?

Threads, yes. Synchronizing, yes, but more difficult.

quote:
6. What about incorporating the notion of "events" and "state", very much like UnrealScripts implementation?

States are cool because they make things faster (you simply have a vtable for each state and switch vtables for your object when you change state). Events are cool, although UnrealScript doesn''t actually do ''events'', per-say - UnrealScript events are just methods that have been called events. You can see proper events in VisualBasic (and particularly version 4 and above, where any variable can receive event notifications from its value) and C# (and probably Delphi and other GUI-orientated languages, although I only know about VB and C#''s events).

All your bases belong to us