how we develop a game for employees

For three years now, our team has been developing an online game for ourselves. At first, during the Covid times, it partially replaced offline corporate events for us, and now, having already become a tradition, it complements live meetings. We started with a simple board game on the web with a map and dice, and now we are making a custom isometric 3D game with a top-down view on ThreeJS. In this article, I will share the process of evolution of the game from the point of view of development and game design, and also talk about the idea, motivation and resources for development and how to encourage colleagues to communicate with each other, working from different parts of the world and different time zones.

My name is Artemy, I am a frontend developer, I do all sorts of improvisations. If you need to build something experimental in a short time – come to me.

Why did we start this?

2020, Covid, lockdown, restrictions on offline events. Companies around the world are organizing remote work, cookies are getting stale in empty offices, and people are learning to work without being distracted by their families. We are sure that you all remember this time and how it felt.

But when it became clear that life on the planet would not be destroyed by the Wuhan virus, and work processes were put on new tracks, the next question arose, which we asked ourselves at that moment. We learned to work remotely, but how can we relax and communicate remotely? How to develop a corporate culture without live communication at fun corporate parties with a bar, chill zones, rock concerts and everything we are used to? Online gaming became the answer to this question for us.

Web-desktop

The most logical way for us to write a game was web development — we have a lot of web developers on our team due to our job description. The frontend was written in React, the backend in Node.js. This stack is good enough for a board game with dice rolls.

First, we drew the path along which the players would move, something like a rough map. At this stage, we also thought in advance about what events would take place and on what cells. While the illustrator was drawing a beautiful map, the front-end developers were already laying out the layout, so this rough map saved us a lot of time.

Note to the owner: if you screw up at the map design stage, you can break the entire gameplay. That's why we carefully thought out which cells would move the player forward and which would throw him back, so that the player wouldn't get into a loop with constant back-and-forth moves or impassable tasks. Roughly speaking, if the player lands on a cell that takes him back 5 moves, there shouldn't be a cell there that takes him back 5 moves forward. It seems obvious right up until the moment you start double-checking the entire map design for such dirty tricks.

While the map was being drawn, we wrote the basic functionality: throwing dice, moving around the cells, scoring, a cell with an input form, and a quiz cell. And then we worked on additional features, for example, adding the position of the other players on the map so that everything looked like a regular board game with chips.

Oh yeah, we developed and launched the first version of the game in 2 weeks. We were just so spontaneous at the time that we wanted to make our own game for the New Year. We even got by without any serious bugs, but we weren't in such a hurry anymore.

We released the next version of the game in the summer. In the summer version, for well-known reasons, the concept changed to relocation, and players moved around different countries. In addition to the fact that we redrawn the map, we also added mini-games and “PVP mechanics”: chess, rock-paper-scissors and even Go (a game, not a programming language). Any player could challenge another player, and the latter had the right to accept or refuse. We played for money, or rather for the internal currency, which was then exchanged for merch, cards in the Golden Apple and all sorts of subscriptions like TG Premium, films and music.

Own “metaverse”

It was 2021. Back then, techies were just waiting for the release of Apple's AR headset, and Mark Zuckerberg was desperately dreaming of metaverses, which caused some to be enthusiastic and others to be skeptical. These “metaverse” memes gave us the idea to develop our own metaverse at home.

Jokes aside, the concept fit perfectly with our desire to “enter the game at any time, so that there is always something to do there,” so we jumped at the idea. And since it's called the metaverse, let's get into 3D.

3D Research

Why reinvent the wheel, we thought, and started by looking for ready-made solutions. But it soon became clear that all of them were either very expensive (around $50-60k) or could not be customized in any way. But most often, both at the same time. The situation with ready-made solutions was best described by my manager.

One of the promising ready-made solutions was thirdroom.io: open source, built-in audio and text chat, server-side physics support, and, most importantly, a familiar stack.

But the main technical disadvantage was the overly complex architecture – all networking worked through Matrix (a distributed mesh network) and required NATS, which made use of it with Docker and nginx incredibly problematic.

I also looked at Mozilla Hubsbut due to the lack of many built-in capabilities, such as creating scripted objects, I also abandoned this option at the stage of the joint demo call.

After looking at various options for ready-made solutions, we finally decided to leave these attempts in the past and start moving towards our own.

Initially, we thought about creating a third-person walker. But we quickly dismissed this idea, because a full-fledged walker would be too resource-intensive for the web. Instead, we decided to make a game in isometric projection, where all the buildings are only half-modeled, which allowed us to get rid of unnecessary polygons and reduce the load on the PC.

At the same time, the isometric Plus City was launched, so all our doubts disappeared – if they can, then we move on. The only thing left was to choose a stack.

For the rendering system I chose Three.js and its React wrapper Three Fiber. “Easy to learn – hard to master” – that's how I would describe the learning path. I put together the first demo in literally one evening.

The library acted as a model of the physical world Rapierwhich we chose for its fairly transparent concepts. Another advantage of the package is that it comes in the form of WASM, which results in a large increase in productivity compared to similar solutions on JS.

As network libraries we have taken geckos.io for communication via UDP via WebRTC for fast packet exchange. In them we transmit the current state of the world. And for events that we need to make sure we receive, we chose socket.io — one of the most popular libraries for WebSocket communication for Node.js.

We developed the 3D experience itself in waves, and each time the beginnings of the metaverse changed dramatically. The first thing we did was add basic character display and movement. After that, the order was:

• experimented with instancing;

• after, we started working on post-processing;

• worked on colliders and related events;

• integrated video material;

• made spatial audio and a system for linking events to animations.

Next, they brought in a route search, which made it possible to control the robot not only with a keyboard, but also with a mouse.

We created a system of markers – they show the direction to an object on the map.

There were some experiments as well. We tried using WebWorker rendering with react-three-offscreen — this was supposed to help unload the UI thread. But because the library is still in an experimental stage, the number of compatibility issues forced us to abandon this idea.

We also tried rendering the game via WebGPU. The result is on the screen, and, as you can see, it is not very successful. WebGPU, alas, does not support post-processing yet.

But surprisingly, netcode on Node.js did not turn out to be a bottleneck for the project and easily handled 80+ people in one session.

After over a thousand commits, countless man-hours, and several reincarnations of the project, we finally have a quality product that we can proudly boast about. Vote for this article or something…

Resources for development

We managed to create the very first version of the web-based board game in 2 weeks, but if you decide to repeat it, we advise you not to rush – it's tough. Although, despite the tight deadlines, after the release, my colleagues who were not involved in the development did not even manage to hack anything!

Speaking of the project participants, from the very beginning the small gamedev studio included:

• one-man band: project manager, designer, analyst and art director all rolled into one;

• the illustrator who drew the map;

• backend developer in my person;

• 3 front-enders;

• tester;

• 2 content specialists who came up with tasks and generated ideas on how to make employee communication more effective and fun.

When we realized that the game was going well, we expanded the team for the development of the next versions and began to allocate adequate time for development. Now the resources for the 3D game look like this.

Permanent team:

• Project management, design, 3D modeling, analysis and art direction in the person of one person;

• Chief of Development, responsible for both the frontend and backend (Mom, I'm on TV);

• 1 front-end developer;

• 1 backend developer;

• 1 QA engineer.

The temporary team is those who we periodically involve:

• 1.5 designers;

• 1.5 3D modeler;

• 2 more front-end developers;

• backend developer;

• QA engineer.

Well, that's not all. From time to time, other guys helped us with the game's creation on individual tasks: design, brainstorming, copywriting, development, and 3D modeling. The names of all those involved are immortalized in the credits for the game, and this article is another reason to express gratitude to everyone; we are sure that many of the team will read it.

It was worth it?

Yes.

Firstly, our own game has really united the remote team not only in terms of work tasks, but also in shared leisure time. Each game event becomes an event that is awaited: on event days, Slack is bursting with local memes and warm words of gratitude, colleagues prompt each other with answers to questions, and chip in internal currency for those who are short of the coveted hoodie in our merch store.

Secondly, we started making 3D not just on a whim (although not without that, okay). The game became our internal testing ground. While developing it, we dive deeper into ThreeJS, understand what the technology is capable of, and gain skills that we then apply in commercial projects. A multi-move!

Now you can play such a game only if you are a Merc employee. In the meantime, we continue to improve it: we come up with new locations, tasks, expand the map and prepare the next events, and at the same time we study new possibilities of 3D on the web.

If you liked the development process and the inside story described here, subscribe to the telegram channel Merk/Daily — there we write daily about important events in the world of IT, application development and invite employees to lead the channel from the first person. I also write there, for example, from here a series of posts about the creation of the game, which formed the basis of this article, begins. Well, write comments, I will be glad to chat and answer questions about the game.