• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
sooner123

[web] How do Browser games implement 'tickers'?

40 posts in this topic

For lack of a better word, how are 'tickers' (things that make time tick by and events happen in browser games) implemented?

I could think of a few ways.

-cronjob (linux dependent and useless to me since i run a windows server)
-server itself has something running like a 'update.php' page with a meta/jvs refresh timer
-windows scheduler or something which isn't really any different from option #2
-cgi script (not really sure how to do this but it seems like it might be the most common solution. that's just a guess though)

I was hoping for a more logical solution than having to have a webpage open on my server in order for my game world to be alive.
0

Share this post


Link to post
Share on other sites
CronW? Its cron for windows.

Also, I've never used a windows server before, but supposedly there is a task scheduler you can set up.
1

Share this post


Link to post
Share on other sites
Depends how often they happen, if it's happening often why not just make an executable that runs as a service do it every X amount of time you need it to, otherwise if it's infrequent scheduled tasks are what you're looking for
1

Share this post


Link to post
Share on other sites
It's a Browser based game that updates every minute.

How would I go about writing this type of executable? Do you mean like a c++ application that loops on a timer and calls update.php every minute? If so, how do I call a webpage with C++? Is that a CGI thing?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by sooner123
It's a Browser based game that updates every minute.

How would I go about writing this type of executable? Do you mean like a c++ application that loops on a timer and calls update.php every minute? If so, how do I call a webpage with C++? Is that a CGI thing?


Ask yourself this:

Does it really matter if it updates or not while noone is playing ?

You can easily have it run as many updates as necessary to catch up once a player accesses the game.
1

Share this post


Link to post
Share on other sites
I've considered that option but I don't like it for a few reasons related to workload distribution.

What is the way this is usually done? Like say for large scale games like.. Farmville or Travian or any number of Browser based games with an updating world.
0

Share this post


Link to post
Share on other sites
If I had to implement such a feature, I'd be in favor of what SimonForsman proposed. It seems unnecessary to have your server working away, when no one is playing. I assume, like the games you mentioned, you'll require some form of registration to play? I would imagine the standard practice would be to save the time the users game was last updated and, the next time they launched the game, calculate the number of updates that would've happened and perform them.

If you wanted to entertain an extreme example, say you have 1,000,000 users. If you updated every minute, you'd have to update all 1,000,000 users at once, even if there were only 2 users currently playing. If you had a lot of game state data, that could be hell on your server, and annoy for those 2 user. If you allow interaction between users (as in a farm style game), and one of the users isn't logged in, I would just update their game if/when the other user interacts with it.
1

Share this post


Link to post
Share on other sites
As opposed to a user not logging in for a week, and then having to calculate 10k updates? And that's not even taking into account any actions that impact other players..

Basically, calculating past steps on demand only becomes somewhat viable when players cant interact with each other at all. Once they can, you basically need to save the state of the game for all players at all steps in order to make sure interactions occur with the right data for each player.

Also, if you want to be able to notify users of things by email when they happen.. it's not terribly helpful to be emailed about your pet starving and dying only when you get around to logging in a couple days later.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DEbig3
And that's not even taking into account any actions that impact other players..


Quote:
Original post by AverageMidget
If you allow interaction between users (as in a farm style game), and one of the users isn't logged in, I would just update their game if/when the other user interacts with it.


I agree with the e-mail feature, though.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by sooner123
I've considered that option but I don't like it for a few reasons related to workload distribution.

What is the way this is usually done? Like say for large scale games like.. Farmville or Travian or any number of Browser based games with an updating world.


For a really large scale game i would write a dedicated server and treat it like any other multiplayer game. This pushes the complexity up to that level aswell though and pretty much requires that you use browser plugins(flash,java,silverlight or similar) for the client unless you're fine with only supporting modern browsers (Firefox4, Chrome4 or Safari5 basically)

a third option is to use a cron job or the windows task scheduler to run a script at a set interval, personally i'm not a big fan of this approach though since it greatly restricts your hosting options without really adding anything. (Hosts that allow you to mess with the scheduler tends to also allow you to run your own processes, which means you might aswell write a proper server)
1

Share this post


Link to post
Share on other sites
Quote:
Original post by AverageMidget
If I had to implement such a feature, I'd be in favor of what SimonForsman proposed. It seems unnecessary to have your server working away, when no one is playing. I assume, like the games you mentioned, you'll require some form of registration to play? I would imagine the standard practice would be to save the time the users game was last updated and, the next time they launched the game, calculate the number of updates that would've happened and perform them.

If you wanted to entertain an extreme example, say you have 1,000,000 users. If you updated every minute, you'd have to update all 1,000,000 users at once, even if there were only 2 users currently playing. If you had a lot of game state data, that could be hell on your server, and annoy for those 2 user. If you allow interaction between users (as in a farm style game), and one of the users isn't logged in, I would just update their game if/when the other user interacts with it.


Players interact with each other.

Fleets and armies are moving around in time. Training occurs in time.

It would be far too complex to only compute relevant changes when the user can see it as you'd have to build up some kind of map of all the interactions between the player, the player he's interacting with, all players that player has interacted with etc.

If it was a single player game I'd do it this way though.

As it is I'm leaning towards using curlpp.

I'm still wondering how this is normally done for large scale multi-user browser based games. I would assume it's not windows scheduler or cron since a lot of these games are based on remote hosts. I would imagine cgi would be the most common solution but I don't KNOW at all so I was hoping someone else would.

I think a c++ script with curlpp should work fine though if you guys don't see any other immediate better or more standard way.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by sooner123
Quote:
Original post by AverageMidget
If I had to implement such a feature, I'd be in favor of what SimonForsman proposed. It seems unnecessary to have your server working away, when no one is playing. I assume, like the games you mentioned, you'll require some form of registration to play? I would imagine the standard practice would be to save the time the users game was last updated and, the next time they launched the game, calculate the number of updates that would've happened and perform them.

If you wanted to entertain an extreme example, say you have 1,000,000 users. If you updated every minute, you'd have to update all 1,000,000 users at once, even if there were only 2 users currently playing. If you had a lot of game state data, that could be hell on your server, and annoy for those 2 user. If you allow interaction between users (as in a farm style game), and one of the users isn't logged in, I would just update their game if/when the other user interacts with it.


Players interact with each other.

Fleets and armies are moving around in time. Training occurs in time.

It would be far too complex to only compute relevant changes when the user can see it as you'd have to build up some kind of map of all the interactions between the player, the player he's interacting with, all players that player has interacted with etc.

If it was a single player game I'd do it this way though.

As it is I'm leaning towards using curlpp.

I'm still wondering how this is normally done for large scale multi-user browser based games. I would assume it's not windows scheduler or cron since a lot of these games are based on remote hosts. I would imagine cgi would be the most common solution but I don't KNOW at all so I was hoping someone else would.

I think a c++ script with curlpp should work fine though if you guys don't see any other immediate better or more standard way.


using curlpp to load the script from a c++ program is just insane, if you're able to run your own software on the server you can have it update the gamestate directly rather than go the long way through the webserver. (I'd also recommend having your own software handle the communication with the client in that situation since HTTP and HTML/XML overhead will kill your bandwidth for any large scale game)

What i suggested wasn't to only update for the player in question, but rather to update for everyone, So instead of running update.php once per minute using cron/windows scheduler or your own app using libcurl, you run the update script when a player tries to access the gamestate if it is time for an update. if the last update was at 22:00 and any user tries to access the game at 22:05:50 you run update.php 5 times before running the normal script (then it would set the last update time to 22:05 and the next update would run if a player is playing at or after 22:06), a simple table lock will avoid having multiple users cause extra updates to run and unless your game is completely empty for a very long period of time the backlog won't be a problem. (Unless your game is incredibly complex you should be able to run a few hundred updates per second on a modern server without any problems, at an update rate of once per minute a 24 hour backlog won't take more than a few seconds to work through and if you got that few users you'll have bigger problem than them having to wait a second or two extra to load the login screen)
0

Share this post


Link to post
Share on other sites
You've got to be a LOT more specific to figure out how to make events 'tick' in a web environment. To take your main points:

Players interact with each other.

Spectacular! How? They fight and/or trade, I assume, from the army bit in the next sentence. Do you allow active/inactive fights? If so, all outcomes will be formulaic (pre-determined actions by inactive player). Your game logic will be something like ACTIVE_PLAYER attacks SUPERMAN, SUPERMAN not online (query updates for SUPERMAN, apply), SUPERMAN follows scripted battle.

Fleets and armies are moving around in time. Training occurs in time.

Probably nothing happens during transit/training, right? Or, if it does, those changes are effective after the movement/training? Then all changes can be applied when USER/PLANET/BASE/AREA is accessed after the end time.

It would be far too complex to only compute relevant changes when the user can see it as you'd have to build up some kind of map of all the interactions between the player, the player he's interacting with, all players that player has interacted with etc.

Why is it too complex? A user doesn't need to change AT ALL unless someone (the user himself or another player) accesses the user. When your battle/trade/display scripts access user data, they should confirm the data is timely (typically by including a LAST_ACCESSED field or separate, searchable update queue). You don't need to know (or care) what triggers your update method, you just need it to run prior to any interaction.

I would avoid lumping all your check update routines at login because you'll still want progress to roll forward while users are playing. Especially at the beginning of your dev cycle, no one will be signing in, meaning you'll never have updates while playing.

But really, what is happening EVERY minute? Interest on bank accounts? Auto-experience? Some sort of special power growing? Those are typical things (AFAIK) that can happen "constantly" in a game, but they are often not. Even some of the most complex growth patterns you can find (I did some crazy interest gains in Calc) can be figured in one step to adjust for time. Say you want them to gain 0.5% of their experience every minute and they don't login for exactly one week (10080 minutes). You just use a basic compound interest formula (assume 100 XP at logout 1 week ago - in the Wikipedia link, here n is 1): 100(1+.005)^10080 = 682185533694734340099690.06898055 XP when they login again. Also, that is a prime example of why you should avoid any kind of uncapped interest on games...

The point is that your updates are probably just numbers changing by a formula and you can adjust that formula for ANY amount of time, making "on-demand" updates a simple, practical solution.

Another thing to remember is you AREN'T Farmville or EVE. You aren't trying to balance simultaneous updates of 600,000 users in realtime because you have 500,000 online. Trying to design for those problems when you'll be successful with 10,000 regular players (not simultaneous) is absurd. Do you think about transferring exabytes of data every time you make a website?

Anyway, feel like I'm straying from the initial point: Breakdown EXACTLY what is happening in your game and then figure out how to best keep it up-to-date. That means being much more specific than armies grow, people age; you have to figure out precisely how you will track that information (database design/formula work). I'm not out to dis cron jobs, even this usage, just that you need to consider if that's the best method. The only way you can do that is by knowing precisely what and why your 'update.php' does every minute.
1

Share this post


Link to post
Share on other sites
Quote:
Original post by SimonForsman
using curlpp to load the script from a c++ program is just insane, if you're able to run your own software on the server you can have it update the gamestate directly rather than go the long way through the webserver. (I'd also recommend having your own software handle the communication with the client in that situation since HTTP and HTML/XML overhead will kill your bandwidth for any large scale game)


I don't understand what you're saying about using curlpp being insane.

How would I update the gamestate "directly." Without having a c++ program that sleeps or loops on a timer and uses curlpp to call update.php every 60 seconds?

Quote:
Original post by SimonForsman
What i suggested wasn't to only update for the player in question, but rather to update for everyone


I see what you mean here but I still don't like this solution. I'd like the game world to be alive when no one is in it. But I'm still not sure I see the advantage.

Whether it calls update.php 5 times after 5 minutes of zero activity or once a minute during those 5 minutes, it's the same amount of work done by the server, but less chance of a user having to wait a little longer than they would normally have to.

As you said, it's a solution that works, but I don't see what advantage it has over a c++ program looping/sleeping.

Is the advantage just that the continuous cpu-usage of the c++ program looping/sleeping is not necessary if I do it this way?
0

Share this post


Link to post
Share on other sites
Write a CLI PHP or Ruby script that handles simple HTTPSocket handshakes and run it on as your game server. It's a persistent process that your javascript/other server can connect to using HTML5 sockets/CURL (or you can drop the whole HTTPSocket all together if you're using flash [or some other applet with socket support] and just implement your own basic protocol on-top of tcp.)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by sooner123
Quote:
Original post by SimonForsman
using curlpp to load the script from a c++ program is just insane, if you're able to run your own software on the server you can have it update the gamestate directly rather than go the long way through the webserver. (I'd also recommend having your own software handle the communication with the client in that situation since HTTP and HTML/XML overhead will kill your bandwidth for any large scale game)


I don't understand what you're saying about using curlpp being insane.

How would I update the gamestate "directly." Without having a c++ program that sleeps or loops on a timer and uses curlpp to call update.php every 60 seconds?


He's saying that if you're going to use a C++ application, you might as well connect to the database and manipulate the game data directly, rather than connecting to a PHP script, which then connects to the database to manipulate the data.

Also, if it were me, I would never use C++ for something like this. I would tend to lean toward a small Python app or something similar, which would be much easier and faster to develop, and no less powerful.
0

Share this post


Link to post
Share on other sites
Ahh I see.

I don't see a big advantage of having the C++ application make all the updates itself over it calling an update.php. Unless C++ would simply do it far faster than PHP can. But I'd imagine in both cases the bottleneck would be the database.

Well I'll definitely weigh all the suggestions here and figure something out based on the final nature after more design fleshing. I now see that choosing between an "update when user loads a page or does something update-relevant"-solution, a "curlPP-driven C++ app that executes an update.php"-solution, and a "C++ app that updates the gamestate itself"-solution is fairly dependent on the specific nature/popularity of the game.

Ultimately I'll choose something that works without introducing any serious bottlenecks and takes the least work to implement.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DEbig3
As opposed to a user not logging in for a week, and then having to calculate 10k updates?


I doubt this is a problem. 10k is not very much, that's just about 1 ‰ of the number of rays a very basic realtime ray tracer can trace each second. Of course a web-server is usually not fast, as are most languages when compared to non-beginner C++.

So let's assume a tick is needed once per second:

1 tick/second
= 60 ticks/minute
= 3.600 ticks/hour
= 86.400 ticks/day
= 604.800 ticks/week
= 2.419.200 ticks/(28 days)

Advice A) Benchmark how long it takes for so many ticks. If it is just 10 seconds or less, I'd say we have no problem (in case this technique is applicable)

Advice B) Do you really need 1 tick/second? In case 1 tick/(30 seconds) would be enough, e.g., you would only have 80640 ticks/(28 days). Then go back to A).

(again, this is only in case the technique is applicable and to show actual numbers)
0

Share this post


Link to post
Share on other sites
Quote:
Whether it calls update.php 5 times after 5 minutes of zero activity or once a minute during those 5 minutes, it's the same amount of work done by the server


This is rarely true in practice and completely wrong in theory. An operation 5 times is not equal to 1 operation that comes to the same answer. Example: Do this 5 times: n^2 = nnext, where n is initially 2. Convert the final answer to binary.

Or take 2 in binary (10) and append five 0s (1000000 = 64).

Just something to think about.

PS: Learn to use cron/task scheduler/roll your own if you go that route. Dealing with the extra overhead of triggering it via HTTP (even just the transfer costs!) isn't worth it and can easily become a MAJOR problem. What if your connection goes down? What if the server is disconnected for updates?
0

Share this post


Link to post
Share on other sites
Ahh. I'm actually the webserver myself.

For the time being, I've just got an update.php on a META 60 second content refresh.

Later on I'll either use windows scheduler or a curlpp app.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by jolid
Quote:
Whether it calls update.php 5 times after 5 minutes of zero activity or once a minute during those 5 minutes, it's the same amount of work done by the server


This is rarely true in practice and completely wrong in theory. An operation 5 times is not equal to 1 operation that comes to the same answer. Example: Do this 5 times: n^2 = nnext, where n is initially 2. Convert the final answer to binary.

Or take 2 in binary (10) and append five 0s (1000000 = 64).

Just something to think about.

PS: Learn to use cron/task scheduler/roll your own if you go that route. Dealing with the extra overhead of triggering it via HTTP (even just the transfer costs!) isn't worth it and can easily become a MAJOR problem. What if your connection goes down? What if the server is disconnected for updates?


This isn't about an operation five times vs. a different operation that comes to the same answer.

This is about calling update.php once per minute for five minutes, vs. calling it 5 times in a row. I don't see a difference here.

Also I think you'd have to append 31 zeros for your example, which is really just showing that squaring numbers that are 1 followed by zeroes is easy in any base. It's not a shortcut.

Switching to a different base doesn't help you at all since you still have to do the work of converting it back to the base you're interested in which is even more work than manually squaring 2, 5 times in decimal.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by sooner123
Ahh I see.

I don't see a big advantage of having the C++ application make all the updates itself over it calling an update.php. Unless C++ would simply do it far faster than PHP can. But I'd imagine in both cases the bottleneck would be the database.

Well I'll definitely weigh all the suggestions here and figure something out based on the final nature after more design fleshing. I now see that choosing between an "update when user loads a page or does something update-relevant"-solution, a "curlPP-driven C++ app that executes an update.php"-solution, and a "C++ app that updates the gamestate itself"-solution is fairly dependent on the specific nature/popularity of the game.

Ultimately I'll choose something that works without introducing any serious bottlenecks and takes the least work to implement.


Basically the drawbacks of a c++ program running curlpp is:

1) Most free/cheap hosts won't allow it, you'll have to pay for a dedicated server (Same is usually true for windows scheduler and cron) (The windows scheduler also has a lower limit of 5 minutes, atleast on Vista (not sure about server editions)

2) curlpp doesn't run update.php , it generates a HTTP request, sends it to the webserver and has the webserver parse the php script, this is unnecessary overhead.

a c++ app that updates the gamestate directly basically has the same primary drawback as the curlpp solution, it requires a dedicated server, however it has less overhead since it doesn't involve the webserver or the php parser in the update process, If you've allready written your update.php script its probably not worth the effort though.

If you got a dedicated server and know that the database will be the only bottleneck you could just run "php.exe update.php" and have update.php loop and sleep for you, this has less overhead than the curlpp solution (no webserver gets involved) and takes less effort to code (no need for c++ code, just add set_time_limit(0), an infinite loop, a time check(to ensure the correct amount of time has passed before running another update),a short sleep(to avoid eating up all cpu resources while doing nothing) to your update.php script) and a way to terminate the script cleanly (if you need to make updates to the script you don't want to kill it in the middle of an update).
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0