J'ai trouvé de tout, allant des cartes pour Railroad Simulator de Microsoft, à des logiciels en tchèque (enfin je crois) ou j'ai passé plus de deux heures à comprendre comment faire démarrer le train (sisi !). Finalement, je suis tombé sur un petit programme en Windows 3.1, qui s'apelle CATrain, développé par un certain Joël Bouchat. Un petit programme qui marche tres bien d'ailleurs, puisqu'il fut la conclusion d'un speech en anglais sur la conception de voies ferrées, on plus exactement design of the railroad tracks (oui, j'ai osé).

Bref, les problèmes sont que je ne suis plus sous Windows, que le programme est vieux et soufre des limites d'une plateforme 16 bits, et que ce n'est pas un monstre d'ergonomie pour parler franchement (Joël si un jour tu me lis, et même si on ne se connais pas plus que ça, pardonne moi). Les problèmes trouvés sont les suivants :

  • l'espace disponible pour faire un reseau est petit : 160 cases par 120, ça ne me suffit pas quand on veut faire toute l'Île de France ;
  • l'outil de numérotation automatique des aiguilles n'est pas assez pratique : je veux pouvoir faire des classes de signaux et les étiqueter 50-12, ou W587 si je veux
  • il manque des pièces, et notamment des traversées à jonction simple et double (elles existents mais ne sont absolument pas commode)
  • les apparences des signaux sont pas mal, mais l'avertissement n'est pas du tout utilisé. Et moi qui suit perfectionniste, je veux le changement de voie, le sémaphore, etc. Avec evidemment les réactions appropriées des trains.
  • selection dynamique des voies : cas concret, la voie "officielle" est occupée pour une raison quelconque, hop, le train se dirige vers une autre voie (définie à l'avance)
  • quelques bugs plus ou moins génants à corriger (cliquer sur bypass pour que le train attende au signal, j'ai jamais compris pourquoi)

Comme vous pouvez le voir, j'ai éprouvé une certaine frustration. D'autant plus que Transport Tycoon, et plus tard Locomotion n'ont pas ces défauts. Ils en ont d'autres encore plus pénibles, comme par exemple, le train qui fait demi tour parce qu'il a trop attendu au feu, le train qui prend un voie dans le mauvais sens parce que toutes les voies etaient occupées, le classique cas d'interblocage (sisi !), le train qui va dans le mauvais sens, etc.

L'idée est donc de ne prendre que le meilleur des deux, et de faire un truc qui marche bien en toute circonstance. CATrain possède une feature interessante dont je n'ai pas encore parlé : il pilote de vrais réseaux en cartons et en 12 V. J'ai décidé de faire en sorte que cela soit possible avec ma simulation. Je ne ferais pas la partie controleur, mais je fais un truc suffisament souple pour que quelqu'un d'assez fou puisse le faire sans le devenir completement.

Les fonctionnalités seront donc les suivantes :

  • les voies
    • elles seront alignées sur une grille. J'ai pensé à faire dans le purement vectoriel : ça n'a que tres peu d'interet par rapport à la somme de boulot que ça représente.
    • elles seront constituées uniquement de pièces simples (droites, courbes de différents rayons, éventuellement un S, rien de plus). Les aiguillages seront formés par la superposition des voies, comme dans locomotion. J'ai testé le système à mainte reprise, il fonctionne de façon tout à fait convenable et je ne me suis jamais retrouvé dans une situation inconfortable sur ce point.
    • elles seront équipées de détecteurs de passage, qui ne connaitront pas leur (éventuel) destinataire
    • elles seront équipées de signaux qui seront pilotés de façon indépendante de la voie
    • les aiguillages sont pilotés de manière automatique
  • les trains
    • nombre de wagons variable (comprendre : un canton entier peut être rempli par un train)
    • taille des wagons variables (le déplacement du wagon se fera en son centre, je ne simule pas les bogies, faut pas charrier non plus)
    • ils s'adaptent (ou pas) à la signalisation. Je n'ai pas prévu de simuler les accidents.
    • ils suivent strictement les aiguillages (l'intelligence n'est pas embarquée dans le train), sont capable de refouler
  • la signalisation
    • techniquement, elle indique la vitesse du train, et rien d'autre
    • elle peut être statique (limite de vitesse)
    • elle est gérée par un ou plusieurs modules, suivant l'effet obtenu
  • le décors
    • n'a pas d'action sur le reste, mais évolue en fonction du reste (exemple, le passage à niveau). Je n'ai en effet, jamais trouvé un seul simulateur ou le passage se ferme avant le passage du train.

Le système doit être capable de simuler, en fonction du reseau :

  1. un système de canton classique, avec itinéraire défini à l'avance des train
  2. un système de régulation de traffic comme le métro parisien
  3. un système de signalisation en cabine, avec cantonnement dynamique
  4. un système mixte ou certains convois suivent un itinéraire et d'autres sont pilotés à la main (avec éventuellement débrayage de la sécurité)
  5. une gare de triage, avec possibilité de changement de l'attelage (ça, c'est une idée toute fraiche de ce soir)

De tout ce qui précède, j'ai imaginé le système suivant :

Un moteur de jeu simule les voies et connait grace aux détecteurs l'emplacement des trains, il gère la position des aiguilles, ainsi que l'état de la signalisation et des éléments du décors qui en ont besoin. Sur ce moteur viendront se connecter (au sens socket) dees modules qui implémenteront à leur guise :

  • Un controleur qui fera avancer les trains en fonction des informations de la voie. Techniquement, le controleur génerera les évenements des détecteurs.
  • Des vues affichant l'état du réseau en recevant les évenements des détecteurs, et ceux des signaux
  • Un système de signalisation positionnera les vitesses acceptables sur les voies en fonction de divers algorithmes, des états précédents des signaux, des positions des aiguilles
  • Des systèmes de gestion des aiguilles, qui gerera dans les faits les trajets des trains

La liste n'est pas exhaustive, mais vous voyez le principe. Il reste a répartir précisément les rôles, sachant qu'un programme client typique implémentera les modules controleur et vues en même temps afin d'avoir un affichage fluide.

Je n'ai pas encore tout défini, mais je sens que j'ai une architecture qui tiens la route, là.