Everything You Always Wanted to Know About Game Developing (But Were Afraid to Ask)

Everything You Always Wanted to Know About Game Developing (But Were Afraid to Ask)

Dariusz Sadkowski - Senior Magento Developer
5 minutes read

When it comes to the games, Dariusz Sadkowski is a real pro. Not only a player but also a great game developer! We talked about his experience, technologies used to code games these days, and the future of the game industry. Check it out!

What came first – a passion for games or coding?

A passion for games, definitely. I got to know games before I even discovered such a thing as programming or computers. It started with Russian games like “Wolf and Hare”, and some races played on a console my father made. Later, it went downhill. Programming showed up about five years after my first contact with games. It was fun to play, but sometimes I found some options missing, and some games could be done better. Therefore, I started my adventure with games (Doom, Quake I, HeXen II, and a few others), willing to improve original performance or add something from myself. However, it was not enough over time according to some limits in the game codes I worked on. And eventually, I reached the level of tailoring my own games from scratch.

Can you briefly describe how game development looks from the developer's perspective? What are your significant tasks?

If you happened to work in a team (usually a few people, performing without any detailed division of work), I usually assumed the role of a broadly understood programmer. I was responsible for programming the interface, gameplay, combat systems, shaders, sound support, graphic libraries, the behavior of objects and elements of the environment, physics, AI, or implemented scripting languages ​​into the engine.

On the other hand, a lonely game dev has to face many things. Of course, the lion's share is programming. But you also have to deal with graphics and sound, write out all the elements to appear in the game, write a script, or work out some realistic gameplay that will appeal to the potential users. So, you have to struggle a bit with the balance of items, opponents, etc.

Moreover, it looks a bit different with each genre. There is definitely less clean writing and design in a typical network shooter than in an RPG. In the first case, it is enough to design a dynamic gameplay: a way of moving characters, several weapons, maps, game modes, or some exciting pickups. You can fit on dozens of pages of a typescript without forceful stuffing. On the other hand, in the second case (RPG), apart from the plot outline, locations, items, or gameplay, you need to spend a lot of time designing expressive characters and tasks that will make the player actually want to perform them. In addition, there are relations between characters and quests, the consequences of the player's choices, and many other elements. Complete documentation for an RPG for around 40 hours may be more extensive than the entire Lord of the Rings trilogy.

From a purely programming perspective, it takes a long time: class diagrams, relationships between them, and lists of required methods. This working process might be tedious, in which the coding itself sometimes might seem like a rest (as long as we didn't overlook anything in the design phase).

What tools/languages do you use? What exactly do you apply?

Languages: mainly C ++, C #, sometimes LUA for scripts, and GLSL and HLSL for shaders.

The main tools are currently Visual Studio (IDE), Blender (3D graphics), GIMP (2D graphics), Audacity (sound effects, dialogue tracks), and LMMS (music).

Several physical tools are available, such as a microphone, digital camera, graphics tablet, and scanner.

Despite the high entry threshold, C++ still takes the leading position. It perfectly combines a high level of abstraction and objectivity while allowing almost direct access to hardware resources. However, today mainly ready-made libraries are used, but sometimes you have to rewrite it for better optimization.

Along with C++, I also use C #, Java, and even JS combined with HTML5. There are also scripting languages such as LUA and Squirrel incorporated in my list of technologies used.

What do you consider the biggest challenge in coding games?

Aside from designing mentioned above, the biggest challenge is imposing some specific restrictions to work on a particular aspect of the game. Even if everything works the way we want, there is always something we could do better, something that can be polished up: to enhance performance, add new possibilities, and many other things. So instead of focusing on completing the project, a person spends endless time on corrections and sometimes wastes dozens of hours making changes that hardly anyone will notice, until eventually they just burn out. As a result, job satisfaction decreases, everything is done by force, and more and more mistakes are made until the project dies or turns out to be (from a technical point of view) a total failure.

You've worked on many great projects. Which one are you most proud of?

It's hard to say. Every project fills with pride as soon as it takes its final form. However, what I remember the most is the modification to Jagged Alliance 2. We had to change the game’s current form a bit and add a few elements, weapons, characters, and new mechanics. The satisfaction didn’t came from working with one of the best tactical games of my era, but the fact that it worked at all. ;)

The JA2 code I received could serve as an example of how NOT to PROGRAM. Classes with several thousand lines were a standard, mixing probably all known methodologies and frequent "goto". It was hell, but it worked.

Based on your experience, how do you think – in what direction the game development will move forward?

Today, it is obvious to state that it is going towards photorealism. What Unreal Engine or Unity tech demos typically show is to make a person forget at some point that they are watching a reflection generated in real-time by their own PC or console and not by another Marvel movie or the next part of the Matrix. The components are on fire; the fans are spinning so fast that they open up black holes, yet it all generates home appliances. I ensure that in a maximum of 10 years, such quality graphics will be easily generated by a mid-range smartphone.

According to other future aspects – 3D with battery-operated glasses once seemed to be the future, but it died before it even settled. For years, the market has been trying to get VR with bigger (Walking Dead, Beat Saber, Half-Life: Alyx) and smaller successes. In my opinion, the market will move forward in this direction, improving the goggles and controls while adding the possibility of experiencing an increasingly different range of sensations through a specifically created outfit. (By the way, vests that allow you to feel like you got shot have been in the game for several epochs).

What challenges or problems do you need to expect when entering this industry? For example, "crunching"?

As a programmer, I will answer: “it depends”. ;).

If we decide to create the so-called "Turkeys" (independent products), the only thing that can lead to crunch is ourselves. We set ourselves deadlines and requirements. Also, we make ourselves promises about our products on the web.

Unfortunately, when working in a specific company bound by contracts with the publisher, the situations may vary. It is essential for each team member to truly estimate their capabilities by correcting them for as many errors and corrections as possible, which will come out only in the testing phase. But the benefit is that everyone who takes the issue seriously counts in delays and the fact that the project will ultimately cost more than the initial valuations assumed. However, you cannot afford to delay too long because there might be lawsuits for the money return invested in addition to breaking the contract.

In other words, the larger the company is, and the more expensive the contracts are, the greater the likelihood of a crunch is. Sometimes the opinion of engaged team members on the project is not even taken into account. Someone "in advance" sets a deadline for the second quarter of 2022, following their statistics that this is enough to offer three years for a team to embrace a project that does not even have a pre-outlined scenario. And the only known thing is that the project will be a sequel to another title publisher. Of course, this is an extreme example but it does happen. Therefore, transiting from a small indie studio to a large gaming corporation might turn out to be way worse.

Can you tell us what does the retraining from a backend or frontend to a game developer look like? What are the common parts of these roles, and what are the differences between them?

At large, these roles have more in common than differences. I started with game dev, and only later fate set me on the path toward e-Commerce. However, it seems to me that backend dev could find their way into programming in C ++ or C #, and a frontend dev would definitely feel in their element with JS/HTML5.

The main difference lies in the product to be created and its level of interactivity. When developing a store, website, or application, we usually have a relatively limited amount of action that the target user can perform. The only thing the user can see is the UI. You don't have to worry about optimization either. Getting the full outcome in less than a second is usually satisfactory for a user. For games, the UI is often minimalistic. Apart from some menus, configuration, inventory management etc., the interface for most of the game is limited to displaying a few basic information.

Usually, at least these 30 frames per second (FPS) should be maintained, considering the fact that the game on different hardware configurations may work differently. Weaker equipment will display those 30 FPS, and the more powerful one – 120 FPS. Therefore, it is unacceptable to make any mechanics dependent on the number of displayed FPS (which Bethesda had a problem with even in TES V: Skyrim).

If you want to code games, do you have to deal with 3D graphics, motion design, and highly interactive, three-dimensional elements?

Despite appearances – no. That's the job of graphic designers, animators, and level designers. For a programmer, all you need is a cube in the game world and some math (matrices and quaternions). From a programming point of view, a given element is to change its state depending on the actions taken. It doesn't matter whether this element is a tree, a tank, or a character; you just need to leave a way to the appropriate people so they can set a specific object model in the editor and assign animations to specific states.

The gaming market is basically bipolar. How does it look from your perspective – AAA or indie? Where do you see yourself? Would you like to work for large labels, or are these small companies more inviting because of their independence?

I prefer to work for a large label that has not gone public and does not have to confess to shareholders. The team still has something to say, crunches are much less frequent, and the team can focus on delivering a refined project – not just giving everything a lick and a promise, so that the artificially pumped numbers on the stock exchange don’t get red.

Are there significant differences when creating games for various platforms? What does the work on adjusting the game to a specific format look like?

There used to be big differences. The leading game mechanics, file formats, etc., remained the same, but the code responsible for rendering, audio, and even controls had to be redone. Even before that, many additional optimizations were needed. For example, a home PC from the mid-range price segment had twice more RAM than the consoles available at that time, a more powerful processor, or a faster GPU. Currently, there are ready-made libraries to facilitate this task, or even engines (Game Maker, Unity, Unreal Engine), where a few clicks make the conversion to a specific platform, and we only have to work on optimization, not processing the entire renderer or management memory.

What competencies in a team or on your own do you need to have to develop games? Is it about both hard and soft skills?

I'm not sure how to answer. ;) The nerd will just get along with the nerd, even if their interests are completely different. You need to have an open mind, the ability to get in another person’s shoes, and strong self-criticism (a genius mechanic from the developer's point of view can be a hopeless mechanic from the player's point of view). Of course, there should also be a love of games. You have to feel what you are doing and put your heart, soul, and sometimes even your liver into it. The best ideas are likely to appear at the weekend party.

If it’s about the hard skills, you need the ability to apply the tools, experience in programming/graphics/sound processing (it depends on what exactly you do in the project), coping with stress, and the ability to read with understanding.

For "soloists", it is preferable to avoid problems with total strangers and maintain self-discipline: not to overdo with the constant design improvement and stick to agreed requirements on the original documentation. Improvements are obviously good, but their excess can kill any project because a person will just burn out and get bored.

Let's talk about something more pleasant. So... what games do you like to play the most, and which have you played best?

If I had to pick one genre to play, it would definitely be RPGs. And frankly speaking, I work best with such ones. Despite the enormous project complexity, the satisfaction is huge, and the "request" to create a world living on a computer is simply outstanding.

Do you remember the first game you got your hands on? What game was it? And what hardware did you play it on?

The very first one was Pong on TTL, developed by my father. The controllers were probably resistors with knobs when you turned them, and the rectangle, being the paddle, moved up or down.

When it comes to specific titles on specific platforms, it’s Mario on Pegasus (Taiwanese clone of Famicom/NES). ;)

And that's a great choice! Thanks a lot. ;)


On-demand webinar: Moving Forward From Legacy Systems

We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.

Watch recording
moving forward from legacy systems - webinar

Latest blog posts

See more

Ready to talk about your project?

1.

Tell us more

Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!

2.

Strategic Planning

We go through recommended tools, technologies and frameworks that best fit the challenges you face.

3.

Workshop Kickoff

Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.