My name is Branislav Vajagić, and I officially started programming games at the end of 2001. When I say officially, I mean it became my job. Before that, I engaged with games in every possible way, like many people do: as a hobbyist and an enthusiast. I played games and tried to create something of my own. Those were the days of Spectrums, Commodores and so on. It was a great experience, pure fun. As for the business side of things, I started at Metamorph Studio, then moved to some local studios, like Level Bit, then the Serbian-Israeli co-production TabTale and later worked at Eipix. In between, I freelanced and now I’m in the position of a Lead Programmer at Yboga Studio.
As a kid, I got hooked on playing various games on old machines. I didn’t choose to work in gaming because I had a grand master plan. I just loved games, and when the opportunity arose, I simply took it. The opportunity strangely presented itself when Goran Rajšić and Nikola Vitković came from the underground comic scene of the former Yugoslavia. They decided to take a surreal step – to start producing a game, which wasn’t a small thing at that time. I happened to be in contact with the right people and entered the gaming scene. It just happened, it wasn’t planned.
Before that, I had some semi-professional experiences and dabbled a bit in web development. It was professional in the sense that it was a paid job, but it wasn’t entirely professional in terms of the team that gathered and started working. Then this happened and I never knew what would have happened next if I had continued on that path. As for non-professional experience, there were always amateur projects of various kinds, not just games.
I like to say that I’m like the successful and famous Bill Gates and Mark Zuckerberg – a college dropout. I didn’t formally finish the education I started. I went to college and then dropped out. It was the Faculty of Mathematics, where I was majoring in computer science. From this perspective, I think formal education plays a significant role. There you can learn things you wouldn’t otherwise. It may seem boring and hard, but it is very useful. It’s hard to push yourself to learn such things on your own, but when a professor pushes you, you simply have to. There were also things of the same nature that personally didn’t interest me much. I have nothing against mathematics, but it simply didn’t interest me. There was some friction between me and college. Then the opportunity to work on games came along and I accepted it. Just as it wasn’t strictly planned, leaving formal education wasn’t planned either. I just got too absorbed in game development. Fortunately, today, a lot of formal education can be obtained over the Internet, and much of it is free. Which has its advantages – no one specifically harasses you to do anything. And it has its drawbacks – no one specifically harasses you to do anything, so you can easily give up. Some majors, especially programming, are quite grinding. You have to endure a lot, but when you get through that phase, it’s useful. There’s another issue here. Formal education is often used as a kind of filter, which is completely understandable. When someone needs to hire someone, they look at work experience and education, and then education can be a filter – if someone hasn’t learned anything, maybe they don’t know anything, so why would we take them? Likewise, education doesn’t have to mean anything. Formal education is a special kind of sport; there you learn quite well how to pass exams, but it doesn’t necessarily mean that you master the subject. Again, it doesn’t mean that you don’t, either. I have a lot of acquaintances from my college who are brilliant people and connoisseurs, and some people graduated from college and completely specialized in other things – they are very good in their jobs and it has nothing to do with their formal education. In such cases, it’s not that great a filter. If I’m looking for someone good at math, I could never conclude that based on formal credentials. That’s why my attitude is a bit mixed. Fortunately, I say, today you can learn a lot on the Internet. And I often visit various courses from various world universities because you can learn something that helps you there.
Continuous learning is an integral part of the job. Whether it fits into working hours depends on the environment in which a person works. I’ve been very lucky; all the environments I’ve worked in have been such that there’s been a lot of freedom in that regard. Anyone who wanted to improve could. All resources were available, no one ever made a problem if someone spent work time on personal improvement. And I think that’s how it should be, at least in this business. And the way to get there, I suppose, is individual. For me, it usually happens when we come across a problem, so I have to struggle to solve it. Sometimes I have the opportunity to follow it, get interested and then start digging deeper.
I didn’t have any mentor in the classic sense, but in every other way – definitely. My mentor would be a collective personality: a bit of book, a bit of video, a bit of colleague and collaborators. Certainly, some professors, especially assistants at the faculty. There were several of them who were significant to me. Lately, the biggest mentors have been videos and colleagues. Regardless of age, experience, position… We can all learn a lot from colleagues.
In addition to knowing the code, non-technical skills such as general organizational skills, management skills, or simply communication with people are required. Since this is part of the job, I think it’s one of the important skills that aren’t programming-related. Although, in my experience, most of this comes over time through interactions with people who work in similar positions. If someone has any type of education in these areas, formal or informal, it’s certainly useful. But most people I’ve had the opportunity to communicate with, who work in similar positions, think that this is built over time due to the needs of the job itself.
A Lead Programmer position can vary a lot depending on the context and the size of the team. If the team is small, this position is a mix of managerial-organizational tasks and programming itself. Plus, some mentoring, if you have less experienced colleagues in the team. If the team is larger, it’s similar, but you focus less on other things. In a small team, you often do things that aren’t strictly related to programming. You might deal with some bureaucratic work, game design, testing and live ops. Simply put, someone has to do it, and if you don’t have enough people, whoever can, does it. This happened to me during my career. If it’s a larger company like Epic Games or Ubisoft, I assume their Programmers are a bit more focused on more precisely defined tasks and don’t have as many indirectly related tasks in their workday. In the end, a Lead Programmer position comes down to coding and collaborating with team members.
I also worked in the financial industry as a Programmer for a while. The biggest difference is that in gaming, there’s a complete lack of responsibility. When you mess something up, no one will die. Which is quite liberating because you’re not creating a scanner to detect someone’s illness. Someone will certainly get annoyed, but in the end, they’re just games, so it’s not that scary. I think that’s a big difference between gaming and other IT industries.
In the financial sector, there’s a more rigorous layer of software testing because if someone clicks something you made and loses money, that can be a big problem. In games, it’s a bit different. It doesn’t mean there’s no responsibility – if your game is bad, your company will fail, so it’s not insignificant. But it’s still different from medicine or infrastructure monitoring, air traffic control and so on. The nature of the job itself is different, too. In the financial sector, there’s high-frequency trading and there’s a big focus on how to execute transactions as quickly as possible. These speeds are measured in very small parts of a second and people go so far as to program hardware. They try to get the computer physically as close to the stock exchange as possible to achieve these speeds. Here, it’s a similar issue – you want to display as many frames per second on the screen as possible. But if you’re in the mobile gaming industry, fortunately, someone has made it a bit easier for you, as mobile phone manufacturers say: “Our phones run at 60 frames per second. Maybe you’re better than that, but it won’t do you any good.”
Compared to other industries, perhaps the main difference is that the variety of problems a Game Programmer encounters is much greater. There’s less specialization. When you specialize in something like analyzing photos from the Hubble Telescope, it’s very specific. You have a set of problems that you deal with, and they may even be unsolvable, so it’s difficult for you. But when you make games, you usually come into contact with everything that exists in games. And in games, there’s everything we can think of. So I think that diversity is one of the key differences.
The main goal is to have a game that works and is as bug-free as possible – to ensure code quality for easier project maintenance in the future so that it can continue to be maintained or parts can be used for the next project. Equally important is for a Lead Programmer to help less experienced colleagues to improve and become more independent. To impart knowledge gained along the way and learn something from them. I think the main goal is the quality of the product itself and the quality of the code, for the future maintenance of the project, but also collaboration with colleagues.
As for my team, we are currently a small team, there are six of us. Actually, we split between several projects: we start in one and finish in another. As for the methodology, I must admit that I have tried everything and I am not overly happy with any methodology. We use what ultimately proves to be most suitable for us. Specifically, at Yboga, we are a new team, we are still getting to know each other, so we are still experimenting with the methodologies we use. We use some issue tracker, we try to plan relatively well what we can. We somewhat stick to agile, of which I am not a fan, at least not in every part of the production. Some methodologies are definitely useful in some parts of production, and not so much in others. For example, while at the beginning of production and while working on something in the prototype or experimentation phase, I don’t see the need for strict methodologies. But if you enter the final phase of production or post-release, then agile methodologies can be quite more useful than scrum. We have tried various technologies (Trello, Jira), and even paper and pencil. Some of these methodologies are more effective in person, and some when working remotely. I don’t have a favorite methodology. On this project, we are still exploring which one will be best for us, so once we establish that, we will probably stick to it.
A Lead Programmer mainly communicates and collaborates with a Producer because that is usually the person who brings all the other teams together into one entity. That’s how plans and tasks are determined for any given period. Since we are a small team, I collaborate with everyone. Also, the Lead Programmer communicates a lot with the Art Director because the graphics themselves require technicalities due to the technical requirements of the platform for which the game is being developed, so a lot of collaboration is needed there. I have always collaborated with everyone, but I suppose it’s physically impossible when the teams are larger. Maybe in a place like Blizzard, a Lead Programmer exclusively communicates with a Producer who is responsible for that project. It also depends on what kind of team it is. If it is a team that works on backend server support, that person probably has to communicate with various positions, such as people dealing with hardware, especially if you are building your own server farms.
As for the workflow, we get the game design and collectively make a plan for what we want to achieve in the next period. Then we simply break it down into smaller tasks. Later we divide it up, which is again my part of the job – to assign who will do what. And then we start working. If the task is larger, we agree on the main code architecture and everyone starts implementing what they have. If the tasks are smaller and everyone is already familiar enough with the broader architecture, then whoever gets something, starts working on it. At some point, my job is to do code review, which is done as often as time allows. The workflow is quite tedious, it comes down to coding, discussions and testing of code, both independently and through gameplay. Sometimes it’s not bad to do Unity tests, although I haven’t seen Game Programmers use these tests excessively so far. We don’t use them that much. I like to say that the goal of a Unity test is to test some code and thereby reduce the number of bugs, but on the other hand, a Unity test is also code. You can easily make a bug in a Unity test, and then what? Of course, it has its usefulness, so whoever likes it, can use it.
When it comes to documentation, it mostly boils down to some gameplay design snippets because it’s crucial to determine the programming part. What I produce are often task lists, tasks that we’ll all work on. And perhaps at the beginning of the project, or when new people come on board, documents related to coding standards or general coding rules. And, certainly, at the beginning of each project or part of the project, as a Lead Programmer, I should produce a document related to the architecture of the code itself.
These documents can be both short and long, they can also include diagram sketches, depending on the collaboration with other Programmers. If we already know each other well enough, then even simple documents can convey a lot, but if we don’t, then sometimes even an encyclopedia isn’t enough, although it usually is. That’s what a Lead Programmer should produce, and what they need to consume are mostly either production documents or game design ones. And, of course, what each of us should consult are calendars – since we mostly make plans and set deadlines to achieve something.
As for software, I use whatever seems useful to me at the given moment. Since we’re currently developing games using Unity, of course, there’s Unity, Visual Studio and various browser tools (Jira, Confluence, Google Docs, Google Spreadsheets). Then, I often like to use diagram drawing tools. I’ve used Miro, an online whiteboard for collaboration. That works well for me because some things are easier to represent visually, even though it’s later translated into text, which is code. I also use various small editors for JSONs, for converting various files. Therefore, I also use Visual Studio Code as a text editor or for some other things that aren’t strictly code-related. I often keep a text file where I jot down anything that comes to mind. Daily, I use Discord, Slack, Zoom, Skype and all sorts of communication programs.
As a final note, I would dispel an illusion that many have who want to enter the gaming industry. When something is your dream job, you expect it to always be interesting and enjoyable to do. However, everywhere I’ve worked, there has been both something boring and something interesting. Every time I take a step forward, then when I look back, it’s like: “Oh, how could I have done this?” And as long as that’s the case, I think it’s good. When a person can no longer look back and say: “Oh, this was silly,” then they haven’t progressed. I’ve been lucky to work on a variety of projects, so each one was a different experience, unique to me. It was always interesting and always boring because every gaming production reaches a part that is a grind – you simply have a task and you have to do it, whether you like it or not. The game doesn’t exist if it doesn’t have all the elements, and as boring as some elements might be, for example, integrating ads into the game, it has to be done. So, the grind in MMORPGs prepared us for the grind at work, so be sure that you are really prepared for it!
