CODEWITHSUNDEEP
client-sideserver-side
Ilariel
Ilariel

Reputation: 3

Approach to create a web server for a game with web browser client and possibility for client software?

Basically the reason for asking this "question" is to get some information available that at least I didn't find from stackoverflow or didn't actually find by google searches.

So the product would be an multiplayer game, that would be played with browser and also be capable of being played with client software that could be programmed in C#, C++ or any other capable language. The language of the "desktop" client is coded should not be what were are discussing here about.

So the this means that we should be able to separate the presentation code, networking code and actual underlying game logic so that the server handles the game logic while clients present data from server regardless if they are the website version or the desktop client.

After all because this is a multiplayer game we have to take in account the number of connections. The amount of connections would be more or less around 8 to 12 per "game rooms" and server could be limited to handle up to what it can handle so no problems about that either.

Here is something that I thought but I'm not sure if this is even to right direction at all.

The web interface could be coded with javascript and make use of ajax or ajax-like technologies.

On the server-side php could be probably used and that would also allow us to make us of sockets which will allow the client software to connect to the server.

However can you silently update php generated pages with javascript without having to have the actual page changing behavior? I'm concerned about the interface flickering more or less when navigating through different pages and I really aren't that familiar with different "ajax technologies".

So I wish to hear and learn about different approaches to this kind of program building and I'm sure that this page could become good resource for other people struggling with this kind of issues.

Upvotes: 0

Views: 1267

Answers (1)

Toad
Toad

Reputation: 15935

Your approach is ont he correct path. The first and only webpage should serve the entire game completely in javascript. There is no concept of other 'pages' you have to navigate to. You'd do everything (browser dom manipulation, game logic, transitions, input/output, etc) in javascript code.

The game state which can be lost you'd maintain on the client, and persistent state you'd maintain on the server. You would indeed access the server through Ajax calls from within the javascript game. On the server side you would expose API's which expect some kind of parameters, and return JSON data with the results back to the javascript code.

Now on the desktop you would create the game exactly the same, except that the language you use is not javascript but for instance C# or java or C++. The gamestate you would still store on the server, and you would access it with webcalls from within the desktop game.

Upvotes: 1

Related Questions