Radical suggestion: Move to HTML5

[Olof]

Hello I have a very radical suggestion for you
HTML5 is the future. You should code the mana world completely in javascript instead.

It very much possible. Take a look at this simple example I coded:
http://game.sylt.nu/example/ <-- Look at this
Use scroll-wheel to zoom in and out, WASD or arrow keys to move. Also please use a browser with hardware acceleration like FF4 or IE9. Chrome is quiet slow as it does not hardware accelerate the canvas yet.

Reasons for it
- Cross compatibility. HTML5 games only depends on a web browser. The game would work on soooooo many platforms without additional work.
- No installation needed. The players would not have to download an installer etc. They could just go to the website and we host the game files for them.
- Much is coded for you already. It is very easy to code HTML5 games as you do it in a high level language. For example you need not maintain libraries to draw to the HTML5 canvas. The browser have taken care of that for you already.
- Non modern projects needs to me modernized, otherwise the die. IF hypotheticaly HTML5 is the future for 2d games THEN TMW project would die if not moving to the new technology.
- Easier to attract new developers. Javascript is an easy language. Many coders start learning through coding websites.

Reasons against it
- It would be a huge undertaking to port the code. Do you have the human resources to port it?

More details on technology
The server should be coded in javascript as well. For this we should use node js project:
http://nodejs.org/

Multiplayer support will need sockets. For this we should use the socket io project:
http://socket.io/

So... what are your thoughts on this? Count me in as a dev if you decide to code in javascript instead.

[Crush]

While the new possibilities of HTML5 (especially when using WebGL) are impressive, the Mana project is already in a too advanced state to start from scratch.

[Matt]

More details on technology
The server should be coded in javascript as well. For this we should use node js project:
http://nodejs.org/

LOL. Why o why.

[Olof]

More details on technology
The server should be coded in javascript as well. For this we should use node js project:
http://nodejs.org/

LOL. Why o why.

What an intelligent and constructive comment

Why should the server not be coded in js as well?
There are three "code-places": client, server and scripts. The project would be more understandable and easier to maintain if all of these three places used the same language. The server and client will also have some logic in common, for example due to client side prediction, and that logic could really be shared, be the same source files if the server and client where coded in the same language.

And most of the scripts are run server side right? Quests etc. Currently the home made EAthena scripting language is used. But that would not be necessary if the server were coded in js. Instead the quests could be scripted in js which would be better for sure as maintaing your own script interpreter is a big project just on it own.

[Olof]

While the new possibilities of HTML5 (especially when using WebGL) are impressive, the Mana project is already in a too advanced state to start from scratch.

I both understand and expected that opinion

[Crush]

I think the main reason which prevents HTML5 from being used for more elaborate games is that it is not possible to store a lot of data on the client.

Cookies can only store a few bytes and even the new DOM storage feature goes only up to about 5-10 MB, depending on the browser. When you need more space for game data (TMW currently has about 15 MB of game data without music, 3d games take several GB nowadays), you need to reload it from the web every session.

This means very long loading times (especially for people without broadband connections), high bandwidth usage for the server (which increases cost) and high bandwidth usage for the clients (which is bad for people on limited data plans).


Another shortcoming of HTML5/Javascript which makes it badly suited for real-time multiplayer games is its lack of a native socket API. Well, there is AJAX, but XMLHttpRequest has a lot of overhead and isn't optimized for low latency.

[Crush]

Why should the server not be coded in js as well?

Because that's not what Javascript was designed for.

Javascript was designed for little code snippets embedded in HTML to make websites more interactive. It was never intended to code a more complex application in it. Being forced to distribute it as sourcecode instead of more compact bytecode, being extremely weakly typed, having implicit variable declaration, being object-oriented without actually having classes or encapsulation, all these are things which are nice for small snippets but annoying when you are programming a larger application.

Unfortunately it is currently used a lot for that purpose because it being present in every browser makes it the only available choice for complex browser-based applications. But just because Javascript is currently the golden calf which is towed through the web development world, it doesn't mean that it has to be used for everything.

[Olof]

I think the main reason which prevents HTML5 from being used for more elaborate games is that it is not possible to store a lot of data on the client.

Cookies can only store a few bytes and even the new DOM storage feature goes only up to about 5-10 MB, depending on the browser. When you need more space for game data (TMW currently has about 15 MB of game data without music, 3d games take several GB nowadays), you need to reload it from the web every session.

This means very long loading times (especially for people without broadband connections), high bandwidth usage for the server (which increases cost) and high bandwidth usage for the clients (which is bad for people on limited data plans).


Another shortcoming of HTML5/Javascript which makes it badly suited for real-time multiplayer games is its lack of a native socket API. Well, there is AJAX, but XMLHttpRequest has a lot of overhead and isn't optimized for low latency. The socket IO library you mentioned would fix that, but it isn't part of the standard. This means it's exactly what you want to avoid with a HTML5 client: a platform-specific binary program the user has to download and install.

The saving of data on the client is not much of a problem. For "resources" like images or tmx files you can simply use the browser based cashe. It is a matter of sending a correct expire header
http://www.w3.org/Protocols/rfc2616/rfc ... l#sec14.21

In the future "web sockets" will fix the socket issues.
http://en.wikipedia.org/wiki/WebSockets
web sockets is already implemented in most modern browsers but disabled due to a small security issue that needs to be solved. Read more here: http://hacks.mozilla.org/2010/12/websoc ... firefox-4/
The socket io project just falls back to more crude methods if websockets is not available

[Crush]

You can't rely on the browsers cache. Every browser uses its own caching strategy. The expires and/or cache-control header sent by the server is merely treated as a recommendation. Most browsers have a configurable quota of disk cache, and when this cache is full it decides what to discard based on various criterions, the expires header just being one of many.

That means just because you send an expires header of 14 days you can't expect that the user has the file still cached when he visits the website again tomorrow, because your game is unlikely to be the only web browsing activity of your users.


Regarding web sockets: I wouldn't describe the security issues it has as "small".

[Olof]

Why should the server not be coded in js as well?

Because that's not what Javascript was designed for.

Javascript was designed for little code snippets embedded in HTML to make websites more interactive. It was never intended to code a more complex application in it. Being forced to distribute it as sourcecode instead of more compact bytecode, being extremely weakly typed, having implicit variable declaration, being object-oriented without actually having classes or encapsulation, all these are things which are nice for small snippets but annoying when you are programming a larger application.

Unfortunately it is currently used a lot for that purpose because it being present in every browser makes it the only available choice for complex browser-based applications. But just because Javascript is currently the golden calf which is towed through the web development world, it doesn't mean that it has to be used for everything.

I think you underestimate the power of javascript
Neither encapsulation/namespacing nor classes are hard to achieve using js.

For classes I use:
http://ejohn.org/blog/simple-javascript-inheritance/

And namespacing was never a problem. You only need one global object that is your namespace and then you can store the other variables in that object.

About bytecode: Why would you want to distribute bytecode? Why would you want to compile if you do not have to? The browsers do that for you nowadays and take care of all cross platform issues.

JS is weakly typed yes, it is a more high level language. Coding js is easier and faster. The question that is important is: Is it fast enough during runtime? and the answer to that is yes. So why would you use a lowlevel language if you do not have to?

[Olof]

You can't rely on the browsers cache. Every browser uses its own caching strategy. The expires and/or cache-control header sent by the server is merely treated as a recommendation. Most browsers have a configurable quota of disk cache, and when this cache is full it decides what to discard based on various criterions, the expires header just being one of many.

That means just because you send an expires header of 14 days you can't expect that the user has the file still cached when he visits the website again tomorrow, because your game is unlikely to be the only web browsing activity of your users.


Regarding web sockets: I wouldn't describe the security issues it has as "small".

Yes you can rely on the browser caching mechanisms. You will loose some control as you outsource some of the decision making to the browser. But I would say the loss of the fine grained control is worth it. So much is coded for us already if we use the features given to us by the browser. You can either code a game in a lowlevel language and put enormous time and effort into it as you must reinvent so many wheels. Or you do it in a highlevel language/environment and save loads of time as well as decrease the code complexity so other devs can understand and help out with the project easier.

I think the reason we don't see so many games in javascript yet is because HTML5 and it's goodies is very new. Because of that it is not very adopted yet and some issues might exist due to the specifications being new but that those issues will be fixed in time.
And for closed source games js is not good as you can just read the source whilst bytecode is pretty obfuscated already
But if you aim for an open source 2d game I really think js and HTML5 is a good choice.

[Olof]

Well of course saving loads of time is not an argument in the TMW case
It would rather take loads of time to recode it from scratch
However all the other benefits such as decreased code complexity, no installation needed etc still applies ^^

[Crush]

About bytecode: Why would you want to distribute bytecode? Why would you want to compile if you do not have to? The browsers do that for you nowadays and take care of all cross platform issues.

It's a problem of size. I got a simple java project here, which has 92 kb of sourcecode, but the compiled classes are only 60 kb. Even in the age of broadband connections, filesize still matters on the web.

Being unable to distribute compiled bytecode is also a problem for non-open-source organizations which would rather prefer not to publish sourcecode.

JS is weakly typed yes, it is a more high level language. Coding js is easier and faster. [...] Or you do it in a highlevel language/environment and save loads of time as well as decrease the code complexity so other devs can understand and help out with the project easier.

Weak typing and implicit variable declaration make it faster and easier to code a simple application, but unfortunately it becomes dangerous and makes it hard to maintain code when developing a complex application. Ever wondered why all the programming languages made for large-scale projects, C++, Java, C#, etc., are strongly typed and require explicit declaration of variables?
Technical limitations?
Performance?
Sadism?
No, it's because as soon as the program doesn't fit on one screen anymore, you will get a lot of headache without.

Misspelled one of the 353 variables you have? Or accidentally referenced a variable which isn't available in the current scope? A language with explicit declarations will immediately output a compiler error or even warn you in the development environment as soon as you type it, but a language like Javascript will just assume you made up a new variable and treat it as such. It will run happily but won't do what it's supposed to do. Have fun finding this mistake.

Not sure how the arguments of function xyz are supposed to be formated? When a language is strongly typed, it will not allow you to pass a string when it expects a linked list of integers, but Javascript will happily allow you to do that and only complain about it at runtime, when it complains about it at all.

Finding such problems is both hard and time-consuming, negating the easiness and quickness you get from using a "simpler" language.

[Olof]

Good point there. You are probably right about that such problems are introduced when using a weakly typed language.
I must admit that I never participated in a project of the same size as the Mana project, so I would not know if the weak typing is an issue.

About someting else: I found this nice article on how to handle inheritance in javascript:
http://www.crockford.com/javascript/inheritance.html
According to that article you should code inheritance in javascript differently from a strongly typed language.

...The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.

[Bertram]

Hi Olof,

I have a simple question:

What reason made you think about javascript for The Mana World? What motivated you in proposing your suggestion?

Best regards.