Moderator: OpenTTD Developers
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.
* 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.
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.
Care to elaborate?
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
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
* 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.
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.
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.
- Posts: 24954
- Joined: 26 Jan 2001 20:18
- Skype: orudge
- Location: Banchory, UK
Perhaps one day somebody will do a C# port of your Java port.
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.
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.
Users browsing this forum: No registered users and 3 guests