I apologize if this is posted in the wrong section.
A game community that I am currently involved in is planning on making a switch from a client/server model to a web-based one. Some of the the community members are weary of this change fearing loss of performance and ease of use. I am trying to explain what this means for the game itself and for the individual players but, I have been away from programming too long to offer any concrete facts on the situation.
Any information or views will gladly be welcome. I appreciate the time you have taken to assist me.
[web] web based questions
The web (as in HTTP + HTML) is just a specific kind of client/server model, with its own benefits and drawbacks, which may or may not apply to the project you are dealing with.
For instance, HTTP is a pull-only stateless protocol, which is both a benefit (you can handle more clients per server, and you can spread the load across multiple servers) and a drawback (the server cannot initiate communication with the client, every request must carry all necessary state information). So, it would be a great choice for a game that involves millions of low-bandwidth clients, and a bad choice for games with a handful of high-bandwidth users.
The web does have the benefit of being fairly platform-independent and requiring no software download (although you can achieve this with a client/server model using Flash or Java, too), but you will be limited in terms of rendering power. Presenting static dialogs and forms, along with simple 2D graphics and animations, is possible, but anything more complex than that (including, say, playing sounds) is going to require specific software on the client side.
To be able to tell more, we would need more information about your project.
For instance, HTTP is a pull-only stateless protocol, which is both a benefit (you can handle more clients per server, and you can spread the load across multiple servers) and a drawback (the server cannot initiate communication with the client, every request must carry all necessary state information). So, it would be a great choice for a game that involves millions of low-bandwidth clients, and a bad choice for games with a handful of high-bandwidth users.
The web does have the benefit of being fairly platform-independent and requiring no software download (although you can achieve this with a client/server model using Flash or Java, too), but you will be limited in terms of rendering power. Presenting static dialogs and forms, along with simple 2D graphics and animations, is possible, but anything more complex than that (including, say, playing sounds) is going to require specific software on the client side.
To be able to tell more, we would need more information about your project.
Any game developed poorly will suffer poorly. That shouldn't be a reason why not to move to a web-based approached.
As ToohrVyk wrote, HTTP is based on a simple request-response method. Clients make the request, the server sends the response. It made for a poor platform to building rich games. However, in the past few years, methods have been developed to circumvent that limitation. AJAX made it so that you don't have to reload a whole page. Comet and WebSockets (a draft in the HTML5 spec) makes push and real-time, bi-directional communication a reality. jQuery and CSS updates make the user experience much richer.
With everything that is out there now, there is no reason why you can't develop a 2D MMO using nothing more than HTTP, HTML, CSS, and JavaScript. There is even very limited and immature support for audio and video built right into HTML5!
In a year or 2, a 3D MMO will grace the browsers using nothing more than native HTML support. As web developers and game developers, HTML5 is opening up a whole new world of games.
I have started a game development series for JSMag (jsmag.com). April 2011 has the first article in it and it talks about using Node.js and Socket.IO to achieve real-time/bi-directional communications between the browser and the server. May's edition will have Component-based Entity Game Object Library and object persistence. Check them out to get an idea if your community can make the switch.
As ToohrVyk wrote, HTTP is based on a simple request-response method. Clients make the request, the server sends the response. It made for a poor platform to building rich games. However, in the past few years, methods have been developed to circumvent that limitation. AJAX made it so that you don't have to reload a whole page. Comet and WebSockets (a draft in the HTML5 spec) makes push and real-time, bi-directional communication a reality. jQuery and CSS updates make the user experience much richer.
With everything that is out there now, there is no reason why you can't develop a 2D MMO using nothing more than HTTP, HTML, CSS, and JavaScript. There is even very limited and immature support for audio and video built right into HTML5!
In a year or 2, a 3D MMO will grace the browsers using nothing more than native HTML support. As web developers and game developers, HTML5 is opening up a whole new world of games.
I have started a game development series for JSMag (jsmag.com). April 2011 has the first article in it and it talks about using Node.js and Socket.IO to achieve real-time/bi-directional communications between the browser and the server. May's edition will have Component-based Entity Game Object Library and object persistence. Check them out to get an idea if your community can make the switch.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
