Architecture Discussion

The development stack used is Node.js, WebSockets (with Socket.io), and HTML5 canvas. Express was used, but really only to serve the initial page and its assets.

Architecture Pros

1. Since both the back and front end were written in JavaScript, it was nice to use a single language throughout the development process.
2. Development was very quick and easy since we did not have to worry about types, and were using a very flexible language.
3. Development was fast since the technology stack was lightweight. Things like building the project and starting/stopping the server did not hinder the development process.
4. Since everything in Node runs on one thread, we did not have to worry at all about synchronization issues. For example, we didn't have to worry about one part of code updating the user's position while another was reading it. Again, this made getting the project up and running relatively hassle free.

Architecture Cons

1. Hard to develop good design because you aren’t forced to think about it. In other words it is hard to make reusable, interchangeable code in the traditional object oriented sense. This leads to a project that easily lets in cluttered code that "just works" but isn't easy to maintain.
2. Lots of helpful IDE tools not available, because of the dynamic nature of JavaScript, simple refactoring options and autocomplete things were not as helpful as they would be in a language like Java. (It is possible I just don't know how to use them)
3. Node's single thread of execution makes scaling up nearly impossible. The rest of this page will be dedicated to discussing this single limiting factor.

Lets review quickly how Node's runtime works. (In a very rough sense, but it gets the point across)

Node works a little bit like your browser. Function calls and events are put into a single queue, and Node's processing loop takes a single item off at a time and runs it. Where Node thrives is when these tasks in the queue can be handed off and run in the background asynchronously. An example would be an HTTP request for a large file. Node gets the request and hands off the task to an OS thread, then picks up the next item in the queue. When the OS is done getting the file, it puts a task into the queue that Node can later pick up and run to actually give the file to the client.

If you read much online about Node, you will read that it is not good for CPU intensive tasks. What happens is that when the number of connected users gets high, the server's game loops become CPU intensive tasks. This essentially bogs everything down. A single thread of a CPU simply can only do so much. In my opinion, this makes Node unfit to be a back-end for most simple multiplayer games.