hojo118

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

100 Neutral

About hojo118

  • Rank
    Newbie
  1. Browser Game "Tick" Engine

    I've been doing quite a bit of reading on this topic, as I get ready to write a backend for my web game. There seem to be two schools of thought about simulating a persistent, database driven, real-time multiplayer environment through a web browser. If you are not sure what that means, it can be summed up with a few names: Ogame, Ikariam, Travian, etc.. It does NOT, however, mean Farmville, City Ville or any other single player game with social networking aspects. They are two different designs and I am speaking about the first type. I feel I need to make that clarification as there seems to be a lot of confusion about what people think is a browser game and what I am actually seeking information on. The basics: The game has steadily incrementing resources based on x increase over a unit of time. Players can construct improvements to modify the rate of increase. The player can attack and be attacked by other players and be penalized for losing or rewarded for winning, in direct proportion to one another. The losing player loses as much as the winner gains. These conditions must exist when a given player is not logged in and playing the game, which can be hours, days, weeks, or months. Since not everyone is playing at the same time or with the same frequency, "missing" players need to be updated regularly in order to make sure that their resource levels, building levels, etc. are valid if some other player decides to take action against the "missing" player. So far I have seen two ways of handling this: [b]1)[/b] [b]The Just In Time update:[/b] Player information is updated every time someone initiates an action against them. This means that buildings that are in queue to be constructed and resources that are collecting don't exist in the database until an action from either a player or an opponent causes, through a mouse click, the "update" procedure to run. This is believed to be efficient in that it only calls for updates when needed, via a player interaction. Problems I see with this are: [b]1a[/b]) What if nobody initiates an action against the player to cause an update and there are persistent "high scores" that everyone can view. These high scores need to be calculated from at least somewhat up-to-date player data. If a "missing" player has not had any updates for a week, but has been collecting resources, then their score will actually be much lower, because no update has been run and the database doesn't know a thing about the "to be determined" resource levels [b]1b)[/b] Random events: If a random event occurs to a player while they are absent, the effects of that event still need to be calculated based on current data. For instance, there is an event where x resources are destroyed. Something has to "start" the event and write it into the database. Otherwise it "never happens" or "never ends" until the player logs in. This also applies to player-requested notifications. For instance, an email or SMS notification when an event has occurred or a condition has been met. Since the absent player actually never logged in, the events can't have happened because the player hasn't caused them to occur by logging in! (my head hurts) [b]2)[/b] [b]Running a cron job[/b]: Player information is updated when a script is run at x time interval by some cronlike method. This updates all characters, resources, scores, battles, births, deaths, events, etc. Problems with this are: [b]2a)[/b] Performance/Load barriers, possibly not scalable when large numbers of database rows need to be frequently updated. Right now option 2 is looking really attractive, and I'm not thoroughly convinced of the performance problems that people here and elsewhere are predicting. Most people seem to favor option 1 however, and I can't figure out how I could make it work in a world that requires persistence even when a lot of people might not be playing. How is this done in other games? Does anyone even know?
  2. I found this thread to be pretty helpful as I come up with a way to implement "ticks" in my browser game. However I am not clear on something. Example: Players gain resources at a rate of x/hour and a player's global high score is calculated from total resources. If the player begins construction of a building that increases that rate by 1/hour, and is told that it will take 12 hours for the building to complete and start conferring the new production rate, what happens when that player goes on a business trip and doesn't come back for a couple of days (48 hours)? Other players will be able to look at the "top player scores", but if there is no update being run (since the player is away on business), there will be more than 24 hours where the player is ranked much lower because there was nobody to cause an update to his building and the last couple days' of resource production. How is this resolved in a "Just in time" updating system. It seems to me that a cron job or background updater running at intervals is required to keep everyone in sync and make sure that scores are correct. Example: Players have "assistant" NPC characters that have a lifespan. If the NPC "dies" while the player is not logged in, how is that resolved in a "Just in time" update system? The same goes for births. If two "married" NPCs have offspring while player is away, something has to generate a new character during the player's absence. The only way i can imagine this working is with a cron job, otherwise these characters simply do not exist until the player logs in again. It could even be possible that a character will be born and die before the player logs in again, so the player would need to be notified when they log in again of both the person's birth and death. However, with the just in time method of updates, NPCs could only be "born" when a player runs and update, since logging in and hence running the update script causes a rash of births and deaths. Example: A player wants an email notification when a particular resource threshold or event occurs while they are away. If updates to the players' game only happen when they are logged in and causing updates, they will never get an email, or they will simply get all the emails at once the next time they log in. This seems to require a cron job and I do not know how it is resolved with just in time updating. Those are some examples that I could think of off the top of my head. I really am having a lot of trouble finding resources about how these many browser game companies are handling their backend infrastructure and updates. It seems to be either a closely guarded secret or something that nobody has been able to figure out how to do outside the confines of internal development studios. If any of you know any resources I could look at to help me wrap my head around this problem of "persistent" browser games, ticks, updates, etc. I would be extremely grateful.