Applying 16 years of experience from Gamedev to the Enterprise development

Introduction and background

Hello everyone. My name is Elijah, I am the CTO of Neurosell. For the last 7 months I've been developing technological products for ecommerce.

In this article I would like to share a case study of transition from gamdev to fully commercial development in the B2B segment. We will touch upon both difficulties and successful cases.

Before I start, a bit of background: I've been working in game development for 16 years, taking part in projects of various scales - from social browser games to AAA projects on PC and consoles. During these years I've been involved in many things - client and server side, AI implementation, architecture and infrastructure creation and many other things. I managed to work both in small teams and in big studios.

So, here we go.

---

Why did this happen in the first place?

It all started banal and simple - from fatigue. Somehow, on another heavy Friday night, after a passed release, we met with my good friend Max. Behind the bar we discussed life, different perspectives and projects.

And here, remembering some old ideas for creating applications for VK and Telegram, we gradually (it took more than one evening in the bar), we came to the fact that we wanted to try to change our range of activities and adopt the idea of developing mini-applications for social networks, which later grew into a large product for e-commerce using AI.

Having decided to launch my startup, I, as the person in charge of the technology part, went away to generally remember what it is - product web development and to forge an outline of the plan. And there was a lot to think about - work organization, architecture, technology stack, and more.

Eventually, after a few months (and a few rewrites of critical architecture), we came up with the following stack:

Let's break down why this particular stack?

• NodeJS - In general, in my bearded years I wrote back on puffy, but we live in the 21st century and I wanted to take something faster and more flexible, understandable for further development state and universal. Yes, of course there are still different Java, Python and Go, but here the question of experience, feasibility of some solutions and the possibility of hiring a team quickly arises. Of course, we use Python (for AI services) and C# (more on that below), but the main products work on Node.

• Express - Staying on the node. Why Express? After all, there are more modern solutions. However, my hands, beaten off in gamedev, say that the simpler and smaller the framework, the better. I didn't want to drag dozens of libraries, some of which won't be used in 99% of cases. Simple rationality. And Express is known by all noders.

• C# - For some heavy calculations, we use C#. I think the advantages of compiled languages over interpreted languages don't need much explanation, besides, we use Shared code (partially overflowed from gamedev projects), which can still be deployed in WebAssembly, where JS just can't achieve the results you need in the browser.

• JavaScript - Yes, I'm a stickler for pure JS, however I have to use it minimally. Mainly because there are people in the team who are used to working with typed languages and don't know all the pitfalls of JS.

• TypeScript - It is used for basic development of critical components. So that there are no errors with types. It may be unnecessary, but it often saves life.

• Tailwind - Why Tailwind and not Bootstrap? We actually use Bootstrap too, just not on all projects. Tailwind is more convenient. Bootstrap allows you to develop simple applications faster. That's all for now.

• Sass - For the most part, have given up on pure CSS. It is more convenient to use selectors and work with variables. And in any case we will get CSS at the output.

• Webpack - Why him? It's as old as the world. Well, in fact, even though it is ancient, it is well studied, and it copes with its tasks very well. When properly configured, it does not cause any problems. Hot Reload also helps.

• React - This is where I am impressed with the similarities in our UI frameworks in the gaming industry. React bindings and all that. Yeah and it's just already an industry standard.

• PostgreSQL + Sequelize ORM - We mostly use PostreSQL, for we have our hands full. But in general, nowadays there is ORM and we use Sequelize. Less headache when designing queries, convenient work with schemas and models.

• GraphQL - For internal work of services - GraphQL is used because of its convenience, but as external handles of work with API - Rest is used, because it is more common and understandable to other developers.

• Rest API - For external requests we use the more familiar Rest API.

In general, the base has been discussed. Now let's look at different approaches and experience in both spheres - game development and commercial software development.

---

What surprised you about the move into commercial B2B product development?

In fact, there are no differences in development approaches. The same modern standards are used everywhere - Git Flow, sprints, retro and so on. However, if you dig a little deeper, on average across the market, there are still differences:

• Reduced development pace - Perhaps, at first glance, the difference may be insignificant, but as my personal research and experience has shown, the gamedev industry has a stricter development pace (especially when it comes to mobile games), which is due to many factors, but the main one is, no matter how ridiculous, a more A/B-oriented and experimental approach to product development, aimed at maximizing profits.

• Customers - In gamedev, as a rule, your product has one or maximum two customers, in the form of a producer and/or publisher. Here (if we take B2B sphere), every new client is a new customer. And that customer may have another customer and so on. This leads to the following point.

• Customers at Customers - In addition to being responsible for the success of your product and business, you are also responsible for the customers at your current customer. The implication of this is that all development and support is broken down into two areas - support for the product itself and its end users (customers), and support that extends to the customer's end users.

• Lower entry threshold - As it may seem, it's much harder to get into gamedev, so there is an unpleasant situation where there are a lot of low- and mid-level low-quality staff on the market (even more so than in gamedev), and as a consequence, there are difficulties in recruiting really cool specialists.

• Market overheating - Huge stack of technologies (let's say in gamedev there are 3 main game engines and a couple more solutions for back end, and in Enterprise it's dozens of technologies just for the front end), a large number of different companies and outsourcing studios, freelancers, market dumping and much more. Well, and also - gamedev community is more close-knit, narrower, though not much inferior in market volume.

Thus, the differences are mostly in the business processes themselves. However, there are also technological solutions that are squeezed to the fullest in game development. We will talk about them below.

---

What kind of experience from gamdev helps?

Now let's break down what experiences help us the most when transitioning from game development to creating enterprise B2B products.

Complexity of technologies

The first and one of the most important is the complexity of technologies. In the game industry, developers have to study and work with many complex subsystems inside game engines, such as working with graphics, physics, audio data, and optimization. Optimization plays a particularly important role, as developers sooner or later have to delve into a fundamental understanding of optimal handling of CPU, RAM and many other aspects, as games are very complex software where every byte of memory has to be saved.

Architectural solutions and optimization

The second most important thing is architectural decisions. The game, in essence, is a huge monolith with hundreds of different subsystems, which you cannot scatter into microservices on different servers. Some of these systems are quite computationally heavy and it is very important that your architecture perfectly handles all the bottlenecks of the project.

Network solutions

Networking is also one of the most important aspects (especially in online games), where algorithms for instant response of subsystems need to be designed. Unlike corporate solutions, where a notification or message may arrive with a delay of up to half a second, which is not so critical, in real-time multiplayer games, such delays will destroy the product (especially in dynamic projects like shooters).

Teamwork

Another important aspect is teamwork. Game development, as a rule, implies cooperation between different specialists on the whole way of creating a product: programmers, artists, designers, sound engineers and scriptwriters. This teamwork experience is quite more versatile than in the usual corporate development, where a programmer usually communicates with a smaller number of different specialists.

Working with innovation

Working with innovations that often originate in the gamedev itself. Such examples can be new GPUs and new trends such as VR / AR. In general, game development strongly drives progress in hardware, and game developers more intelligently understand how to use its resources more efficiently.

Gamification

Gamification is the whole basis for product-user interaction in gamedev. Hundreds of mechanics for user retention, increasing the average check and time spent in the application were born there. All of this can be used in classic business development.

Thus, the experience gained in game development allows us to create really optimized, high-quality and large-scale projects, using technologies and approaches that have successfully proven themselves in products with multi-million audience.

---

What experiences get in the way?

In general, from the point of view of the development department, the transition to corporate B2B solutions from gamedev - from a general point of view simplifies the processes of product creation and technology implementation, somewhat reduces the simultaneous load, but on the other hand - some business processes change, burnout factors increase due to double responsibility.

Moments we highlighted for ourselves:

• Business communications with development and understanding of technology are weaker developed than business communications within gamedev, which creates an additional burden due to the extra step of onboarding new customers;

• The business is growing more shakily due to less adoption of product metrics, which 99% of product in gamedev is covered by (don't count indie developers, there's more of a creative story there);

• In gamedev, any mechanics are built around the psychology of the user, their behavioral factors;

• Products are more difficult to launch because of the presence of an additional link in the development chain (the customer);

• The quality of MVP launches should be an order of magnitude higher, particularly if the product approach has not been communicated to the client;

• Less automation in processes. Still a lot of things are done manually.

• Poorly justified technical decisions that may shoot off the knee in the future (chasing unjustified technologies).

It is clear that everything I described is quite individual for each business, I just tried to make an average estimate based on my experience (IMHO).

If you have any other examples or contradictions, I would be happy to discuss them with you.

---

What would we like to see in the future?

In general, we like to implement all the practices that we have carried with us from game development. However, in the future, we would like to implement the product approach of game development as much as possible, minimizing losses, while restoring the clarity of all processes and development chains to the same level as before.

So far, this has been hindered by some differences in business processes, but I am sure that everything can be adjusted to using a rational approach. It is clear that somewhere something will have to be dropped or completely removed from the work.

---

What are we doing today?

Today we are developing a whole range of services to create an ecommerce 3.0 ecosystem. We are developing new solutions for e-commerce based on AI, gamification methodologies (with transferred monetization mechanics in gamemade) and personalization of many processes through social mechanics.

You can read more about us on our website.