Let me be honest: I always wanted to build a game. Not because you make money with it. Mostly you do not. But because it is the one thing you want to have done at some point as a software developer. And I did not want to do it the way many do it. I wanted it to be right.
What I always wanted
A catapult. An old world, a bit like in Anno, walls, houses, castles, towers, wood and stone. You stand there with an onager, set the angle, the tension, pick a projectile, and fire. And then the thing flies, hits, and the wall breaks.
Up to here that sounds like a hundred other games. The difference was a decision we made on day one and never took back: we compute the physics. We do not work with animations that are fixed.
What YOW is
YOW stands for Ye Olde World. A 3D game, by devpoint, Early Access on Steam on 4 July 2022, release on 25 January 2023. Windows and Mac. There is a demo, 21 achievements, and a price you have earned back after an hour of catapult.
You fire an onager at targets. Walls, houses, castles, towers. The targets are different every time because they are built procedurally. No level is the same twice, and so no level reacts the same way twice to the same projectile. There is a training mode, 24 missions where the targets shoot back, a final boss, and a mode where you fend off waves of balloons, with ballistas that help you.
And there is the camera I am proudest of: you fly along with the projectile. You release, and then you sit on the stone, see the wall come closer, and see what happens when it hits. Exactly what happens. Not a video of it.
Compute instead of play back
Here I have to explain briefly how most do it, so it is clear what we did differently.
In many games a collapsing wall is an animation. Someone once built on their machine how the wall breaks nicely, with dust, with flying stones, and that is played back when the projectile touches the wall. No matter where it hits. No matter how fast. No matter how heavy. It looks good every time because it is the same every time.
We said: no. Every projectile has a weight. Every shot has an angle, a tension, a trajectory. When the stone hits the wall, it hits it at a point, with an energy, from a direction. And the wall consists of parts that hold each other. Where the energy is enough, the joint breaks. Where it is not, it holds. What stands above loses its support and falls. And what falls hits something again.
That means: a light stone at the top of the tower is a different result from a heavy stone at the bottom of the tower. A flat shot is different from a high one. And a second shot at a half-broken wall is something else entirely, because the wall now holds together differently. On Steam we wrote: the direct way is not always the goal, almost every target can be hit in at least two ways, and sometimes low hits are better than high ones. That is not a marketing line. That is the physics.
On Steam we also wrote: physically correct, most of the time. Sometimes an effect remains that we lovingly called the ACME effect. Whoever knows old cartoons knows what is meant. A stone that hangs in the air a moment too long. A beam that decides differently from gravity. We did not hide that. It is part of computing instead of playing back.
Native code, a lot of it
And now the part you do not see from the outside.
We wrote an extreme amount of native code. Not because we wanted to, but because what we wanted was not fast enough in what you get off the shelf. A physics that computes for every part of a wall on every shot whether the joint holds, and that sixty times a second while thirty things fall at the same time: that does not run in the scripting language of an engine. That runs close to the machine, or it does not run.
So we wrote the hot parts ourselves. The trajectory calculation. The check of what breaks. The management of the parts that are in motion right now. We had done that once before, at Scan Your World, when we wrote the tracking ourselves, and I thought back then that was the hardest number crunching up to that point. YOW was harder. Because in a scan the room stands still. In YOW nothing stands still.
When the hardware gives in
That was the real problem, and it was not a technical one. It was a communication problem.
Fact is: when you compute the physics, every object that moves costs computing time. A stone that flies costs. A wall of two hundred parts that collapses costs two hundred times. Two walls, a tower, a house, all at once, and the player's machine, which we do not know, gives in. The frames per second drop, the game stutters, and the whole magic of the stone you fly along with is gone.
So the three of us had to coordinate constantly. Whoever builds a level decides how many parts a wall has. Whoever builds a projectile decides how much energy it has, and with that how much breaks at once. Whoever writes the physics decides how many parts may be in motion at the same time before we freeze them. And all three decisions are connected. If one builds a prettier castle, the other has to make the projectile weaker or the third has to make the physics faster.
A budget for moving objects. No more than a certain number of parts may fall at the same time. What is above that gets merged or is already lying down. That number was the most discussed thing in the whole year.
Every projectile is a contract. Weight, size, energy. Whoever builds a new one tells the others what it destroys. Otherwise someone builds a level that is gone in one shot with the new projectile. That happened.
The physics decides, not the design. If it looks beautiful but stutters, it is wrong. If it computes correctly but looks boring, it is also wrong. Both together, on a machine we do not have: that was the work.
Extremely demanding in terms of communication and coordination. That is the sentence I tell everyone today who wants to make a game. The physics you can learn. Talking about one number, the three of you, every day, for a year, that is the real work.
One year, three people
The game took a year, with two more people. Three people, one catapult. No publisher, no outside budget, no plan that this would become a company. It was a fun project. From the start. And I believe that is exactly why it got finished.
We were in a few magazines. That is a moment I remember: our own castle, our own physics, in a magazine someone buys at a kiosk. For a fun project by three people from Zug that is more than you may expect.
What it means to build a game of this class
We learned so much that today I can say: I know what it means to develop a game in this class. Not a prototype. Not a jump and run for the weekend. A 3D game with its own physics, procedural levels, missions, a final boss, on Steam, on two operating systems, with achievements and leaderboards, that people buy and play.
A game is ninety percent not the game. The physics was the core and maybe a third of the time. The rest: menus, saving, Steam integration, achievements, demo, build for Mac, build for Windows, store page, trailer, bugs on machines we do not have. You only know that once you have done it.
Performance is a team decision. It is not one developer optimising at the end. All three decide every day what may move. Whoever does not settle that early ends up with a beautiful game that stutters.
Computing is more expensive than playing back, and it only pays off if you show it. That is why the fly-along camera was not decoration. It was the proof that we compute. Without it nobody would have seen the difference, and we would have done the physics for nothing.
Finishing is a skill. Early Access in July, release in January. In between lies the part where many stop. We did not stop because we had promised each other. With three that works. Alone it would have been harder.
You can still download it
The game is still there. On Steam, with a demo, for Windows and Mac: YOW, Ye Olde World. I play it sometimes. Not to check whether it still runs. But because it is fun to aim a stone at a tower and fly along. I still love it today.
And if I built it again today? I would compute the physics again. I would build the camera again. I would write the budget for moving objects on the wall on day one instead of discussing it for a year. And I would start with three again. Not alone, not with ten. Three people who argue about one number every day and still like each other in the evening.
I wanted to make a game where the physics is right. It took us a year, the three of us, with a lot of native code and even more coordination about what may move. Now I know what a game in this class costs. And I know it was one of the greatest joys of my life. Both are true. You can still download it.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.