OpenTTD clone in Java

[dzavalishin]

Hi.

We're looking for a brave programmers to join a new project: NextTTD - clone of OpenTTD rewritten in Java.

Project is here: https://github.com/dzavalishin/jdrive

Key idea of the project is to detach game from the architectural solutions of a 30 years old TTD and redesign internals in a more or less modern way. We do think that it will simplify development of game and let us implement things that nearly impossible or very hard to implement in traditional OpenTTD architecture. As a side bonus - effortless portability to major platforms.

Clone is based on a quite old version of TTD, but that's on purpose - it is based on a version that, to my opinion had the best implementation of rail signals. Also, C code was easier to port to different language, than C++.

Current state: Game is mostly playable. Save game code is basically working but not yet mature enough. Network support is completely missing for now (port is in progress).
Last success is working AI.

Currently we do not make any groundbreaking changes - most modifications are to make code more clean and readable. For example, old tile representation with bit encodings is still here. Current plan is to recreate the game more or less completely and start major refactoring later.

How can you help the project:

* Test game and provide feedback. Your feedback on missing features that exist in mainstream OpenTTD is very welcome.
* Help with automatic regress tests - what we really need is some test suite for game to be sure that ongoing modifications do not break it.
* Content server integration, load/save format import code to support OpenTTD music, scenarios and heightmaps.
* 32bpp blitter and sprite loader code
* Rewriting UI with native Swing framework
* Any other crazy idea.

FAQ:

* Rewritten from C to Java in 1 month by me. Vacations project.
* No, not slower at all. 100 fps with delay.
* All OS dependent parts are rewritten to be seamlessly portable.

Welcome: https://github.com/dzavalishin/jdrive

[Taschi]

Rewriting UI with native Swing framework

This is a bad idea.

Swing is not at all "native" and its performance is generally pretty poor. I think it has gotten better in recent Java versions but I still would not trust it to consistently render at 60fps.

Swing will also tie you to the desktop, preventing you from porting the game to, for example, Android. In a project with the express goal of increasing portability (which I find dubious, given the number of systems and platforms OpenTTD can run on), I would find that a very dubious decision.

Note that I'm not just saying this to stir one of the usual framework flamewars, I am currently developing a project using Swing myself - see my signature.

[jfs]

I'm not sure if I read this correctly, but it looks to me like you're porting a 16 years old version of OpenTTD, not any remotely current version. Things have changed a lot since then.

[Lord Aro]

Clone is based on a quite old version of TTD, but that's on purpose - it is based on a version that, to my opinion had the best implementation of rail signals.

Care to elaborate?

[TrueBrain]

I hope you had a lot of fun doing this

On a more serious note, and please do take this serious: your license.

Your work is a derivative of OpenTTD, and by our license, the contract you accepted by using our code, any derivative work has to be GPLv2 (compatible) licensed too. And MIT is not that kind of license. Please change this ASAP! (is there a smiley face to express I am rather serious about this?)

Additionally, and this is just a friendly reminder, you have the original TTD files (and xussr.grf) in your repository. Those are copyrighted, and could result in a takedown notice by the copyright holder (I am not the copyright holder of either, to be clear). Something you might want to take care of

Sorry for being "that guy", but if you want to do this, at least make sure you stand on legal ground Means less fuzz later on

[Taschi]

So, after some thinking about your project I have some more thoughts.

* You state that your approach to this port is to first do a fairly straightforward port and then refactor it later. But if you are not going to redesign your internal data structures and logic from the get-go, I do not see what advantage your port offers. Why not "just" refactor the current C++ code? (I see the advantage that Garbage Collection has for complex data structures, but I don't think memory management is the biggest obstacle to OpenTTD development by a long shot.)

* You've decided to go for an old version of OpenTTD, which I assume will completely destroy any chance of NewGRF compatibility with "proper" OpenTTD. Given that modding is fairly integral for the community, that seems like a fairly huge stepping stone for your project. Ditching NewGRF might actually be a blessing in disguise if it is replaced with a more modern, convenient and consistent modding system but that is not something I see on your to do list.

* Please do fix your licensing issues, especially the use of copywritten material from the original TTD - and I'd advise you to purge them completely out of your git history.

* I do not think that your Java port will actually be any more portable than OpenTTD already is. I'm not aware of any environment that can run Java SE but cannot run OpenTTD.

* If you want programmers to join, your code should be clean. I've done a bit of poking around, and the code I've seen so far isn't even properly or consistently indented.

[bjgttd]

Sounds fishy.

[dzavalishin]

* You've decided to go for an old version of OpenTTD, which I assume will completely destroy any chance of NewGRF compatibility with "proper" OpenTTD. Given that modding is fairly integral for the community, that seems like a fairly huge stepping stone for your project. Ditching NewGRF might actually be a blessing in disguise if it is replaced with a more modern, convenient and consistent modding system but that is not something I see on your to do list.

That's true. Will implement NewGRF loader ASAP. Actually I have NewGRF loader for old file format, and parser for a new file format. Just need a connection between them.

[dzavalishin]

Ditching NewGRF might actually be a blessing in disguise if it is replaced with a more modern, convenient and consistent modding system but that is not something I see on your to do list.

I'm thinking about either Eclipse style plugins (very flexible but not easy to use) or some scripting engine to build into. Groovy comes to mind.

[orudge]

Interesting project, though you’ll have a lot of work to do if you want to reach feature parity with OpenTTD. I’d reiterate the licensing issues - very important you get that fixed.

Perhaps one day somebody will do a C# port of your Java port.

[Eddi]

the main problem i see is that by your "design decision" to build upon an old version, you're throwing away over a decade of community effort (both in game coding and in newgrfs)

[Taschi]

the main problem i see is that by your "design decision" to build upon an old version, you're throwing away over a decade of community effort (both in game coding and in newgrfs)

I wholeheartedly agree but didn't want to put it quite that bluntly. But playing a ten-year old version of OpenTTD when I could just play up-to-date OpenTTD is absolutely not an enticing idea to me.

[TrueBrain]

First off, really appreciate you fixing the license issue. Cheers for that

To balance the negative vibe in this thread, I like that you set a goal, went for it, and are making it a reality Most of these things we do for ourselves, and not for the judgement of others.

The whole reason I did OpenDUNE, was because I could. Not because anyone was really waiting for me to do it (there were plenty of alternatives to run Dune2 on a modern system). Sometimes things are just fun to do

As for the old version of OpenTTD .. I kinda get it. Using a C version is useful, as that makes converting to Java easier. And there are more than one person that enjoy the "more pure" TTD variant, that didn't have all the modern bells and whistles on top of it. I mean, let's be honest, can we truly state that the "improved" order window is really an improvement? And if signals are that thing for you, than for your own project you should indeed pick the version that was like you want it to be.

In the end, you do you. I like that you did, and I hope it brings you a lot of joy doing so. I like your enthusiasm, and that you think Java can solve stuff that cannot be solved currently; can't wait to see how you plan to address those things, and how they turn out.

If you need (non-Java) help, feel free to reach out. The infrastructure around openttd.org is meant to be used by any fork/clone/patchpack/etc, so don't feel shy to ask for help with that part. There are limits of course, but those are meant to be found.

Good luck!

[recyc]

Hi. Do you still writing this game, is it working well?

I tried in Javascript, but some how it was slow. I couldnt understand what I did wrong, so I stoped.

[_finelogistics]

NextTTD looks cool.

Could you explain how have you been porting logic?
Thanks for the notes in `converting_c_to_java.md` (as of `374766d`), some of them are really interesting.

The repo is missing few, modern nowadays, things like releases and version tags so we can compare. I have been wondering have you been using pull requests during the development? I was hoping to be able to understand more about the project history from pull requests, but it seems I cannot.

I will try to run it. Thank you for this edition of OpenTTD, it might be easier for me to dig into the code of both NextTTD and even OpenTTD, because logic in java might be really implemented easier.

I've got some questions:

1. How did you solve squirrel lang integration?
2. Did you port YAPF? How about other?
3. What is (what was your original plan) for regression (aka backward compatiblity)? (e.g. existing tests as a daemon/service server and calling service from java test runner or total rewrite to java?)
4. Could you elaborate on architecture? Are there any differences?
5. have you been contributing to original OpenTTD before getting your hands on jdrive/NextTTD or you just did it? Are there are differences from structures/models in original version?

More questions to come I think.

[jfs]

1. How did you solve squirrel lang integration?
2. Did you port YAPF? How about other?

The answer to both of these is that this port is based on a very old version of OpenTTD, so old that neither the AI or GS scripting existed (the AI in this version is a port of the original Transport Tycoon Deluxe AI), and YAPF did not exist in that version either.

[_finelogistics]

very old version of OpenTTD

ok, thanks! This explain everything.
Btw. I started working on my own openttd in the browser (no wasp or any other approaches), link in my signature if you would be interested in so far I've done menu at the top and few modals with dragging them around, I might provide video soon if anyone would be interested
currently I am evaluating any ways of running backend as an external process so that I need to take care only about rendering the view

I hope hear you soon