OpenTTD clone in Java
Moderator: OpenTTD Developers
- dzavalishin
- Engineer
- Posts: 3
- Joined: 16 Sep 2021 09:19
- Contact:
OpenTTD clone in Java
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
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
Re: OpenTTD clone in Java
This is a bad idea.Rewriting UI with native Swing framework
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.
Re: OpenTTD clone in Java
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.
Re: OpenTTD clone in Java
Care to elaborate?dzavalishin wrote: ↑16 Sep 2021 10:58 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.
AroAI - A really feeble attempt at an AI
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
Re: OpenTTD clone in Java
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
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
The only thing necessary for the triumph of evil is for good men to do nothing.
Re: OpenTTD clone in Java
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.
* 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.
- dzavalishin
- Engineer
- Posts: 3
- Joined: 16 Sep 2021 09:19
- Contact:
Re: OpenTTD clone in Java
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.Taschi wrote: ↑16 Sep 2021 21:20 * 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.
- dzavalishin
- Engineer
- Posts: 3
- Joined: 16 Sep 2021 09:19
- Contact:
Re: OpenTTD clone in Java
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
- Administrator
- Posts: 25137
- Joined: 26 Jan 2001 20:18
- Skype: orudge
- Location: Banchory, UK
- Contact:
Re: OpenTTD clone in Java
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.
Perhaps one day somebody will do a C# port of your Java port.
Re: OpenTTD clone in Java
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)
Re: OpenTTD clone in Java
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.
Re: OpenTTD clone in Java
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!
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!
The only thing necessary for the triumph of evil is for good men to do nothing.
Re: OpenTTD clone in Java
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.
I tried in Javascript, but some how it was slow. I couldnt understand what I did wrong, so I stoped.
- _finelogistics
- Engineer
- Posts: 2
- Joined: 02 Sep 2022 08:55
- Contact:
Re: OpenTTD clone in Java
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.
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.
my openttd in js otjs - demo https://finelogistics.github.io/otjs/public/index.html or https://github.com/finelogistics/otjs
Re: OpenTTD clone in Java
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 wrote: ↑02 Sep 2022 09:14 1. How did you solve squirrel lang integration?
2. Did you port YAPF? How about other?
- _finelogistics
- Engineer
- Posts: 2
- Joined: 02 Sep 2022 08:55
- Contact:
Re: OpenTTD clone in Java
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
my openttd in js otjs - demo https://finelogistics.github.io/otjs/public/index.html or https://github.com/finelogistics/otjs
Who is online
Users browsing this forum: No registered users and 21 guests