Identifying Pitfalls for new Players

[sdog]

Having read a thread responding to a review by Free Gamer blog, i was thought we should try to identify pitfalls and obstacles for new players again. The times seems, right, as the new stable version with network-games has been released most recently.

Starting this, perhaps we can check the issues identified in the thread mentioned above.
- Easy installation of a complete game, running out of the box
- Availability of a tutorial (ingame/online)
- Documentation and Help (bundled/online)
- Tester started his game in a timeframe not supported by the pakset. (default value was fixed)
- music was considered horrible (i know of a friend who couldn't turn it off in an instant and never looked at the game again)
- tricky railway building. (especially double track)

[IgorEliezer]

- Easy installation of a complete game, running out of the box

To be honest, Simutrans has one of most unfriendly installation I've ever known.

I'm afraid most of download centers (like baixaki.com.br) provide only the executable without the paksets, and no further info about. Needless to say, we can guess what happens with the new players who face a back screen and an error "no pakset found".

Another thing, Simutrans starts up in darkness, no splash screen, well, almost all games I know, you just need to run the game, a splash screen of the game welcomes you and then a main menu pops up letting you to set few things, if you want to, and the game is already to start off. If Simutrans doesn't have all things in place, the game doesn't even let you to go beyond the black screen, if you're a newbie, you're doomed to think the game is broken.

Considering Simutrans is distributed mainly without the paksets, Simutrans could have:

- a minimal start-up GUI not bound to a pakset:

If you are a newbie, you'll expect the game will at least run until you get a main menu where you can set the things up, to be warned about the lack of paksets and give you the solution.

You start up the Simutrans, a splash screen is run, then a main menu with languages and paksets is displayed; if there's no pakset installed, a "no pakset found" message is displayed in the list, and a "Download" button is given.

- built-in downloader

Some softwares I know are capable of downloading add-ons, updates and confgs from a list of servers. Simutrans could have a built-in downloader to make everything simple:

1) In the main menu (just before choosing the pakset), you click "Download";
2) Simutrans will try to load a list of available downloads. This list is hosted in simutrans.com. To be precise:
  a) you click "Download" in main menu, Simutrans searches in simuconf.tab for "download_list_address=http://www.simutrans.com/download_list.txt"
  b) then, Simutrans will download download_list.txt which contains a list of available downloads and is easily updated.
  c) once Simutrans has got download_list.txt from our site, Simutrans displays a list of pakset for download.
  d) you choose a pakset, and Simutrans starts to download the pakset and installs it.

[ӔO]

perhaps having a demo.sve for all paksets will help if it includes all forms of transport?

An in-game tutorial for setting up each type of transport would be nice.

[ojii]

- built-in downloader

Some softwares I know are capable of downloading add-ons, updates and confgs from a list of servers. Simutrans could have a built-in downloader to make everything simple:

1) In the main menu (just before choosing the pakset), you click "Download";
2) Simutrans will try to load a list of available downloads. This list is hosted in simutrans.com. To be precise:
  a) you click "Download" in main menu, Simutrans searches in simuconf.tab for "download_list_address=http://www.simutrans.com/download_list.txt"
  b) then, Simutrans will download download_list.txt which contains a list of available downloads and is easily updated.
  c) once Simutrans has got download_list.txt from our site, Simutrans displays a list of pakset for download.
  d) you choose a pakset, and Simutrans starts to download the pakset and installs it.

Completely agree with this! I have no clue how hard that is to do in simutrans, but at least the web part is trivial. Ideally you could even update simutrans itself from ingame. I'd be more than happy to help out with the web part (although my refusal to work with PHP might be a problem, not sure how you guys would feel about having the addon repository/catalog in Django).

[prissi]

Actually some time has passed since the review and things progressed on several places. So here my reply:

easy installation

The web part is not trivial, as it must work on all platforms. So it needs new dialogues etc. which reuires already a basic installation. But then you already used the online installer. If not, it is your fualt, the official download on sourceforge points you to the online installer. And the online installer exists for more than a year. (And for linux simutrans comes usually with the distribution.)

You can download the installer and just click next and you are finished. How difficult of an installation is that? Furthermore it displays the sizes you need and so on. You can install nearly all pak sets with a simple click, in any supported language.

If some other no-official sites provide outdated downloads, then we cannot do anything about it. You can still quite frequently stumble upon version 84.16.4 which is more than seven years old. We cannot do anything about this, but request to only use the official download.

splash screen

There is also a splash screen. But to display it, you have to have some data already, since the images are different for each pak set. There is also basic gui support bundled with the executable.

addon downloader

As for addons: Since there is no central addon repositiory, and anddons could be also used for several pak sets (like all addons for 64 size are interchangeable), a download system is not trivial and would require quite some effort on catalogizing, centralizing, packing the files in the same way etc.

Same even for paksets. The internal packing of the paksets is very different, and the online installer goes quite a way to unpack them.

And online update of the executable is nearly impossible for a cross platform program. It would even require to run simutrans with administrator rights on Vista/7 and would screw up any debian based distribution.

ingame help

You press F1 for ingame help. F1 is the standard key for ingame help (is there a help key for mac?), which is available in many languages. If people cannot press F1 they could eventually click on a question mark, like they could do in any windows (and some other UIs') dialogue. It is not really possible to provide much more ingame help than that.

About tutorials: Nobody wanted to program one yet, although it would be very easy now, with the new tool system working, neraly trivial to allow the execution of scripts.

timeframe

Currently the timeframe can be limited by the pak set. The lowest date is given by the first year where roads and townhalls are avaiblable. That you may have to deal with horses and ships in 1600 should not surprise anybody.

[VS]

Installation... On Linux(es) the default packaging should be enough. On Windows we have the online installer. Elsewhere, the process will be a bit rough anyway and make a small total % (not a fact). The real question is, what about paksets that roam freely around? I think we can safely disregard these...

Central repository for addons would certainly help matters somewhat.

Tutorials? We could make a few on youtube, perhaps.

[ojii]

addon downloader

As for addons: Since there is no central addon repositiory, and anddons could be also used for several pak sets (like all addons for 64 size are interchangeable), a download system is not trivial and would require quite some effort on catalogizing, centralizing, packing the files in the same way etc.

Same even for paksets. The internal packing of the paksets is very different, and the online installer goes quite a way to unpack them.

I don't really see the Problem. Paksets just have to define a manifest where for example they can list dependencies or compatible paksets/resolutions. There wouldn't even be a need for a central repository with the actual packsets, just a catalog of the manifests (provided they include a download link).

[prissi]

Install

On windows I cannot even write to the program directory with restricted rights or I will loose my changes after quitting the program => simutrans needs to ask for administrative rights every time it is started.

On debian, simutrans is even in a directory it is not allowed to access as normal user, you have execute rights only there (and reading rights). => cannot even write a pak set.


Addons

The addons could be easier in principle; if they are just pak files "bzip"ped or "compress"ed then simutrans could handle them immediately. But most are in one or more subfolders, sometimes with source and often in other formats liek zip/lzh/rar/...

Still there needs to be an interface and a site with a list of all addons in their format for a certain pak. However, in most cases the informations about addons is much more than the actual addon downloaded ...

[sdog]

Two years ago i introduced my father to the game. Starting with pak128. Since i installed it, this was not a hurdle. The obstacles in-game i remember the most where, in order of relevance:

a) transporting to not-linked industries
He tried to transport coal from a coal mine to a power plant, however it did not work since both were not linked. It was not obvious to him that the plant did not accept any coal. It could be found, but i had to point him to that dialogue.

b) station not linked to industry
A stop building was one tile to far away from the receiving industry, the trucks waited for full load in a correctly connected stop at the supplier. He suspected such an error, but searched at the supplier side.

c) adjacent station tiles in different stations
Linked to this, when expanding a station he started in one case not at a tile directly adjacent, but one tile away and closed the gap to the existing station. Thus two stations were formed. A transport chain involving transfer of cargo from one to another vehicle was broken.

d) Confusing depot window
In the depot window he was overwhelmed by a multitude of vehicles. It was not immediately clear what was usefull for what purpose. It was also difficult for him to spot cargo types from the small images. (Oil and Milk trailer were also easy to confuse)

e) Station length has to match train length
trains waited for ages to load, as the platform length was not sufficiently long

f) Signals can be cycled to on way signals by clicking again
This and other interface elements, like ctrl-click were not obvious.

g) Uni-Directional Signals block in reverse direction
When using one way signals he assumed that they will not impede trains in the reverse direction, the red light only points into the forward direction. It was also nowhere to be found that they are a signal and a one-way sign at the same time. I had to explain it.
Help files did not help here, as the error in the routing was thought to be somewhere else or more fundamental. The signal seemed to be well understood and self explanatory from it's looks (as i said, red only in one direction, the other is not signaled)

h) trafic jams
he had to find a way to avoid them, not a big issue

i) going bankrupt all the time
not a big problem at the beginning, but after a few weeks he lost interest and gave up the game. He revisited it the next winter and started profitable companies.


Game installation discussion
I've just used the packet installer in ubuntu 10.10 (linux distribution) to install simutrans. The version is a bit outdated, to say the least, it is 102.2.2. Right now we are at 110.0.1. Two pak-sets are also available pak64 and pak128.britain. I haven't checked the version of both.

We should perhaps get in contact with the package maintainers, check if they are even active, and suggest to update it there. Alternatively it would perhaps be interesting to start a ppa repository?

Can anyone please check repositories for other major linux distirbutions? (suse, mandriva etc)

I don't think that pak-set download should be included into simutrans. The way to go is an installer as prissi did. Perhaps it might be a good idea to think about a launcher too, with buttons to download pak-sets automatically and start the binary with a -pak xx option.

Do you really think addons, this does not mean full pak-sets, are relevant for beginners? If someone wants to install addons, she is already experienced enough with the game. We can safely assume such a person is capable of searching and downloading them. On the contrary, making it easy to automatically download addons opens a new can of worms, by having unballanced and perhaps even broken addons in a newb's game. I don't think we want that.

Let new players play with mature pak-sets. That's in my oppinion at the moment only pak64 and pak128. For slightly experienced players pak64.germany, pak96.comic and pak128.britain are very good already, and should be perfect for players who have a basic understanding of the game. There are a few gaps still, that might offset an absolute beginner.

Minimalistic pak-set
As i said before, my father was a bit confused by the multitude of options in the depot. How about a minimalist, beginners pakset. Only one signal type, only one vehicle for each goods category. Perhaps reduced industry supply-chain complexity. Only one type of bridge, rail, road etc. Only one signal type.  No timeline, everything is always available.

It would be only a job of recompiling a sub-set of an already available pak. The standard pak would be the first choice perhaps. It might be even better though to base something like that on pak96.comic, as it looks also very clear. The reduction in detail helps a bit with reducing confusion. It seems to have the best liked look too, winning most SMSC screenshot contests.h

[prissi]

Some of the pitfalls could be easily avoided. Using the "beginner mode", all factories are connected with each other and the income would be larger (1.5x) This was explicitely made for beginners.

pak.Hajo has a very basic choice of vehicles and using standard catchment area size of 3x3. pak96.comic has also only a few vehicles and a very easy economy. Those are better suited for beginners, imho. pak.contrast has also very few trains to play around. pak64.japan has also only 1-2 vehicles, if you play with timeline.

Imho pak128 is not a good choice for beginners, as there are many misbalanced stuff and way too many vehicles. It has also very complex factory chains and very expensive rails and many more pitfalls for beginners.

The adjacent stations can be and was of course discussed, i.e. autojoin stations touching each other. I think this may be the way to go as only very few player use explicitely separate joined stations.

How would you consider draw a signal which cannot be passed from the other side? All transport games (TTD, Locomotion, Transport Giant) use single direction facing signals.

[VS]

Imho pak128 is not a good choice for beginners

True, or at least I hope so...

[IgorEliezer]

True, or at least I hope so...

VS is too evil. D:

[Defacto]

I think we need a tutorital mode, with a helpful little text bubble that tells you how to do stuff and gives you goals to accomplish, and when you're done with that and have built up a small profitable company, you can continue on your own (this should take max 10 minutes)

[prissi]

In simutrans it is nearly impossible to built a profitable company in 10 minutes, at least when passengers are entering the play.

[sdog]

Some of the pitfalls could be easily avoided. Using the "beginner mode", all factories are connected with each other and the income would be larger (1.5x) This was explicitely made for beginners.

pak.Hajo has a very basic choice of vehicles and using standard catchment area size of 3x3. pak96.comic has also only a few vehicles and a very easy economy. Those are better suited for beginners, imho. pak.contrast has also very few trains to play around. pak64.japan has also only 1-2 vehicles, if you play with timeline.

I think a new player will look the last at those two paks. Most go with pak64. I went to 128, i thought 64 was outdated and 128 the new standard when i started. If you want to have pak Hajo as be it should be bundled with the executable. Also get rid of all signals except normal. Throw out everything clutteing the interface. Di types,bridges, different station platform, station extensions, o-buses, tram.

Having a narrow selection of vehicles isn't enough either, they need to be all that is ever needed.

Imho pak128 is not a good choice for beginners, as there are many misbalanced stuff and way too many vehicles. It has also very complex factory chains and very expensive rails and many more pitfalls for beginners.

really? when i tried it first it felt exactly the opposite way to me. pak64 felt very unbalanced, i could get a profitable company in one try. in 128 i needed at least two weeks of constant bankrupcy. But i was comming from openTTD and wanted a bit of a challenge. (it was a complete sandbox, the other game)

The adjacent stations can be and was of course discussed, i.e. autojoin stations touching each other. I think this may be the way to go as only very few player use explicitely separate joined stations.

By all means, if you can implement it without to much work...
it will save you a couple of forum postings.
it should be always on at least in beginner mode.

How would you consider draw a signal which cannot be passed from the other side? All transport games (TTD, Locomotion, Transport Giant) use single direction facing signals.

This might be the case, but it is still misleading. The best sollution would be the way of openTTD, where such signals are ignored in reverse. It could be possible with simutrans, does not need to be an aspect requiring path based signalling.

[prissi]

In TTD you cannot pass through a reverse facing signal, I just tried it again.

pak64 is made to be hard, but just manageable for AI and balanced for all modes of transport.

In pak128 is very simple to make money by road transport but rails are completely out of proportion concerning maintenance and running costs. The AI will never choose trains (if it does not have too) in pak128, since cars are so cheap there. Also the coal line to power station is always working to generate huge income in pak128 (but not on pak64). In pak64 real good chains give more money, especially processed goods like gasoline, books, ... (And a filling station chain is not very complex).

pak96 was made to generate high income.

[Djohaal]

Constant bankrupcy, could be circumvented if we used cultural engineering to make the motto "going bankrupt is fun", just like in dwarf fortress "losing is fun" is the main motto. A more detailed guide on profitable chains for each pack would also be helpful on this aspect.

What I find most frustrating though (specially in SE, but applies to simutrans standard too) is when due to pathing errors your choo-choo refuses to move, and you have to plough through your new pristine railway to find that misconnected tiler or something. Perhaps if pathing errors came with a bigger description of what happened (or an option of "going to" the tile the problem arose) this could make the gameplay flow easier. This might prove a code a huge coding challenge though.

[sdog]

Two way double and triple track layouts in openTTD worked only with path based signals, being passable in reverse.
http://wiki.openttd.org/Advanced_path_signal_layouts#Two-way_triple_track_layout

You can see here the centre track is bi-directional, the side tracks on either side are unidirectional, the signals have a yellow bar at their base. Haven't tried it in two years though. A quick glance on their forum gave me the impression advanced path based signaling is in trunk now.

I hope they haven't turned it off, it was the only thing that really worked in that game.

[prissi]

If you start plain vanilla OpenTTD you get the normal block based signals which cannot be passed, just like 15 years agon. Same for locomotion or any other train simulator I tried.

Maybe you can built signals you can pass from the other side. But then it is not straight forward but hidden somewhere in the settings. The one you get by a single click behave exactly as in simutrans, including direction reversal with next click.

This section in OpenTTD wiki is called "Advanced signalling" for a reason. If you really want to do logic with trains, then OpenTTD is the better game. Simutrans is more about general transport. Those are deliberately kept different. OpenTTD is most exclusively about running trains, simutrans mostly about moving stuff from A to B.

[Erik]

When I begun with Simutrans the biggest trouble to begin was to make a vehicle at all.
I didn't know that I had to build a depot for it.

After discovering this, the rest was quiet easy.
However there was less choice then.
Only one type of signal and a few train, cars and such.

Still I think a simple tutorial will do.

Just don't getting started is frustrating.
But after that is discovering how the game works just a bit of the fun.

[sdog]

Prissi, perhaps you have to turn it on, YAPP in patches. I can't install openTTD right now to test it.

Yes, it is advanced use, but there is also basic use for those signals which is easier. In total the YAPP system was by far easier to get started with than the old openTTD way. People often confuse "user friendly" or rather "beginner friendly" with "the same way it was always done". Reason is to learn a new way they have to learn something new and forget the old method. For someone never having played the game the new method might be much more direct to understand.

I don't want to be rude, but this is perhaps leading to far away, i put this issue at point g) of a long list. It is weakly ordered by difficulty i experienced in one case.
However one question, regardless of if implementation of a change would be possible or desirable, do you concur that it might confuse new players that the signals can't be passed in reverse?


Erik has a good point. Impossible to see for us who played this type of games for years. For a new player it's not obvious at all that a depot is needed.
I suggested in experimental before, why not completey get rid of depots. They are not even consistent with the abstract principle used in the game. (Unlinke openTTD vehicles don't ever have to return to the depot. We see the individual vehicle in game as an abstract token for indistinguished vehicles in a line)

A buy vehicle button, or perhaps integration in the line dialogue would be enough. Vehicle is first spawned at it's first stop in the timetable.

[Venkat]

Hello Everyone,

As Djohaal said and I qoute

What I find most frustrating though (specially in SE, but applies to simutrans standard too) is when due to pathing errors your choo-choo refuses to move, and you have to plough through your new pristine railway to find that misconnected tiler or something. Perhaps if pathing errors came with a bigger description of what happened (or an option of "going to" the tile the problem arose) this could make the gameplay flow easier. This might prove a code a huge coding challenge though.

I have had this issue many times as I play zoomed away to get a feel of a larger area of the game. This suggestion is to specifically address the issue of trains not moving due to the tracks not being connected. Could I suggest a feature/tool that enables you to check the track's connectivity. This IMHO saves all players the puzzlement of why their trains are not moving.

This might be implemented with a tool that we already have in ST. The 'Block' tool invoked using the 'b' command. This shows the blocked rail till the next signal as a red overlay over the rails. This block of code can be extended as:

1. Only invoked when the game is in the 'Paused' mode.
2. Clicking a rail should color the track .
3. The coloring should stop when the next tile in the game is a joint/point (where more than one track join).
4. The coloring should stop when the end of rail is reached.

If I understand correct, the 'Block' tool would need to check the next tile to color, if the tile is a signal, the coloring stops. If my above assumption is correct, then this can be extended where coloring is stopped only if there is no more connecting rail in the next tile in any direction.

Could I request you to consider this tool? I would have saved me and a large number of others a lot of pain.

Thanks in advance.

Regards,
Venkat.

[prissi]

As also state several time, a computer is dub. So if no connection, it can only find no connection is completely unable to pinpoint the loss of connection (well, it can be done, but this would involve a very compute intensive search, maybe taking 15 minutes or so on a 2048x2048 map).

Computers are very bad at those simple tasks.

[gwalch]

I imagine it's very hard to program that... I often have a similar smaller situation : i had a diesel engine, and want to remplace by electrified... Sometimes i forgot one tile, and "the convoy can't find any road"... If the rail exists, is it possible to change "no route" by something more explicit, maybe "lack of electrification on this road" , and precise where ? If the road exists, can the program find easily the situatio of the problem ?

[Erik]

A tool who just say there is the problem is (very) difficult to build.
Now the route engine search to shortest existing route and then take that route.
But if the route has been broken (missing a tile connection) the engine don't recolonise the route you has planned.

A tool who shows the connection from crossing to crossing or other end point.
You will see where the route is broken because the selection wouldn't go further.
Would be possible and perhaps even not so difficult to build.
But then for new players it is more difficult to find.

[jamespetts]

It would be possible to check for lack of electrification without the intensive search mentioned by Prissi simply by running the route search normally, then, if no route is found, running the route search again hypothetically without the electricity constraint and, if that turns up positive, highlighting all the non-electrified tiles in that route and giving a "way not electrified" error message.

In cases of a simply missing connexion, it is rather harder to deal with the issue, since a computer cannot simply guess where a connexion ought to be. One thing that might, in theory at least, be possible, however, is to identify candidates for accidentally broken links: ways of the same types on adjacent tiles that are not connected to each other. This could, in theory at least, be done by, in any case of failure to route not caused by absence of electrification (in Experimental, the system for electrification could be replicated for weight limits and way constraints), every tile with an adjacent tile with the same waytype not connected audited to check whether assuming that the two are connected would make any difference to the routing. In fact, probably better would be for a database of such sets of tiles to be compiled, not at route search time, but when that situation is first created, and for the second pass of routing simply to assume that all such tiles are connected. If routing is then possible, the relevant tiles through which the route passes could be highlighted and a "broken link" error message displayed.

Whilst this would probably be reasonably computationally efficient (although still add a non-trivial burden on both processing and memory), I do wonder whether this approach would be worthwhile for the result to be achieved. Better might be simply to have a tool which, at the player's selection, audits all way tiles and highlights all way tiles that are adjacent to other way tiles of the same type (and going in the same direction, so as to avoid highlighting all tiles of double track) but not connected so that players can find the problem more easily. Even that, however, might be more trouble than it is worth.

The system of checking electrification, however, probably is worthwhile. I should note that this will become more important when Standard introduces weight limits.

[trian]

Sorry for committing thread necromancy but one thing just came to mind:

Wouldn't it be easier to write a function that highlights all way tiles a given vehicle could possibly go to? (Yes, it would probably pretty cpu-consuming...) Afterwards the player can easily spot the disconnected tiles or misdirected signal or leftover one way sign themselves.