Russia 1917: Thinking mobile, not PC

The April 2026 update on the mobile redesign, scenario pacing and research into GOAP-style AI.

Old organisation of the Russia 1917 screens on mobile
Old organisation of the Russia 1917 screens on mobile

Hello,

Development of the game continues, and I would like to keep you informed about its progress. There are few major new features this month, but there are still some interesting developments to share.

Thinking “mobile” rather than “PC”

In March, I had the opportunity to let a friend test the game (thanks Gabriel) — and it was a real revelation.

As you know, my goal is to create a mobile game. Yet until now, I was still thinking too much like a PC developer.

In the first version, the game was structured around two main screens: a strategy screen and a scenario screen. The result was that, on a small smartphone display, everything became too crowded. Elements were too small, the interface was overloaded, and switching between menus made the whole thing difficult to read.

New organisation of the Russia 1917 screens designed for mobile

New screen structure

For example, I had to give up displaying soldiers on the mini-map: on mobile, it simply turned into a mess of pixels.

So I had to change my approach and think “mobile”, meaning no longer concentrating all the information on a single screen, but distributing it across several screens.

This new organisation ultimately gives me more freedom. I can now offer:

  • a clearer map showing the soldiers,
  • graphs showing how the number of cities occupied by each side changes over time,
  • or larger propaganda posters accompanied by historical context.

Comparison between the mini-map and the large strategic map showing cities and soldiers

This image shows the map with cities and soldiers. You can see that the “mini” version on the left becomes a real mess of pixels when trying to identify the soldiers, represented by crosses. By contrast, when the map is larger, it is much easier to read. That is the benefit of thinking in terms of several screens.

⚖️ Rethinking scenarios and interruptions

The second point concerns the scenarios. I had a discussion with another tester (thanks Laura).

In the current version, the player is very quickly interrupted by notifications asking them to make political choices. This makes sense in principle: these choices influence strategy, enemies and resources.

But in practice, it breaks the rhythm.

It becomes difficult to stay focused on strategy when you are constantly interrupted by political decisions.

So I redesigned this system.

From now on:

  • Political choices are indicated, but remain optional.
  • They are time-limited: each choice is available for only one minute, whereas previously the game paused if the player had not resolved the debate.

Each decision is still tied to a precise historical context. For example, the question of Finnish independence appears in November 1917, in accordance with the historical timeline.

The idea is simple: during a first playthrough, the player will probably take part in only a few debates. But over successive games, they will become aware of the possible choices and their consequences.

🤖 Redesigning the enemy AI

For April, I am focusing on another subject: enemy artificial intelligence.

🔧 How it currently works

To explain the evolution, I first need to describe how my AI is currently built.

During the game, each enemy faction receives an attitude defined by the scenario.

  • Inactive: reacts only if attacked
  • Limited: acts only within a specific area, for example independence movements such as the Ukrainians or Finns
  • Active: operates across the whole map, for example the White Russians and foreign forces

I then use a decision tree combined with random variables.

At regular intervals, each faction analyses:

  • its troops and cities,
  • nearby allied forces,
  • nearby enemies.

Depending on these elements, it has a greater or lesser chance of attacking an enemy city, producing troops or attacking an enemy unit, with an element of randomness.

For example, if allied forces are nearby, there is an 80% chance of attacking an enemy city, whereas otherwise there is an 80% chance of attacking an enemy unit.

This system works… but it has become a real “spaghetti dish” to maintain.

I currently have two major bugs in particular:

  • the Japanese attack western Russia instead of staying around Vladivostok
  • the White forces sometimes remain completely motionless

🔄 Towards GOAP-style AI

As part of an effort to simplify the system, I am now exploring a new approach: the GOAP model as a replacement for the decision-tree model.

GOAP stands for Goal-Oriented Action Planning.

The principle is as follows: we define a goal for the AI that changes according to the environment. For example, many nearby enemies lead to a defensive policy, while few enemies favour an offensive policy.

We then define actions.

These actions must be usable in different chains. For example, if we have the actions “create troops”, “send troops to attack” and “explore”, we can define plans such as:

  • create a unit → explore
  • create troops → create troops → create troops → send the troops to attack

Finally, there is the plan itself.

The idea is for the AI to be able to build its own plan, in other words its own chain of actions.

Two approaches are possible:

  • either we write several plans and ask the AI to choose the most relevant one
  • or we ask the AI to test different combinations of actions to see whether they make it possible to reach the goal

And this is where something interesting appears: emergence.

✨ Emergence: the Holy Grail

Imagine this:

The developer defines several actions:

  • create troops
  • move troops
  • build roads

And suddenly, the AI decides on its own that building a road is the best way to achieve a military objective.

In the developer’s mind, the action “build roads” was not designed for military purposes but rather for economic ones. Yet because the AI tests all actions in combination with all the others, it can arrive at plans the developer had never imagined, for example by combining “build roads” and “move troops”. This behaviour was not explicitly programmed.

You find this kind of logic in some games where NPCs block a road with objects instead of attacking directly.

That is the kind of “unpredictable but coherent” intelligence I would like to achieve.

⚠️ Technical limitations

The problem is that I use GDevelop, which is based on a system close to pseudo-code.

That makes implementing a GOAP system complex.

I still need to run several tests to see whether a functional version is possible.

My current idea would be to add this logic as an additional layer to manage local strategy. Another possibility would be to use GOAP in a mini-game within the game, “Taking part in the Baku Congress”. I will talk about that later.

Screenshot of the mini-game devoted to the Baku Congress

Screenshot of the mini-game “Taking part in the Baku Congress”

I had a lot of difficulty understanding GOAP, and it was really thanks to my partner encouraging me that I managed to get there (thanks Holly).

🎯 Conclusion

That is where the project stands today.

A lot of thought, some major adjustments, and a direction that is becoming clearer.

The objective remains unchanged:

👉 release the game this summer.