Jump to content

Recommended Posts

Posted
1 hour ago, jeffryfisher said:

If you want to be cross-platform, then I'd pick Java, which can run on any machine for which a JVM exists.

 

For Java what graphics framework or API would you suggest?

1 hour ago, jeffryfisher said:

Perhaps, though I'm unsure about the top-down part. A mock-up (proof of concept, however projected) could go a long way without real art. However, we might not need to. I know from watching SimCity 4 modders design 3D models that there are some very talented artists out there. We would just need to find a few who love railroading. Come to think of it, people like that are still adding 3D train sets to SimCity 4...

If you want 3D from the get go, the obvious starting point would using cuboid (ie square 3D blocks) placeholders for the trains until someone built a suitable set of 3D models. The tricky bit is track, I guess a basic texture could be used for that.

Are you thinking of full 3D (ie RRT3) or the orthographic look of RRT2?  You can do the latter with full 3D models not just 2D sprites like I believe RRT2 used but you'd have to set the game camera to orthographic to avoid perspective effect.

Posted

I have no graphics lib preference. My first thought is to use whatever Minecraft uses simply because there's a huge batch of decompiled, deobfuscated Minecraft rendering code out there to learn from. However, its (clunky) polygon 3D models with skins might not suit us.

As for full 3D versus orthographic, I have no strong preference. As far as I'm concerned, the game's entertainment comes from the business and economic model. I'd be happy even if running trains were abstractly schematic, like a dispatcher's wall-mounted network diagram with blinkin' lights. I must defer to others' judgement when deciding what level of graphics eye-candy will be necessary in this day and age.

BTW, Among my wish-list items is a desire to adjust train size according to map scale. On continental maps, I hate having 100-mile long trains clog up my interstate rail net.

Posted

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!)

Posted (edited)

Agrees with that, decoupling the display from the game logic is key, I like cell/tile based too.

If c# then Unity is obvious choice, if Java I looked there are several libraries that could be used but I have not used any or done work in Java before. 

When you say scripting are you meaning in game scripting?  Or scripting for more flexible game tuning, editing and modding?  For the latter you can integrate python or Lua or Unity can allow you to create a moddable game with users creating their own plugins in C#.

 

This video shows how to create isometric view using 3D with orthographic camera in Unity. https://www.youtube.com/watch?v=XhliRnzJe5g

Edited by JonMoore
Posted

(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!).

Posted
18 hours ago, VisualMelon said:

It would be necessary to decouple of the logic engine from the rendering engine

Natch

(especially for stuff like network play)

Initial development should skip network play. In 15+ years, I've never known anyone who used it (though some tried and failed).

My wish-list item would be an integrated scripting language, so that I can automatically schedule train-replacing.

We have a wish-list around here somewhere. I included train-list filtering, plus multi-train selection leading to bulk engine replacement.

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.

I excel at rescuing / porting orphanware.

Orthographic vs. 3D isn't really a graphics issue as a game mechanic concern.

Then I guess I don't understand the issue. I thought each was a way of rendering (projection) the same internal data. How does the game mech change based on how one models trains and buildings?

 

Posted (edited)
19 minutes ago, jeffryfisher said:

I excel at rescuing / porting orphanware.

Fair enough! Even so, using deobfuscated code sounds like an ethical nightmare, but I don't really know anything about this.

19 minutes ago, jeffryfisher said:

Then I guess I don't understand the issue. I thought each was a way of rendering (projection) the same internal data. How does the game mech change based on how one models trains and buildings?

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).

19 minutes ago, jeffryfisher said:

Initial development should skip network play. In 15+ years, I've never known anyone who used it (though some tried and failed).

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.

Edited by VisualMelon
Posted
5 hours ago, JonMoore said:

If c# then Unity is obvious choice

Isn't C# a compiled language? If so, then it would make multi-platform compatibility more difficult. However, I wouldn't mind adding C# to my resume.

2 hours ago, VisualMelon said:

a highly efficient local server-client interface (i.e. same process, not networked)

But still separate threads, which requires sync care. On the plus side, separate threads means obvious multi-core load balancing. I'll grant that a goal of eventual networking should influence early design toward client-server arch, but it would still be easiest to do a single-player case first so that play-testing can get involved before anyone tackles real MP issues.

For anyone involved in development, client-server can be a mind-bender the first time one encounters it. I liken it to the separation of church and state: If you grew up without the separation of decision and rendering, it can be disorienting. For the first-timer then, I'd recommend doing a Minecraft mod or two as exercises (which can also teach Java).

2 hours ago, VisualMelon said:

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

I like it: Put the map on one screen while the reports, controls, lists etc share the other.

3 hours ago, VisualMelon said:

Personally, my time is a bit confused at the moment

I'm unemployed, which means that I have some time but should be searching for paying work (O-O programming and/or relational DB design).

Posted
3 minutes ago, VisualMelon said:

using deobfuscated code sounds like an ethical nightmare

That's in Minecraft, which is written in Java, which is especially amenable to decompiling. Forge seems to have an understanding with Mojang, who seem to have supplied much of the name deobfuscation gratis to empower the modding community that makes the game so popular (a rather progressive attitude compared to most American game companies).

OTOH, I don't even know what language RT2 was written in, and none of the companies involved in its development and distribution will admit to owning any source code or resources. So I don't think we have a snowball's chance of getting anything of RT2's original code, but maybe somebody can surprise me.

I'd like to eyeball it if only to learn architecture and technique from it before writing something from scratch (I am unfamiliar with overall game architecture, so I am missing the big picture).

As it is, we will probably start from nothing, with only the game's UI to guide imitation. Maybe exploring open-TT's source would be educational. There might even be modules there that we can adapt.

Posted (edited)
33 minutes ago, jeffryfisher said:

Isn't C# a compiled language? If so, then it would make multi-platform compatibility more difficult. However, I wouldn't mind adding C# to my resume.

 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).

Quote

But still separate threads, which requires sync care. On the plus side, separate threads means obvious multi-core load balancing. I'll grant that a goal of eventual networking should influence early design toward client-server arch, but it would still be easiest to do a single-player case first so that play-testing can get involved before anyone tackles real MP issues.

For anyone involved in development, client-server can be a mind-bender the first time one encounters it. I liken it to the separation of church and state: If you grew up without the separation of decision and rendering, it can be disorienting. For the first-timer then, I'd recommend doing a Minecraft mod or two as exercises (which can also teach Java).

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.

17 minutes ago, jeffryfisher said:

That's in Minecraft, which is written in Java, which is especially amenable to decompiling. Forge seems to have an understanding with Mojang, who seem to have supplied much of the name deobfuscation gratis to empower the modding community that makes the game so popular (a rather progressive attitude compared to most American game companies).

OTOH, I don't even know what language RT2 was written in, and none of the companies involved in its development and distribution will admit to owning any source code or resources. So I don't think we have a snowball's chance of getting anything of RT2's original code, but maybe somebody can surprise me.

I'd like to eyeball it if only to learn architecture and technique from it before writing something from scratch (I am unfamiliar with overall game architecture, so I am missing the big picture).

As it is, we will probably start from nothing, with only the game's UI to guide imitation. Maybe exploring open-TT's source would be educational. There might even be modules there that we can adapt.

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).

Edited by VisualMelon
Posted (edited)
15 hours ago, VisualMelon said:

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).

Unity is C# game development system and supports windows, linux, Mac, android and iOS so you need look no further than that for C# game development.  Its free to use if you earn less than a certain amount from the game.

Is it free, for this kind of open project yes, see:

" There are three editions of Unity3D, Personal, Plus and Professional.

Personal is free, Plus is $35 a month and Professional is $125 a month


If you or your company currently makes more than $100k in annual gross revenues or has raised funds in excess of $100k, you are not permitted to use Unity Personal as defined in our Terms of Service. If this amount exceeds $200K, you are eligible to use Unity Pro only.

The only difference between the free version and the others is it has a "made with Unity3D personal edition" splash screen on your builds and the professional has a dark skin that's nicer to look at, plus a free more pro tools. "

Edited by JonMoore
  • 2 years later...
Posted

It has been SO long since I've visited this forum.  Catching up on reading this thread was enjoyable.  A number of people with talent appeared to have stopped by in the past couple years.  I'd love to know if the idea of a new railroad tycoon game is still alive and well, though it might not be, judging from the dates on the posts.  I've looked for a few games over the past couple years, trying to find one that gives a similar experience to RT2, but have come up short.  There are things like Railway Empire and Railroad Corporation, and maybe some others, but none seem close to what RT2 delivered.  I did come across this interesting thread on reddit.  And here was an article on the best PC train games.  Any guesses on which one (even after all these years) is at the top of the heap?  It's evidently been very challenging for game companies to emulate the essence of what made RT2 special (in spite of its flaws), in a new game.

I did enjoy reading the ideas shared above, even if I don't entirely understand much of the tech-talk behind some of them (my vocation is accounting, and not programming unfortunately).  Still was some good reading.  The idea of including modding capabilities, and a scripting language such as lua caught my eye, though.  A few years back (around January of '15) I discovered the Farming Simulator game franchise, and that's been my primary focus since.  It took untold hours of pain to do, but this accountant even managed to learn a few things about lua coding to create some mods.  Would be really neat to have the ability to do that with a RT game.  Alas, I'll probably stick with Farming Simulator for the foreseeable future... though I miss the railroads.  Just need a good replacement for RT2, and I might be enticed back to it.
 

Anyway, I hope everyone here has been doing well.  I have no idea how many even visit here anymore, so maybe I'm just talking to the wall.  Take care all. ;) 

  • 1 month later...
Posted

Well peeps, I did some digging a time ago, and I can confirm Railroad Tycoon 2 was written in C++. Not that it matters all that much, but it might be useful regardless.

 

Posted
2 hours ago, SD45 said:

Railroad Tycoon 2 was written in C++

Sigh, so not easy to decompile, especially since there's probably some assembly linked in there too. I wonder if a copy of the original source-code (and resources etc) even exists anymore. I think it was lost somewhere in the ownership changes between RRT3 and Sid Meier's Railroads.

  • 1 month later...
Posted

Phil Steinmeyer might have it, but he's retired. The closest thing I could find on him was this reddit post: https://www.reddit.com/r/tropico/comments/b3oxwy/what_happened_to_phil_steinmeyer/  a reply from his daughter is in the comments, but it's been over 8 months since she posted her comment. We could also try to hit up Firaxis, as PopTop was merged into them, they might have a copy. Of course, the game is only ~646 MBs so maybe if we hire a whole lot of monkeys they could recreate the code. 🤣

Posted

I contacted Phil multiple times, and he couldn't help. I contacted TakeTwo (not Firaxis), and they claimed that Sid Meyer  (Firaxis) bought the whole kit & kaboodle before making Sid Meyer's "Railroads". Firaxis told me that they got only RT3, not RT2.

If PopTop didn't keep any source code to RT2, then it has been lost. It may sit on an optical disk in a landfill somewhere, but it's unlikely it will ever be found. To recreate the game, somebody will need to reinvent it from the ground up. I didn't, because lacked the skills. Now I'm working a 7-6 job again, so I don't have the time either.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.