Starting in game development

I recently held a presentation about my work at Frostbite at my old university. The first part was about the cool stuff I get to work on at Frostbite. In the second part of the presentation I talked more about my experience going through the interview process. Since this can be quite intimidating and stressful I wanted to give the students who would be in the same situation as me an overview of what had worked for me and what could I have done better.

Since I always prefer a written down version myself rather than just the presentation here are some thoughts on this. For each part I will talk about what worked for me and what I could have done better in hindsight.

Before applying

The most important thing when coming straight from university is to show that you have some practical experience in programming.

What I did:

  • Writing a blog is a good way to highlight your interests. It is also great to see the development of a project that way. Also your blog can be used to show your projects.
  • Hobby projects are great because it shows that you are actively work on broadening your knowledge besides what you have been doing in university. It is also very good to learn a lot. Obviously if you do it on your own it can get a bit frustrating if you are not making as much progress as you want. Because of this try not to create too large projects from the beginning.
  • University projects: This is straightforward, you are already spending time on these projects. Especially if these projects are more open ended it is a great opportunity to create something interesting. One thing which you should keep in mind is to highlight what things you have been working on. These projects are also a great way to show that you can manage to work together with other people.
  • Open source: With GitHub or bitbucket you can have unlimited repositories so use that. It becomes a lot easier to maintain these and if you make them public even better. The quality of the code is not necessarily a big issue, I personally find it more interesting to see if someone finishes projects and continues to grow.

What I could have done better:

  • Maintaining a website from the beginning I only started like a year before I finished my studies. Going through my old projects and remembering what I did became a lot harder to do.
  • Use source control This would have made it a lot easier to maintain all my projects. So start using it as early as possible.
  • Advertise myself - I am not a big fan of social media so I was never really interested in doing this. But it can definitely be very helpful to get in contact with people.
  • Focus more on practical experience In the beginning a lot of the courses in university would be a written exam which would determine your grade and then a practical exercise giving you a small bonus on the exam results. Looking back I should have focused more on the exercises. In general do as much practical work as possible.

Useful resources

When I was working on starting my online presence I was delving a bit in website development. However I was not a big fan of this and I felt this was taking time away from what I actually wanted to achieve. Thankfully Matthäus suggested to use a static website generator instead Link . I have been using nikola since then and I am pretty happy with it. I am also hosting the blog on github pages which is super easy and free.

Application

After you have made sure you have some online presence and some practical examples you now have to decide for which jobs you want to apply.

What I did:

  • Looking for specific job offerings: I already knew that I wanted to work in computer graphics and in the games industry so I focused mainly on jobs as a rendering engineer. I specifically looked for AAA game dev companies as well as game engine companies.
  • Be open for working abroad With these goals in mind I soon realized it will not really be possible to achieve them by staying in Germany. So I focused instead on the job and not on the location. As an example I was considering jobs in Sweden, England, Poland, Canada and Germany.
  • Gather information about the company When preparing my applications I found glassdoor quite useful. Especially in the games industry you might be able to see some red flags before hand. But it is also a good tool to get information how their interview process might work.
  • CV Not sure how good my CV really was. What I focused on was to emphasize my practical experience and the projects I worked on. Also don't try to fill it up with useless information.
  • Get in contact I was quite fortunate to be supervised by Matthäus from AMD during my masters thesis. Thanks to him we got in contact to Sebastien Hillaire from Frostbite which supervised the thesis as well. Already having this contact helped a lot to make the application process as painless as possible.

What I could have done better:

  • Get in contact I cannot stress enough how important this is. For most of the applications I did send out I only got automated messages back and never heard from them. This was quite discouraging and could have been prevented by getting in contact directly with the developers. So try and get in contact directly with the developers if possible. One of the best resources for this is twitter. Don't be afraid to ask questions or contact people. From my experience all the people I am now working with are always willing to help.
  • Work during your studies Obviously even better for your application is if you already have some experience working at a company. Even if you do a lot of programming on your own, being in a professional environment is far different. In hindsight I should have done this but I must admit that I was too lazy to look for a job.

Interview process

In my opinion this is the hardest part to prepare for because it is hard to know what to expect. I also did not have a lot of different interviews. This was simply because I did not get invited to a lot of them and never heard back after I did send my applications out. So make sure to get in contact with someone to make sure you get invited to interviews.

What I did:

  • Revisit theory I tend to forget quite a lot of things when I don't use them very much. So I prepared for the interviews by revisiting a lot of theory. I have added some of the books I found helpful under Additional resources.
  • Go through old projects Since I tried to highlight those as much as possible I wanted to be prepared to talk about them. I looked through them and thought about what I found challenging and what I had learned from them.
  • Research about company Obviously I already did that when I looked for companies to apply to. However for the positions I actually interviewed for I made sure to be up to date with the company.

What I could have done better:

I am not really sure what I could have improved since you usually don't get much feedback after the interviews. I guess I could have looked into identifying some of my weak points in regards to the job requirements and try to improve there.

Interview Process

This is an overview of the process I went through during my interviews.

  • First Interview this was less technical and more about the team getting to know me, what I had worked on and what I was interested in. It was also about describing what my job responsibilities would be.
  • Practical exercise After that interview I got sent a practical exercise which I had a certain time to solve and send back to them.
  • Second Interview this was an actual technical interview. It covered a very broad range of topics and it was quite difficult to go through all those context switches.
  • Onsite Interview Finally I was invited to an all day onsite interview. This was actually made up of multiple interviews with different members of the team. It also included a longer technical interview which did go more into detail than the second phone interview. In general this was to meet as much people from the team as possible so that they can get a feeling for the new person.

Additional resources

Some of the books I used while preparing for the technical interviews:

  • Cracking the coding interview is a good overview of general comupter science topics. In hindsight this did not really reflect the kind of questions I was asked but it still is a nice structured book.
  • Game Engine Architecture a great book giving you a broad overview of game dev tech and engine development.
  • Real Time Rendering also great book giving you an overview of computer graphics techniques.

Some additional links that might be useful and contain additional information:

Volumetric Particles Part 1 - Adaptive Grid

This is the first part of a series of blog posts covering the details of my master's thesis. An overview of this project can be found here. The source code is available on github.

In this post I am going to cover the data structure that is created on the CPU and used during raymarching on the GPU to calculate the volumetric effects. I am using a simple example scene for this. The subdivision of the grid can be seen in the following screenshot:

/images/volumetric-particles/GridSubdivision.png

It consists of the root node in the background, two nodes on the medium level and four nodes on the highest resolution. The subdivision factor on each level is 16. This creates a similar tree to GVDB.

Node Data

The following buffers contain the data needed on the GPU for the adaptive grid:

  • NodeInfo - image and child offsets
  • ActiveBits - bits to indicate which child nodes are active
  • NodeCount - store the number of active nodes
  • ChildIndices - index into the NodeInfo array for each child

Each node stores the 3D image offset into a 3D texture atlas which contains the actual volumetric data. This image offset is packed into a 32bit unsigned integer value. In addition to this an additional offset for mipmaps is stored. Each node also stores the start offset into the child indices array.

For the current subdivision factor of 16 it is necessary to store 16^3 bits for all possible active children based on their positions inside of the parent node. For each node 128 32bit unsigned integer values are reserved inside the active bits array to store the child information. In addition in the node count array the number bits are stored which have been set until this position in the array.

The find the index into the node info array for an active child bit counting is used. To achieve this the node indices are stored inside the child indices array. Because they are ordered based on the 1D index of the bits it is possible to find the correct position in the child indices array from the active bits.

Example

Using the same subdivision of the grid as in the example above the following data on the different levels is stored:

Node Index Grid Level Node Position 1D index Array Index Bit Index Child Offset
0 0 0,0,0 0 0 0 0
1 1 7,7,8 2167 67 23 2
2 1 8,7,8 2168 67 24 4
3 2 15,15,6 1791 55 31  
4 2 15,15,7 2047 63 31  
5 2 0,15,6 1776 55 16  
6 2 0,15,7 2032 63 16  
Child Indices 1 2 3 4 5 6

The following calculations are performed:

  • 1D index = (pos.z * resolution + pos.y) * resolution + pos.x
  • Array Index = 1D index / 32
  • Bit Index = 1D index % 32

How this data is used on the GPU to traverse the grid is described in the next blog post.

More screenshots

I added some screenshots of the volumetric rendering I am currently working on for my master thesis here .

I also added some reviews to a tool I wrote for AMD OCAT.

More information on both projects is to come after I finished writing my thesis.

Ifc to Unreal

I wrote an article about a project to import architectural Ifc data into Unreal Engine. We managed to import the complete mathematics - informatics building of our university. More information about the import process and the different issues we faced can be found here .

First project pages

I added some of my projects to the project page:

  • Interactive Visual Data Analysis: C++/DirectX tool for rendering of scientific volume data sets.
  • VR Exploration: The results of my bachelor's thesis. A framework for Oculus Rift and Leap Motion for VR movement of data sets.
  • Into Darkness: Detailed information on what I worked on during the Into Darkness project.

I also added some information on other projects. However for those I have not yet wrote a complete article. More will come later.

Into Darkness Postmortem

Introduction

Into Darkness is a top down isometric shooter game I developed with four other students in a practical course during one semester at TUM. We decided to write the whole game from scratch using C++ and DirectX. This proved to be quite a different experience than other projects I did before. I will add more information on the project page in the next time. In this post I want to give an overview of my experiences during this project.

The Positive

I really liked the setting of our game. Our vision was to create a game where the player would explore abandoned underground places and try to gather needed resources. The idea was to increase the danger in form of aliens attacking the player while going deeper underground. In the same way the player would find more resources in lower levels. We wanted that light would play an important role both as an atmospheric element and as a game mechanic to be used against the underground dwelling aliens. Overall I think that could have created a quite interesting game experience.

The best thing of the whole project was to develop the whole game from scratch. While it was a lot of work it was also a great experience and a lot of fun to see the game grow continually from nothing. For it was far more rewarding to get a feature running properly than just using a pre made game engine like Unity. Even though the progress is obviously a lot slower compared to using an engine you can really understand what is running under the hood of the game.

The Challenges

Concept Phase

While the initial concept definitely was interesting we made the mistake to not concentrate on one specific feature but had a really broad set of features we wanted to create. This especially proved a problem later in the development because we had to divide our time between them instead of focusing on one at a time. The general design was too ambitious to be achieved in the time we had.

During the course we had to create a physical prototype before starting with the development. While I can understand why one could use this to test an initial prototype it is not usable during later development in my opinion. The game play can not really transferred to the paper prototype. It would have been more useful to use an engine to create small game play prototype during the development.

Programming

Because of our design we started from the start to create systems specially for this, making assumptions how we could improve the implementations early on. This was a mistake which became apparent later in development when the requirements changed. We had to change systems completely which would not have been such a problem if we had started with a more flexible, general approach.

Something we did not do during development was code review leading to quite interesting commits from team members. Sometimes the game would not work almost at all after changes made and we had to get back to previous commits.

One problem during the development was definitely the lack of experience. Especially the interaction between the different game components was quite hard. I would have preferred to have someone with industry experience to provide some guidance during the project.

Art

A problem we had with most of our student game projects was the lack of artists. If only programmers are on your team it will definitely show in the resulting assets. For the project I did most of the modeling and texturing myself. Looking back at the results which are more like placeholders than real art I think the realistic art style was not the right decision. Some more abstract rendering would have helped to make the game look more finished in my opinion.

Team management

Because most of the initial design was my idea and I also had done some of the basic engine programming already I was really interested in getting stuff done for the game. Due to this I tried to do as much as possible myself leading to a bad task distribution overall.

Task distribution in general proved to be quite some problem. There was a difference in experience between the different team members which made it harder to get important features done on time and with the correct quality. Communication is really important to find out if a given task can be solved by the assigned team member. We also had a new team member joining us almost at the end of the project. Without much documentation it was quite hard for him to join the development.

Another aspect of team management which did not always work was team motivation. As with most other university projects some people see it more as an easy way to get credits instead of working on the game. Fortunately, most of us were motivated in the beginning. However, with the increasing complexity and more and more time constraints in the end, this became a problem. To prevent this communication again is really helpful. Not addressing problems like this right away can damage the relationship between the team members really fast.

Conclusion

By only looking of the final game I would say the project was not really successful. This has different reasons: First the presentation of the final game is not polished enough. The graphic and art style still look more like placeholders and most of the menu and HUD are also placeholders. Second, the actual gameplay is not really fun and has no really motivation for the player.

However, the overall project was a great learning experience for me. The challenges I had to face would not have been present like this if we had created the game using an existing game engine. Some of the things I would do differently next time are:

  • focus the design on one game element and test it
  • use an engine for prototyping
  • check if your game is actually fun to play
  • let others test your game
  • don't focus to early on optimizations
  • Instead implement more flexible, general systems
  • more communication between team members
  • improve task distribution and don't try to do everything yourself

Welcome

I decided to start blogging about some of the projects that I am currently working on and have been working on in the last years.

I will be focusing mostly on real time rendering and virtual reality and game development. Currently I am planning to remove the dust from some of my projects and making them presentable.