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

koteko · 11-15-2012, 07:43 PM

This is my first post, but I've been following you for a while. I'd like to start a discussion about the thing put in the title (saying goodbye to game loops), as a starter, and possibly get some feedback about my own project.

Ok, so here's the thing. As many before me, I decided (11 months ago) to start making my ideas concrete. The language I best knew was Java, and still is, so I started looking for Java codebases..but after a few source code browsing on sourceforge, I understood I could do it myself, maybe better (the Java codebases I've found are all seemingly dead anyway).

I decided to challenge myself on a particular design aspect: not using a game loop at all. On a linux machine, with Java 7 and a quad-core 64 bit, tens of thousands of (small) threads can be executed at once without the system being slowed down at all. I've searched around for statistics on that and it seems confirmed.

I've been using blocking IO on sockets, since for each player there is a dedicated thread and the blocking IO make the thread sleep most of the time, saving computation. Various "worker threads" do background stuff, like waiting for commands to be executed, waiting for new users so as to create a dedicate thread on the fly, doing timed events etc.

I guess, with the number of users of modern MUDs, I'll be having at maximum a few tens of threads, maybe if I'm overly lucky on the order of 100. Still, acceptable performance wise since, at a particular time t, most of the threads should be waiting/sleeping.

As far as I've seen this is a new approach to mud coding. Am I right? Or have I just been too quick on my web search one year ago?

There is a particular thing I still have somewhat in common with game loops style approaches. I have a thread, ActionExecutor, where each Action (can be a player Command, or a MobAction, or a RoomEvent) has to pass on to be executed. This guarantees a sequence of actions.

If player A issue a command before player B, it won't happen that the command B is executed before, as it could in a totally decentralized system. At the beginning I was going to make it decentralized, but this sequence problem and the need of carefully design the concurrency to avoid deadlocks just drove me to this other solution.

So far I have implemented the few basic mechanics that allows it to be called a MUD-like thing. Players, mobs, objects, rooms, take-wear-open-lock and the opposite commands. It is like a chat with object interaction and world navigation.

I am just not sure if this approach is actually feasible. When more commands will be implemented, I'll pick up some friends and random people to do a mass connection issuing commands at maximum speed, to see if they are able to lag the server.

I'll surely need to do deep optimisation in the future, using a profiler, but in general terms what do you think? Is it possible with today's hardware to have a event-driven, highly threaded mud? It seems like in the next few years we're going to have cpus with a lot more cores. Intel is already selling 6-cores cpus, but what about a cluster of 100 raspberry pie? It'd be something like one for each player (or even more). The MUD would be extremely reactive in this way I guess.

Well, that's a long first post

I look forward to your opionions and thoughts about this.

11-15-2012, 07:43 PM	#1
koteko New Member Join Date: Mar 2012 Posts: 20	Event-based with threads instead of game loop This is my first post, but I've been following you for a while. I'd like to start a discussion about the thing put in the title (saying goodbye to game loops), as a starter, and possibly get some feedback about my own project. Ok, so here's the thing. As many before me, I decided (11 months ago) to start making my ideas concrete. The language I best knew was Java, and still is, so I started looking for Java codebases..but after a few source code browsing on sourceforge, I understood I could do it myself, maybe better (the Java codebases I've found are all seemingly dead anyway). I decided to challenge myself on a particular design aspect: not using a game loop at all. On a linux machine, with Java 7 and a quad-core 64 bit, tens of thousands of (small) threads can be executed at once without the system being slowed down at all. I've searched around for statistics on that and it seems confirmed. I've been using blocking IO on sockets, since for each player there is a dedicated thread and the blocking IO make the thread sleep most of the time, saving computation. Various "worker threads" do background stuff, like waiting for commands to be executed, waiting for new users so as to create a dedicate thread on the fly, doing timed events etc. I guess, with the number of users of modern MUDs, I'll be having at maximum a few tens of threads, maybe if I'm overly lucky on the order of 100. Still, acceptable performance wise since, at a particular time t, most of the threads should be waiting/sleeping. As far as I've seen this is a new approach to mud coding. Am I right? Or have I just been too quick on my web search one year ago? There is a particular thing I still have somewhat in common with game loops style approaches. I have a thread, ActionExecutor, where each Action (can be a player Command, or a MobAction, or a RoomEvent) has to pass on to be executed. This guarantees a sequence of actions. If player A issue a command before player B, it won't happen that the command B is executed before, as it could in a totally decentralized system. At the beginning I was going to make it decentralized, but this sequence problem and the need of carefully design the concurrency to avoid deadlocks just drove me to this other solution. So far I have implemented the few basic mechanics that allows it to be called a MUD-like thing. Players, mobs, objects, rooms, take-wear-open-lock and the opposite commands. It is like a chat with object interaction and world navigation. I am just not sure if this approach is actually feasible. When more commands will be implemented, I'll pick up some friends and random people to do a mass connection issuing commands at maximum speed, to see if they are able to lag the server. I'll surely need to do deep optimisation in the future, using a profiler, but in general terms what do you think? Is it possible with today's hardware to have a event-driven, highly threaded mud? It seems like in the next few years we're going to have cpus with a lot more cores. Intel is already selling 6-cores cpus, but what about a cluster of 100 raspberry pie? It'd be something like one for each player (or even more). The MUD would be extremely reactive in this way I guess. Well, that's a long first post I look forward to your opionions and thoughts about this.