[Gardon]

I've never used a scripting language before, or made my own. I just don't see the true purpose of these, and maybe someone could explain it to me.

Why can't you just call a function in your program? Or are scripts generally used for in game calls?

[Hajo]

Scripts are most useful if your games core is closed source and you want to allow other people to expand it with new functionality, or modify existing functionality.

In this case you put the parts to be open/modifieable into scripts.

The other thing is, that developing a script can be quicker than developing the games core. This much depends on the scripting language, the interfaces, and the games core itself.

Another thing, if you can dynamically reload scripts into a running game instance, you can bugfix on the fly and try the new script just in place. Again, this depends on the languages. Most Java IDEs can reload class files dynamically, giving you just that effect.

Scripts can be useful, but there are a whole lot of "it depends" there.

PS: My former RPG project used Lua as scripting language. I had scripting in place to allow other people to modify and expand the games core, even those who cannot compile C++ into a new executable. A text editor most people have.

[Verious]

I would not attempt to develop your own language for two reasons. First, players will need to learn a new proprietary language if they want to mod/extend your game, which will create a much smaller more fragmented community and second, it takes a lot of time and experience to build a functional and powerful scripting language. Instead of re-inventing the wheel consider embedding one of the following "scripting" languages (I am using the term "scripting" very loosely as several of these are full blow programming languages):

VBScript
JavaScript
VB.NET
C#
Java
Lua
Python

[Gardon]

Hey, thanks Verious for the reply.

Unfortunately I do NOT want players to edit my game. I wanted to use scripts to control the behavior of the game from the server. ie. new maps, items, character states, etc.

I'm looking into Lua wrapped around my base code in C++. I'm looking into RakNet for the networking side, and using DirectX for the graphics.

I'll let you know how that goes.

[Verious]

With any of the above scripting languages you could always encrypt the client-side scripts to prevent unwanted modification. Encrypted scripts provide rapid development while protecting your scripts from tampering. Scripts can be signed with a hash code to further ensure they have not been modified. It should also be noted that C# and VB.NET can be compiled (and obfuscated).

If the scripts run on the server, encryption and compilation are not necessary, because the scripts will not be transferred to the player's computer.

[Gardon]

What would be better for an MMORPG?

I'm aiming for 1000 on a server at a time. Should the scripts be run on the server or the client? Encryption for the client would make more sense to free up bandwidth/processing of the server, but then again I'd like to not trust the client.

I have another question. In regards to other players you can view, how do you update yourself with their information?

Example: I'm in player killing mode. I have to have information about those around (their position, their looks, their gamestate, etc.). Is it necessary to constantly update the server with simple things like their armor and item selected, or should I keep a copy on the client for them to view, and only update it once that player changes his outfit?

so if a player is weilding an iron sword, and I can see that sword, should the server keep telling me what that player is weilding, or should I just save it in memory until the server says he changed it?

[Hajo]

In case of Sonnheim I've chose this approach:

- Server has "master data" which is the reference for all.
- Clients have local copies of that (maybe not all of it).
- If a client wants something changed (e.g. player equips a new item), it sends a message to the server about the change to be performed.
- Server checks if the change is valid, and discards or performs it.
- Server sends update messages to all affected clients.

This does not answer where scripts should be executed, though. I can see use for scripts on both sides. The server side is what you can keep under control more easily, so sensible data should never be on client side.

[Verious]

Generally, in a client-server architecture, any script that can affect the outcome of the game should be executed server-side, or at the very least verified/validated server-side. This will prevent players from compromising the integrity of the system to cheat or cause grief for other players.

As far as updating information, it is best to cache "display" information client-side and only update the information when necessary. Many commercial games that allow character customization (such as "paper doll" systems) send a version (or hash) with each movement packet. The version or hash represents the current state of the player and can be easily compared with the local cache, which stores the version information each time it downloads customization data for a specific player/entity. If there is a discrepancy, the client can request the new information.

With a little bit more work, the server can store the last version number for each player/entity that was sent to a specific game client and automatically send the updated customization information if necessary. This reduces the packet size because the version information does not need to be communicated to the game client. This approach requires careful implementation because lost/dropped packets can result in visual desynchronization with the game state.

From a technical perspective, the transmission protocol choice is important, for example TCP/IP automatically handles packet state, as well as, resending and reordering, while faster protocols such as UDP do not; however, UDP incurs far less overhead.