Let's port openttd to the browser with this

[Valentijn]

http://www.isogenicengine.com/

[planetmaker]

It's open source. You can start without anyone's permission.

[Digitals]

Hi,

What do you do infact? You make the pub for a game? Or you make a suggestion to open TTD? Because I did not understand

[Alberth]

He says "Let's port openttd ....", which sounds to me like he will do the port.

[Digitals]

Okay, I understand, thank you for your answer

[Valentijn]

Well, openttd was the first thing that came to mind when I saw a demo/interview of the makers of isogenic engine.

However, a port would be a massive job and probably a lot of things can't happen in it.

[Alberth]

You realized that in the past 5 hours?

[Valentijn]

You realized that in the past 5 hours?

I realized that not everybody seems to understand the meaning of a wink.

[planetmaker]

You realized that in the past 5 hours?

I realized that not everybody seems to understand the meaning of a wink.

You post in the development section. As such it's reasonable to assume that you are going to start and take on the task.

Suggestions have their own forum - where we also don't expect the posters to do more than suggest whatever fancy they have at that moment, irrespective of work involved and technical realities.

[CMircea]

You've got to be crazy. That means rewriting the whole of OpenTTD in JavaScript. It may not seem like a complicated game when you play it, but it's on par with more modern games like Battlefield 3 (sans the 3D part). You'd have better luck porting OpenTTD to Google's Native Client, but that wouldn't make much sense.

[Bilbo]

You've got to be crazy. That means rewriting the whole of OpenTTD in JavaScript. It may not seem like a complicated game when you play it, but it's on par with more modern games like Battlefield 3 (sans the 3D part). You'd have better luck porting OpenTTD to Google's Native Client, but that wouldn't make much sense.

I think porting openttd to run in the browser may not be as hard as it seems to be ...

Just start with the Linux port and use this:
http://bellard.org/jslinux/

You'll need to add some sort of networking and graphics to the 486 emulator, but if you "invent" some special opcodes for few common operations (putpixel/bitmap blit ....) and then use them in the graphics driver, this should be relatively easy (you don't need to emulate ordinary full-featured VGA card). Same for networking ....

[Yexo]

You'll need to add some sort of networking and graphics to the 486 emulator

Which is a very hard project in itself.

Not to mention about the speed issues you'll run into when trying to play even a 64x64 map.

[Bilbo]

You'll need to add some sort of networking and graphics to the 486 emulator

Which is a very hard project in itself.

Not to mention about the speed issues you'll run into when trying to play even a 64x64 map.

I guess you'll get performance quite close to the 486 - which was enough to play even 256x256 maps on original TTD :)

It won't be easy project, but I think it would be easier than rewriting openttd in JS.

Another option could be this:

https://github.com/kripken/emscripten/wiki
Basically you compile C++ with Clang (OpenTTD is already compilable with Clang/LLVM 2.9 - 3.0) to produce LLVM bitcode and then compile that bitcode to JS code. Should be faster than doing full emulation of 486 and should be easier to hook special functions (network code, graphics....) in it. IMHO time to do that would be probably less than twice of time needed to port OpenTTD to some completely new platform. You'll need to write new video driver (~1000 lines of code), sound and music driver (~200 lines each) and then add some OS-specific functions (add new dir in src/os/, about 1000 lines of code to handle files and networking)

Possibly doable within week of full-time work, if you already know all the OpenTTD internals.

[Yexo]

It won't be easy project, but I think it would be easier than rewriting openttd in JS.

I agree with that, but I still think you're vastly underestimating the required time.

https://github.com/kripken/emscripten/wiki
Basically you compile C++ with Clang (OpenTTD is already compilable with Clang/LLVM 2.9 - 3.0) to produce LLVM bitcode and then compile that bitcode to JS code. Should be faster than doing full emulation of 486 and should be easier to hook special functions (network code, graphics....) in it. IMHO time to do that would be probably less than twice of time needed to port OpenTTD to some completely new platform. You'll need to write new video driver (~1000 lines of code), sound and music driver (~200 lines each) and then add some OS-specific functions (add new dir in src/os/, about 1000 lines of code to handle files and networking)

Possibly doable within week of full-time work, if you already know all the OpenTTD internals.

I'd estimate more like a month of full-time work. Unless of course you happen to also be an expert in javascript, in high-speed sprite drawing and javascript socket code. Oh, knowing a lot about LLVM bytecode won't hurt either, since I doubt it's going to run flawless the first time you compile it. Now I think of it, even a month full-time is probably way too optimistic.

[Eddi]

[...]video driver (~1000 lines of code), sound and music driver (~200 lines each) and [...] about 1000 lines of code to handle files and networking[...]week of full-time work

let's see...

• assume you're a good programmer.
• assume a good programmer produces on average 10LOC per hour (if you produce more, you haven't thought long enough about how to do it in fewer lines)
• assume a full-time working day has 7 hours
• assume a full-time working week has 5 days
• that means you produce 360 LOC per full-time week.
• so to produce 2400 lines of code, you need ca. 7 weeks

now factor in that this is a hobby project, and you don't find someone with the "perfect" knowledge... you're looking more towards 2 years than 2 months...

[Edd.Dragon]

Well, openttd was the first thing that came to mind when I saw a demo/interview of the makers of isogenic engine.

However, a port would be a massive job and probably a lot of things can't happen in it.

Game engine is cool. But what about of performance of the browser's js engine itself? It is many times less in comparison with native application. And I doubt whether this potr will be suitable for large map with many vehicles and big cities

And... why browser? What profit from this?

[FooBar]

And... why browser? What profit from this?

None.

But it seems to be hip at the moment to do things opposite of what is logical. Porting games to browsers (see angry birds for example) and creating apps for things that can be done perfectly fine in a mobile website (and get cross platform availability for free).

[Ruudjah]

• WebGL/hardware accelerated canvas for gpu offloaded rendering
• Simpler upgrade (F5), server always offers uptodate version
• Native Javascript means all kinds of lively interesting libs (e.g. node.js)
• JS cloud IDE (http://c9.io) means simple link to patch/fork with "run" button in near future
• Html/Js means easy interesting mashups, reuse of code for webapp integration (e.g. vehicles browser)

Personally, I'd like to think Js/html5 lowers the barrier for everyone to join development, but that's entirely based on gut feeling.

Raw engine performance likely will be slower then optimized C++, but I doubt its orders of magnitude, if at all a magnitude. Since a few years performance is getting more and more decent of Js VMs.

Likely a Js client is doable performancewise.

[FooBar]

looking forward to your test version of this. When can we expect that, next month?

[Ruudjah]

All the wise/rockstar coders having done big projects in Js say it's possible, but say it is a balancing act on a small wire. There is no unified project structure for Js projects, and dynamic (runtime) typing (e.g. dynamic properties) makes for lame tool support. If you look to say c9.io you can see its basically a few ginourmous Js files, not a nice clean organized folder structure.

CoffeeScript (less loc, classes) /Dart (designed for this kind of apps in mind) may be more suitable for this kind of project, where it is evident from start the project can grow relatively big. But those langs have their on problems, adoption/age being the most important.

For Js/Cs, c9.io may solve most problems, Dart needs a few more months. I think time is not quite right yet, but getting very close. Off course, anyone can start now, but certainly would encounter much handicap (see Law of the handicap of a head start). Project structure, c9.io, Cs, Dart, certain libs, debug tools, testing all contribute to this law currently.

When OpenTTD started to develop, most tech was already present as example, for instance project packaging. Not so much yet with a Js client, and projects sharing certain properties with OpenTTD (e.g. size) learn it is in the early days still.

Then again, the moment big Js apps take relatively normal development effort is at hand.