WEBGL MMO is the idea, but...

[tourmaline]

Hello,

I picked this forums up from somewhere else. Thought I would ask my same old question, with the possibility of a new perspective for an answer.

Yes, WEBGL/MMO. Problem is, what language? For what I want to do, C++ would make a good backend. Plus, I'm not crazy about the idea of JS through-and-through, no matter how you sell it. Node/js looks nice, but I want the server side process to be tight.

I could probably code all the logic and test it in a console window, but part of the concept will be space like and 3d, with some orbit calculations and other various math. So having a crude visual in WEBGL to interact with would be fantastic. If my game ever becomes awesome, I'll hire art/graphic support. I am more interested right now in the network and database portion of the project, but I will still need to spend some time on that crude visual as I move along.

I've looked at many many libraries. The more options I see, the longer it is going to be before I write any code. I'm starting to get extremely frustrated, not having at least a rough path to start doing some code. I have database schemas, I have game mechanic notes; I'd like to write some code.

Again, WEBGL is the ultimate outcome, but with the current opinion on its maturity, what should I grab to get started? Should take the long road and get going with C++/ SMFL, or go node.js and maybe do a native plugin if I become so inclined, then rewrite for a WEBGL client if WEBGL is still relevant after a time? Should I grab a basic network IO/HTTP library in C++, work the database into the mix and see what's changed in a year? Duetto? Minko? CopperLicht? Wt, Poco, straight up Boost?

cpp-netlib and mysql++ looks like a nice match to my start goals, but it's probably a longer road starting there, and no socket support. But node.js and a later decision to move some things to native C++ could be even longer.

The options are becoming insurmountable and I'm about ready to just turn around and walk away. The initial environment choice will play a big part of success/failure, or even the longevity to stick to the project.

This decision process has been going on long enough to have actually built and released a simple game in the time passed.


Any encouraging thoughts?

[Jackolantern]

I haven't messed around with WebGL much myself. The admin of this site, Hallsofvallhalla has much more experience with it, and has a demo or two from playing around with Babylon.js which he really liked. I remember asking him about CopperLicht, and he didn't like it, but I can't remember exactly why nor can I find the conversation. I know it had to do with the editors.

As for the server-side, if you are very familiar with multithreaded socket servers in C++ and have written a couple, I would say go that route. It will obviously be blazing fast, and has decades of libraries, help resources, etc.

However, if you would be starting from about the same amount of experience whether you go with node or a multithreaded language, go node. It can massively cut down development time and debugging time because asynchronous programming is just more simple and less error-prone than multithreading. Plus, Socket.io is amazing. If you decide to roll your own server in C++, you will have to implement your own websocket fall-back strategy. Websockets themselves just aren't ubiquitous enough today to rely on them 100%. Socket.io will first try to connect with websockets, and then will fall back to an invisible Flash app for socket connections, then through several Comet techniques. Basically, you can get a real-time connection on just about 95%+ browsers. It may be less of an issue since your game will require WebGL for its basic functions, but it is probably still good to have this effortlessly handled for you.

Node is also amazingly fast. Of course not as fast as an expertly-tuned C++ socket server, but many tests have shown it to smoke Java multithreaded socket servers. So don't worry that it won't be fast enough, as it could probably comfortably handle 1000 concurrent users per process (depending on your code obviously).

There is also the option to use a commercial MMORPG server solution. That could possibly save you a huge amount of time in a project that is already pretty massive (any MMORPG) and get you off the ground faster. These include Photon Server (.NET if I remember right), ElectroServer (Java), or SmartFox Server (Java). Commercial MMOs have been built with all of them, as far as I know. And each of them likely has a man decade or more of work in them already.

[tourmaline]

Thank you Jackolantern.

I suppose learning node.js and socket.io couldn't hurt - as it is quite popular at the moment, and it would get me to a visual concept much quicker. I do fear that I could get lost in one component long enough to kill overall interest, by going harder native route.

My background is many years in webdev with the holy trinity (apache/php/mysql), and I've come a long way with the database end in general. But looking back on the best things I've done using PHP, it's really all garbage. PHP great for the speedy development time when under the gun, but in the end, it's almost embarrassing looking back at the overall mess. I want this project to be solid in structure, which is why I'm gravitating to at least some C++. I suppose that overall, C++ would play a very small role in a project with a WEBGL target.

I do want some solid interfaces though, and from what I've read about node, it seems more procedural. I want to use classes and all the goodness that comes with them.

Another thing is I have VPS dev environment, so I can connect and work from anywhere with minimal client side requirements, but node.js fits fine there.

I should reduce to my top 6 path choices and roll a die...

[Jackolantern]

My background is many years in webdev with the holy trinity (apache/php/mysql), and I've come a long way with the database end in general. But looking back on the best things I've done using PHP, it's really all garbage.

While I totally understand the desire for more structure, don't call everything you did in the past garbage! We all wrote basically structure-less PHP apps for years because there really wasn't a better way. It is just now really becoming accepted that PHP frameworks are required for the structure of maintainable applications.

PHP great for the speedy development time when under the gun, but in the end, it's almost embarrassing looking back at the overall mess. I want this project to be solid in structure, which is why I'm gravitating to at least some C++. I suppose that overall, C++ would play a very small role in a project with a WEBGL target.

If you do go node, I am sure you will be amazed by how fast you can get results. However, without reviewing some other, large node projects first, it can be easy to not follow solid structuring. That was the downfall of my first project with node, which was going to be a text-based MUD. Be sure you are familiar with and comfortable with the node module pattern, because that is really the best way to break up node code into a structure. You can simulate classical OO classes pretty well with modules. That is where my first node project fell short (well, that and an incredibly messy client-side codebase and poor data access schemes), because I didn't use enough modules, and didn't use them logically when I did, until it was too late. I should have planned more. I was really just toying around, learning node and Socket.io when suddenly I realized I had everything I needed for a MUD, got excited and just jumped into coding. Bad idea lol.

I do want some solid interfaces though, and from what I've read about node, it seems more procedural. I want to use classes and all the goodness that comes with them.

Just like regular, browser-side JS, Javascript is OO, but in a different way. Node is just Javascript with some nonblocking I/O built on top of it. Since node is just regular Javascript, many of the object oriented libraries and tools for JS have been ported out of the browser to node, and many more have been written from scratch for it. I haven't used them myself so I can't give too much in the way of suggestions, but I know every other week or so I will come across a library that wraps Javascript's prototype-based object system and offers more of a traditional class-based approach. Maybe try out some of those and see what you think. But still get to know node's module system and how to write them, because you can really make those almost like classes. Also check out Express.js for serving webpages. With Express, the app.js file is almost like your main() function, and then you can build out specific functionality as either node modules or JS objects. It really can be quite OO

I should reduce to my top 6 path choices and roll a die...

LOL I have felt like that before! Just take a little breather from your project, and try out node. Write a browser-based chat room with node and Socket.io. See if you like it. I loved it, but I can't pretend like it is for everyone and all projects. If you like the feel of it and the results you are getting, consider writing something a bit bigger with it. If that works out, I would say move ahead with it for your main project. If at any point you don't, just dig in with C++.

[tourmaline]

Thanks Jackolantern,

I think I will dig into node for a bit. With it's current popularity, it's probably a safe bet to spend some time with it. And if node-gyp hangs around for awhile, I can build some bits in C++ and have an abstraction of sorts if the current JS trend changes over the course of my project.

I am certainly interested in the socket.io portion, as it sounds like it will remove a ton of work.

This site is great. Lot's of fresh perspective, instead of the old "you'll never do it, it's too hard!".

Thanks again,

[Jackolantern]

No problem! I don't see native C/C++ node extensions going anywhere anytime soon. That is how node was created in the first place

And yeah, this community and its predecessor were basically created as a reaction to the hate that gets spewed anytime someone says "MMORPG" in a game developer forum lol. The sheer number of indie MMOs out there now, both traditional and browser-based, you would think would start to change minds, but it is a slow process. The best thing we can do until then is just enjoy our corner of the web, and work on our games that will prove them wrong

EDIT: Oh, and definitely check out Express.js when you try out node and Socket.io. Some tutorials will have you build up the whole web server yourself, which is really ridiculous, as no one does that in practice. Express is a nice lightweight web server/web framework (that really just feels like a framework; you don't really feel the server). If you are used to more full-featured MVC frameworks from PHP, there are other more full-featured node frameworks like Sails.js. But Express is probably the best one to start with. Almost all the other frameworks are really forks of Express anyway. Plus it is dead-simple, easy to learn to use in a day, and works pretty well with Socket.io.

EDIT2: Another edit lol. Speaking of proving them wrong, you should check out "Cubicverse" by our esteemed member, Alain (a_bertrand). He has made all of that by himself, using Canvas, 3D modeling tools, node and Socket.io. It totally can be done!

[a_bertrand]

There is a new option: Unity 5 which will soon come out. It exports to WebGL too.

[tourmaline]

I don't think Unity is the road I want to travel, although I should keep watching it; and thank you for pointing that out. That is a big addition for Unity.

Also, regarding node.js and accessories: I was reading about the package manager, and I'm wondering if there is any benefit in building node.js components (express, or various whatever) from source? Most of the time I build latest versions of what I need from source, but node.js seems different altogether, Since it's not repository specific like various linux distros, the update/upgrade command should get you to the latest stable of every piece of your node install?

[Jackolantern]

Yes, when you just use "npm install socket.io", for example, you will always get the latest stable release. Inside your project, if you have a package.json file, you can change what version you want there if you don't want to use the most current version (this must be added in yourself, because the version listed there by default is the minimum version), and npm will install the correct version automatically.

Building from source is really only apt for node.js itself (and possibly MongoDB if you use that for your database), because it is the only real piece of the stack that is compiled. The rest is mostly JS, so technically the source is what npm is grabbing for you, putting in the correct folders and adding to your package.json file. If you needed a bleeding-edge nightly build of a major component, you could download the source and set it all up yourself (that was what Windows node devs had to do for a while before npm was ported). But I think there is a way to do that through npm, too. npm just rocks lol

EDIT: Oh, and as far as staying up-to-date, provided you have a package.json file in your project, if you just use the command "npm update", npm will update all of your packages to the latest stable release, and install any packages that are missing that your package.json file list as a dependency. npm really makes package management easy!