Upcoming Games

(UTC times)


Full list
Add a game

Upcoming Events

No events to display

On Game vs Simulation...

You are here: Home > Forum > General > General questions, comments, and issues > On Game vs Simulation...

Page 1 of 2

On Game vs Simulation... 19/12/2011 at 10:28 #25790
Kage
Avatar
65 posts
My 3 cents on the whole Game vs Simulation debate, and the New vs Experienced player divide...
in which I also have a rather large suggestion\comment below

SimSig is a rather difficult game to "get". (I use game here simply for convenience)
Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

Years ago I first tried SimSig when it became free. Only a few sims, not a lot of user interface niceties, no wiki, no beginner sims etc. I went into it knowing nothing about UK signalling practice (I'm from Canada). I gave up trying to figure it out and deleted it. A few months later I tried it again after some research I started to get it a little bit. I would only play sims with ARS, because If left to myself, I'd screw up anything more complicated then clicking a signal now and again. I distinctly remember the original Didcot, any time a train entered or exited the yard, I hard trouble with it. Now, I almost always have ARS turned off (Only for some of the LC's In Peterbourgh now) and now I prefer lots of shunting :D

I think I fall into your target audience. I had the interest in all things rail, I didn't care about graphics as long as it was interesting, reasonably computer savvy, and I still couldn't figure it out at first. I could have easily have tried it again, and It's a fair bet this has happened to some people.

I'll bet most of the people here play it different than me. I've never played multiplayer (Though I did play a chained KX\NLL\Peterborough game by myself once ;D) I like big sims, with the most complex TT's I can find, I play with one finger on the pause key, because otherwise my brain explodes I like to pause when using the phone and when trains enter etc, otherwise I can't manage it very well, I have terrible short term memory...

I don't play some of the older sims anymore due to not being interesting enough for me, and\or being a bit too old for some features I've grown used to.

Now we have some nice small sims to start off with, but new users need all the help they can get if they're ever going to go from the 'played it a few times then deleted' group to the 'core' userbase here.
Take the the Train List. In its first incarnation it was a static list, then a Update button was added, and now its a dynamic list. Realistic? No. But very useful. If you like playing with 100% realism, you never have to press F2, but it's a godsend when you're trying to figure out what mess you've gotten yourself into.

Real signallers are trained on there panels before being let loose, not to mention usually working in teams, and have things like TOPS, simplifiers, controllors\regulators etc helping them. You need to know quite a lot, how interlocking works, names, signal numbers, geography, regulation etc both in real life and in SimSig. (You wouldn't believe how long it took me to figure out what Up and Down referred to!)

Nowadays I prefer complex simulations, complex train movements and shunting, and lots of trains coming and going. I sure didn't when I started, and most people first starting out won't either. Unless they have a very large interest in signalling (like me), and lot of imagination (like me!), and a healthy supply of patience (not so much nowadays :D) they will move on to something else. And let's be honest here, the market for software like this isn't very large to begin with, you need to hook them in that vital first couple of plays...

I keep seeing the phrase "It's fine the way it is". This is correct. However, its also generally from an experienced long time player. Can it get new and improved features? Sure.
I remember when the first scrolly came out. Some people liked it, some preferred the old way. I liked it, I thought it was a good compromise adding flexibility to only having one monitor as opposed to the multiple ones IECC has. I have 2 monitors, and I like the expanded view. I can't live without sticky notes now either.
When the 'can't do anything while paused' feature came out, I didn't like it as it seemed to be a multiplayer feature, which I had no use for as it really interfered with my play style. The latest ones seem to have relaxed it a bit, but I would have preferred to be able to completely turn it off, and leave it to you multiplayer guys.

I read these boards every day. Some suggestions I like, some I don't, but it is slightly hostile to new players who make suggestions, and a us vs them mentality. I've seen lots of good suggestions go down to a hail of "its-fine-the-way-it-is", "devs have no time\they do this on your their own time, be grateful for what you get", "We shouldn't listen to the vocal minority" and so on. And yet I doubt there was anyone who didn't play multiplayer, new or old player who would want that Pause feature, yet it was put in, without being able to turn it off, no doubt at the by someone who plays a lot of multiplayer, and one of the 'majority'

(I need a splitting distant pic here!)

How much of it is due to the long dev cycles SimSig seems to have? I remember when one sim first came out, and it had the beta time lock code still enabled, took about 2 weeks for a new version to get released... but I seem to recall it happening again on another sim, and another having a game-stopping save bug on release, but sometimes the wait between versions is months, if not years.

I wonder if the structure and codebase is slowing things down a lot. Right now there's something like 30 simulation executables, each with copies of the core code, the layout and interlocking data, and the custom code specific to that sim. I imagine when it first started as a commercial product with only a few sims, having everything in one executable was manageable, as it started as a tightly focused IECC simulation, with pretty much the same functionality. Now any change to the core code would potentially need to be done to 30 different versions of the code, with a lot more variation in functionality. Any non-trivial change or bug fix would need to be potentially be implemented in a different way on each sim, which I guess is why we only get refreshes every once in a while. I believe every build every dev makes has to be compiled\vetted by Geoff, and he only has limited time to work on SimSig too, factor in testing (How much is automated?) and you can start to see why it takes so long. Creating a new simulation from scratch is even longer.



Well here's a non-trivial suggestion, but It would take a while at the start but pay off in substantially less development and testing time.

Have you ever thought of moving all the code into a single SimSig.exe, and having a seperate binary .layout file that used some private SimSig API or something? Any changes and fixes would only need to be implemented and tested once, and every sim gets the new feature or fix. The exe could be continually updated a lot more frequently, and if a core bug is found, fixed and tested in days or hours even. The .layout file would only have data, and if the data is isolated from the code, much easier to test and update.
It would function as a loader menu, If you wanted, you could have it update the .exe\layouts\timetables etc.

Here's an example off the top of my head:

Central Scotland\NE Scotland and Worksop have 3 different versions of mechanical interlocking, and since the core code was never intended to support that, its sort of hacked in there in the custom sim code.
Personally, I like the mechanical stuff, but i bet newer players would be overwhelmed. I like Worksop's system the best, personally, and it would be hard to change the other two to use it.

If all that mechanical code was moved into the core code, all the sim dev needs to worry about is specifying that a block instrument exists what type it is, and who it talks to. The core API will render the controls and provide the actual functionality. If you currently wanted to switch systems, say NE Scotland to Worksop's system, it would be a royal pain, as you'd have to test both the code and the data, as right now they're pretty dependent on each other, and any change in the layout data would require changing something in the code, and vice versa, with all the knock-on effects and increased testing that would require.
Not to mention you'd have to do it all over again for other sims..
Fixes and updates would only need to be tested against one codebase, and switching out for a new block system would be straightforward, as long as each mechanical module had the same interface, you could have multiple modules, from the ultra-realistic to easy-mode simplified, and the sim layout isn't affected in the slightest.

All it needs to know is that there should be a block instrument here. It does not care how it looks, or about the details of how it works as far as user input or how its coded to work as a simulated instrument.
Does that make sense?

The layout data is fairly static, other than typos or new information found it shouldn't be affected by code changes, and you would be able to test the logic free of any concern about the actual implementation. Most of the testing could be automated, computers are far better than any humans at repetitive stuff like this.
If a sim developer only has to worry about the layout and not the code, I bet it would take a lot less time to develop, and you could have more developers who wouldn't need to know about the intricacies of the core code.

I know the SHumberside layout is being updated, would it be quicker and better if changing the layout didn't require changing the code as well? Would it be easier to implement radically different eras?

Something like this would be a large project, with not very much visible to the end user, and take quite a while, but from what I can tell, all you devs are going to find it harder and harder to add new things in, and fix old things. A project like this, you'll eventually be spending more time and effort trying to keep 30 different codebases up to date, and new features could be way easier to add, that would be available in every sim right away. Heck you could probably do it in stages. How much time do you spend fixing the same bug, and then making sure it works on everything? Once you find a new bug, add a new test to your test suite, fix bug, run test suite, you know you haven't broken anything else, and since the layout data is nice and decoupled from the code, you know it will automatically work for all sims

Wouldn't it be nice when a user reports a code bug, to reply in a few hours, Fixed in exe v2.555, please download, and KNOW that the bug is fixed in ALL sims?

Wouldn't it be nice of sim devs could concentrate on the layout and sim data and not have to worry about code?

To Geoff and the other devs:
I don't expect you to do any of this, (If I could make people do what I want, I'd have you send me all your pepsi and interesting rail books :D)

Your time to work on any SimSig stuff is limited, your time should be spent on making new sims, and adding features and ahem 'research', much more fun and interesting than bugfixing and manual testing

Note: I am not interested in making SimSig conform to only my ideal. I'd just like to improve the experience for everyone.

OK, I should really cut back on the caffeine... nahh...

Last edited: 20/12/2011 at 09:34 by Peter Bennet
Log in to reply
The following user said thank you: postal
Re: On Game vs Simulation... 21/12/2011 at 09:30 #25949
clive
Avatar
2789 posts
" said:

I read these boards every day. Some suggestions I like, some I don't, but it is slightly hostile to new players who make suggestions, and a us vs them mentality. I've seen lots of good suggestions go down to a hail of "its-fine-the-way-it-is", "devs have no time\they do this on your their own time, be grateful for what you get", "We shouldn't listen to the vocal minority" and so on.
On the other hand, it only requires either Geoff or I to like a suggestion and it does get done, no matter how vocal the opposition (eventually - we are limited for time). If anyone else who has access to our bug tracking system likes it, it has a good chance.

Let me make this clear: I do want to hear suggestions of how SimSig can be improved and I'm sure Geoff does as well. It doesn't mean that we think that every suggestion is an improvement, and it doesn't mean every suggestion can be implemented. But anything that's described politely and with rationale behind it will be given a fair hearing. I don't want to see people just shouting down ideas because they're unfamiliar or come from a newbie (but it's reasonable to explain to newbies why things are the way they are).

(For the avoidance of doubt, that is my personal view and not (yet) a forum policy.)

Quote:
And yet I doubt there was anyone who didn't play multiplayer, new or old player who would want that Pause feature,
Actually I think it pre-dates multiplayer; it's been around a long time.

Quote:

I wonder if the structure and codebase is slowing things down a lot. Right now there's something like 30 simulation executables, each with copies of the core code, the layout and interlocking data, and the custom code specific to that sim.
[...]
Now any change to the core code would potentially need to be done to 30 different versions of the code, with a lot more variation in functionality. Any non-trivial change or bug fix would need to be potentially be implemented in a different way on each sim,
Um, do you know anything about commercial software development? Things just don't work like that.

There is one master copy of the core code source. This gets bugs fixed and features added and, every now and again, is used to build what is effectively a library that gets sent to the sim developers. Fixes are not put into older versions - if a developer wants a bug fix, they have to move to the latest version. More on this below.

Quote:
I believe every build every dev makes has to be compiled\vetted by Geoff,
You believe wrong. Releases get vetted (and not even releases to testers, just public ones).

Quote:
factor in testing (How much is automated?)
Testing is done by the sim developer and those who he's asked to assist him. Geoff doesn't do it. (Very little is automated for various reasons.)

Quote:

Have you ever thought of moving all the code into a single SimSig.exe, and having a seperate binary .layout file that used some private SimSig API or something?
About 14 years ago (no, that is not an exaggeration).

Quote:
Any changes and fixes would only need to be implemented and tested once, and every sim gets the new feature or fix. The exe could be continually updated a lot more frequently, and if a core bug is found, fixed and tested in days or hours even.
{mode=sarcasm} Would you like some egg-sucking lessons? {mode=normal}

Let me give you one example of why this isn't anywhere near as easy as you make it sound.

I'm currently working on a new feature for the core code that affects the way in which timetables work. Based on developer comments so far, I expect it to be received rapturously by most players. Now about 98% of this feature will work automatically as soon as you rebuild a sim with the new core code, but there will be a few places where the layout information needs to be changed and, for a range of reasons, it isn't possible to automate that last 2%. Furthermore, if it isn't done then the feature will look really horrible and broken. So I have two choices. I can disable the feature by default and require sim developers to put a significant effort in to make it available, or I enable it by default but say that all sims (yes, even Drain) require changes - albeit minor ones - to use versions of the core code later than N.NNN. I've chosen the latter.

Quote:
The .layout file would only have data, and if the data is isolated from the code, much easier to test and update.
You don't know anything about this stuff, do you?

Quote:
Central Scotland\NE Scotland and Worksop have 3 different versions of mechanical interlocking, and since the core code was never intended to support that, its sort of hacked in there in the custom sim code.
[...]
If all that mechanical code was moved into the core code, all the sim dev needs to worry about is specifying that a block instrument exists what type it is, and who it talks to.
More eggs.

Quote:
The layout data is fairly static,
Sounds of hollow laughter.

Quote:
If a sim developer only has to worry about the layout and not the code, I bet it would take a lot less time to develop, and you could have more developers who wouldn't need to know about the intricacies of the core code.
The sim developers don't know about the intricacies of the core code.

Grandma, your "suggestion" is how it works.

Log in to reply
The following users said thank you: postal, Sam Tugwell, delticfan, Phil-jmw, GoochyB
Re: On Game vs Simulation... 21/12/2011 at 13:05 #25967
maxand
Avatar
1637 posts
Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.

Having said that, I have to concur with you on a lot of what you said.
Quote:
SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?

Quote:
I have 2 monitors, and I like the expanded view. I can't live without sticky notes now either.

Sticky notes are a great innovation - I wonder if IECC panels have them?
I think I'll have to sell my 2 Tb drive and buy a second monitor. :)

As you say, the older we get, the worse short-term memory becomes. When it comes to mind training applications that might stave off the development of Alzheimer's, SimSig would have to be at the forefront.

I have to agree with you that it's inevitable that as sims increase in area, complexity and number, the development bottleneck will worsen. The reasons for it appear to be:

1) It is easier to write custom code to handle the local peculiarities of each sim than to write a one-size-fits-all package for which we can write layout scripts, as you and I have both suggested. Although programming is hardly rocket science, each sim as you've noticed contains a great deal of intricate, handcrafted code which would take a bit longer to learn to debug - unless you are prepared to spend time getting up to speed. More pertinent is Clive's reply to one of my posts:

Quote:
It's a lot easier to keep the relevant development tools under control than to chase down the creators of unauthorized sims.
2) The developers insist on "quality sims". Clive again:
Quote:
I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

Frankly, I think the user base, not the devs, should be the judge of this. I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim. Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

That about sums it up for me. Pity.

The woods would be very silent if no birds sang there except those that sang best.
-Henry Van Dyke

Last edited: 21/12/2011 at 13:25 by maxand
Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 15:11 #25972
postal
Avatar
5265 posts
Online
" said:
Frankly, I think the user base, not the devs, should be the judge of this.
I am not a developer or writer but I am happy to use the product of voluntary efforts. I would be embarrassed to keep posting such arrogant messages which can only help to make the developers wonder why they bother.

“In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe
Log in to reply
The following users said thank you: delticfan, dmaze, andyb0607, Steamer, Phil-jmw, GoochyB, Signalhunter
Re: On Game vs Simulation... 21/12/2011 at 15:56 #25975
Kage
Avatar
65 posts
Quote:
Actually I think it pre-dates multiplayer; it's been around a long time.
I was referring the the change to the pause functionality where you can't do any operations while
paused, as far as I know, that was introduced in brighton and the exeter\westbury refresh in June.

Quote:
Um, do you know anything about commercial software development? Things just don't work like that.
I can hardly claim to be an expert, but I know enough at least to have a discussion on it...
As far as I know, even if the core code is a library, there are still ~30 different projects, each with there own custom code. If I'm mistaken, OK then. But if the core code, custom code, and layout\model data are still that tightly coupled as they appear to be, then yes there are some ~30 different code bases. If SimSig was built for a commercial client, and they asked for a change like the one you mention to Timetable, how long would it take to make the change in the core code, apply it to every sim, and completely test and fix all of them?

Quote:
There is one master copy of the core code source. This gets bugs fixed and features added and, every now and again, is used to build what is effectively a library that gets sent to the sim developers. Fixes are not put into older versions - if a developer wants a bug fix, they have to move to the latest version. More on this below.
There is a custom code portion as well is there not?
If the core code is something binary linked library, Any change to the library could possibly break the custom code. If you're merging the core code with the custom code, well, dealing with merge conflicts can get extremely aggravating. Either way, that's a lot of testing that needs to be done, which I gather is done primarily by the old Mk. 1 Eyeball, and the longer the interval between updates, the harder it gets.

Quote:
Quote:
I believe every build every dev makes has to be compiled\vetted by Geoff,

You believe wrong. Releases get vetted (and not even releases to testers, just public ones).
Pardon me. I used the wrong word. I recall a post where it was mentioned that Geoff was the only one
who could compile a sim, as everyone was waiting on a bug-fix, which Geoff didn't have time, or was sick...

Quote:
Testing is done by the sim developer and those who he's asked to assist him. Geoff doesn't do it. (Very little is automated for various reasons.)
I read this post
on how time consuming the testing was, and wondered why there wasn't any sort of
automated unit testing suite, as I would have thought the sheer number of possible permutations
would have made manual testing prohibitive...

Quote:
{mode=sarcasm} Would you like some egg-sucking lessons? {mode=normal}

Sorry, that euphemism went right over my head ;D

Quote:
Let me give you one example of why this isn't anywhere near as easy as you make it sound.

I didn't intend to make it sound or suggest it would be easy, exactly the opposite, nor would it be easy... If your development can be faster, easier to change and more reliable...

Quote:
I'm currently working on a new feature for the core code that affects the way in which timetables work. Based on developer comments so far, I expect it to be received rapturously by most players. Now about 98% of this feature will work automatically as soon as you rebuild a sim with the new core code, but there will be a few places where the layout information needs to be changed and, for a range of reasons, it isn't possible to automate that last 2%. Furthermore, if it isn't done then the feature will look really horrible and broken. So I have two choices. I can disable the feature by default and require sim developers to put a significant effort in to make it available, or I enable it by default but say that all sims (yes, even Drain) require changes - albeit minor ones - to use versions of the core code later than N.NNN. I've chosen the latter.
I understand what you are saying, and thank you for your effort, in case you might have a suspicion I don't appreciate you and the rest of the people who work on SimSig.
It's in my weird aspie nature to figure out how things work and poke at things :D

I'm not sure exactly what the layout data contains, I figure it has all the visual elements, and the model data and logic for everything. As far as I know the only thing the data has to do with the core code timetable is that it contains the list of timing points and other timetable locations. The layout should not be dependent
on an specific implementation of the Timetable class. If it was only dependent on a ITimetable interface, you could swap in new implementations as needed.

If your logic data was only dependent on an ILayout, you could set up a really good automated test, where it used a mock non visual ILayout to automate sending UI events. Since it wouldn't need to have any visuals or users clicking things, it would be very fast, not to mention more reliable than manual human testing.

As I mentioned before I don't claim to be an expert in software development, but it seems that

Any change to the core code can potentially break either the custom code, or the layout data
Any change to the custom code can potentially break the layout data.
Any change to the layout data can potentially break the custom code.

For instance, say the dev of NEScot wanted to use Worksop's mechanical box code.
Since it's not a core function, it would require a lot of work to integrate it, and require the layout data to use the different controls and logic, and a lengthy period of manual testing. Not something that's entered in lightly, and would probably only be done on a major refresh, which seem to be on a cycle of at least a year or two, depending on available dev time. Also, since its not in the core code, any changes or fixes to that system need to be made twice, which leads to higher risk of bugs.

Quote:
Quote:
The .layout file would only have data, and if the data is isolated from the code, much easier to test and update.

You don't know anything about this stuff, do you?

As far as I know, separation of the UI visuals, the UI code and program logic should not be coupled as loosely as possible, as it makes changes and testing exponentially more difficult.

Quote:
Quote:
The layout data is fairly static,

Sounds of hollow laughter.

Sorry, did I miss something?
The layout data only needs to be updated as far as I can see, to fix
things like typos, and corrections to the model data, ie signal logic.

When a paged sim is converted is converted to a scrolly sim for example,
The visual data representing the controls should for the most part stay the same, except for the circuits that used to span across pages. The underlying model representing all the signal and track logic for the most part should be the same.

Quote:
The sim developers don't know about the intricacies of the core code.

I stand corrected. Who writes the custom sim code then? I assume either you or Geoff, which again
runs into the limited dev time issue.

Log in to reply
The following user said thank you: maxand
Re: On Game vs Simulation... 21/12/2011 at 16:25 #25976
andyb0607
Avatar
260 posts
Quote:
but what matters most is enjoyment and playability
I tend to stay out of discussions like this but all the bickering and sniping currently taking place on this forum is adversely affecting my own enjoyment and playability.

I’m all for suggestions for improvements that are in the nature of the “simulations” but what we seem to be getting is a continual attack on the devs, who, lets not forget, give up their own time and energy to create the “simulations” we have all come to enjoy.

So much so that if you really think that there is so much wrong with SimSig why use it at all?

This thread was given the title of Game vs Simulation. At the end of the day this is a simulation, so for me, accuracy and authenticity is the most important part. Once you have mastered the way SimSig works then enjoyment and playability kicks in.

When I first started to use SimSig I had a rough idea how the railway was signalled in the UK. Only by using the sims over and over again and working out how things worked, and a fair amount of disaster recovery, did I get to the level I’m at now.

Signallers spend months learning their craft and I for one am happy that SimSig gives me a real insight into the jobs they all do extremely well.

So come on everyone give our devs a break and remember that this isn’t a game it is a simulation of real life signalling. What’s more it is a FREE simulation, so remember to click on the donation button every now and then to help support it. Just remember that other signalling/dispatching sims/games are available out there that cost a hell of a lot of money and are no where near as authentic as this.

Log in to reply
The following users said thank you: Steamer, delticfan, Meld, Phil-jmw, postal, NCC1701
Re: On Game vs Simulation... 21/12/2011 at 16:44 #25980
indian_railways_fan
Avatar
72 posts
" said:
Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.
I think you have summed up the problem rather nicely which is the lack of knowledge on your part about signalling and operations on a railway.Before criticising Simsig so much in the forum,you should go back and brush up on your knowledge about signalling and even more important is your knowledge about railway operations.You need to get into the mood of a signal box or PSB or panel to really appreciate Simsig.What you call idiosyncrasies of British railway signalling are actually what makes these simulations so interesting.It is not the simulation but the authenticity with which it manages to reproduce these so called idiosyncrasies which makes Simsig so interesting that we spend hours in front of the simulation without regard for anything else.

" said:
Having said that, I have to concur with you on a lot of what you said.
SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.
I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?
It is the process of actually "getting" it that makes these simulations so interesting.It is for that we eagerly lookout for new simulations.It is one of our most interesting times to download and install a sim just to see what it has and what is new in it.As far as the graphics are concerned,let me again remind you that in most instances,Simsig is trying to reproduce the conditions on real panels and real panels have only 2D displays and are relatively simple.If you are not familiar with this,then I would suggest you visit flickr where there are thousands of such pictures of real panels so that you can get a feel for them.I have,I think written this earlier also and would like to remind you that Simsig is not a commercial product which needs to be continuously improved or tailored to a client's needs or shortcomings but a simulation which is more directed towards reproducing the conditions in a PSB and if these conditions are difficult them Simsig should also be difficult.

Needless to say that inspite of your repeated criticisms about the graphics,the software is immensely complex and has taken years of hardwork to complete and is still undergoing improvements.Regarding your uppercase comment,that is probably because real panels also have almost everything written in uppercase to make the text more visible.Also please remember that the lack of flashiness of the graphics means that a person can work for long hours on the computer screen without straining his eyes.Windows default colours would probably cause much eye strain.On a six or eight hour shift,the operator would need to constantly stare at the screen and the Simsig graphics are very soothing to the eye.Please note that real IECC terminals also have the same colour scheme.

Let me remind you--please learn more about signalling and operations first and only then can you really appreciate Simsig.

Khalid.

Log in to reply
The following users said thank you: delticfan, BarryM, Peter Bennet, andyb0607, Sam Tugwell, bfcmik, Phil-jmw, Meld, postal, NCC1701, TimTamToe
Re: On Game vs Simulation... 21/12/2011 at 16:55 #25983
Kage
Avatar
65 posts
" said:
Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.

Quote:
I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this.
Gameplay always trumps graphics for me :D
The first IECC was in 1989, it's early 80's display technology. Also makes it easier to simulate as well..
That's why I like SimSig, realism miles above anything else out there...
My favorite though are the big NX panels, lots of lights and colours, very tactile...

Quote:
Sticky notes are a great innovation - I wonder if IECC panels have them?

Nope, but NX panels are covered in them, as well as magnets, posters, notices etc.

I don't think SimSig is an IECC simulator anymore, its trying to be a bit more of a generic panel simulation,
what with the transition to scrolly etc.

Quote:
As you say, the older we get, the worse short-term memory becomes.

Mine is already bad, I get a call that a train is entering somewhere, by the the time I close the window,
I've forgotten where it is, and what it's called. Then I realize a class 1 is stopped at a junction somewhere...


Quote:
2) The developers insist on "quality sims".

I insist on them too...

Quote:
Quote:
I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?


I think there's a financial and work related aspect here. One of the disclaimers was something along the lines of 'only for personal entertainment use only, not to be used for the training of signallers'

1) Legal issue, so no one can sue them if someone attempted to train professionally, and screwed up
2) TRE makes professional training simulations, with real controls, and multiple monitors, and assessor stuff, lots of custom stuff, very expensive, and would probably be rather annoyed at Geoff if any company could make there own for free...

I also think that he does need to maintain a certain level of quality, or it would reflect badly on TRESIM.

Quote:
Frankly, I think the user base, not the devs, should be the judge of this.

Careful there...


[quote]I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim.
Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

I recall at least one sim the dev had problems finding out a couple of TC lengths, but since they were plain line, he gave a good approximate figure. Since we can't have IECC's any more, its tricky to shoehorn other types of panels in to software that was originally only designed to be a strict IECC simulator.

I may not agree with some decisions, but I think they've done a pretty good job expanding.

Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 17:12 #25987
Steamer
Avatar
3985 posts
" said:
I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications.

I would imagine SimSig would continue the way it does. Other companies produce sims with flashy graphics and easy-to-use software, but the point of SimSig is to simulate things as they are, and the displays are accurate to those of a real IECC- look at the spash screens on Wembley Sub for example. Case in point: PC Rail appears to provide lots of things you want: easier interface, custom colours, smaller areas etc. However, I prefer SimSig because it is more true to life, for example it has slots and a more in-depth telephone, and realistic ARS. Also, scine the UK is quite away off developing moving block technology (the only in-train signalling is on a branch line in Wales and is fitted with Level 2 ERTMS as far as I know), those types of Sims probably won't be around for a while.

" said:
Sticky notes are a great innovation - I wonder if IECC panels have them?

Admittedly no, but since most Sims are actually based on Power Signal Boxes (PSBs), for example Bristol, I imagine this has been provided to simulate the physical post-it note stuck on the panel.

" said:
The developers insist on "quality sims".

Why he inverted commas? They are highly realistic Sims, which a lot of people on the forum view as high quality!

" said:
Frankly, I think the user base, not the devs, should be the judge of this.

Can I point out that the user base consists of more than yourself? As has been said before, SimSig exists to provide realistic Sims. The fact that PCRail, Train Dispatcher and others exists is testement to the fact that there are sub-markets in the general Signalling simulation market, and SimSig caters for those who like realism.

" said:
I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim.

An excuse for what? Of course, some compromises have to be made since some things would be very difficult to code, but that shouldn't stop us aiming for realism.

" said:
Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

People such as myself find SimSig enjoyable and playable, because it is realistic.

Can I also echo the comments made by Andyb0607- I also knew fairly little about signalling practices when I started, and had to learn from scratch. Please stop attacking the developers at every turn and assuming bugs where there aren't any, and as andy says, remember they are uner no obligation to do the work they do and appreciate that. I'm reminded of an old phrase we like to say in Lancashire: "Like it or lump it!" Suggestions for Sim improvement are good and valued, however please remember the aims of SimSig.

"Don't stress/ relax/ let life roll off your backs./ Except for death and paying taxes/ everything in life.../ is only for now." (Avenue Q)
Log in to reply
The following users said thank you: Sam Tugwell, delticfan, postal, TimTamToe, NCC1701
Re: On Game vs Simulation... 21/12/2011 at 17:54 #25989
Peter Bennet
Avatar
5402 posts
I was going to add something further but as I've the attention span of a gnat I lost the will to half way through reading some of this stuff and now I've forgotten what I was going to say.

Oh yes
Quote:

maxand wrote:
I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim.
Quote:

An excuse for what? Of course, some compromises have to be made since some things would be very difficult to code, but that shouldn't stop us aiming for realism.

It'd be a damn site easier is we weren't so rigid as we could build any old things really quickly.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 18:15 #25991
Sam Tugwell
Avatar
494 posts
Maxand said:
Frankly, I think the user base, not the devs, should be the judge of this.
A bit of a strange one. You would expect the Developer of a sim to be proud of their work, which would have taken (even for a small sim like Lime Street - Cheers Matt for a great little sim) a lot of time and effort to build.

It seems Max that you are suggesting that a developer should let ordinary members (you and I) decide whether a sim is realistic. Have you been to a signal box to get the data needed to make a sim? I highly doubt it. Therfore, the developer (more often than not) will have a more reliable opinion of the realism involved in a sim than the majority of users.

Also, you should consider the fact that a sim isn't always going to be completely realistic no matter how much development and testing time is put into the sim.

Maxand said:
I agree the graphics reminds me of those on the first computer I ever bought. Practical but incredibly primitive, particularly the unrelenting upper case.
I don't have a problem with the graphics, they add to the realism for me...

"Signalman Exeter"
Last edited: 21/12/2011 at 18:33 by Sam Tugwell
Reason: Mispelling "Quote"

Log in to reply
The following user said thank you: delticfan
Re: On Game vs Simulation... 21/12/2011 at 18:22 #25992
kbarber
Avatar
1743 posts
" said:

Quote:
SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?

My late father was an even older railwayman than me... he retired as Chief Divisional Movements Inspector of the South Central (nowadays Southern Railway, Three Bridges (ie Brighton & Croydon) & Oxted made up part of his area). In his papers, that I inherited, was a copy of the first British Rail spec for VDU interface. The first one to be commissioned wasn't an IECC, it was an expeimental installation to drive part of an otherwise conventional NX relay interlocking in Leicester PSB; along with the experimental Automatic Routesetting in Three Bridges and the experimental Solid State Interlocking at Leamington Spa it was part of the process of developing IECC. Leicester PSB was commissioned, IIRC, around 1986.

The spec looked exectly like the screens that appear in SimSig; nice try but it's actually over 25 years since these graphics were developed. Those British Rail types (even the boffins at Derby Tech Centre) knew what they were doing.

And the managers and inspectors and signalmen who had to use them knew what they were doing too. And the fact is that these ancient-looking graphics now serve extremely well in controlling many miles of intensively-worked main line and busy suburban areas. This is what the professionals use - and I've heard nothing, not a peep, to suggest they're not happy. So why would we want whizzy new eye-bending artificial fireworks if it doesn't help control the trains any better?

If it's good enough for the guys doing the job day in day out to make a living (and I know for a fact there's some here on this forum) it's absolutely good enough for me.

Last edited: 21/12/2011 at 18:24 by kbarber
Log in to reply
The following user said thank you: delticfan
Re: On Game vs Simulation... 21/12/2011 at 18:47 #25993
tccb
Avatar
14 posts
Perhaps it might be worth codifying a couple of 'core values' for SimSig.

Could even be as simple as 'SimSig aspires to simulate as realistically as possible'.

Then any new feature suggestion can be assessed against the core values, which is easier and less controversial than assessing it ad-hoc.

Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 18:51 #25994
kbarber
Avatar
1743 posts
" said:
Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.
<snip>
" said:
It's a lot easier to keep the relevant development tools under control than to chase down the creators of unauthorized sims.

2) The developers insist on "quality sims". Clive again:
Quote:
I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

Frankly, I think the user base, not the devs, should be the judge of this. I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim. Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.
[/quote]
Sorry guys, I don't often lose patience, but I think this one needs to stop here.

Max, Kage, the developers give a great deal of time & expertise - in some cases professional in a number of fields (computer- and signalling-related) to produce these sims. They started as a hobby. Get that: a hobby. A hobby which first Geoff then a slowly increasing number of developers have been willing to share with us. As it's theirs, I believe it's their choice how they do it. If we, the users, were paying commercial money for these sims we might have a case for saying it's the users, not the developers who decide what should be made available and how. But I think I can safely say that if we were paying commercial money we'd be lining the pockets of a commercial organisation that would give very short shrift to any user telling them how their product should be packaged and made available.

You feel privileged or not as you choose. I certainly do. As a result of Geoff and Clive's work on the core code and a number of developers' hours spent writing sims and even more testers' spare hours (which sometimes, I suspect, they'd rather spend doing other things - perhaps even being with their families!!!) we have some of the best sims there are. They are good enough to be used for training real-life signallers - and Geoff spends his working life writing SimSig's big brother to do exactly that! As it's something he does purely out of his own generosity (and, I suspect, at some personal expense), I reckon Geoff is fully justified in deciding how his product is produced and distributed. And quite frankly, after some of what's been said in this thread, I could hardly blame him if he simply wrapped up the whole thing & pulled SimSig entirely! Clive likewise, particularly as he has taken your comments very seriously (when even senior and respected people here were telling you to shut it).

I think a little more gratitude might be in order. If you don't like realistic sims of real places, develop your own tools, do your own research and produce your own - but don't assume you can lift stuff from SimSig and don't expect us follow you if you can't provide an authentic-feeling environment, even if it is bright and new and shiny.

Oh, and if you don't like learning a bit about signalling principles & practices and how it was actually done in real life, I hope you're never faced with a decent simulation of a mechanical box working absolute block... then you would have something to complain about!

Sorry if this comes across a bit strong and hurts what I was beginning to think of as a friendship. But I believe certain boundaries need to be maintained and this, I'm afraid, is one.

Last edited: 21/12/2011 at 18:52 by kbarber
Log in to reply
The following users said thank you: Sam Tugwell, AndyG, Steamer, ralphjwchadkirk, Prof Jolly, Firefly, Hooverman, officer dibble, Phil-jmw, ipswich, andyb0607, Silverstar, Meld, delticfan, MikeW, TimTamToe, Kage, crompton
Re: On Game vs Simulation... 21/12/2011 at 19:23 #25997
ralphjwchadkirk
Avatar
275 posts
Well said kbarber.
Log in to reply
The following users said thank you: delticfan, Phil-jmw
Re: On Game vs Simulation... 21/12/2011 at 21:50 #26015
clive
Avatar
2789 posts
" said:

As far as I know, even if the core code is a library, there are still ~30 different projects, each with there own custom code.
Yes, but the custom code is a relatively small part, and getting smaller as the core code develops.

Quote:

If SimSig was built for a commercial client, and they asked for a change like the one you mention to Timetable, how long would it take to make the change in the core code, apply it to every sim, and completely test and fix all of them?
A fair while, but that's because it's a feature that interacts with the data. A change to the core code that doesn't (e.g. a change to train dynamics) wouldn't need to be tested with every sim.

Quote:
If the core code is something binary linked library, Any change to the library could possibly break the custom code.
Yes; another reason why we're trying to get rid of custom code.

Quote:
and wondered why there wasn't any sort of automated unit testing suite
Because there isn't any obvious way of doing it. The vast majority of bugs in simulations are errors in the data that cause it to behave in an unintended way. The sort of stuff that can be detected automatically is.

Quote:
I'm not sure exactly what the layout data contains, I figure it has all the visual elements, and the model data and logic for everything. As far as I know the only thing the data has to do with the core code timetable is that it contains the list of timing points and other timetable locations. The layout should not be dependent on an specific implementation of the Timetable class. If it was only dependent on a ITimetable interface, you could swap in new implementations as needed.
The layout code isn't dependent on a specific implementation of the "Timetable class" (I know what you mean, but that's not what it's called). The problem is that this new feature requires a change to, in your terms, the "ITimetable interface". More specifically, it requires the developer to distinguish between two types of simulation entity that, up to now, haven't been distinguished.

Quote:
If your logic data was only dependent on an ILayout, you could set up a really good automated test, where it used a mock non visual ILayout to automate sending UI events.
And how does it know what the effects of those events is supposed to be? By looking at the logic data? But that's precisely where the bug will lie!

A compiler can tell me if I've used an undeclared variable or tried to mix integers and pointers. It can't tell me that I've written "x + y" when I meant to write "x - y".

Quote:
it seems that

Any change to the core code can potentially break either the custom code, or the layout data
Any change to the custom code can potentially break the layout data.
Any change to the layout data can potentially break the custom code.
All three are true. The first means that Geoff and I need to be really careful when we change the core code. The other two mean that developers have to watch what they are doing. But none of these errors are automatically detectable.

Quote:
For instance, say the dev of NEScot wanted to use Worksop's mechanical box code.
Since it's not a core function, it would require a lot of work to integrate it, and require the layout data to use the different controls and logic, and a lengthy period of manual testing.
Yes.

Which is why Geoff will need to decide, at some point, whether mechanical box logic is something that he wants to include in the core code. At which point adding it to a new sim will be a matter of altering the data slightly.

A similar example is AHB level crossings. The AHB in Royston was custom code. In some later sims it became an optional module which custom code could use to create crossings (such as the 29 crossings in Cambridge). Now it's part of the core code and a dev adds an AHB with a few lines of additional sim data.

Quote:
Quote:
Quote:
The layout data is fairly static,

Sounds of hollow laughter.

Sorry, did I miss something?
The layout data only needs to be updated as far as I can see, to fix
things like typos, and corrections to the model data, ie signal logic.
I.e. the location of 99% of the bugs in simulations.

Quote:

When a paged sim is converted is converted to a scrolly sim for example,
The visual data representing the controls should for the most part stay the same, except for the circuits that used to span across pages. The underlying model representing all the signal and track logic for the most part should be the same.
True, but such conversions aren't difficult or require much testing for just that reason. But a refresh rarely consists of just converting to scrolly.

Quote:
Quote:
The sim developers don't know about the intricacies of the core code.

I stand corrected. Who writes the custom sim code then?
The sim developers do. But they only need to know about a few function names and such-like; they don't need to know about 99% of the core code. Setting a route doesn't require them to access or understand the hundreds of lines that implement route setting, just to write "R123.Request".

Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 22:41 #26018
clive
Avatar
2789 posts
" said:
It is easier to write custom code to handle the local peculiarities of each sim than to write a one-size-fits-all package for which we can write layout scripts, as you and I have both suggested. Although programming is hardly rocket science, each sim as you've noticed contains a great deal of intricate, handcrafted code which would take a bit longer to learn to debug - unless you are prepared to spend time getting up to speed.
I'm just going to comment on this one bit.

I'm not sure what you think "layout scripts" are. Each sim contains a great deal of intricate handcrafted data which takes a long time to learn to debug. In general, the custom code is a very small part of a simulation, and getting smaller each time. It's perfectly possible to write a large simulation with interesting features with no custom code at all, just data.

For example, the custom code for Euston consists of 151 non-blank lines. Of those, 63 amend the timetable analyser to warn you if a train won't fit into a platform at Euston and 32 deal with penalties for trains leaving the simulation on the wrong line (both features which could be in the core code and may well get added in the future). By comparison, the data for the signals is 374 lines and that for the route setting is 822 lines, none of which is "custom code". WembleySub custom code is about 300 lines, but 280 or so of those could now be replaced by data and probably will be when I do a refresh (I've received information since the first release which requires me to make some changes to the data); the data (which is what I think you mean by "layout script"is just under 2000 lines.

Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 22:52 #26019
Peter Bennet
Avatar
5402 posts
Just to add that Westbury has no Custom code procedures, Swindid 3 procedures (one since removable) and Exeter one procedure.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
Re: On Game vs Simulation... 21/12/2011 at 22:54 #26020
Ron_J
Avatar
331 posts
I have been an occasional user of SimSig on and off for years and a very infrequent contributor to this forum for a short time. I don't really have anything to add to this topic other than my own experience..

I am a relief signaller and currently work a number of mechanical boxes and a medium sized panel box. Although you may think it a bit of a busman's holiday for me, I find playing SimSig quite relaxing. I think a lot of this is derived from the fact that I can ply my trade whilst sitting in front of the tv with my laptop and a beer and if it gets too busy or goes pear shaped, I can close the program and do something else. It's good having the chance to walk away from a sticky situation if I choose to do so, which I certainly can't at work. At the same time, the SimSig environment is so close to the real thing that I find it very natural to play using the real rules and regs. I've been lucky enough to have a go on actual workstations at Edinburgh and York IECCs and found the resemblance to SimSig uncanny.

I suspect I am different to the majority of users in that I have little interest in the monster scrolly sims of recent times, nor do I use multiplayer. I enjoy playing medium sized sims such as Stafford and Southampton - I started way back with Didcot, which I enjoyed immensely. These reflect the size of box which I am used to in real life and have enough workload to make the experience for a single player challenging without becoming a chore. I'd like to see more sims like this, rather than the larger releases that I struggle to keep on top of on my own.

In conclusion, as someone who already has a solid foundation in signalling principals, theory and practice, I think SimSig has struck exactly the right balance between ultra-realism and the compromises necessary to make for fairly easy gameplay. Once you know your way round the quirks of a particular area, it is a very rewarding way of wasting a few hours. I can certainly see how someone coming to the game with no knowledge of UK signalling practice would be completely baffled, but I'm not sure that is really a concern for the developers. If you're willing to start small, put in a little bit of extra-curricular effort and - crucially - recognise that SimSig is a simulation then there's no reason why you shouldn't get hours of of enjoyment from it. If you don't like the graphics, or struggle with the seemingly arcane rules then perhaps you'd be better sticking with one of the more 'gamey' PC Rail type offerings.

Log in to reply
The following users said thank you: Phil-jmw, Hooverman, AndyG, postal, Firefly, Forest Pines, Steamer, TimTamToe, guyh, NCC1701
Re: On Game vs Simulation... 22/12/2011 at 00:28 #26028
Danny252
Avatar
1461 posts
" said:

Quote:
SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?
Very, very rarely do industrial programs (which reflects an IECC better than "commercial"have "pretty" interfaces. They show the information required and accept the necessary commands, and that's about it. Why make it look pretty? It merely takes more time to code and debug, which will therefore cost the customer more, and only distracts the operator from the job at hand when doing it.

The most modern signalling technology (Switzerland) has apparently seen no reason to diverge from IECC practise: http://i219.photobucket.com/albums/cc317/keithjn/Switzerland/KW20020916001OltenETCSdesk.jpg

Nor does anyone see the need for a flashy driver-side display on the same system: http://photos.signallingnotices.org.uk/photo.php?pc=387&p=IMG_8890.JPG

What "you" expect in terms of graphical conveniences is nothing like what professionals expect.

Last edited: 22/12/2011 at 00:30 by Danny252
Log in to reply
The following user said thank you: bfcmik
Re: On Game vs Simulation... 22/12/2011 at 00:35 #26029
Danny252
Avatar
1461 posts
" said:
Quote:
It's a lot easier to keep the relevant development tools under control than to chase down the creators of unauthorized sims.
2) The developers insist on "quality sims". Clive again:
Quote:
I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

Frankly, I think the user base, not the devs, should be the judge of this. I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim. Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.
Simsig prides itself on quality, as compared to the sometimes lacking quality of other sims. User generated content is inevitably going to produce some buggy, low-quality products - take a look at any "moddable" game. The devs don't want to spend time running around answering "how do I code a signal?" and "so-and-so's sim broke my computer!". It actually seems a bit insulting for you to say "they're just making excuses when they say they're trying to be accurate".

Log in to reply
The following users said thank you: ipswich, AndyG, Meld, Prof Jolly
Re: On Game vs Simulation... 22/12/2011 at 00:45 #26030
maxand
Avatar
1637 posts
I wasn't going to add anything to my original post but maybe I should.

Kage:
Quote:
Gameplay always trumps graphics for me

I agree with you there. Whether we think of SimSig as a simulator or a game, the fact that people such as Ron_J find it relaxing to play after work means that it has the elements of a game as well as a sim - a sim game. Obviously the word game has different connotations for different people here, and I don't propose starting a discussion about the difference, but the elements of a game are now fairly well defined, and SimSig fits them rather well, which explains its addictive properties.

Therefore as SimSig evolves to cope with an increasingly wider range of localities and technologies, it is important that its developers and timetable writers not get carried away with macho complexity but keep a regular eye on whether their creations stay within the capability of single players who use the game to relax, rather than attempt the impossible. I think multiplayer games are a great idea, but haven't got time for them right now. So multiplayer-size sims are out as far as I'm concerned. Even some of the "smaller" sims I feel should be also be made available as workstation-sized chunks which could be chained together, and with timetables to match. Maybe if I can't break down the sim to my size, I can at least write a timetable for part of it that enables me to concentrate on a particular area, and enjoy that. But since nobody else seems to be doing this, I guess I'll have to work at this myself.

One of the elements of a game is a level playing field.

A lot of you took me to task for writing
Quote:
Frankly, I think the user base, not the devs, should be the judge of this.

about what I termed "quality sims".

Even Sam Tugwell said
Quote:
It seems Max that you are suggesting that a developer should let ordinary members (you and I) decide whether a sim is realistic

I'm no expert on any of these localities so can't comment on realism, but I do know when I find a sim enjoyable to play and when I don't. For example, signal 76 in the Bristol Modern Era sim desperately needs to be capable of automation, but isn't. If I could change it, I would. It's only a minor detail; I don't really care whether it's authentic or not.

I'm not deprecating the standard of the sims already available to us - if anything, some are a little too high for me; some challenges I can do without. I don't get my kicks from realism but from playability. That's what I really meant by letting the user base decide. Relaxation doesn't mean banging my head against a brick wall. The idea for my statement came from other sims where amateurs can are encouraged to submit their own layouts for others to test. The result is a much wider range of quality than seen here at SimSig, but it doesn't take long to weed out the good from the bad. Should we adopt the same policy?

Peter Bennet said
Quote:
It'd be a damn site easier if we weren't so rigid as we could build any old things really quickly.

Is that such a bad thing? Is there any reason not to have a "test sim" area in the downloads section? Remember, Royston never existed at all; 'twas ever only in the mind's eye. As for the Drain...

Last edited: 22/12/2011 at 01:15 by maxand
Log in to reply
Re: On Game vs Simulation... 22/12/2011 at 00:53 #26031
ipswich
Avatar
247 posts
max:

Quote:
signal 76 in the Bristol Modern Era sim desperately needs to be capable of automation, but isn't. If I could change it, I would. It's only a minor detail
but if signal 76 is not an automatic signal in reality why should it be automatic in SimSig because if you did make that signal automatic it brings the realism down

Log in to reply
The following user said thank you: Prof Jolly
Re: On Game vs Simulation... 22/12/2011 at 01:05 #26032
maxand
Avatar
1637 posts
Danny252 said
Quote:
User generated content is inevitably going to produce some buggy, low-quality products - take a look at any "moddable" game. The devs don't want to spend time running around answering "how do I code a signal?" and "so-and-so's sim broke my computer!". It actually seems a bit insulting for you to say "they're just making excuses when they say they're trying to be accurate".
You're trying to combine two unrelated issues here. Accuracy (I presume you mean authenticity) has nothing to do with coding bugs. You should be able to change the dimensions or properties of a layout without causing a bug, and fixing a bug doesn't change layout dimensions.

Accuracy is a self-imposed limitation which is nice to have, up to a point.

Log in to reply
Re: On Game vs Simulation... 22/12/2011 at 04:30 #26035
northroad
Avatar
872 posts
"Accuracy is a self-imposed limitation".[/quote]

You want to try reading all of our Class Rules, SOLAS, SPS code, MARPOL, MSC etc. etc. etc. and then see if accuracy is self imposed.

For the sake of this topic though I personally find Sim Sig to be just fine as it is (keep it up chaps) and cannot understand what all the problems seem to be. Maybe it's an age thing I possess but who needs change...I'm quite happy with what we've got.

Merry Christmas guys from South Korea.

Geoff.

Log in to reply
The following users said thank you: Prof Jolly, Meld, ipswich