Working on a web game similar in some respects to Ikariam

[clamum]

A couple guys and myself are working on a web game (using ASP.NET 3.5 and SQL Server 2005) that has some functionality that is similar to the Ikariam web game that was posted in the OT forum awhile back. However, I was wondering if anyone here had any input on a specific task we are in the process of implementing.

For anyone unfamiliar with Ikariam, you have an outpost where there are empty spots where clicking on them allows you to build a structure there. After a structure is finished building, clicking it will allow you to upgrade it. When building or upgrading, a "under construction" image is displayed and a timer counts down to zero from the length of time the action requires.

This functionality is what we have in our game. We have the logic implemented to show the "under construction" image and have a timer counting down using JavaScript, which when it gets to zero refreshes the page and in Page_Load there is logic that checks a couple of database tables to see if any building/upgrading has completed; if so the construction records are deleted and new building records inserted, into their respective tables.

However, we have other functionality that needs to happen behind-the-scenes on a real-time basis (example: the player earns so much money per hour). So we were thinking of two options to implement this:

1. Have a SQL Server scheduled job execute a stored procedure that checks tables and does the necessary inserts/deletes/updates. This job would ideally run every second or maybe thirty seconds.

2. Create a Windows Service that does the logic and have this service trigger every second (or thirty).

Option 2 is my preferred way as implementing the logic using C#/LINQ would be much easier than doing it in a stored procedure using SQL. I'm just not sure how efficient either of these methods are. For each player, I don't think these building and construction tables will have more than a couple tens of records so the database should not be too big.

Has anyone implemented this timer "real-time behind-the-scenes" sort of thing in a web app before? What do you think about the options we came up with? I'd appreciate any suggestions.

 

[imported_Dhaval00]

I'd go with the second option, too, but can you elaborate on how the updated data will be used at the Website level? Also, LINQ makes things easier and fancier, but if you're going to be running the same piece of code over and over again, you better code a SPROC that gets called from the Windows service. This is exactly the same discussion people were having when SQLCLR came out. In the end, you'll have to find the right balance. Just my two cents.

 

[ahurtt]

If you do what you're proposing every second for every player your server is going to come to its knees. . .with just 10 players you're going to be doing this operation 10 times per second x 60 sec per min. = 600 times per minute. With only 10 players. For every new player you add, add 60 more times per minute. . .your performance will be horrendous.

What if you only calculate the money earned on an "on demand" basis, as in only when the information is needed for some reason? Either that or make your calculation interval much longer. Maybe at the end or beginning of each turn if you have the concept of turns. Why does it really need to be "real time?"

 

[Snapster]

Originally posted by: ahurtt
If you do what you're proposing every second for every player your server is going to come to its knees. . .with just 10 players you're going to be doing this operation 10 times per second x 60 sec per min. = 600 times per minute. With only 10 players. For every new player you add, add 60 more times per minute. . .your performance will be horrendous.

What if you only calculate the money earned on an "on demand" basis, as in only when the information is needed for some reason? Either that or make your calculation interval much longer. Maybe at the end or beginning of each turn if you have the concept of turns. Why does it really need to be "real time?"

It doesn't need to be but I can understand the perception of it being real time as that's what it feels like when you play it. On demand is more realistic and scaleable and you can have a few cron jobs that run every hour or so if necessary to bulk update things.

How I reckon they did it:
They know when a task ie gathering wood started
They know the current rate of collection/time
They know when a user looks at a page
Calculate the difference in time, use a formula to show user how much they have made since the task started until current time.

Of course this is a simplistic view of things.

Remember when the clocks screwed up due to DST and everyone's totals got messed up? Should give you an idea

 

[ahurtt]

Yeah one thing I can see that would make doing the "on demand" type approach would be keeping track of external events (perhaps actions by other players) that occur which might affect the outcome of the calculated result and factor them in at the time the calculation is done. Of course even using the "real time" approach, no matter how long or short your calculation interval is (be it every second or every 5 minutes) you'd still have to have a way of listening and queuing up these types of events if they exist. Like if a player has an income generating structure that they created at a certain time one day but some time between that time and the time they come back to check it, another player destroys it or something. Obviously it must not generate any more income for the owning player after the point in time which it was destroyed. Or maybe it is captured intact by another player and now generates income for that player instead or something like that. . .
Since I don't really know how your game works, I don't really know if those are valid scenarios but I'm just imagining what's probably commonplace in this type of game.

 

[Markbnj]

I think you'll ultimately be unhappy with this approach. You're relying on refreshing the web page to re-query the state of the objects so that you can rebuild the UI. There are a number of issues with this. First, the round-trip time to execute the ASP.NET assembly and rebuild the HTML response is not going to be constant. Second, depending on browser and other factors you may get a lot of flickering (you can use meta tags on the page to minimize this, but these are all browser-specific extensions as far as I know, so that opens up a different can of worms). You are also moving a lot more data than necessary, and this will limit the speed with which you can refresh the view.

You really need a combination of background processes to execute the game logic against the world database, and a services/ajax-based API for the player to execute transactions (take game actions) against the database and receive UI updates. On the front end the UI should just update the elements that change, and be responsible for those UI changes that don't require a round-trip to the back end.

For the background processes you could indeed use stored procedures executed on a schedule, but I would recommend against it. The primary reason is that you're too likely to get well into the effort and discover that you're having to do more and more complicated things in SQL, and at the point where you decide SQL was the wrong platform you either have a port on your hands, or logic code spread between multiple layers.

I would sit down and think through the architecture a bit. I don't know the game that inspired you guys, but for a single player game I would move as much as possible to the client. If you have processes running on the back end then you get into session management, killing dead games, etc. You can probably do everything you want in-memory using jquery or some other javascript framework (scriptaculous, or whatever). Do you really need to store the game state in SQL Server? If it's a multiplayer game, then the architecture makes a lot more sense.