The story of Maps4FS

The beginning · 2024

A place to disappear into

It started at the beginning of 2024. I was bored, but more honestly, I was going through a pretty rough moment in my life. I needed somewhere to escape from everything that was happening around me, and Farming Simulator 22 became that place.

There is something special about the way that game can shrink the whole world down to one field, one tractor, and calm music in your headphones. For a while, nothing exists outside the next straight line you need to drive.

Then I remembered the stock maps. Small fields, fictional places, all of that. And I thought: no way. I wanted big, real fields. I remembered a place from an earlier part of my life where I loved cycling and looking across what felt like endless farmland. I wanted to drive there in the game.

The question

Surely somebody had already built this

I downloaded the tools, opened Giants Editor, looked around, and immediately revised my estimate: this was going to be incredibly hard.

But I remembered playing Cities in Motion years earlier and using a tool that painted textures from a real place so you could build on top of them like a blueprint. I found it again: Maps4CIM. Farming Simulator had a huge modding community, so surely somebody had made the same thing, only better.

Google said no.

I did not believe Google. It simply could not be right. I must have searched badly. On January 17, 2024, I went to Reddit and asked whether an application like that existed. The answer was still no. One reply said, in effect: please go ahead and make one.

My post ended with a very casual suggestion that I could develop it myself if nothing existed. Looking back, that postscript had the energy of somebody opening a basement door in a horror film and saying, “I’ll just take a quick look.”

Maps4FS, version zero

Born in blood, sweat, and terrible coordinate math

This was my first contact with GIS. I did not know the libraries. I did not even know what a coordinate reference system was. You will laugh, but I was literally sitting with a notebook and calculating how geographic coordinates should become pixels. I worked through what should happen in the northern hemisphere, then the southern one, and built the first version around my own calculations.

It worked in the north. The south was bugged as hell. The deeper alignment mistake sat inside Maps4FS for almost a year because I did not yet know enough to know it was there.

Large language models were not nearly as useful for coding then, so there was no magical conversation that solved it for me. The first Maps4FS was born through trial, error, documentation, more error, and the kind of confidence only ignorance can provide. It was full of awful bugs, but it existed. It could bring in SRTM elevation and OpenStreetMap features. It worked.

Then I reached elevation scaling. I found the game’s height-scale value and spent hours trying to understand how real elevation should translate into the engine. I did not solve the puzzle. I added a few hard-coded presets that looked more or less fine and moved on with my life. This was a recurring development strategy in early Maps4FS.

One good idea was there from day one: the texture schema was customizable. People could decide how OpenStreetMap tags should become ground textures instead of being trapped by my defaults. That idea survived every rewrite and eventually became MapToPlay’s collection and vector-mapping system. Apparently my previous development experience was useful after all.

The first users

A script, a Telegram bot, and levitating trees

My first attempt at sharing Maps4FS was a Python script. There is an old YouTube video where you can still see the experience: install things, run commands, answer prompts, and eventually receive terrain and textures. That was it. By modern standards it was a hardcore user experience, but the core concept was alive.

After a while I admitted that expecting normal people to enjoy this was unreasonable, so I put a Telegram bot in front of it. Then I used Maps4FS to make my own map.

It had copy-pasted trees floating in the air. It had no generated fields or farmlands, so I made those manually. It had no proper map boundary, so I fell off the edge several times. It was objectively rough.

But that feeling. Oh my God, that feeling.

It was outstanding. I had solved my problem, so I more or less forgot about Maps4FS and continued with life.

Six months later

Someone actually needs this

Around six months later, people started contacting me on Telegram. They were trying to use the script and struggling with it, which was not exactly shocking. But the important part was not that they struggled. It was that they were there at all.

Somebody actually needed this.

I started thinking about a better way to deliver it. First I built a Streamlit web app and deployed it publicly. The heaviest maps quickly overwhelmed that setup, so the hosted version was limited to two- and four-kilometre maps.

The fact that I was using Python shaped everything. Processing happened away from the user’s browser, so their own computer did not have to do the heavy work. That later became a crucial part of MapToPlay’s usability. In the beginning, however, it mostly kicked me in the nuts: more users and bigger maps meant more resources, and the hosting bill kept growing.

Delivery problems

Docker is not an onboarding flow

A self-hosted option seemed easy. Give people a few Docker commands and let them run it themselves. From a technical perspective, yes. From a real-world perspective, absolutely not.

People struggled with Docker, so I recorded a video explaining how to install Docker. This did not fix the central problem, which was that normal users should not need a containerization lecture before they can make a Farming Simulator map.

Meanwhile, Farming Simulator 25 was approaching. I had already started turning the script into software that could understand different games. When FS25 arrived, Giants Editor was not available yet, so I sat in a Farming Simulator Discord with other modders, waiting and refreshing the page like everyone else.

The conversation drifted toward why I was there and what I was building. That was the real beginning of Maps4FS becoming popular. Somebody told me, “Man, go and make your own Discord.” I thought: who the hell needs that? Looking at the thousands of people who eventually joined, I can confirm that the anonymous Discord man was right. I am sorry I do not remember your nickname, but thank you.

I was also too bored to keep refreshing the Giants Editor download page, so I made a Telegram bot that checked it and notified everybody when it finally appeared. This may be the purest description of how I build things: mildly annoyed, slightly impatient, and suddenly maintaining another bot.

Growing up

It was no longer enough to make a blueprint

FS25 support came quickly. Then the obvious problem returned: a blueprint was useful, but I still had to build almost everything by hand. That began a long and painful stretch of late nights, debugging, and reverse engineering.

Trees arrived. Water. Background terrain. Eventually buildings. Each one looked like a feature from the outside and a small private war from my side of the keyboard.

At some point Kim joined the Discord. People wanted elevation data better than SRTM, and I said I could not personally maintain integrations for every third-party source, but I could document how to add one. Kim did exactly that and contributed many of them. That is how much more detailed elevation providers reached Maps4FS.

Better data also exposed my ancient day-zero alignment bug. With SRTM’s lower detail, the offset had been hard to see. With high-quality data, it became crystal clear that something was terribly wrong. I spent a long time tracking it down and finally fixed it, with help and evidence from the community. Maps4FS became much more stable after that, and features like rotation and scaling became reliable instead of hopeful.

Then I approached roads. Not long before, I had assumed UV mapping was related to the ultraviolet index in a weather forecast. Now I was trying to generate road meshes. The first version was bad and ugly, but it was also the first brick in something that would later become one of MapToPlay’s most sophisticated features.

The end of the Python front end

I was building a workbench inside the wrong tool

By then I was no longer solving only “generate a map.” I was trying to build a real workbench: a map manager, reusable OpenStreetMap files, saved settings, collections, and a way to pick up the configuration from one map and use it again.

I was still building all of that in Streamlit. Streamlit is a decent tool. It is not a happy home for an application becoming this complicated. Eventually I hit a wall where making the experience behave properly was nearly impossible.

So, once again, I rebuilt everything: a separate front end, an API, and all the glue in between. I made one-shot setup commands with a wizard that checked Docker, installed what it could, pulled the application, and offered one-click upgrades in the interface. In its own way, it was beautiful.

It was also still a bad experience for many people. I had built scripts, upgrade buttons, and a detailed interactive help page that generated reports and commands. None of that changed the fact that users were being asked to operate a small software deployment in order to create a map.

Open source strikes back

The generous offer that was not generous

Public hosting was producing most of the maps, and I was paying for it. The bill kept growing while “thank me with a donation” worked about as well as those sentences usually work.

Then a good Samaritan appeared with a generous offer: a powerful machine, free for the community to use. I was cautious, but the benefit seemed obvious, so I took the risk.

It failed. The offer turned out to be a way to watch the traffic, copy the open-source deployment, and prepare a paid map-generation service on somebody else’s server. I had invested endless nights, barely received enough donations for coffee, and was still struggling with the hosting cost. Watching somebody plan to charge for the flow I had built felt like theft, whether or not a licence at the time gave them room to do it.

That was the moment I changed the Maps4FS licence. But the licence was not the real problem. This person was a symptom. The sickness was that the only easy experience still depended on somebody hosting a heavy service for everybody else.

Give them an app

The painful lesson that led to the right answer

The solution was to stop treating Docker as an end-user product. Docker is great for developers and awful for somebody who only wants a map. I researched the alternatives, found PyInstaller, and built a standalone Windows application.

It worked. Very quickly, roughly half of Maps4FS usage moved to the local app. The whole encounter had been painful, but it forced me to see the delivery problem clearly. Better software is not only better algorithms. Sometimes it is simply software people can actually open.

I also started looking at the technology I had built and thinking beyond Farming Simulator. Elevation is elevation. Vectors are vectors. Surely I could reuse this for a SnowRunner generator one day. I began pulling Maps4FS apart into reusable components and somehow turned one project into an ecosystem of about ten repositories. Very normal and restrained behaviour.

It created another important foundation, though: a standardized way to bring real-world data into different games.

The end of Maps4FS

The moment I started to hate my own software

Buildings were there. Maps4FS placed them somewhat randomly, but somehow it worked. Then I added electricity: poles, towers, and power lines. It was difficult, and when I finally finished it, a question that had been quietly following me became too loud to ignore.

This software had become impressive and almost impossible to use well.

You edited data in JOSM, fed it to Maps4FS, waited, opened the result in Giants Editor, and discovered that the poles were too close to the road. Or too far away. Or a building was missing because its size differed too much. So you edited, generated, waited, looked, and repeated. Again. Again. Again.

While trying to make my own map, I seriously began to hate the software I had created. That hurt. Maps4FS was supposed to save people from wasting days, but the more clever features I added, the more the black box punished them. You were doomed to generate maps endlessly and pray that this time the hidden decisions would be right.

After the electricity update, I stopped.

Experiments

If not a black box, then what?

I paused development and tried alternatives. First came preprocessing OpenStreetMap data, an idea that would return in MapToPlay later. It helped, but not enough.

Then I trained my own segmentation model with Supervisely, hoping aerial imagery could identify fields and other features. The tooling was excellent and the experiment was not bad, but my training labels came from public OpenStreetMap data. They were too incomplete and inconsistent for the result I wanted. The model worked. It just did not work well enough.

And then I stalled.

I will not sit here and pretend I spent months discovering the answer. The answer was simple. A black box did not work. A collection of disconnected tools did not work. Editing an OpenStreetMap file and feeding it into a generator was like replacing JOSM with Notepad and manually changing polygon coordinates. Technically possible. Deeply bad.

The only honest answer was what you see is what you get. People needed to see the terrain, roads, fields, buildings, and objects; edit them directly; trust that the work was saved; and export from the exact state in front of them.

The decision

The idea was clear. The scope was terrifying.

The problem was the size of it. A live, persistent 3D editor was an enormous amount of work. Almost none of the old interface could be reused, no matter how carefully I had separated the processing code. This was not a new Maps4FS feature. It was a completely different approach built from scratch.

The real question was whether I was ready for that crunch — and whether my family was ready for me to disappear into it for God knows how many months. The effort felt unbearable. I was scared as hell. So I stalled a little longer.

Then I decided to try.

I ruined a family vacation by thinking about it twenty-four hours a day and starting a proof of concept even though I had promised we would actually have a vacation. I hope my wife forgives me one day.

But there it was on my laptop: a freaking 3D editor, running in a browser, with real terrain inside it.

I announced in Discord that it was time for something new. Then I disappeared for weeks.

MapToPlay

Alpha, disappear, repeat

The work was not only writing code. Most of it was thinking: how should this feel? How do I keep it approachable without stripping away the procedural tools that make the whole idea valuable? How do you get one-click filling, smoothing, copying, and generation while still letting people touch the result?

I took shortcuts. Some were useful; some eventually led to rebuilding the editor again. That became Editor V2, a story I have told elsewhere. But the first editor proved the bigger idea.

About two months after that first proof of concept, a small group entered closed alpha. A few weeks later I opened the alpha more widely. Then I closed it and disappeared for a couple more weeks to work through everything real users had uncovered. Apparently this had become my release process: invite people in, learn something frightening, vanish.

And that is how MapToPlay started.

I knew some Maps4FS users would not like the new direction. Maps4FS was limited, but from a distance it looked like a one-click experience — if you politely ignored the fifty settings, hand-edited schemas, and occasional Docker education. MapToPlay asked users to participate in making the map instead of accepting whatever a generator decided.

I had no doubt about the decision. Maps4FS was created to solve one specific problem and it was good at that problem. It should never have carried all the complex features I kept attaching to it. It took me a long time to stop shipping one more feature and ask where the whole thing was going.

MapToPlay gave the idea rails. Games can be added one by one. The same place can become a farm, a trucking region, a survival world, or something I have not imagined yet.

If you want the next chapter of the editor itself, I wrote about why I rebuilt that too.