If you wish to consult it, it is available here but only in french (and as this is the first game design document we've written, we are uncertain of its quality, so let's hope it's correct).

At first the game was intended to be entirely done in ASCII art but during the GDD writing, we switched to a misc-text mode style close to PETSCII using the Textor engine I'm working on. ASCII surely was very cool but I think colored text mode will allow more expressiveness and cool animation style (like the previous cycling animation I posted). Here a a mock-up for the riding screen, including landscape parallax scrolling and dialogue between characters between road events and getting to destination.

Without yet having reworked the prototype we have for this type of view with these new graphics, here the animated sprite of a cyclist to give an idea of what it will all look like in motion :

There will be turn-based RPG mechanics adapted to cycling. The team will battle against random elements and road events determined by topographical properties based on the player's travel choices. For example, the forest will prevent wind, while the mountains will increase the chances of ascents and descents. These elements will be encountered as some sort of enemies sending malus to the characters stats, and skills will be available to eliminate them or convert them into bonuses.

At each stage, between travel phases, visual-novel-style gameplay will be used to explore the towns and various locations in which the embodied cycling team stops. In addition to encounters with NPCS, dialogue trees will sometimes propose an area exploration system and generally will modify the statistics of roleplay elements according to decisions made, as can be done in Roadwarden or Disco Elysium.

We've also been working a lot on a sci-fi story set in a world finally decarbonized after a bitter struggle against a globalized thermo-fascist regime. A sort of “sweat-punk” utopia (like a variation on solar punk about Human-powered propulsion and energy, including lots of pneumatics and an obsession with bicycles) set after a dystopia inspired by our contemporary situation.

We've been working on this theme with references like Low-tech magazine and our reading of A Psalm for the Wild-Built in mind. We've also recently started reading specialized science fiction on feminism and cycling from Microcosm Publishing's “Bikes in space” catalog (thanks a lot Fisk for this discovery), which will surely inspire us for the rest of our narrative work.

We are excited about the next step. Adel is planning to reduce his professional time to do what he can on the project, keeping his fingers crossed that it will be a fun game. The idea is to make a demo, share things online while making it and see if there's a chance for some crowd based funding or why not find a publisher to finance the rest of the production (hoping we are not daydreaming).

Ces mini-jeux pourraient ouvrir à des possibilités graphiques et interactives autres que la vue de profil. Une idée de mini-jeu serait d'évoquer le jeu Out Run en reprenant le principe d'une caméra derrière le personnage et la route en pseudo 3D. Le principe pourrait être d'éviter des obstacles, de ramasser des objets, de prendre l'aspiration.

Nous avons trouvé quelques références qui détaillent la manière de s'y prendre pour calculer la projection d'éléments 2D selon les positions d'une caméra et de l'écran afin de produire un effet de 3D :

• http://www.extentofthejam.com/pseudo/
• https://github.com/jakesgordon/javascript-racer/
• https://github.com/ssusnic/Pseudo-3d-Racer
• https://www.youtube.com/watch?v=N60lBZDEwJ8

Nous avons donc développer une version demo en JS dont voici une archive vidéo :

Pour améliorer tout ça, on pourrait :

• gérer le déplacement via le concept de vecteur
• intégrer un calcul de forces à vaincre pour avancer à la manière dont on l'a fait dans Development of a physics engine
• intégrer un fond et de la parallaxe
• intégrer des décors autour de la route et sur la route

Cependant, nous avions des difficultés à intégrer aisément ces calculs au sein d'une technique de rendu graphique pour un jeu vidéo (l'élément HTML Canvas par exemple) afin de faire bouger un cycliste dans un environnement. C'est pourquoi nous avons regardé plutôt la manière dont on peut convervoir un moteur physique avec des langages de programmation. Le livre et le site Nature of code de Daniel Shiffman a été d'une grande aide. Nous avons surtout regardé les parties sur les vecteurs et les forces.

La vidéo ci-dessous montre une version de démonstration d'un moteur physique. On peut changer l'inclinaison de la pente, la vitesse du vent et la qualité de la route. Ces changements sont pris en compte dans les calculs des forces de la pente, du vent et du frottement. La logique des vecteurs permet d'ajouter une série de forces que la force du pédalage doit vaincre pour avancer.

Les variables sont modifiées via des touches du clavier. Voici le détail de la signification du changement de l'objet qui bouge :

• Forme carrée : le cycliste est en roue libre
• Forme ronde : le cycliste pédale
• Forme triangulaire : le cycliste freine

Ces débuts sont plutôt prometteurs. Pour améliorer tout ça, on pourrait :

• intégrer plus de variables dans le calcul des forces
• définir un équivalent de vitesse à laquelle se déplace le cycliste
• intégrer une force ou une variable liée à la santé du cycliste
• intégrer la possibilité de pédaler plus fort ou bien de freiner plus fort
• intégrer un calcul de puissance à partir des données de force et de vitesse
• utiliser l'intégration de Verlet plutôt que la méthode d'Euler pour calculer le changement de position du cycliste

• Banister EW, Calvert TW, Savage MV, et al. A systems model of training for athletic performance, Aust J Sports Med 1975;7:57–61.
• Murray NB, Gabbett TJ, Townshend AD, et al, Calculating acute:chronic workload ratios using exponentially weighted moving averages provides a more sensitive indicator of injury likelihood than rolling averages, British Journal of Sports Medicine 2017;51:749-754.

Nous avons également regardé comment était calculée la charge Coggan.

Nous nous sommes ainsi concentrés sur le modèle condition physique/fatigue. Il consiste à calculer la condition physique et la fatigue par rapport à des cycles d'entraînement. La condition physique est calculée sur un cycle à moyen terme et la fatigue sur un cycle à court terme. La soustraction de la conditition physique et de la fatigue donne une indication de la forme.

Ci-dessous, des détails pour :

• calculer de la charge d'un entraînement
• calculer fatigue, la condition physique et la forme

Calcul de la charge d'un entraînement

La charge d'entraînement est un indicateur chiffré de l'effort qui a dû être réalisé pour un entraînement. Pour ces calculs, il faut avoir une valeur limitante propre à un individu. C'est un seuil à partir duquel un effort ne peut plus être maintenue dans la durée. Cela peut être la vitesse ou bien la puissance (par exemple) qui peuvent être maintenues pendant une heure d'effort. La durée choisie aura pour conséquence de valoriser des entraînements au-delà de cette durée.

var treshold_value;    // km/h, W, etc
var training_duration; // h
var training_value;    // km/h, W, etc
var training_intensity = training_value / treshold_value;
var training_score = ((training_duration * training_value  * training_intensity) / treshold_value) * 100;

La valeur de seuil est appelée "treshold_value". La valeur "training_value" doit être dans la même unité.

Calcul de la fatigue

La fatigue correspond à une charge d'entraînement de cours terme. Ici on la calcule sur un cycle de 7 jours. On prend l'unité de temps "un jour" pour calculer la fatigue, la condition et la forme. Du coup, quand on parle de la fatigue précédente, on parle de la fatigue du jour précédent.

var fatigue = previous_fatigue + ((training_score - previous_fatigue) / 7)

On calcule la fatigue tous les jours. Si "previous_fatigue" n'existe pas encore, on commence à 0, sinon on prend la valeur du jour précédent. La fatigue est généralement comprise en 0 et 50. Elle ne peut pas être négative. Proche de 0, la valeur n'est pas très haute, au-delà de 50 elle est importante.

Calcul de la condition physique

La condition physique correspond à une charge d'entraînement de moyen terme. Ici on la calcule sur un cycle de 42 jours.

var fitness = previous_fitness + ((training_score - previous_fitness) / 42);

On calcule la condition physique tous les jours même si elle est plutôt pertinente à 42 jours. Si "previous_fitness" n'existe pas encore, on commence à 0, sinon on prend la valeur du jour précédent. Elle ne peut pas être négative. Proche de 0, la valeur n'est pas très haute, au-delà de 50 elle est importante.

Calcul de la forme

La forme est calculée par la différence entre la condition physique et la fatigue.

var form = fitness - fatigue;

La valeur de la forme peut être entre -30 et 20. Pour s’entraîner de façon optimale, il est intéressant d'être entre -10 et -30. La fatigue est donc au-dessus de la condition physique. Mais pas trop, sinon au-delà de -30, des risques de blessures peuvent arriver. Pour arriver en forme à un évènement, il faut cependant réduire la fatigue. Alors si la valeur de la forme passe au-dessus de 5, elle manifeste un certain niveau de fraîcheur. C'est-à-dire qu'on a une fatigue inférieure à la condition physique : on a troqué de la fatigue contre de la fraîcheur.

Il s'agit donc d'équilibrer la fatigue par rapport à la condition physique (les cycles cours par rapport aux cycles moyens) pour progresser et ensuite créer de la fraîcheur.

Last summer we (Adel and Vincent) applied for a grant from the CNC (The French National Centre for Cinema and Moving Images) to finance the game design conception and writing of The Wind Through the Wheels, and it was accepted!

We received this news in December 2023, signed the contract in February and received 75% of the money last month.

It's €10,000, which we split 50/50. It won't be enough to finish the game, but it will allow us to work on it part-time until 2025. It's a great start for the game!

I (Adel) feel very fortunate to be able to work on a game with a friend, and I'm convinced that all the support I've received since I started sharing my work has contributed greatly to this situation. I'm very grateful to everyone who follows my work and encourages me with their compliments, comments, messages and questions. It has really changed the way I work and made me feel legitimate in what I do. Two years ago, I would never have dared to ask an institution for funding.

The CNC gave us a summary of their deliberations. They felt that our project stood out for its originality and the quality of its visual direction. They were interested in the fact that the initial narrative and ASCII display raised environmental concerns. They also expressed some concerns about the effectiveness of the gameplay, the feasibility of an ASCII display and the need for more in-depth narrative work.

We now have one year to work on defining the game and turning it into a game design document. This needs to be a 40-50 page document describing the narrative, game mechanics and art direction in as much detail as possible. We also need to keep track of the chronology of our work and specify our spending on the project.

To give you an idea of what we sent to the CNC, here's the PDF we submitted [link]

Our roadmap

As well as writing the game, we want to produce a demo that can be used as the basis for a crowdfunding campaign so that we can continue to work on the game. We hope to achieve this before 2025, although we still have a lot of work to do before we get there.

Beyond these goals, we want to continue to work on things in a free and experimental way. This applies to the narrative, the gameplay and the visual direction. What will not change is the text mode rendering of the game's graphics, the cycling theme, and a gameplay that is mainly based on exploring and training in side view.

For example, we will soon be trying to render game visuals in a coloured raster style, and on the writing side we are working on a sci-fi theme where humanity has abandoned fuel-based technologies for human motricity and penumatic-based tools. A kind of Solarpunk derivative, something like Rollerpunk, Airpunk or maybe Sweatpunk?

A devlog

Today we launched our devlog https://the-wind-through-the-wheels.com/ where we will publish our progress. This site is available in French and English. We have already published two posts which are the two threads about the game we published previously on social media. To easily follow our news, we have set up an RSS feed https://the-wind-through-the-wheels.com/rss/

An article on the mathematics of cycling we are using for the gameplay will be published soon.

We have also re-posted the May 2023 article on Velvetyne about the Jgs Font, the font used for the game's rendering, this article also talks more broadly about ASCII art, some of its artists and history.

The design of this blog is probably temporary, very Web 1.0, it aims to recall the mood of the oldschool web and operating systems of the 90s, the period when the ASCII art scene emerged on Usenet. Still, this style might be a bit harsh for a game promotion.

February-March progress

We haven't shared any news from the project on social media since February, but there has been progress on several aspects of the game.

A first stage in the making

We started a first stage of the A first stage in the makinggame. This involved integrating the 3D landscapes generated from the topographical data we had, integrating a physics engine that translates the player's state into speed, power and distance, and creating a minimal physiological system to simulate the cyclist's endurance. This physiological system could lead us to a survival/simulation style of gameplay, perhaps requiring precise management of nutrition, hydration, rest, bike maintenance, etc. This type of gameplay seems appropriate for the contemplative aspect we want to focus on. In the same spirit, we think of games like Oregon Trail or Caribbean Sail for their mechanics of waiting, travelling and survival. We are also thinking of Lone Sails and how the scrolling of the landscape is at the heart of the gameplay. In a more RPG style, we are really into the writing of Roadwarden.

Progress on the game engine

While working on this first stage, we continue to work on the game engine. It's like a project within a project, we'd like to end up releasing it under a free licence and with enough documentation to ensure that it can be used by other people for other projects.

The short demo "A Very Bold Character" released by Adel last month (link) was a pretext for more extensive experimentation with the engine's capabilities.

This engine is called Textor and, apart from its use in The Wind Through the Wheels, it is used as the basis for a text-mode image editor that Adel uses for his latest artworks, experimenting with a bitmap rendering with colours as an alternative to the game's current black-and-white ASCII art.

In its latest version, Textor allows the same interactive features for both pure text and bitmap rendering.

At some point there will be a more specific article on the development of Textor.

What else we're working on

We also started researching graphics, atmosphere and colours. The challenge is finding a visual style that extends or matches the ASCII artwork.

Another big work in progress is the writing of the game's story. We started by writing short novels.

Some characters, places and events begin to emerge. We must give them characteristics, speech, geographical locations, specific environments. As stated above, the main theme is that humanity has chosen to move away from fossil fuels. We are exploring this in our novels. We have started three of them: one in which the main character encounters a farming community that uses only human motor power for work, another about people who are building their lives around a water source found in an abandoned oil field, and one in which the protagonist discovers a kind of mental superpower that allows him to create a kind of projection in different environments.

To write all this, we are documenting alternative energy sources, ways of travelling, pre-industrial ways of farming, alternative ways of living with animals, how to decontaminate industrial waste. We also read some science fiction. For example, we've read Becky Chamber's A Psalm for the Wild-Built, 2021, and R. F. Kuang's Babel, or the Necessity of Violence, 2022. We also read older books such as Edward Bellamy's Looking Backward: 2000-1887, 1888, or William Morris's News from Nowhere, 1890.

Finally, with the aim of creating urban landscapes, we have been working on an ASCII art facade generator. This still needs some work, but we hope to release it as an independent tool under a free licence at some point.

We started this work with realistic calculations. The websites of Jacques Jacques Fine and Bernard Mischler were a great help in developing the calculations. The general principle is to be able to switch from a speed (km/h) to a power (W) and vice versa. So, for a given power and depending on the conditions, we can find out how fast a cyclist is travelling. We have called these conditions "performance factors".

var performance_factors_values = {
    health: 0,                // float
    athlete_position: 0.4,    // float
    athlete_weight: 75,       // kg

    bike_condition: 0.01,     // float
    bike_weight: 10,          // kg
    
    road_condition: 0.004,    // float
    slope_gradient: 0,        // %
    g_force: 9.81,            // m/s2
    
    real_wind_speed: 0,       // km/h
    air_temperature: 20,      // °C
    air_pressure: 101325,     // Pa
    air_molar_mass: 0.028965, // kg/mol
    gas_constant: 8.3144621,  // J·K-1·mol-1
}

The object above lists a set of performance factors and values that are useful for starting the calculations. For example, we've chosen a bike weighing 10kg, a wind speed of 0km/h and a temperature of 20°C. These performance factors are variable: the friction of the road, the condition of the bike and the position of the athlete can all change and therefore affect performance differently. Even the force of gravity can vary if we choose to send our cyclist to the Moon...

So we've created a set of JavaScript functions that take this object as an argument. Here's the function that calculates the influence of the slope:

function calc_slope_power(values) {
    var v = values;
    var slope_power = v.speed * (v.athlete_weight + v.bike_weight) * v.g_force * v.slope_gradient / 100;
    return slope_power;
}

By adding a series of functions that calculate power, we then obtain the power required to move the cyclist. Calculating power as a function of speed is easier than calculating speed as a function of power. The latter requires us to solve a third-degree polynomial, which we have done by adopting a numerical solution method.

Once all these calculations were in place, we developed a tool to visualise the results. It takes the form of two graphs showing speeds as a function of power output. The first graph shows the speed in relation to the slope and the second the speed in relation to the wind.

We have also added inputs so that we can vary the performance factors. For example, we can see the effect of the athlete's weight on the speed achieved for a given power output.

We then added an input to manage inertia. The previous speed is taken into account to improve or reduce the new speed. If the cyclist was stationary, he will have a penalty when he tries to move. On the other hand, if their previous speed was high, they will have a bonus. We have also taken into account the inertia involved in a slope: it's better to arrive on a hill in a hurry.

We think this approach is an interesting way of estimating cyclist effort. It will be possible to calculate training loads and deduce risks of injury, fatigue or physical fitness.

We created some sort of shader that renders ASCII relief volumes using arrays of 2D coordinates projected into space. The first two relief arrays in the data are used for the roadside.

Once the 3D environment of the scene is in place, it’s a matter of finding the right XYZ scale, balancing geographical realism, the length of the race, the difficulty and the relevance of the viewpoint. Perhaps these factors will be something that the player can modify during the game as special powers or abilities?

Beyond the rendering of roads and landscapes, there is the issue of their design. It’s quite difficult to create consistent landscape data by hand, so we started using data from Open Elevation. As a test, we used it to model the relief around Retournac, a town near where we live.

Using existing rides (from Open Runner data) as a starting point for designing stages is a neat aspect of the method.

However, our way of visualising cycling from a side view means that we flatten out the road from all its bends, so we can’t build a coherent stage from unmodified geographical data. We will design stages by modifying and interpolating cycle route reliefs and selected or generated landscapes that are not geographically coherent at first.

Each character is subdivided into rounding positions to determine the entry and exit points of a line.

I’ve added 65 special characters to the Jgs font corresponding to these junction points.

I used line equations like y = slope * (x - aX) + aY and sort functions to find these in and out between two given points to render these smooth lines. And because I am very bad at maths this step took me almost an entire week…

This feature should be very useful for road rendering in The Wind Through the Wheels, in particular finally being able to render road crossings in the player’s path.