Hi people,

With the launch on Playforceone.com of THE GYM and the subsequent spanking the server took, I'm rethinking the basic building blocks of the next installment. The problem I had was that there were not enough concurrent connections available so even though the page updates (clientside with javascript), the corresponding image may fail to load leaving a blank screen. I thought I'd done my research but have been slammed for the concurrent connection issue.

My choices are:

1) Javascript again. Loading all the javascript files at first loading( currently it grabs extra js files as needed). This was prefered as it took the majority of processing and logic away from the server and put it on the players computer. Downside: Pages aren't easily reloadable.

2) PHP and Mysql is my second choice but as it's all serverside, so the number of calls to the server increase quite a lot. This would reduce the number of players that could play at any one time. There are also seperate issues with concurrent connections to the mysql database so there would be two potential bottleneck points. Upside: If a page doesn't load, refresh is an option.

3)Java and ajax is my third choice but suffers from similar issues as the second choice but would greatly increase what could be achieved within a game.

Also, can anyone recommend a provider and plan that has worked well for them (I should have asked this eariler)

Thanks

Sportd

Hi

I think the best option is to load all JS files at once. First time the page loads it will require more time, but then you'll reduce connections. Using PHP or JAVA won't fix that problem.

About provider... recently google has allowed to host pages (html, js, css) maybe you can try that.
Also, you can check amazon services, it works fine and it isn't expensive. The rest of providers that I know are more expensive, like heroku

Well... i read the preceding post, but with my lack of programming skill, it was like reading Japanese for me. I can't help !!

sportd wrote:1) Javascript again. Loading all the javascript files at first loading( currently it grabs extra js files as needed). This was prefered as it took the majority of processing and logic away from the server and put it on the players computer. Downside: Pages aren't easily reloadable.

2) PHP and Mysql is my second choice but as it's all serverside, so the number of calls to the server increase quite a lot. This would reduce the number of players that could play at any one time. There are also seperate issues with concurrent connections to the mysql database so there would be two potential bottleneck points. Upside: If a page doesn't load, refresh is an option.

3)Java and ajax is my third choice but suffers from similar issues as the second choice but would greatly increase what could be achieved within a game.

2 & 3 option will be very difficult to use in offline mode for most of the users.
I think, tlareo game system is the best choice if you want to keep a html system.

Else, you can have a look to rags or inform platform, but they need a program to run (rags player / daydreamer).

sportd wrote:1) Javascript again. Loading all the javascript files at first loading( currently it grabs extra js files as needed). This was prefered as it took the majority of processing and logic away from the server and put it on the players computer. Downside: Pages aren't easily reloadable.

Are failed downloads really an issue? It should be no stretch for even a lightweight server to serve up static javascript and HTML. Even images shouldn't be a serious problem in terms of CPU usage, although they would cause a significant hit on your bandwidth. With no evidence to back it up, I would bet your problems were more due to the design of the game itself. While you grabbed extra .js files as needed, all the text, actions, jumplists, and variables were stored indefinitely in a couple of enormous arrays. I would expect people who had trouble with the game were either using older computers, or browsers with javascript engines that could not handle those arrays. I know firebug choked hard trying to deal with them.

Hi wagner,

You are right in saying the javascript arrays are huge. That is a definate downside.

Are failed downloads really an issue? It should be no stretch for even a lightweight server to serve up static javascript and HTML. Even images shouldn't be a serious problem in terms of CPU usage, although they would cause a significant hit on your bandwidth.

Yes failed downloads are an issue. As it's written as one page, if a download fails, the image isn't shown and gameplay is negatively impacted.

My current host allows 200 concurrent connections and my understanding is:

A normal html page uses a seperate http request for each image on the page plus another request for the page (html file) itself...plus more for each external js / stylesheet. On a serverside game, the first page would be the same as clientside (probably 10-15 images, stylesheets etc...). they would be cached and then for server side game, each following page would require minimum 2 http requests where as the javascript page only requires one new request (to get new image).

That to my mind means there could be close to double the number of players before there is a concurrency issue. (please correct me if I'm wrong.

Also, in saying all of that. I've started the framework for the next game which will be written in php and I'll find a host that provides a decent concurrent connection level. It won't we downloadable like the last one however.

I got a simple question : If the game is to be download, is it take more server resources or less ?? If it's less why not make the game to be play offline ??

jfrancois323 wrote:I got a simple question : If the game is to be download, is it take more server resources or less ?? If it's less why not make the game to be play offline ??

@jfrancois , downloading a game uses less bandwidth ''server resources '' ex; replaying a game for different endings or replaying at a later day etc.. will load much faster without Internet usage !

Rikwar wrote:@jfrancois , downloading a game uses less bandwidth ''server resources '' ex; replaying a game for different endings or replaying at a later day etc.. will load much faster without Internet usage !

And always available, due to the missing server side ...

So, why a programmer choose to make it available online only, if he could save resources and eventually money (from the hosting fee) ???

Especially, because there's always someone to get it & put it somewhere else to be downloaded !!

jfrancois323 wrote:So, why a programmer choose to make it available online only, if he could save resources and eventually money (from the hosting fee) ???

Especially, because there's always someone to get it & put it somewhere else to be downloaded !!

I was really aware of these constraints as the only funds available have come from donations (Thank you to all those who have helped) . Long term, a downloadable game causes more problems than solutions. A web-based game means web traffic which can be monitised eventually, it is also easier to fix a web based game as there is only one lot of code. As soon as it is downloaded, each person who has a problem needs a patch... and needs to know how to patch which seems simple but some people have downloaded the game and don't know what to do. (I took it for granted that the would open the unzipped folder and open index.HTML).

In a nutshell, I think the potential for generating income is reduced more than the savings that could be had.

I'd also add the intellectual property argument here if there was anything to protect but the game is pretty basic.

sportd wrote:Yes failed downloads are an issue. As it's written as one page, if a download fails, the image isn't shown and gameplay is negatively impacted.

My current host allows 200 concurrent connections and my understanding is:

A normal html page uses a seperate http request for each image on the page plus another request for the page (html file) itself...plus more for each external js / stylesheet. On a serverside game, the first page would be the same as clientside (probably 10-15 images, stylesheets etc...). they would be cached and then for server side game, each following page would require minimum 2 http requests where as the javascript page only requires one new request (to get new image).

If your host supports it, HTTP Pipelining and SPDY both allow multiple transactions to be passed through a single connection, allowing the full 200 concurrent users regardless of how many items were being loaded. You mentioned AJAX, which could be used to retry page loads in the background should it fail the first time.

Have you checked for bot activity? I see several dozen independent bots daily spidering through one of the websites I manage, and there's usually at least five active at any given time. Many obey the 'robots.txt' files, but many more outright ignore it. I'm sure it can't be a good thing for bots to regularly trawl through the hundreds of megabytes of images in one of these games. Perhaps some basic user agent blacklisting could help? You could return a 204 or 403 code when any tries to access the internals of the game.

sportd wrote:

jfrancois323 wrote:So, why a programmer choose to make it available online only, if he could save resources and eventually money (from the hosting fee) ???

Especially, because there's always someone to get it & put it somewhere else to be downloaded !!

I was really aware of these constraints as the only funds available have come from donations (Thank you to all those who have helped) . Long term, a downloadable game causes more problems than solutions. A web-based game means web traffic which can be monitised eventually, it is also easier to fix a web based game as there is only one lot of code. As soon as it is downloaded, each person who has a problem needs a patch... and needs to know how to patch which seems simple but some people have downloaded the game and don't know what to do. (I took it for granted that the would open the unzipped folder and open index.HTML).

In a nutshell, I think the potential for generating income is reduced more than the savings that could be had.

I'd also add the intellectual property argument here if there was anything to protect but the game is pretty basic.

Maybe the solution could be to allows download after you're sure that the game has no more major bugs. If you mark down the change, people could choose if they download the new version or not ??

Just throwing this out there...

I downloaded this game when it was available and played through it a few times. I really liked it. When the new version was put up without the download option, I attempted to play the game and was discouraged by the long load times and occasional missing pages. Also, I use ad-blocker on random sites, so if I was even able to play the game, you wouldn't receive ad impressions anyway. It seems like you would best be served by offering both. One group of people would get you referrals from download sites and one group would give you ad impressions because they would play the game on the site.

I understand the concerns about filesharing...but that's an issue that multi-billion dollar corporations haven't been able to fix yet, so you're not affecting any changes there. I haven't attempted this, but I imagine your game can be ripped pretty easily, considering similar, actual monetized games have been ripped, so you probably don't have ultimate control over your site/game anyway. Eventually, this game will probably end up on a random sharing site anyway and you'll miss out on referrals and ad impressions both anyway.

In summation, it's your choice, but as far as I'm concerned, you lost a 'customer' when you turned off the download ability. I won't play your game, give you ad impressions, or referral points/whatever because I'm unable to play the game properly through your site, and there is no alternate download site, so you lose on any cash associated with that.

Sorry for the late response, i'm realtivly new to this forum.

A while ago i launched a tool to create HTML Adventure games like "The Gym".
The tool is called "Web Based Adventure (WBA)" and is totally free to use and even modify to your own needs.

I'm actually terrible in promoting it, but it seems to fit your concurrent connections need.
With the first pageload, it loads a HTML, 2 css (default and your own custom) files and 3 javascript files (the engine, your game logic, some custom logic).
From that moment it only loads the images.
So in terms of concurrent connections this is probably the least expensive way.

The WBA is very usable in its current state, and features are constantly added.
Ill be even willing to build features on request.