VisualMelon

C# is just like Java, Compiled to bytecode (MSIL/CIL) then JITed when run. I don't know much about multi-platform GUI stuff under .NET, but I believe GTK# exists (I ought to look into that some time...). Recent (asin, last few days) developments have opened up much more of .NET to Linux/MAC, but I don't think there is much (if any) 'official' GUI support other than on windows and mobile platforms. If you can code in Java, then you can probably bluff your way through C# with a bit of context to look at, but again, I think language choice is a decision for much later date (though certainly worth investigating our options ahead of time). I'd condone a serial engine (i.e. engine consumes a message queue on one thread/message pump); multi-threaded state is a lot of effort, but we can separate user-commands and 'timed' events at a layer above the state-engine. Thinking about it, RRT2 does have some perculiar behaviours in single-player mode (multi-player runs continously (as you'd expect) while single player likes to 'pause' while you perform actions): that'll be fun. I'd guess RRT2 is a glorious mass of C++. I've never written a whole game before (not a good one, atleast!); how hard can it be?! I can't imagine life is that hard without networking; the hard bit is knowing what you want, and thankfully the RRT2 devs have done that bit for us! Having half a clue how other stuff works would probably help though, so there is some notion of how stuff actaully works (I'd naively approach this just like any business line application, except for any networking).

Fair enough! Even so, using deobfuscated code sounds like an ethical nightmare, but I don't really know anything about this. You are of course right; I thought the previous comment was more about RRT2 vs RRT3 style environment, the rendering of the former (which happens to be orthographic) lends itself to the cell-based mechanic, the later (perspective) lends itself to a continuous 3D environment. You can of course use an othographic camera with a continous 3D environment, and a perspective camera with a cell-based environment (I can't off-hand think of any examples of games using either, but my gaming interests are not diverse). Train/building modelling itself is technically no different for a naive orthographic projection rather than a perspective (as opposed to RRT2 which is sprites on an orthographic terrain). I have many times played RRT2 over LAN/IP (with success; never tried over the internet); though, I agree that it would by no means be a priority early on, just sensible to keep it in mind if we don't want to preclude it.

(Big rant about extensibility...) I meant a scripting system for the player, so that they can write their own administrative helpers (e.g. to bulk replace locos, search for stuff, etc.). It's blue-sky stuff, but would certainly enable the dedicated player to offload some of the tedious late-game tasks so they can focus on fine-tuning their lines and upping the dividends. DSL, pre-fab language, or purely plug-in based would all suit me. What I would really love would just be a high degree of extensibility (as Jon has alluded to), so that you can write your own rendering engine/routines (e.g. write your own radar map showing positions of trains which have broken down, etc.), and so your own scripting interface. I'd also love more cooperative opportunity, so that two people (under one ingame-name perhaps, or joint directorship) can slog it out maintaining different parts of the same company. For network play, it would be necessary to write an efficient networking/sync system, and have such extensions plug into the client component (fast, easy, independent of server). Server <-> Client-Server Interfaces (in-process/sockets) <-> Client <-> User Interfaces (focus of extensibility) <-> User Sensible decoupling, and serious extensibility would enable a small group to focus on, say, the server (i.e. game logic) while others can have fun trying out different rendering schemes before focusing on polishing up a small number of 'really nice' components. It makes sense to write the base 'client' and 'server' in the same language, so that you can write a highly efficient local server-client interface (i.e. same process, not networked). Another benefit would be implicit multi-monitor support, so the player can focus on performing tasks on one screen, and whatever else they want on the other (even just a listing of events (arrivals, stock purchases, breakdowns, etc.) could be good use of space. Just to clarify, I believe there should be one 'all-powerful' user interface in the style of RRT2, and it should look really nice (ideally as similar to RRT2 as possible), but as an avid coder and long-time RRT2 fan, the prospect of custom extentions is all-too appealing. With regards to language, C# is (in my opinion) a great language, but the real concern is probably finding the platform/engine which unloads the most effort where the team doesn't have experience (e.g. graphics, or networking). If I have time to commit to such a project, I wouldn't care much which language is used, so long as there is someone else who knows what they are doing, and it's got a reasonably expressive and static type system (Java and C++ certainly count)! I'll add that I have no experience with Unity (or any suitable engine, really). Hopefully, the very nature of such a project would necessitate the kind of design which would enable such extensibility, but it would of course need to be kept in mind from the outset. If people have time, and think such a general design sane, then the first task would obviously be writing up a rough and agreeable spec of some sort (like RRT2, cell-based, fun, extensible (perhaps a bit more detailed than that)), after which we could start panning out the interfaces exposed by the server and 'client' before there is any need to settle on technologies/languages. Personally, my time is a bit confused at the moment, and I'm committed to a couple of other hobby projects which I've made no progress on recently, but it is not unthinkable that I could find time in the reasonably near future when I actually have a schedule to work on such projects again (presuming I (and others) generally support the processes and decisions involved!).

It would be necessary to decouple of the logic engine from the rendering engine (especially for stuff like network play), so there should be no concern about being tied down to one. My wish-list item would be an integrated scripting language, so that I can automatically schedule train-replacing. This would likely be technically simple, but probably not a pretty feature. A way to define named consists and apply to them to trains would be great also (so you only have to change one, it isn't lost if your sole train crashes and find yourself in debt, etc.) I'm still a C#er, but I've worked with Java (basically the same language) and C++ in the past, done a fair amount of (casual) DirectX, and jot of OpenGL: can just about write shaders and all that, but it has been a while now. I would either work ground up, or work from a well written engine, wouldn't even consider trying to understand and mutate someone else's code. Orthographic vs. 3D isn't really a graphics issue as a game mechanic concern. 3D like RRT3 would exclude an RRT2 style rendering, but (cell-based) RRT2 could trivially be rendered in 3D. Personally I'd go with simple (cell-based) and pretty (as close to RRT2 as possible!)

I've no experience with Minecraft, and having RRT2 inside it doesn't sound like my cup of tea. Nor is Java really (I'm a C#er) but I can code in it and am still up for helping with a project such as this, so long as it's faithful to the glorious RRT2! (I'm not a fan of RRT3's visuals or changes in gameplay) I was considering throwing together some stuff in the vain of Railroad Tycoon last year when I was getting good (read: not entirely useless) at 3D stuff, but that was all C++/C# and DX9/11 (probably want OpenGL if multiplatform is a goal (DX background means I can read and modify OpenGL code no-problem, not written anything substantial for years, however)). RRT2 is, naturally, not entirely rendered 3D, but I'm sure the sophisticated Isotropic look can be preserved without having to put too much effort into an efficient renderer (a luxury the original developers could not afford, I'm sure). If we go about coding this nicely, then we can do such wonderful things as writing a horrendously ugly 2D top-down gauntly-colours covered-in-debugging-text interface for use until the backend is sorted out, and glue a nice interface onto it later (when horrors such as networking and state preservation has been addressed). Glad I got the email notification for this... I couldn't find this forum the last time I looked and was worried I was missing stuff.

Howdy - sorry I'm rather late to the party but if people are still dreaming of an extendable Railroad Tycoon II then I'm all for helping with programming, testing, whatever (and I like the look the looks of some of the "wishes" in the wishlist thread) I've recently been considering how multi-monitor Railroad Tycoon could have worked (i.e. one for the map, one for the Stocks, Station Listings, everything else) so I figured I'd see if there was any outlook for continued/open development of the game (RRT3 doesn't cut it for me) I could get involved in. On a side note as this is my first post, I'm really glad to see this game still has a serious following, RRT2 is probably my favorite game of all time - fun to play both casually and competitively.