View Single Post
Old 02-16-2012, 07:36 PM   #11
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: High volume scripting question

Hi again;

First, thanks for the pictures. I'm unfortunately visually impaired and will not be looking at them. In case you weren't aware, that is a good advertising avenue/playerbase source: making sure your game is blind-accessible. Not hard to do, I assure you, but this is taking the topic in another direction.

Recall I did say that I was only making suggestions based on somewhat shaky assumptions. This could be totally wrong; I don't have nearly enough experience to come close to calling myself an authority on this. Listen to dentin or KaVir over me, as I can personally vouch for them, or just about anyone else on here who's actually done this.

Anyhow, the idea with allowing scripts a certain time is this, and it may (probably?) isn't applicable in your case:

Using the numbers, both before and after as an illustration (this is good because it's going to run slower until those scripts run the first time).

You have scripts taking anywhere from 1 millisecond to .5 milliseconds and want to run 50 each game loop. Assume that you have some scripts queued, and that (due to players) you can't control which. They could take anywhere from .5 milliseconds all the way up to 1 millisecond each. So, you have as a worst-case scenario 50 milliseconds and a best-case scenario of half that: 25 milliseconds.

Here's the catch. You have to write your game logic to assume the worst-case scenario, if you want no lag whatsoever.

Let's assume that you account for the worst-case scenario above. You allot 50 scripts and assume at worst, 50 milliseconds.

Well, ok, good. So you get a bunch of scripts queued. But. It's one of the iterations after the mud's been up for a day, and each one's going to take only .5 seconds. So, you account for 50 milliseconds, but can't let the mud just barrel ahead because that's going to cause combat to speed up and slow down as well. So you have to add a delay in for the unused time: 25 milliseconds in which potentially another fifty scripts could get done without waiting for the next iteration.

As I said, lua coroutines would allow you to pause the scripts after a certain period of time; alolow .5 milliseconds for each script to run, or even .1 really, and pause until the next iteration, whereupon you unpause them. Now, you've got 100 running in parallel with no noticeable lag.

So, that said, that does introduce some potential bugs that I could forsee, depending on use-case. You'd probably have to add additional functionality to avoid them, but if you really want to run thousands of scripts at the same time, you're looking at something like this or even more complex (threads and a multi-core system would work wonders, but as dentin said is beyond difficult to get right).

One final note. If you're not providing the computer and are working off your home pc, you need to consider that a server is generally sharing processing power with other stuff. The nice not-laggy codebase that's the only piece of software running in an environment with all sorts of priveleges and no virtualization...that's going to come crashing down when you put it on someone else's machine. At least, if you're not prepared. If you want to run thousands of scripts (a goal I kinda agree with), you're either going to have to provide the computer or do a ton of optimization.

Also, something that you could check. Try compiling without debugging if you aren't already. I didn't know till earlier this week that f5 in visual studio for instance slows down the application by 5 times. This one's direct from my c++ professor who's been teaching for 16 years; he made a point of telling us. Just something to check.

When are you going to open? I'd be interested to see a new type of mud, that is, one done from scratch. So many are circle/diku/<derivitive used by everyone else goes here>.
camlorn is offline   Reply With Quote