Top Mud Sites Forum - View Single Post - Event-based with threads instead of game loop

koteko · 11-16-2012, 06:49 PM

Thank you very much for the thorough message. This actor system seems worth to be checked out, I'll look into it. It seems like a framework that do, under the hood, something similar to what I do now, but surely in a cleaner and more efficient way. I'd also like to learn Scala (on coursera there was a free course from the creator of Scala, I missed it sadly). Let's see. I'd especially love to make the server a distribute system as you suggest..even though I fear that's too much for my current knowledge, yet I do love learning new things. I still don't understand whether akka is totally asynchronous or it can be made synchronous, but I think that's just my very poor understanding of it.

I should have clarified however that I'm not going to release the source code, so the important things are that: it is enough performant to not have lags, I feel comfortable with it (and I love it, I must say, I find it the cleaner piece of code I've ever written) and it scales well with added complexity, ie the combat system, delayed commands, the magic system (the MUD is actually totally focused on the magic system, maybe I'll talk about it in the near future). Of course, in addition, building should end up being as straightforward as possible (but not simpler than that

but I think my system doesn't make it more complicated in any way.

The fact that other people have tried the multithreaded approach is both good and bad. Good because if there are codebases it's doable, bad because if there aren't actually running MUDs it might mean it does not scale well. I guess, unless the akka system conquer my heart while studying it, that I'll let you know how it goes. I'll also look forward Iberia MUD which is even more extreme.

I did, and actually now I'm really curious to know how Viriato solved it in his IberiaMUD. As said however that's not really a problem with my own system: the command Move of the dragon (which contains the check on whether the door is open or not) and the command Close of the player would be executed sequentially according to which one arrives first to the pendingCommand queue, so it's easy here. With a game loop too.

For a fully asynchronous system, a lock on the door object would solve the problem in that particular case, with really little effort and overhead. A remark I've found on the internet is about what happens with crowded rooms, or with fights. You need to put locks pretty much everywhere to avoid race conditions, and this might end up being slower than a game loop.

11-16-2012, 06:49 PM	#9
koteko New Member Join Date: Mar 2012 Posts: 20	Re: Event-based with threads instead of game loop Thank you very much for the thorough message. This actor system seems worth to be checked out, I'll look into it. It seems like a framework that do, under the hood, something similar to what I do now, but surely in a cleaner and more efficient way. I'd also like to learn Scala (on coursera there was a free course from the creator of Scala, I missed it sadly). Let's see. I'd especially love to make the server a distribute system as you suggest..even though I fear that's too much for my current knowledge, yet I do love learning new things. I still don't understand whether akka is totally asynchronous or it can be made synchronous, but I think that's just my very poor understanding of it. I should have clarified however that I'm not going to release the source code, so the important things are that: it is enough performant to not have lags, I feel comfortable with it (and I love it, I must say, I find it the cleaner piece of code I've ever written) and it scales well with added complexity, ie the combat system, delayed commands, the magic system (the MUD is actually totally focused on the magic system, maybe I'll talk about it in the near future). Of course, in addition, building should end up being as straightforward as possible (but not simpler than that but I think my system doesn't make it more complicated in any way. The fact that other people have tried the multithreaded approach is both good and bad. Good because if there are codebases it's doable, bad because if there aren't actually running MUDs it might mean it does not scale well. I guess, unless the akka system conquer my heart while studying it, that I'll let you know how it goes. I'll also look forward Iberia MUD which is even more extreme. I did, and actually now I'm really curious to know how Viriato solved it in his IberiaMUD. As said however that's not really a problem with my own system: the command Move of the dragon (which contains the check on whether the door is open or not) and the command Close of the player would be executed sequentially according to which one arrives first to the pendingCommand queue, so it's easy here. With a game loop too. For a fully asynchronous system, a lock on the door object would solve the problem in that particular case, with really little effort and overhead. A remark I've found on the internet is about what happens with crowded rooms, or with fights. You need to put locks pretty much everywhere to avoid race conditions, and this might end up being slower than a game loop.