The idea of having a game run in a web server, and have a bunch of clients connect to it sounds doable, but if you've never made a game before, this has a HUGE scope, even just making a working prototype of such a thing. Making a game is hard to begin with, but multiplayer and client/server setups make it a whole lot more complicated.

I'd have some questions-

If the simulation is happening in one place (you said your computer, but lets say it could be hosted anywhere), then why do the clients also need to be running their own servers? If you're going to require each client to run something natively to begin with, why not either just make the whole client a native app, OR just do the whole client in the browser and eliminate the need for the other part?

Similarly, why the need for the huge memory requirement on the client? IMO, your server should be doing 90% of the simulation work, and the client only needs to do enough simulation of its own to maintain the illusion. If your rendering is something simple, and you're only showing a small part of the simulation at a time, then your client should be relatively lightweight I would think.

I do like the idea, and I've had a similar idea of my own that I wanted to try out a while ago. It's a huge undertaking though.

I'd have some questions-

If the simulation is happening in one place (you said your computer, but lets say it could be hosted anywhere), then why do the clients also need to be running their own servers? If you're going to require each client to run something natively to begin with, why not either just make the whole client a native app, OR just do the whole client in the browser and eliminate the need for the other part?

the way I have things set up right now I would need to allocate as much processing power to rendering the content of the game via the browser. webGL doesn't utilize the GPU like DirectX or Opengl 3.0, but rather relies on the CPU to do most of the work. If I'm correct, it's up to the browser to offload a certain portion of the computing to the GPU, but even then it's limited. Now I need to have a few support client side servers to offload some of the simulation work load. Chrome will only allow up to 1.5 gbs of memory for one tab, and the processing power is maybe limited to 15% - 20% of my CPU's full capacity, thus the browser has limited access to system resources. So I figured I could get a couple node servers running to help with some of the computations needed and then the browser can handle only what is being seen. I'd also need a server responsible for synchronizing the clients current time tick with the main server. The main server would be processing all game logic for the simulation.

just make the whole client a native app?, that's a good question. I think the reason why I'm using three.js and node.js is because I can easily develop for the two. And because they are javascript based it will be really easy to give those files to the end user.

Similarly, why the need for the huge memory requirement on the client? IMO, your server should be doing 90% of the simulation work, and the client only needs to do enough simulation of its own to maintain the illusion. If your rendering is something simple, and you're only showing a small part of the simulation at a time, then your client should be relatively lightweight I would think.

Yeah, I suppose this boils down to how I've gone about programming the world. I wanted the user to be able to scroll around the world rather quickly without frame-rate loss. I think right now you can zoom around the world in any direction in less then 2 seconds, so all that world data is buffered into memory which is why it takes up so much, then only a portion of what is buffered is presented, otherwise the frame rate would drop. I definitely think there are better ways to achieve a similar result. I've toyed with the idea of procedural generation, but even then my solution requires a certain amount of buffered data.

I do like the idea, and I've had a similar idea of my own that I wanted to try out a while ago. It's a huge undertaking though.

I'm happy to hear you too have had a similar idea and also see it's merit. I guess right now I'm debating if I should continue working with the existing technology I have, or if I should learn a more powerful language along with some better techniques and come to the point I'm at now with perhaps more horse power under the hood.

To me it seems an odd strategy to want to make a game that requires a moderately powerful gaming computer, does not use the video card, and also is web based.

These three things are all at odds with each other. Usually web games benefit from having low graphical requirements, runescape kinda pioneered that point, they got far more players than most desktop client based games simply because it was so easy to run.

Not to mention if you require such a powerful computer then its a little nonsensible to not be using the video card to full potential, in fact I'd say people with gaming computers tend to gravitate towards desktop style games like stuff available on steam a lot more than they would web based games. Sort of alienating your own audience.

Also not to be rude but I'm rather skeptical you even have the ability to make such a product based on how unsure you seem of each of your own requirements or even if they're the best way to do things. If I see people post 10k game ideas on here a year I doubt more than two of them even get past the prototype stage usually.

To me it seems an odd strategy to want to make a game that requires a moderately powerful gaming computer, does not use the video card, and also is web based.

These three things are all at odds with each other. Usually web games benefit from having low graphical requirements, runescape kinda pioneered that point, they got far more players than most desktop client based games simply because it was so easy to run.

Not to mention if you require such a powerful computer then its a little nonsensible to not be using the video card to full potential, in fact I'd say people with gaming computers tend to gravitate towards desktop style games like stuff available on steam a lot more than they would web based games. Sort of alienating your own audience.

Oh man, fantastic observation. I never even thought about the conflict there. Totally makes sense. It's because of points like yours that convince me of the doubts I've been having about my approach. I'm sort of torn as to what direction to take. abandoning the project is a non-option, but learning more stuff, possibly different languages or different approaches is more what I'm thinking of doing.

To go into a little more detail, I seemed to have maxed out the resources for my game at this stage using the current technology. On one hand I like the limits imposed by the browser because it teaches me to be more frugal with what memory and processing power I do have, my thinking is that if I can design the game within the tighter restrictions of a web browser I'd have more room for expansion on another platform at a later time.

The only reason why I'm using JavaScript is because I can program with it, I've proven to myself though working examples that all the aspects of this project are doable with the language and webGL.

Also not to be rude but I'm rather skeptical you even have the ability to make such a product based on how unsure you seem of each of your own requirements or even if they're the best way to do things. If I see people post 10k game ideas on here a year I doubt more than two of them even get past the prototype stage usually.

I hear you, and your scepticism is 100% valid. My concern isn't whether or not I will finish this working prototype, but rather will the prototype be some deformed monstrosity that completely loses the vision of what I'm going for. Case in point my Z-model program. I asked others to give it a spin and the second person to try it out had difficulty making it work because like you said, I don't really know what I'm doing.

[ ------------------------------------------------------------------------------------------------ ]

I thought maybe I spoke to soon when I wrote about wanting to write my own webgl renderer. My heart was in the right place. I've been looking at custom shaders and this opens up whole new chapters in this projects look and development. A heavy dose of life and direction has been breathed into this game. I'm now looking towards a complete revamp of how it looks. Thinking of ditching the space look and focusing more on the planet.

the way I have things set up right now I would need to allocate as much processing power to rendering the content of the game via the browser. webGL doesn't utilize the GPU like DirectX or Opengl 3.0, but rather relies on the CPU to do most of the work. If I'm correct, it's up to the browser to offload a certain portion of the computing to the GPU, but even then it's limited. Now I need to have a few support client side servers to offload some of the simulation work load. Chrome will only allow up to 1.5 gbs of memory for one tab, and the processing power is maybe limited to 15% - 20% of my CPU's full capacity, thus the browser has limited access to system resources.

Whether or not WebGL really uses the GPU is dependent on the browser- my understanding (I could be wrong, don't quote me on this) is that at least Chrome and Firefox make some use of gpu acceleration for WebGL. I think I read somewhere that Chrome actually translates WebGL calls to DirectX9 or something weird like that. You're right that there are limitations involved when building games in a browser, but in an ideal scenario where the browser is only really acting as a client (not doing any more of the sim than necessary), then as long as your art/rendering style is reasonable you shouldn't need to "offload processing" to a bunch of other processes. Trying to delegate jobs like that might be the source of more problems than it solves.

I think it's worth asking whether or not you think your technical skills match the scope of the project- and I don't mean that as a put down. If you've never made/shipped a game, never made a renderer, are not very familiar with OpenGL/WebGL, not super familiar with web dev, etc., then a project of this scale is going to be next to impossible, in my opinion.

I'm not by any means suggesting you abandon the game or the idea, but maybe break it down into more manageable pieces that you can tackle one at a time, or reduce the scope to something that's not as far outside of your current understand of the technology involved.

This isn't the answer you're looking for, but I think you are getting ahead of yourself. You are attempting to discuss resource constraints and how to deal with them, but you don't have good data on what your game will require. For instance, how did you come up with 3 as your required number of servers (targeting 4 core CPUs?)? Do you really know how much memory this is going to take? Let alone CPU utilization? Most people don't know these things without programming and profiling.

I would also disagree that distributing your game will be a simple matter of handing js files to the end user. Does the end user know how to set up and configure Node? Are you going to have them install npm and then install and run all three web apps? Are you going to give them a script that will do this for them? If so, how does this differ appreciably (from the end-user's perspective) from just giving them an installer?

How is multiplayer going to work? Will one user host, and will that user's servers do all the work for all players? If so, have you worked out all of the complications involved with other users hitting resources on the host user's machine? Will this be done across the internet? Are there security issues involved?

This does not sound like the path of least resistance to me, but to each his/her own. My main concern with your plan is that you don't seem to have the programming chops yet. You will soon. I would definitely recommend that you start with a dead-simple game project that includes a subset of this functionality. Then, work on another game that is slightly more complicated and incorporates a wider subset of this functionality. Gain the experience slowly but surely, and you'll be successful (and you'll have a list of intermediary accomplishments as well).

but maybe break it down into more manageable pieces that you can tackle one at a time, or reduce the scope to something that's not as far outside of your current understand of the technology involved.

Good advice. Thank you.

@CDProp

how did you come up with 3 as your required number of servers (targeting 4 core CPUs?)? Do you really know how much memory this is going to take? Let alone CPU utilization? Most people don't know these things without programming and profiling.

I am able to get a gist of what system resources are required by taking a look at my system monitor, it tells me how much total CPU power is being used and about how much memory Chrome is using up to display the website. As for why 3 or 4 servers. Right now I have what I call "world geometry" divided into 3 categories, display low detail, display high detail and targeting. The display geometries are divided up into 68 chunks minimising draw calls to the renderer. The target geometry is a duplicate of the display geometry but is divided up into 272 chunks, it's purpose is to reduce total process time needed for raycasting calculations. Currently I have all 3 geometries buffered into memory within a Chrome Browser. What I want to do is create a dedicated node server that handles the target geometry exclusively. Then additionally another node server that handles pathfinding. The benefit of using node.js is that I can fork processes, I don't think JavaScript within the browser can, I could be wrong though. Finally I want another server that handles all user interaction requests and then relays relevant requests to the host computer. I'd develop the host server and run it on one of my machines. It would calculate the bulk-work of the simulation and game logic, then transmit location, path, game and content updates to all connected machines so that the connect users would be able to all interact with the same simulation.

Does the end user know how to set up and configure Node? Are you going to have them install npm and then install and run all three web apps? Are you going to give them a script that will do this for them? If so, how does this differ appreciably (from the end-user's perspective) from just giving them an installer?

So this is one of the questions I'm currently tackling. I have no idea really, which is worry-some. Similar to my Z-model program I just gave all the files and containing folder in zipped form to any one who was interested. I relied on their own knowledge of what to do to make it work. questions I have are would the end users trust an installer? What would be easiest given the technology I'm going to develop with? I don't assume you have the answers, but I'm glad you've asked them because I'm going to have to figure this stuff out. I'd also like to protect my code so that it's not extremely easy to duplicate what I've done, would node.js allow for an installer? I'll have to find out.

Will this be done across the internet? Are there security issues involved?

yes, I'll be using socket.io to communicate between the browser, local node servers and the host server. As for potential security holes, Here I need help. I need to figure out how to make communication channel secure to the user and the host computer. I'm not worried about cheaters, but I am potentially worried about unknown malicious behaviour that could affect players.

I would definitely recommend that you start with a dead-simple game project that includes a subset of this functionality. Then, work on another game that is slightly more complicated and incorporates a wider subset of this functionality. Gain the experience slowly but surely, and you'll be successful (and you'll have a list of intermediary accomplishments as well).

It's interesting. I remember attempting to program this concept back in 2008, I made it only so far with Visual Basic and I realised quickly the limitations of my coding and of the idea. I went back to the drawing board and came up with a new strategy to tackle the project. Then an old friend introduced me to WebGL and THREE.js. I fell in love and have been using the technology ever since. So far I've encountered no major road-blocks in the three years I've been steadily working towards this idea. Every 8 months or so I do a complete overhaul of my existing build and they keep getting better and better. But as of late I've come to see that I run the risk of creating something that is cumbersome for the end user. I figure if I can nip this questions in the butt now before I get to that point, I can avoid potential head-ache in the future.

CDProp, I really appreciate you're input over the last couple days, Cheers.

I am able to get a gist of what system resources are required by taking a look at my system monitor, it tells me how much total CPU power is being used and about how much memory Chrome is using up to display the website. As for why 3 or 4 servers. Right now I have what I call "world geometry" divided into 3 categories, display low detail, display high detail and targeting. The display geometries are divided up into 68 chunks minimising draw calls to the renderer. The target geometry is a duplicate of the display geometry but is divided up into 272 chunks, it's purpose is to reduce total process time needed for raycasting calculations. Currently I have all 3 geometries buffered into memory within a Chrome Browser.

You're going to want to step back and rethink this part. Using the system monitor to look at how much memory chrome is using is not going to reliably tell you anything about the overhead involved in running node instances. Node and Chrome are not the same application.

Also, loading the entirety of a game world into memory all at once for the entire runtime of the client is a probably a bad idea- this is what I meant when I said the client should only be doing as much as it needs to in order to keep up the illusion of the world. You absolutely want to break the world into chunks - but all of those chunks should not be in memory at once. You load what you need in time to use it, then unload what's no longer being used when you don't need it anymore. The specifics on how to implement that are too non-trivial to explain in a quick forum post, and they will depend heavily on the rest of the design of the world and the game.

@TedEH, thanks for the feedback, I appreciate it. I've been thinking about what you wrote. A requirement of this project is to be able to determine the paths taken for up to 10,000 AI. The strategy I've come up with to tackle this requirement I've buffered all world data and have successfully simulated 5000 AI on screen at the same time. But I've been thinking that I could instead buffer ~8% of the world and still achieve the same result.

I feel as though I'm way in over my head but... I just enjoy the process so much I'm just going to keep on plugging away.