Where do you draw the line?

[DominusEdwardius]

I've been thinking, when It comes to scripting an engine where would you draw the line? Here's what I mean, say for example you were making "x Locomotive" and you could do any and every piece of scripting in an instant, at what point would you the user be turned off by it, be it sheer number of features, complex starting procedures etc, At what stage does it go from something you love and cherish, enjoy etc to something which will sit in your file structure unused for eternity?

Where do you draw the line? Honest opinions please ( although I suspect we may have a bit of bias here! )

regards
Edward

[AndiS]

In keeping with my reputation, I can only offer erasers and sponges instead of lines.

To make an engine a (commercial) success, you will need an easy mode as an alternative. People will still cheer about all your complications, but take a short cut when they don't feel like complications. This keeps the engine from collecting dust and people are reminded that there would be additional entertainment value hidden in the manual.

People hate reading manuals. So tutorial scenarios are the way of our times. Besides real tutorial scenarios with a ton of pop-ups explaining the stuff in-game, a scenario where you don't have much to do, so you can spend lots of time trying to remember what all these levers were, is a good thing.

There is static complexity and dynamic complexity. But static complexity, I mean all the stuff you need to do to get the engine started. This easily gets boring. By dynamic complexity, I refer to managing the fire bed or wheel slip on changing rail conditions. In my view, the first easily gets boring while the second is interspersed into other actions/activities and it easily becomes the spice of a longer task that could otherwise be boring.

There are challenges which provide yes/no solutions. Either I find out how to start the engine, in which case I just have an engine that does what you would expect, or I fail completely and must restart in noob mode. And there are challenges that provide a gradual degree of success. If I nearly run out of steam at the end of a trip, I will still arrive but not in time. If I manage everything perfectly, I may arrive a few minutes early and feel like a real winner.

There is complexity that you can understand and such that you cannot understand so easily. This is a difficult one, because it depends on the user's interest, and background knowledge. I don't care about electrics, so all the great challenges of not blowing a fuse will be lost on me. But there are still some things that are more likely to transpire to many than some other details. E.g., if you see the wheel slip, and you hear that sand is the remedy, sanding in such a situation is not such an abstract thing to learn. If steam condenses in the cylinders because they are not as hot as they are after a little while of running, you cannot see that and you don't think of the consequences unless you are forced to. People might be more willing to learn to react to stuff they understand. But it is hard to draw lines here, because if you want, you can understand everything using a little patience.

[Rockdoc2174]

For me, the first answer would be not to overdo things. Just because it can be done isn't an indication that it needs to be done. I can applaud the effort that has gone into making it possible to clean out a smoke-box but I don't want such unnecessary nonsense. It's the same with cylinder cocks. I'm an engineer so I know perfectly well that it is possible to do serious damage if significant amounts of water accumulate in cylinders but the likelihood of such damage was well recognised by the railway companies and each end of each cylinder had a pressure-relief valve, which has never been added to the equation.

Secondly, make sure that what you do is truly realistic. Granted, I've only had an experience day at Butterley to base my ideas on but driving the Caprotti Standard 5MT, with and without a train, bore little relation to the way some locos have been made to work in TS. I have been so disappointed that I tend to avoid steam locos that are marketed as being 'realistic'. No, I'm not satisfied with the bog-basic RSC model with superglue on the driving wheels either but when the modifications affect my enjoyment of the game then enough's enough.

Keith

[Carinthia]

I would offer one small point - already "infringed" by a few developers. Make sure that all settings are savable if a scenario is saved for later. There is nothing more unrealistic than resuming a scenario whilst trundling along at line speed and having to rush to stick the engine key in and turn on the AWS as quick as you can to ensure you don't lose too much speed.

I also concur with AndiS about the ability to drive in "easy mode". Believe it or not we are not all here just to drive. I like to enjoy the scenery!

John

[deltic009]

I would offer one small point - already "infringed" by a few developers. Make sure that all settings are savable if a scenario is saved for later. There is nothing more unrealistic than resuming a scenario whilst trundling along at line speed and having to rush to stick the engine key in and turn on the AWS as quick as you can to ensure you don't lose too much speed.

I also concur with AndiS about the ability to drive in "easy mode". Believe it or not we are not all here just to drive. I like to enjoy the scenery!

John

I agree with both of your points - particularly when you consider that it is possible to begin scenarios at speed (Settle Jcn 60mph) it makes it fiddly, and as I have two very keen sons they are being barred from locos they love that don't have a simple mode unfortunately.

[AndiS]

I guess that starting the scenario with anything in motion can be a hard nut to crack in engine scripts. It is a very valid point that this should work because the game communicates to the user that they can save at any time and resume what they saved yesterday without any issue. However if you engage in simulating complex stuff behind the scene, this resuming business may well be a no-go area.

I can only speak of the signals and there, I retreat to a safe base rather than adding a hundred lines just to guess what is going on initially.

For signals, there seems to be some state variable where one might be able to save the internal state to. I never tried it. For engines, I don't know if such a thing exists, not to mention whether it works. And if it does, it will still provide a nasty hacking exercise to write all the internal values to a long string, and decode that again on loading.

[cjbarnes5294]

I would offer one small point - already "infringed" by a few developers. Make sure that all settings are savable if a scenario is saved for later. There is nothing more unrealistic than resuming a scenario whilst trundling along at line speed and having to rush to stick the engine key in and turn on the AWS as quick as you can to ensure you don't lose too much speed.

I agree with both of your points - particularly when you consider that it is possible to begin scenarios at speed (Settle Jcn 60mph) it makes it fiddly, and as I have two very keen sons they are being barred from locos they love that don't have a simple mode unfortunately.

I guess that starting the scenario with anything in motion can be a hard nut to crack in engine scripts. It is a very valid point that this should work because the game communicates to the user that they can save at any time and resume what they saved yesterday without any issue. However if you engage in simulating complex stuff behind the scene, this resuming business may well be a no-go area.

Successfully resuming scenarios with advanced locos is certainly a problem at the moment, especially when you want to use these addons for very long scenarios. It is something that I will be seeking to address in the future, and I'm sure other scripters will be doing so as well. I think it is possible to achieve.

As for drawing the line, I'd say that depends on how far and for how long you are prepared to work on and spend time on each individual project. As long as users are given the choice of driving a normal, simplified version, you can't really have too many features on the advanced version in my opinion. Those that enjoy the additional features will probably be happier being given as much to do as possible, otherwise if not, there is always the simplified version to fall back on. The simplified version should also feature as much, if not all, of the eye-candy of the full-fat version, and be as realistic within the confines of the default system, so that users do not feel punished for choosing to drive the simplified version instead of the advanced version. That way, you cater for as wide a range of tastes as possible. It could also be possible to introduce a third, middle ground version, that shares the core driving controls of the fully advanced one whilst losing the extra complications and gimmicks, but what isn't possible is to provide exactly what each individual wants.

The too long, didn't read version: go as far as you want, but don't forget to include a polished and enjoyable simple/normal to drive version, and then most people will be happy, hopefully. If anyone isn't, then that's life and sadly it's tough luck.

Chris

[AndiS]

Good that you reminded me of long-running scenarios. There was that one where you manage the boiler over a day of work. Not that would certainly mandate some saving functionality. Few are in the position to play for hours without interruption. And it would really be a shame if you fare well and then loose it all over some stupid interrupt.

I was also thinking in too elegant terms before. I referred to ways of making the game save the engine state right with the scenario, so you could have lots of saves of different scenarios, potentially saving the state of several engines (stupid signal-guy digression).

However, on the pragmatic level, many scripters write their own files to some folder. The non-elegant side is that you have to manage them yourself. Tons of old saves can build up that no one cares to delete, but then again, there are more important sources of bloated game folders. In the most simple implementation, you would just have one save per engine, so you cannot play another scenario without loosing the saved state of the first.

A next step would be to mark the current speed with each set of state variables. This would permit the code to find the matching record from a collection of saved states, based on the initial travel speed. Bogus from the IT perspective - saving two scenarios while running at exactly the same speed will perfectly confuse the checking code. But if you add the time of day, the likelihood of confusion is greatly reduced (you would have to run at the same speed at the same time of day while saving two different scenarios, to confuse the checking logic). You could add in the time into scenario, so two different scenarios starting at different times can never get confused. All in all, there is some chance for a home grown solution, that works more or less, if not elegant.


The other interesting point is how much of the full eye candy and other shallow means of satisfaction should you give users of the simple mode. On a first glance, I agree with Chris, in not withholding any fun on a whim. On a second glance, it is great if doing it the hard way yields something on top of what you get the simple way.

A good example is the fireman in MSTS & RW. Firing yourself really gets more performance out of the engine, you clearly experience how you manage to get up some grade (faster) where the stupid A-non-I fails. A bad example is starting the engine yourself. You sure can be proud to know a dozen key presses, but after you succeeded, you get exactly what any noob gets with a simple click - the engine is ready to run.

At the same time, it is important to remember that advanced modes are played for the extra challenge anyway. E.g., people love PZB for the extra thrill to outwit the speed checks and still drive as fast as possible. Likewise, controlling a steam car by whistling for the fireman to move handles is certainly more fun than driving it using simple controls.

[DominusEdwardius]

I'm fairly certain that the loco can be kept the same before and after loading by some clever scripting, but between scenarios is more tricky and I'm not sure totally how It could be done myself unless by some external log file that the previous scenario sets and the second one reads... I digress The problem with longer scenarios is no body will play them, according to DTG I think, the optimum time for a scenario is between 45 mins and 1 hour, after that people simply either do not start, get bored and do not complete or have to complete it in multiple sittings, all of which are far from ideal. The other issue with longer scenarios is testing, the longer the scenario the more time it takes to test it. If you have a 5 hour scenario and a tester discovers the a bug 4 hours in you have to try the scenario to find said bug, after that you have to fix the bug then test it all over again and inevitably another bug will be caused and you end up spending a whole week trying to fix one scenario

All of that means that scenarios do generally have to be split up into "bite size" chunks which plays hell with trying to get a consistent state of an engine throughout a day... I really should look into preserving conditions between scenarios
regards
Edward

[AndiS]

Small idea for carrying over engine state between arbitrary scenarios: You guys abuse the vehicle numbers for so much like head codes and such, you could add another digit which is totally invisible but selects a certain set of changed states. So if zero is default, a 1 in the end will cause state file 1 to be loaded, 2 will load file 2, etc.. Of course, you need to save to the corresponding file, too.

Then you could run your scenario series that uses engine ...1 and alternate running this with another series using ...2. It will not stop people from playing the scenarios in the wrong order, but then again, they may not mind if the boiler state is simply the same as when they complete the previous scenario, even if they go backwards in time. You could, of course, give them an alert when you find time of day being earlier than at the previous save, but who wants that?