Indie-Resource.com

So I'm looking into making a web rpg cause I've got a lot of free time here in tech school for the air force. And I want to make it more graphic than my last one so I'm moving away from php. I've been using python a lot recently and have been enjoying it but I hear JS, node and webgl are also great for it. Any suggestions from you guys? The game is going to be final fantasyish btw.

JS

Alright Halls lol could you explain why a little better? instead of a bunch of faces lol

Keep in mind that the back-end doesn't directly affect how graphical the game can be, only how you can communicate with the back-end. This can have an indirect effect, however, because if you don't have the ability to perform server push (which PHP does not really do well), it can be difficult to achieve an animated online game, such as one where you can see the other characters running around, attack them in real-time, etc. If that is the kind of game you want to make, then Node.js is the best option since real-time networking is so easy with node and Socket.io.

However, making a game that is "more graphical" doesn't really even begin with the back-end. You need to decide on how you are going to support a graphical UI on the client. This can be with Unity, Canvas + JS, or WebGL. However, even with Halls' experiments, I am not convinced WebGL is ready for show time. It isn't so much WebGL itself, but browsers getting better hardware acceleration. WebGL apps run good in Chrome, but complex games begin to clog up in other browsers pretty fast. Mobile is totally out. I think the best option for part-time working on a real-time graphical web game would be Canvas, with or without a game engine.

So JS, node, socket.io and canvas. Any direction you can point me for setting up a testing environment for this? And I know we have a ton of tuts for using it here on the site so I'm not gonna ask about that.

On the server side, your choice of Python or JS is a chocolate vs. vanilla thing and will likely be influenced by which language you prefer. Node.js is pretty cool and has lots and lots of modules, allowing you to get started quickly, but... and this is a big but... it uses a design pattern called a reactor. The reactor is a methodology of doing things concurrently (such a handling client connections in the case of node), while running in a single thread. Its premise is that the creation and teardown of threads is expensive and therefore, multithreaded handlers are not web scale. ( ) The problem with this approach is that as your app becomes complex, it descends into "callback hell" and becomes difficult to debug.

Plus, there is nothing stopping you from building a hybrid. On Magicus Occultus, I use Angela, which is a threaded, rules processing engine, written in Python. I've added a web server to it (using Whizzy.web) to give it a REST interface, but that interface is not intended to be exposed to the world. I'm going to put node.js in front of it, to handle user commands, authentication and translate user commands into something that can be handed over to Angela's REST interface.

if the doesnt get you then nothing will

You can use WAMP as you normally would to run JS and even nodejs. NodeJs does have a web server but I do not recommend using it that way in the beginning. You learn much faster using it as a backend server only.

Run through my nodejs tutorials. Really though start with JS then branch out.

hallsofvallhalla wrote:if the doesnt get you then nothing will

You can use WAMP as you normally would to run JS and even nodejs. NodeJs does have a web server but I do not recommend using it that way in the beginning. You learn much faster using it as a backend server only.

Run through my nodejs tutorials. Really though start with JS then branch out.

I actually have to kind of disagree with this. I think learning Express is a great first step with node and teaches you a ton of the basic concepts of node, and then starting a web server in node is a snap!

And Cayle, it isn't so much that threading is not "web scale", since Apache, IIS and countless others have proven it is. It is more about the fact that dealing with threads is a headache, and they are very difficult to debug. A synchronization bug may occur only once every 100 executions, it may occur a little differently each time, or perhaps even just when another multithreaded piece of software is running, and all because the OS thread scheduler takes that all out of your hands. The asynchronous solution works because the only reason threading is needed for a socket server is because networking is so slow, and the communication is blocking. If you make communication not block, then suddenly one thread can quite easily handle thousands of concurrent connections.

The basic way of handling asynchronous programming with callbacks can get a bit rough, but for me it is nowhere near as confusing as dealing with threading, atomicity, synchronization, locking, semaphores, etc. But callback chaining is just the most simple method of programming in node. There are other patterns and libraries which can be used for more structure.

Awesome guys Thanks so much, I went and picked up "JavaScript and jQuery The Missing Manual 2nd Edition" for a refresher and also picked up "Node.js in Action by Cantelon, Harter" to get started with node. Gonna wait on starting canvas until I'm comfortable with js and node with socket.io.

Sounds good! I bet you will get as excited as I did when you begin to look into node and Socket.io. It was like suddenly I found the key that unlocked all of the web game ideas I always wanted to do but couldn't due to technological limitations.