I have a doubt about using scripting languages like Lua to implement some stuff in a server, specifically player skills/spells. Is it wise to script such things or should I avoid scripts at all in the server design? What can be scripted and what should definitely not be scripted?

That depends entirely on your specific needs.

If you're trying to get thousands of players interacting on a single piece of server hardware with advanced physical interaction, being able to optimize using a profiler and staying away from GC pauses will be important.

If you're putting less than a hundred players on a single server and the main things the server does are enforcing rules on a per-skill basis and verifying/storing data, you could write the entire thing in Lua and it would run fine.

Separately, trying to debug a system that runs partially in a scripting language and partially in a native language can be challenging, because there are very few debugging systems that can "step into" across the language boundary.

What I always say is, if you are going to learn, then learn the best method. So, I would say that my situation fits in the first case. That means that I should avoid scripts.

Ask yourself what flexibility you get from keeping that logic as scripts, and if you actually need that. You could just as well keep the same logic as plugins, swapping out dll's instead of text files.

There really isn't a magic rule to this. Knowing more about the game you want to make will make it possible to make some suggestions, but even then, you can get away with a lot if you have beefy hardware (expensive). At the same time, contradictory though it may sound, you need to be as lean as possible if you want tons of players (also expensive but in a different way).

A decent heuristic is how often will this code run? If you're talking about stuff that will run for thousands of players every frame, you want speed wherever you can scrape it up. If it's every thirty seconds or so and maybe a dozen players will do it "at once", script away.


Again, it would help a lot to know more about the actual game.

Sorry, I should have spcified that the game style is RPG, with PvE and PvP, with large scale battles if possible. So, at some point, the server will be managing two dozens of players casting skills on each other plus summoned NPCs.

For "dozens" of players, I would mostly worry about whether it would be easier or harder to debug the system with the scripting or without the scripting.

I have a doubt about using programming languages like Lua to implement some stuff in a server, specifically player skills/spells. Is it wise to program such things or should I avoid programming at all in the server design? What can be programmed and what should definitely not be programmed?

^I replaced scripting with programming

"Scripting languages" are still just programming languages. There's no real difference between using Lua and using any other programming language.

e.g. Most of the console games that I've worked on have almost entirely been written in Lua. LuaJIT is very fast

Use whatever language you're most comfortable with.

There's no real difference between using Lua and using any other programming language.

I look forward to your next project developed in equal parts FORTRAN and Prolog.

I would say something like : Depends how complex the application of the scripting (how much logic does it add upto) and how often it has to run (some AI does alot of constant reevaluation of a situation just to select one action).

Also what 'script' features are needed that a native language doesnt do for you (ie garbage collection or soft typing, etc)

Script If there are Huge amounts of logic using scripting to make that logic 'nicer' for semi-programmers (and isnt run excessively to significantly lose performance) Thats if the actual server load is of any significance where that performance drop is important.

My usual solution is a normal native language with macros to do alot of grunt work (and alot of manual restrictions given to the scripters - coding forms and standards) but then I thought ....

IDEA :

A preprocessor to 'scriptify' a native language to 'dumb down' what you can do with it, to cut out alot of the 'gotchas', to sandbox it in various ways to allow use of the language in a simpler script pseudo code-like way and gain direct use of the good compilation (execution speed/codesize/lack of the 2 tier data translations) and direct debugger usage against the preprocessor-passed code.

The preprocessor would enforce the simplification of the language (search for verboten statement types, program constructs, etc.. Simple example is barf if it sees a reviled 'GOTO') but would still spit out ordinary native langauge to feed further down the build chain (and barf immediately in a readable way at a user who tried to use language features not allowed them).

Libraries could be controlled further (like not allowing use of ones not part of the allowed 'script language' specifications)

I suppose there have been more than a few script languages that translate to native code for compilation, but then you lose the advantages of a direct debug ability.

The problem -- since thereare all kinds of 'script' language features that make them used in the first place - can you replicate the ones required ?? Do many of them really never get used or wind up being source of programming problems so that its better off to eliminate them (selectively restrict them in the generalized precompiler)...

.