I have an idea for a game which I am in the process of designing, but I am struggling to establish if the way I plan to implement it is possible.

The game is a text based sports management simulation. This will require players to take certain actions through a web browser which will interact with a database - adding/updating and selecting. Most of the code required to be executed at this point will be fairly straightforward.

The main processing will take place by applications which are scheduled to run on the server at certain times. These apps will process transactions added by the players and also perform some automatic processing based on the game date.

My plan was to use an SQL server database (at last count I require about 20 tables) and VB.net for all the coding (coming from a mainframe programming background this language is the simplist for me to get to grips with). I will also need a scheduling tool on the server.

Can anyone tell me if what I am planning is feasible before I dive into the actual coding stage of my project?


Non-distributed systems as you mention, rely on processing within a local environment. They are not designed to scale. Therefore, your approach is based heavily on the use of local processing, in that you aren't considering distributed approaches.

Distributed systems, rely on processing spread out both locally and remotely. In order to achieve a communication method between these systems, a messaging architecture is added in. Information and data is exchanged by this messaging system. These approaches scale well, but require a modified design approach from the start.

It's hard to tell if your planning is feasible for the long term, but definitely feasible for the short term, where scaling isnt an immediate concern.


I think that this kind of approach is reasonable in the first phase of such a project, but in the future it must give way to a more advanced approach.

Normally the web activity consists in altering the state of the system: for each request to a particular set of web pages, you get a side effect in addition to just the content you requested (html, json, images, etc).

In your case, the user is not the only source of status updating, there is also a process that runs at a certain interval: obviously you can not exhaust the matter of the state transition just through the action of the user (using a strategy like "I will compute the partial outcome of your actions now, but I will not tell you until the deadline").

The use of a (centralized) process, implies that the system should not accept operations when that process is running. How long does it take to finish? I imagine that it will need of a time proportional to the number of players, or at most quadratic.

Here is the crux of the matter: this approach does not scale, in the general case, and the process can not last more than a certain amount of time, even with millions of players. At some time you will need to understand how to distribute the upgrading process; probably by precomputing everything you can at the stage where players can operate, and/or dividing update operations in independent blocks give to a process pool.

My opinion is that you have to keep in mind this now; now that you can define the parameters of the project, but probably you can continue as you said for now, since your first goal is to make a limited number of people very happy (at the earliest)

  • \$\begingroup\$ Sound advice there from both of you. I dont expect more than a couple thousand players and I'm hoping the scheduled processes run fairly quickly. However I agree that if the game does become more popular than expected I will have to work out how to spread the workload to ensure there is no downtime. \$\endgroup\$ – Rooq Mar 27 '13 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.