NodeJS: Virtual Game World Framework

I'm a rank hack at Javascript so I can't critique your code, but I did have some comments on the concept.

It seems to me from the basis you've put down and the description that you've actually got some gaps in your picture of how large-scale multiplayer games work. For instance, I see no evidence that this infrastructure could scale to more than a couple of dozen connected clients. Even running atop Node.JS is not sufficient to magically give you scalability.

I see nothing about how you intend to persist game state in a stable fashion, aside from some mentions of MongoDB. It occurs to me that you're inviting a lot of pain when it comes to transaction atomicity and idempotence, which are vital concepts in building distributed systems.

As a very high-level concept it sounds kind of neat, but as I'm sure you're beginning to discover, this is not something for one person to tackle on their own. You're talking about making a lot of radical changes to the way large-scale multiplayer games are traditionally built, without expressing any consideration for why games are built that way to begin with. This makes me uncertain about how successful the project can be.

For instance, you mention making a tradeoff between code cleanliness and efficiency - this is a non-starter in a scalable distributed system like you have designed. Either you need to have many truly-parallel instances of your software that can horizontally scale, or you need to squeeze your vertical scaling for all it's worth. Either way, monolithic servers and unoptimized code combine to form ouch.

Despite the ambitious scope of your ideas and your current flaws in realizing it, I think it's worth exploring, if for nothing else than as a great exercise in building robust, scalable systems.

...without expressing any consideration for why games are built that way to begin with...

Despite the ambitious scope of your ideas and your current flaws in realizing it, I think it's worth exploring, if for nothing else than as a great exercise in building robust, scalable systems.

There is no lack of virtual game world system that are already robust and scalable. So I have no interest in achieving that. The project is currently small scale and has no need for this.

However, I did say why games are built the way they are. It is because the current trend is taking old single-player games, and making them into multi-player games. That's how they mostly feel, too. Like playing a single-player game, surrounded by lots of other single-players.

The purpose of this project is making a game that puts emphasis on player-to-player interaction in the virtual world, online. Does it have to be massive? No. It does, however, have to present players with a world that is full of unique possibilities. Unique, in the sense that the content feels alive and intricate.

By giving the users the tools to influence the world, such as toggling MOB and NPC AI's from the client, it is possible to make such a world. I have seen this work, in small scale, in other games. Wherever game dev's build the tools for the players to use, the results are interesting and fun, instead of repetitive and unoriginal.

I think it's time to make such a world framework that goes all the way, having such tools as part of its' basic structure, instead of as add-ons.

I do thank you for showing interest in this project, and hope that more people show their interests, as well.

However, I did say why games are built the way they are. It is because the current trend is taking old single-player games, and making them into multi-player games. That's how they mostly feel, too. Like playing a single-player game, surrounded by lots of other single-players.

I think your fundamental premise is utterly wrong.

What kinds of games are you talking about? Give examples. Name names. I can offer any number of multiplayer games that feel nothing like single player games, and do none of the things you're attempting.


I also feel like your approach is going to collapse under its own weight if you're already shunning the idea of operational efficiency and robustness. Even games with only 30 players in a world can suffer from badly engineered code.

I think your fundamental premise is utterly wrong.

If you disagree with the emotion behind this project, then it is not for you. I don't appreciate having my feelings disputed, simply because you don't feel the same.

If you disagree with the logic behind this project, at its' current state, then you are welcome to become an active developer. I am not the "abstract complaint" department.

I am happy to clarify. Now...

I welcome any interested developers to contact me, or comment here, and join me in working on this, so that this unique project can reach its' intended goals.

I hope you are also implementing socket.io and Express.js ... kinda need them

Um, his opinion has nothing to do with emotion and neither should your central premise. You stated most multiplayer games are based on taking single-player games and adding multiplayer, and he disputed that. This is not a vague, unanswerable question based on your feelings, it is provable fact one way or the other - either you are right or you are not.

If you start whining about your feelings the moment a well-respected member of a game-development community offers constructive criticism, that's a bigger problem though. You're going to have to be able to defend and explain your project without getting defensive. Asking people on a forum not to post if they don't agree with you is just silly, and using progressively bigger fonts to try and convince people is just going to annoy everyone.

If this is a serious project, present it like one.

I hope you are also implementing socket.io and Express.js ... kinda need them

I am, naturally. server.js shows this explicitly.

Um, his opinion has nothing to do with emotion and neither should your central premise.

I suspect that this argument comes down to "moderator versus random guy", so I don't expect to get a lot of fans out of this.

I do stand for my views, though. My premise is not wrong, because it is subjective. We have no scale in which we measure how single-or-multi a game is. Any person who feels that multiplayer games are not too "singleplayer" oriented, would have no personal interest in this project.

By making this project, I need not prove my bias; rather only show the differences.

This is a serious project. It is so, for me. Actions speak the truth; and the code is my action.

I am almost done having a more representable version running live on OpenShift, so bare with me, and notice future updates in the first post (link to first post in this thread)!

Enough with the big fonts.

Saying it in bigger writing doesn't make it more important or get you taken more seriously. It's not the etiquette on these boards and will just annoy people before they even get to read it!

Live version now available on:

game.AssafKoss.com

This is a developers-only version, not meant for actual usage, but only for testing purposes and fun. You will notice that it looks like a chat room, mostly. I use it for live testing, even though it takes a minute more, doing the 'git push' every time. I don't mind, and this way, everybody can see (and suffer) changes, as they come.

I do stand for my views, though. My premise is not wrong, because it is subjective. We have no scale in which we measure how single-or-multi a game is. Any person who feels that multiplayer games are not too "singleplayer" oriented, would have no personal interest in this project.

So by your own admission, your original statement is meaningless.

I have returned to update the first post with relevant project updates. Lots of changes for the benefit of client-sided people! Scroll up!

As per the continuing conversation about the usefulness of Node World...

So by your own admission, your original statement is meaningless.

Just because only I find this project useful and meaningful, and only some others may think and feel the same, does not mean that it is useless. Subjectivity has its' place in the entertainment and education world.

Maybe a better approach to this topic would be by selecting the major downfalls of modern online virtual game-worlds, and then seeing how Node World can respond with possible solutions. Do excuse me for speaking in present-tense, while the project is hardly in alpha stage.

The Issue With MMO's & Node World's Response

ISSUE:

The modification and alteration of virtual game-worlds is currently limited by the constant need of managing 2D or 3D graphics, even before the actual representation of objects is relevant.

RESPONSE:

Node World seamlessly integrates different clients into the same world, in such a way that modifications can occur in real-time and without graphical input, but still exist, and be available for testing and conceptualization. Going even further, Node World can borrow from other existing graphical elements, and use their properties as a template for new additions.

ISSUE:

Content, interactions, and events can only be managed by the developers, or in rare cases - a select few moderators, which limits the "developers to players" ratio. It is common to have only a handful of developers maintaining an entire game-world, for hundreds, if not thousands of players.

RESPONSE:

Node World modulates and abstracts this hierarchy of content & functionality management. While it is still true that for many things, actual coding by reliable developers must take place, there is now the possibility of creating, destroying, modifying, and toggling the game-world's content, by the players, and without modifications to the code base.

In practice, players that have proven themselves reliable to the developers, can gain Master, or even Builder status. With that status, they can now freely modify the world's content, under the watchful, and mostly automatic, eye of their superiors. In short: User -> Player (registered) -> Master -> Builder -> God (generally developers.)

Masters can do minor tweaking work, such as making the world's content seem more individual and unique. Each part with slight changes that make a difference to the players.

Builders can even destroy existing content, thus making the world feel actual and imminent. Builders may create new content, by relying on the very basic templates the developers make. This removes a load off the hands of the developers, while letting actual players make meaningful changes to the game-world. A Builder may summon ingenious creations into existence, and then only need let the Masters put their hands into work, modifying and tweaking, so as to breathe life into those creations.

ISSUE:
Modern games either require the use of an existing graphical, and even gameplay engine, or the creation of one, for a new game. This adds work for indie developers, where solutions have already been made, but have either not been made available, or are not practical, due to each engine's specific limitations. The game engine market itself is a factor, for the indie developer.

RESPONSE:

By utilizing the power of NodeJS, Node World makes itself hospitable to all modern browser libraries, for the client's presentation and functionality. While a Node World client can be made with any compatible programming language and library that support Socket Networking, it is the fact that new technologies are developed daily, openly, and freely, in the browser application market. For example, a client may utilize the power of a WebGL graphics engine, or enjoy the comforts and simplistic animations of jQuery.

ISSUE:

Very few games actually let the player run their own virtual game-world, or an extension thereof, without the game itself becoming outdated or unsupported by its' own developers. This causes stagnancy and repetitiveness in most MMO's, both in the community, and in the gameplay itself. A game-world will, at most, offer different servers, which function as load-management, more than anything useful to the players.

RESPONSE:

Node World is extremely flexible, drawing from NodeJS, Javascript, WebSockets, and modern Databases, such as MongoDB. A Node World game-world can be infinitely stretched, divided, and combined. The sheer amount of abstraction in the server code goes all the way to allow this. Unlike common server code, which is made to be functional, and must not be touched by amateurs, the Node World server code expects amateurs to tweak it, edit it, remove parts, and add completely new parts to it. It does this, by keeping functionality not only relatively abstract, but by adding guards against mismatching arguments ahead of time - and relying on fallbacks, and by modulating its' own parts, as much as logically possible.

Node World, as a project, is aimed at modification. Even if it means less functionality, more unexpected results (bugs) to handle, and a harder time on client developers. Even if it means that, for a while, Node World will not be able to handle everything we have grown to expect of modern MMO's. This is to ensure that content and gameplay remain the two leading factors in Node World development.

There is doubtless more to clarify in regards to Node World, and the ideology behind this project. Naturally, the difference between ideas and practice is vast, which is why I prefer to keep my attention on the code and testing. If it turns out that Node World could only produce very limited results, well then, I would be proud to see an indie project "that could", by trying - as Monty Python put it - "something completely different."