JAM-City: what started as a 3D database became a multiplayer game

It started as a way to view a database in 3D. It now has a name, JAM-City, and we can walk through it with colleagues, discuss the data model together and play it as a multiplayer game at the office. How did that happen?

At JAM-IT, we work every day on making complex processes easier to understand. For our clients, we build applications in which information, processes and users come together in a logical way. But during development itself, we are also constantly looking for ways to better understand what is happening under the hood. Sometimes that starts with a very practical question. And sometimes it gets rather out of hand. In this case, it started with an idea Armando had been thinking about for a while:

What if you could view the data model of an application not only as a schema, but as a 3D world?

He decided to build that idea. We can now walk through the data model of applications, look around in it with several colleagues at the same time, point at tables and discuss the structure together. It is now even possible to pick up a jetpack and turn it into a multiplayer game. How did we get there?

Complex information sometimes needs a different way of looking at it

The idea did not come out of nowhere. In several projects, we experiment with ways to make complex structures visually understandable. For example, by making routes and dependencies within questionnaires visible. You can then literally see which answer leads to which follow-up question and how different routes move through a process. The principle behind that also turned out to be interesting for a much more technical question: how do you get a clear view of a large data model?

What if a database is not a diagram, but a landscape?

When working on migrations and existing applications, you need to understand how an application is structured. Take a data model. An application can have a user table, organisations, checklists and all kinds of other objects. Those parts do not stand alone, but have relationships with each other.

In a larger application, that can grow into a model with hundreds of tables. Traditionally, you can of course visualise such a structure in a diagram. But at JAM-IT, we had been mulling over a different idea for years: what if we turned that model into a 3D world? Not just an image where you look at hundreds of objects from a distance, but an environment you can actually move through. That became the starting point of the experiment.

A visual environment is generated based on the structure of the data model. Tables become separate objects and the relationships between them form connections through the landscape. The focus is on the technical structure and the relationships between objects, not on the actual data in those tables. That means you can not only see that there are many tables and relationships, but also view the model from different perspectives. We have now created simulations with models of around 500 tables, which you can navigate in both 2D and 3D. And then, of course, came the next question.

If you build a world, you want to walk through it

Simply navigating through a 3D model was not enough. We wanted to be able to stand inside it, literally. So we added a character that lets you walk through the database landscape. That also changed the technical challenge. Because as soon as you let a character move through a virtual world, you suddenly run into things we do not normally deal with every day as software developers.

How should such a character walk? What makes a jump feel natural? What happens when you land? And while we are at it: how should a jetpack work? That is exactly where AI became interesting. We used AI, among other things, to research knowledge and best practices from game development. Behind something that seems as simple as jumping and landing, there are all kinds of principles, calculations and movement mechanics. With the help of AI, we could absorb that knowledge faster and apply it within our own environment. So AI was not only used here to write code faster. It helped make knowledge from another discipline accessible and allowed us to experiment further. And that experiment was not finished yet.

What if we could walk through the same application together?

Once you could move through the data model yourself, a new thought appeared.

What if several people could stand inside this at the same time?

That made the idea even more interesting for the serious use case where it had all started. Imagine that you want to discuss a complex data model with colleagues. Normally, you share a screen and try to point at a part of a large diagram with your mouse. Now you can enter the same environment. You walk together to a section of the model, point at a specific table or relationship and discuss on the spot how that part of the application works. From there, you continue through the structure. The database becomes not just something you look at, but a shared environment you can explore and discuss together.

We also see interesting possibilities for explaining technical concepts. For someone just starting out in software development, concepts such as tables, objects and relationships can be quite abstract. In this environment, you can show what such a structure looks like and literally move through it together.

And then it accidentally became a multiplayer game

Up to this point, we can still pretend that all of this was part of a carefully thought-out plan. It was not. Because once we could walk through a virtual world with several people at the same time, the next thought came naturally:

Can we also turn this into a game?

So a game mode was added. With different game mechanics. With jetpacks. And yes, also with weapons that let us shoot at each other. That means an experiment that once started with:

"It would be useful if we could view a database in 3D."

has now ended with colleagues flying through a database landscape in multiplayer mode at the office. Not exactly the outcome we could have put on a roadmap in advance. But perhaps that is precisely why it has become one of the most enjoyable parts of the project.

Looking seriously at software. And then playing for a bit.

What makes it interesting is that both sides now exist next to each other. On the one hand, there is a serious idea behind it. Complex technical structures become visible in a different way, and you can explore and discuss them together. On the other hand, after such a substantive discussion, you can switch to game mode and use the same environment to play with colleagues for a while.

The game is of course not necessary to understand a database better. But it does show nicely what can happen when you do not immediately limit an experiment to the original problem. Every new step raised another question.

"If we can visualise it, can we also move through it?" "If we can walk inside it, can we do that together?" "If we are inside it together, can we also do something fun with it?"

And before you know it, you have built a multiplayer game on top of the data model of an application.

Sometimes you just have to start building an idea

The original goal was not to develop a new product or build a game. We wanted to explore whether we could get a clearer view by making an abstract technical structure spatial. Along the way, the idea turned out to open up more and more. We can move through a data model together and discuss technical structures. We can make abstract concepts visible in a different way. And AI helped us quickly apply knowledge from a field we normally work with less often while we were building.

There was no client asking for a multiplayer environment. No business case for jetpacks. And certainly no requirement stating that we should be able to shoot at each other between database tables. There was mainly curiosity. And because we kept building and kept asking "what if this is possible too?", there is now something we probably never would have imagined in advance.

Where it will ultimately go? We will find out along the way. But the experiment has already shown us one thing: sometimes a completely new way of looking at software emerges simply by building an idea and continuing to experiment. Not just explaining complexity, but making it something you can experience. That was not the original plan. But it now describes surprisingly well what we have built.