Hi!
I’ve taken a quick look at the darkstar swordWorld tutorial, and I have one major question.
Suppose I want certain things to happen “independently” of the users (like monsters running around, natural events, flow of time, …), how would I do that?
In a single player game, I would have a central loop that the game would execute everytime it is drawing a frame. Creating a task that runs forever is out of the question, because of the locking and starvation issues. Would it be acceptible to create a task that instantiates a copy of itself?
I guess that is what package com.sun.gi.gloutils.pdtimer is for. A new event can be registered via SimTask.registerTimerEvent(…). I have not tried it out yet, but it should basically work like the heartbeat in a mud-like game.
There is a low level system heartbeat directly accessible off the SimTask BUT things driven off that are slice dependant and each slcie has its own independant timer.
The PDTImer utility builds ontop of this to keep one system-wide list of timer events and allow parralel processing of the evenst by whatever slice has free processing time available. It also makes the list of timer events persistant across restrats of any or all of the slices.
Edit: Do keep in moind however that timer driven code on the server side is a necessary evil with the accent on evil. Overuse of this facility is the fastest way to end up bogging down your servers. If at all reasonable, it is better to have your server acting as an event driven processor of client events then generatring its own off a heartbeat. Clients should have central “game loops”. Servers should not.
Keep in mind that, in many cases, the server is a whole lot like a sub-atomic physics system. Its state is irellevent until you need to measure something for the client and thus can be left uncalculated til then. As a brain-dead example, if a guard is pacing back and forth ina predictable manner, and ther are no players to see him, his pacing is irellevent. When the player gets close enough to see him is time enough to calculate position. Simialrly, if your client is doing thinsg like collision detection then your server can afford to wait and check for cheating in “significant” position chnages rather then on every move of the character, like the client has to.
These are all the things you should think about if you plan on scaling to any reasonably large numbers…
Jeff, for a persistent world game there may be events you want to have happening in the background which keep the world dynamic but are not a direct part of a player’s actions. The basic game model I’ve referenced in other recent threads is a pirate-based game with you travelling the Carribien. A weather system is a key example of something that is global to the game world, should be completely server driven, and has direct impact on all clients ( and many other game events ). If a tropical storm builds up and moves west thru the region it will damage port cities, disrupt trade, and threaten the PCs. After the storm as passed and impact dertermined, some ports may be very bad places to trade while they rebuild, or they may have an increase in thier need for certain trade goods during that time. And how one port is impacted by the storm would have an economic impact on other near by ports that they trade with, even if those ports are not directly damaged ( the price of rum goes up if the major supplier for that area is devestated ).
If I’m understanding correctly, you are suggesting not using a traditional game loop on the server and keeping the game design event driven. If that’s the case, in order to handle something like what I descirbed above ( and perhaps a dynamic economic model similar to what was brought up recently in another SGS thread ) would you suggest running an external service for these complex global systems? It could either provides events to the SGS as if it was a client or expose an interface for the SGS to querry ( like a basic J2EE web service ). In this example it would handle modeling the weather, impacting the port location, and tracking the rebuilding progress. If a player visits the port the SGS would send a request for current status to the service and use that information to generate the actual port objects.
It just sounds a bit counter intuitive to have to move something like this outside of the rest of the game server. The scaling capability and likely co-locating business model of the SGS is a major draw for me since I really will be starting small, but hope to grow. If I have to isolate a chunk of my “world” outside of the SGS and take on the questions of managing that service seperately it really impacts the ROI.
Of course, if I’m way off base, please let me know… :
Agreed which is why I said necessary. We did include a timer ebcause we reocgnized the need. The trick is to use it as much as really necessary, and no more.
[quote] A weather system is a key example of something that is global to the game world, should be completely server driven, and has direct impact on all clients ( and many other game events ).
[/quote]
Sure. The good news however is that it evolves slowly so it shoudl be ona pretty low period tick 8)
Yes.
You could, but I dont think its necessary. A tick every 10 minutes to update your weather is not going to hurt your performance much.
A tick every 60th of a second to do micro adjustments of global monster positions will. It should be noted that this is not just my observation. We’re heard it repeated by real develoerps with real shipped and successful games (which I asnt name for NDA reasons)… that the number one cause of over-load for them was tight control of AI of bots.
Basically you suggest to just take a cautious approach. A tick every couple minutes to execute and maintain global events shouldn’t be significant, but don’t get carried away. To paraphrase the lesson I was taught when learning to off-road: “Slow as possible. Fast as necessary.”
