Coincidence, luck and getting my first job in gamedev

I recently hit a milestone in my professional career – it’s been exactly 9 years since I made a move into games industry. This may not sound like something profound or significant but the circumstances of my transition from regular software development were rather interesting. I think it’s fair for me to say I was quite lucky and found myself in the right place at the right time. Today I want to share something I always bring up when talking to students or people who want to get a job in games REALLY bad but don’t know who to ask or how to start. This is the story of how I unintentionally and accidentally started making in games.

In 2006 I moved to Linköping in Sweden, with the goal of finalizing my studies. It was my last year and apart from taking several courses, all I had to do was come up with an idea for a master thesis, get it done and be on my way to a spectacular career in IT. At the time, I didn’t know too well what I’d want to do in my life. I felt like programming was “the” thing for me to do since I enjoyed it and found it pretty lucrative but I had no clear idea on what exactly I’d want to focus on. I came to Sweden with roughly 40000 SEK in my bank account which I made doing some part-time work as a PHP developer which would last me for a few months. I was also backed by a small scholarship from my home university but other than that I was on my own. If there’s one thing a person from a middle-eastern european country can say about Sweden it’s that it’s relatively very expensive. My savings were soon starting to dry up and the remote contracting I did at the time was simply not enough for me to make it through a month, so I decided to start looking for a job in Sweden which would hopefully pay higher than what I was making. Soon enough, I managed to find a small consulting company several blocks away from where I lived and they decided to hire me as a Python programmer. The pay was a mindblowing 15000SEK a month, which was a completely different ballpark from the 2000SEK I was making as a contractor for a Polish company. I took the job and was very happy with it.

Sadly, this didn’t last very long. Soon before Christmas 2007 I was let go. The economy started going bad for the company and they had to cut costs, starting with low-tier employees. Anyone who went through being fired knows how unpleasant it is. It gets worse especially if you completely don’t see it coming, which was how I felt. I did manage to save up a bit over the course of few months I got to work there but it was not enough for me to last until my thesis was done. I was mentally pretty shattered and depression kicked in pretty quickly. To take my mind off this, I turned to the best remedy I could get at the time: alcohol, drugs and online games! is a website with small flash games that don’t require too much of either focus nor time to play them. Back then it was extremely popular and for many developers it was the best chance they could get to actually make some money on a game and get it noticed by wider audience. For me, however, it was an anti-stress device and something that kept me occupied and distracted from my everyday financial problems.
Among dozens of games that I played, there was a very specific bunch I used to replay over and over. Coincidentally, they were made by the same company: Hammock ADB and Numbat Studios. Now that I think about it, I can’t really say what exactly was the “thing” that made me stick with their games. They were simple in concept, pretty and elegant with a slight nostalgia factor since some had a retro-feel to them. The rules were intuitive enough for a player to learn without a tutorial and the controls were flawless. Niether of the games had a particularily involving story but the overall theme of each product was enough for me to spend hours on end playing them. Whatever the reason, I decided to look these guys up and learn a bit more about them. This is where things started getting interesting!

Games by Hammock ADB and Numbat Studios were what kept my spirits high during unemployment depression.

First suprising fact about Hammock and Numbat was that they turned out to be companies based in Sweden. But it got better than that. Turned out their office was 2 streets away from my soon-to-be-former office which completely blew me away! I enjoyed playing their games but it was then when for the first time I thought: “hm… I have nothing to lose, maybe the actually need a programmer?”. At this point finding contact e-mails was a no brainer, so I decided to brush up on my CV, write the best “hello!” email I could come up with and just give it a shot. I didn’t have high hopes since I thought I’d be dealing with AAA professionals who might just shrug me off. Remember, it was 2007 and the indie developer scene was pretty much non-existant with a few minor exceptions. Unity was around but was not yet as relevant as it is today and using it for your small project cost insane amount of money. Unreal Engine was outside mere mortals’ reach, so if you wanted to make a game you’d either have to team up with someone and make your own tech or use mediocre tools. Also, I wasn’t 100% sure making games was what I really wanted to do. Despite my doubts, this is what I sent them:

Few days had passed and I got a resonse from Tomas, though it was not what I silently had hoped for:

So no job but there’s still hope and I should contact “someone who may know something” at a company I didn’t even know existed in the area (something that made me realize I should improve my Google-fu!). I wrote another email and soon enough got a response:

And this my friends is when I felt like everything was predestined for me. Power Challenge was looking for a person with my exact profile and experience, so naturally I followed up on it and in the end got hired. This was also my first exposure to a brilliant interview process where you don’t take a written test and there’s no “whiteboarding” involved. I got a task to do at home, 2 days to complete it and report back. For a freshman out of the university with very little professional experience it was completely unbelievable. February 2008 was my first day at work and it was also my first “real” full-time. This also led me to extend my stay in Sweden from the planned 1,5 to almost 3 years but that’s a tale for a different day… 🙂

The moral of the story and one big thing I learned is never to underestimate yourself and keep trying no matter what. Not gonna lie, in some circumstances it might also require a strike of luck or knowing the right people, which in my case was a subtle mix of the two, since Tomas from Hammock pointed me in the right direction and he happened to live and work in the same city as I did. Today it might not necessarily make that much of a difference since our online presences have no physical locations but being able to meet someone in person will definitely help. Another thing: getting a job in the industry you want to work in might not start off from the exact position you want but getting your foot in the door is always the first step. Even though PHP development wasn’t my dream gig (I wanted to work with C++, not traumatic web development!) it was still an invaluable experience I wouldn’t swap for anything else. You may not work with the things you want to right away but given enough time and persistence, you’ll get there eventually. If it worked for me, it will definitely work for you too. My first gamedev job also opened doors to meeting people in the industry. I got a chance to work with folks from DICE, Ageia, NVidia and a bunch of other companies I wouldn’t even dream to come across in my professional career. A lot of these people have switched jobs since then – some moved to Apple, AMD, Microsoft or big gaming companies across the world. With some our paths have divereged, with others I’m still in touch. Never burn bridges and always try to live as peacefully with your co-workers as possible. You may never know how your or their fate might turn in the future!

Tweet about this on TwitterShare on RedditShare on LinkedInShare on FacebookShare on Google+Share on Tumblr

Oculus Rift DK2 (SDK and OpenGL ES 2.0

Recently I’ve been working on a VR port for Rage of the Gladiator, a game that was originally released for mobile devices and used OpenGL ES 2.0 as the rendering backend. This seemingly simple task soon created several fun problems resulting in limitation of this graphics SDK in relation to “full-fledged” OpenGL. My initial idea was to rewrite the entire renderer but very soon this approach turned out to be a dead end (suffice to say, the original codebase was slightly convoluted), so I decided to stick with the original implementation. To run an OpenGL ES application on a PC I used the PowerVR SDK which is an excellent emulation of mobile rendering environment on a desktop computer.

Once I got the game up and running, I started figuring out how to plug in my existing Oculus code to get proper output both on the device and in the mirroring window. Rendering to the Rift worked pretty much out of the box – it only required changing the depth buffer internal format of each eye buffer to GL_DEPTH_COMPONENT16 (from the “default” GL_DEPTH_COMPONENT24). Creating a proper mirror output was a whole different story and while not excessively complicated, it did require some workarounds to get it working. Here’s a list of things I ran into – something you should consider if you ever decide to use Open GL ES in your VR application (but why would you, anyway? 🙂 ):

1. Replacement for glBlitFramebuffer()

Starting with Oculus SDK, rendering mirror texture to window is as easy as getting the system-handled swap texture and perform a blit to the window back buffer:

    // Blit mirror texture to back buffer
    glBindFramebuffer(GL_READ_FRAMEBUFFER, m_mirrorFBO);
    glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
    GLint w = m_mirrorTexture->OGL.Header.TextureSize.w;
    GLint h = m_mirrorTexture->OGL.Header.TextureSize.h;

    // perform the blit
    glBlitFramebuffer(0, h, w, 0, 0, 0, w, h, GL_COLOR_BUFFER_BIT, GL_NEAREST);

    glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);

With OpenGL ES 2.0 you will soon notice that glBlitFramebuffer() is not present. This causes more complications than may seem at first because now you have to manually render a textured quad which, while not particularily difficult, is still a lot more code to write:

// create VBO for the mirror - call this once before BlitMirror()!
void CreateMirrorVBO()
    const float verts[] = { // quad vertices
                            -1.0f, 1.0f, 1.0f, 1.0f, -1.0f, -1.0f, 1.0f, -1.0f,

                            // quad tex coords
                            0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 1.0f,

                            // quad color
                            1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f,
                            1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f

    glGenBuffers(1, &mirrorVBO);
    glBindBuffer(GL_ARRAY_BUFFER, mirrorVBO);
    glBufferData(GL_ARRAY_BUFFER, sizeof(verts), verts, GL_STATIC_DRAW);

void BlitMirror()
    // bind a simple shader rendering a textured (and optionally colored) quad

    // bind the stored window FBO - why stored? See 2.
    glBindFramebuffer(GL_FRAMEBUFFER, platform::Platform::GetFBO());
    glBindTexture(GL_TEXTURE_2D, m_mirrorTexture->OGL.TexId);

    // we need vertex, texcoord and color - used by the shader

    glBindBuffer(GL_ARRAY_BUFFER, mirrorVBO);
    glVertexAttribPointer(VERTEX_ARRAY, 2, GL_FLOAT, GL_FALSE, 0, (const void*)0);

    glVertexAttribPointer(TEXCOORD_ARRAY, 2, GL_FLOAT, GL_FALSE, 0, (const void*)(8 * sizeof(float)));

    glVertexAttribPointer(COLOR_ARRAY, 3, GL_FLOAT, GL_FALSE, 0, (const void*)(16 * sizeof(float)));

    // set the viewport and render textured quad
    glViewport(0, 0, WINDOW_WIDTH, WINDOW_HEIGHT);
    glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

    // safety disable
    glBindBuffer(GL_ARRAY_BUFFER, 0);

2. Keeping track of the window/screen FBO

Many complex games of today heavily employ the use of rendering to texture for special effects or various other purposes. My experience shows that once programmers start using RTT, the calls to glBindFramebuffer() start appearing at an alarming rate in various parts of the code, disregarding the fact that in many instances switches between rendering to texture and rendering to the actual window happen more often than it should. Not counting performance impact, usually this behavior does not produce unwanted results and it *may* not matter whether we squeeze a render to window between various RTTs or not. Now, consider that the Oculus mirror render is virtually a blit to separate eye buffers which are then later again blitted to the output window buffer resulting in the popular distorted image you see in YouTube videos. If the rendering code performs a blit to window in-between RTTs, parts of the final image may be distorted by weirdly overlaying images.

Notice how a popup is rendered incorrectly behind the lenses due to a mid-RTT render to window.

For this reason it’s important to correctly track which FBO belongs to the window and avoid reverting to it *before* you render the entire scene – glGetIntegerv() is your friend and it can save you a lot of grief, especially with more complex drawing sections. While this is not a VR problem per-se and may happen to you in regular application development, it’s definitely easier to run into in this particular case.

3. Remember to disable OpenGL states after you’re done using them

Again, this is not a strictly VR-related issue but one that can manifest itself right away. With VR rendering you have to remember that you essentially draw the entire scene twice – once per eye. This means that OpenGL state after the first render persists during the second one which may produce some rather baffling results. It took me quite a while to understand why left eye rendered correctly, right eye had messed up textures and the mirror turned out completely black – turns out the cause was not calling glDisable() for culling, blending and depth test. A simple fix but very annoying one to track down 🙂

4. Don’t forget to disable V-Sync

As of today, PowerVR SDK seems to create all render contexts with V-Sync enabled – while this may sound suprisingly easy to detect it did, in fact, caused me some trouble. What’s worse – Oculus Rift didn’t seem to bother and showed a constant 75fps in the stats which only added to the confusion (why oh why does this one single triangle rendering stutter all the time?). Calling eglSwapInterval(display, 0) will solve that problem for you.


In perpsective, the issues I ran into were a minor annoyance but clearly showed how forgetting simple things can cause a whole bunch of issues you would normally never see when performing a single render. The whole experience was also a nice indication that the current state of Oculus SDK performs well even with limited OpenGL – even if it’s a bit gimmicky when developing for a PC.

Tweet about this on TwitterShare on RedditShare on LinkedInShare on FacebookShare on Google+Share on Tumblr

Game Engine Architecture by Jason Gregory

This is the book I’ve been wanting to read for a long time. With close to 1000 pages of pure content, you get a heavily condensed compendium on good, bad and typical practices in game engine design. What’s great about this book is that even though it reads like something straight out of a university library, all the information is based on the author’s practical experience. This means that there’s relatively very little “dry” theory in favor of analysis of real life applications and how each component may perform on current gaming hardware. The latter was something I found especially interesting, since there’s very few articles out there that give you a decent comparison of the XBox or PS4 hardware against a desktop PC. If you never worked in AAA gamedev, you will definitely learn a lot. That said, the book is clearly aimed at people with various programming or industry experience. If you already shipped a title, you may find some parts of the book rather obvious. Nevertheless even having prior knowledge of the covered topics didn’t prevent me from catching some interesting quirks, making going through the entire thing worthwhile.

The two major chapters of the book are focused on rendering and animations which are usually the most complex. However other elements are not neglected in any way – coverage of memory allocators, debug tools, profilers, gameplay design and HID gives the reader a perfect picture of how extensive and complex piece of software a game engine truly is. Comparison of internal software used by major game developers was pretty informative and should give you an insight on how to properly design tools of your own. One thing that should be noted is that there are no straight code solutions in any chapter – the whole book should be treated primarily as an introduction to each topic. Supplementary literature is provided, so this makes a perfect starting point no matter what you want to focus on in your programming career.

If you want to start out in the game industry this is definitely the book you want. If you’re already experienced you may not benefit as much but you might still learn a new thing or two. However if you already own the first edition of the book you might as well hold out. The audio chapter and slightly updated information on gaming consoles, while informative, are not good enough a reason to spend another $60.

Tweet about this on TwitterShare on RedditShare on LinkedInShare on FacebookShare on Google+Share on Tumblr

“Hazumi” – a game that came to be against all odds

December 2014 and January 2015 mark the dates when my simple puzzle game “Hazumi” came out for the Nintendo 3DS. It’s been almost 6 months and only recently I started feeling the whole production pressure wearing off, so I decided to share my story with other inspiring game developers out there in hopes that they don’t repeat the mistakes I made. You won’t find any marketing tips here nor how to interact with the social media to promote your work – there’s a ton of a lot better articles on that topics out there. What I could seldom find was sort of a personal confession from the developers on how they felt during the development and what they had to go through over the course of their work which should be as important in order to maintain mental health. I’m writing this in hopes that someone benefits from my experiences.

It all started in mid-2012, when I came up with an idea of finally making a game of my own. The company I worked for at the time was kind enough to let their employees pursue their own projects and even help with publishing if necessary, so it sounded like a perfect moment to get on the “indie bandwagon” and do something creative. Since I wanted to start off rather easily, I decided to remake one of the games from my early childhood: Crillion for the Commodore 64. The premise was very simple: you’re a ball bouncing around an enclosed brick level, your goal to destroy all the blocks of the same color as the ball in order to proceed further. The idea felt perfect for the mobile market at the time and the basic game mechanics was, theoretically, easy to implement. I teamed up with a friend graphics designer, we set out to release the game for the Nintendo 3DS first as it was the perfect platform for this kind of a game. Thus the development process started.

Choosing the tech
Unlike most cases, choosing the underlying technology was a no brainer – our company already had a basic rendering, input and audio engine which supported multiplatform production (including iOS, Android and PC), so we decided to use exactly that. And trust me when I say, that developing a game for Nintendo 3DS without having to test it on the devkit every single time makes a lot of difference. The underlying software, while solving a lot of initial multi-platform issues, was not truly fit for our needs, so I decided to develop an engine on top of that – something that in the future I would call “Talon“. For graphical assets, we used all regular tools of the trade. We aimed for a classic 2D look, so no additional software was needed. We set up a common project on Todoist and Google Groups and distributed all the task we felt were essential to complete for the prototype. We had everything at that point to make a successful game: technology, skills, idea and enough motivation for both of us. The only thing we lacked, was enough free time.

Initial development
Intensive work started around August 2012. Fellow artist was at the time preoccupied with other project obligations, so at first the main focus was on developing a playable prototype and the engine itself for any future projects. I was hyped and really excited. For the next few months I worked 8 hours during the day, then went straight home and spent another 4-5 hours hacking at the game I would want other people to play as much as I do. The first prototype was finished by November, compileable and playable across ALL major mobile devices with full sound support, input and audio. It felt like everything was going as smoothly as it possibly could.

And yet, it took nearly 2 more years to push the game out for sale.

Time is always against us – this is especially true when you’re employed full time. Getting the graphics done turned out to be an extremely arduous task. By December we had concepts but no clear sense of style direction. We decided to take small steps, relax a bit and don’t press anything in fear of creating a mediocre product. I told the artist to take a break and think over the design while I would tinker more with the prototype, turn it into a full fledged game and add some extra features we were both talking about: UI system, level selection, progression and a level editor. With those thing in mind and still fully motivated, I started implementing each component one by one, further extending the engine’s functionality.

Another year has passed. An intensive, hard working and extremely stressful time where most days I worked over 12 hours a day, the only driving force being my motivation that I want to finish the game. I implemented a level editor, the engine was practically ready for multi-project development and it had all the features I wanted it to have including stereoscopic rendering for the 3DS and support for every existing compressed texture format I could think of. I even took the liberty to experiment with different gameplay types, client-server architecture for sharing levels online and even time challenges that could retain the users on the more difficult Android and iOS. The idea bag was full to the brim but luckily cherry picking them went really well and in a fairly short amount of time I narrowed down all the game features that the final game would have on its release day. But not all things went so smoothly: the time is November 2013 – and we still have no graphics whatsoever. This was the moment I realized the fatal mistake I made. Our team of “dynamic duo” lacked communication and we hadn’t even noticed when. We stopped talking about the game, we stopped thinking what a fun thing we’re making and, as a result, we stopped motivating each other and pushing ourselves further. The team broke up leaving behind it a pile of neatly written code and a game ready to be playtested had it only had the looks. It came unexpected. I didn’t see it coming.

Starting all over
All that time I was so endulged in my own work that I lost the bigger picture. Furstration kicked in. Seeing that I had no other option, I decided to take up the challenge of doing the artwork myself – big mistake in retrospective, since I consider myself “artistically handicapped” and I couldn’t possibly match the quality of games on the Nintendo. Still, I decided to give it a go and believe it or not – it was quite entertaining at first. Over the span of next several months I taught myself how to use all the basic drawing tools and began experimenting with different art styles trying to capture “on paper” what I saw in my head… but it just didn’t “stick”. When showing the game to others I could tell how unappealing the game felt even though the mechanics and controls were found to be intuitive and enjoyable. Something was missing and I just couldn’t get it right myself even with tips from other artists (you wouldn’t believe how difficult it is for a programmer to take art advice!). And then I saw the light at the end of the tunnel when a graphics artist I worked with at my day job said how much he enjoyed the game and that he’d love to help. I gladly accepted, though with slight reluctance after what I’ve experienced in teamwork till that moment. Soon it turned out it was the best decision I could’ve made. While I was taking a bit time off from the excessive amount of work, Rafal did an amazing job and in just under 2 weeks created artwork I couldn’t even dream of making myself.

My attempts to work out graphics style.

Final artwork.

With this new shot of inspiration, we started the finishing work on the game. Level design took another several weeks, interrupted by playtesting and “QA reports” from our friends. This work quickly started feeling rather mundane – coming up with new levels soon became more difficult and balancing the gameplay proved to be a tedious task. Repetition is a productivity killer and tires both body and mind amazingly fast. By the time we got everything polished and done just the way we wanted it was already nearing the end of the year. But the moment finally came. The game was complete. “Hazumi” hit the US 3DS eShop in December and both Europe and Japan in January of 2015. The reviews were positive, people seemed to enjoy the game as much as we did and it felt like the mission was accomplished.

And yet something was missing. The thrill just wasn’t there anymore and all the high flames of excitement from almost 2 years earlier: gone. There was no launch party, no celebration. Nothing. I should have personally felt happy that I eventually *DID* achieve my goal of delivering a complete game. But I didn’t. All the joy was sapped away from realization how much toll the development time took on me. Had it been fully productive 2 years I know I would feel different but the fact that I neglected to address all the problems earlier just hit me way too hard. I was more angry at myself than glad that I pushed a high-quality product to the people. And frankly – this completely destroyed all the fun of game development.

Moral of the story
So what lessons have I learned from this?
1. Address communication problems as quickly as possible. Don’t neglect it EVER.
2. If you feel that any team member starts feeling burned out – REACT.
3. Working long hours, several months in a row with no breaks is BAD for you, no matter how passionate you are about what you’re doing.
4. Don’t neglect your health and activities other than developing your game. It’s not worth it.
5. Never lose inspiration and if necessary do whatever you have to do to self-motivate if there’s nobody else to motivate you around. If you’re a coder – start painting or drawing or writing poetry. This helped me and will very likely help you too on your endeavours.
6. If you have little to no experience/skill in the area you need for your game (graphics in my case) – first try looking for people who can help. Trying to learn and doing things by yourself might be enlightening but it’s unlikely you’ll get as good results as with an expert in your team.

To sum up, developing “Hazumi” was extremely taxing and it took me a long time to recover and start enjoying games all over again. I was lucky to realize something was wrong soon enough not to completely drop interest in the project but had I reacted sooner, I would definately benefit more. I hope this post helps you in the slightest and if it already gives you some ideas how not to lose your mind doing what you love – that’s good enough for me!

Visit Hazumi homepage

Tweet about this on TwitterShare on RedditShare on LinkedInShare on FacebookShare on Google+Share on Tumblr