IntroductionThis will be the first part in a series where we introduce all the members of Frictional Games. Apart from the obvious "getting to know the team", it will also be an insight into the daily workings of the company. What makes Frictional Games different from many other developers is that everybody works from home, rarely meet in person and very few have had any professional game making experience before joining the team. All communication is done over Skype (plus the rare phone call), and for the last few years the whole team only meets up once a year. When we tell this to people we usually get surprised reactions, and they have trouble understanding how it all can work. Hopefully this series can help answer that.
With that said, let's get this series started! First up, I will get myself out of the way.
Who am I?Hi all! My name is Thomas Grip and I am one of the two founding members of Frictional Games. For the first few years at Frictional Games I used to work from my living room, on a desk placed next to the TV.(This made me an expert in shows like Top Model, Bold and Beautiful and whatever my fiancee watched while I worked during the evenings.) Eventually we moved to a bigger apartment and I got my own office. This how my work space looks right now:
BackgroundI started out making games in 1997 (when I was 16) and my first game, called "Köttar Monstret" (yeah, I know...), was made on a
TI-83 and became kinda popular in my class. At the time I did not have a computer, and had never really used one. I did not feel I was a very technical person and even though I had chosen to study the natural sciences, my main interest was with art and I drew and painted a lot. But when I started to program on that TI-83, which was quite clunky with only 8 or so short lines visible at once, it was like a revelation to me. I had never understood that you could do this sort of thing with a computer. I was hooked, and needed to learn more. First up, I got hold of an actual PC,
this wonderful machine, and started to learn QBasic on it. With no access to the internet, my only source of information was old and worn programming books that I found at the library. I remembered that I searched hard for some book that explained how to display graphics. When QBasic did not tell me, I learned Pascal, but no graphics in there, so I went on to C, but I did not find anything there either. The best I could do was to get colored symbols from the
extended ASCII character set, but that was no fun, I wanted proper pictures!
When at school I mostly spent lectures drawing stuff like this.
Eventually, I stumbled upon a book, called Game Programming Explorer or something, in the back of a strange bookstore at the outskirts of my home town. It explained to me that I had to program these routines myself! So I learned all about the wonderful world of
Mode 13h. Soon after I bought a proper PC (120Mhz if I recall correctly) that some shady guy had advertised in the newspaper. As we got better access to internet at school I found a site called
ProgrammersHeaven.com (it looked different back in 98) and I downloaded tons of stuff on floppy disks. My most important discoveries were
Denthor's Asphyxia Tutorials and a small game called "Boboli" that came along with source code (made by
this guy). These were my main inspirations for a while - until I stumbled upon
Allegro. This was (and still is) a game development library with tons of useful functionality. No longer did I need to code all those low-level graphics, keyboard and sound routines myself! It was like magic to me. And what was more, around this library was a whole community of people making games.There were annual competitions, reviews and an online database with all games using the library. As far as I know, this was the first gathering similar to today's indie movement.
Exploring a dark basement in my first proper horror game, Fiend.
Using Allegro I created
Project 2 and continued making another similar top-down game using rendered Half-Life models. Eventually I made
Fiend, the game that set me on the course as a horror game developer. In this game I made pretty much everything myself, code, art and music. As a sidenote, it is interesting to note that I had zero expectations to make any money from this. I simply made these games, because I loved making them. Even getting player feedback was a rare thing. The very idea of selling my games was preposterous. I think this was a pretty common mindset at the time, and quite different from how it is nowadays with outlets like Steam. Making your own games feels much more like a viable career option today. Back in 2000 this was not the case at all.
In 2002 I started studying at the university (bachelor of science in software engineering) and I had also started my next project:
Unbirth. This time I wanted to make it in 3D and started the to learn some basic modelling and texturing. However, there was a big problem with finding a 3D engine. All the good ones were commercial and expensive, and the free alternatives did not feel like viable options. I think the best one was
Ogre3D, but it was lacking a lot of features back then. Luckily, I got in contact with a guy that was developing his own commercial 3D engine and I got to use it for free. I worked on the game for 2 years, but it never got completed, mainly due to various engine problems along the way. After this I swore to never use unfinished third-party software again, and try to make as much as possible by myself. All this time was not wasted though as I had learned tons about the structure and design of a game engine. Had I not used this engine for Unbirth, I doubt I could have created my own later on.
Jumping and shooting, while conserving energy, were the core aspects of Energetic.
During the development of Unbirth I got to know Jens, whom I would later found Frictional Games with, and as our university educations would end at the same time, we decided to make a thesis project together.This resulted in
Energetic, which can be seen as a the first step towards the formation of Frictional Games. It was the first project that we made from the ground up together and some of the game's engine code is still in use (the engine was actually named HPL at this point).
When university was over I did not know what to do next. I knew I wanted to make games, but I do not think I ever saw it as a proper career path and instead just thought I should do something non-game programming related. At this point Jens asked me if I wanted to do a Master's course at Gotland. The course was all done from a distance and was mainly about making a big game project. That sounded really interesting to me, so before the course even started, I began working (using Energetic's code as a base) on my own 3D engine. The idea was to make a game that continued along the same lines of Unbirth. And one thing was sure: I did not want to use a third party engine again. When the course was over, the
Penumbra Tech Demo was the result. The game did not do very well at a competition we submitted it to (
SGA), but I hoped it might be a way to get a foot inside some actual game company. However, a month or so after putting it up online, it exploded and got downloaded more than a million times over the course of the summer. Remember that all start-up game devs: bad results in a competition is not the end of the world!
Before starting Penumbra: Overture, we had some plans to do a sci-fi brawler/shooter. Here is an enemy sketch I made for that game.With this success behind us, we decided to try and start a company, and I scrapped my thoughts on joining a "proper" game developer. The technology used in the tech demo was the foundation for our first game "Penumbra Overture", with the team consisting of myself, Jens and another guy from the master's course, Anton. Having worked on the game for more than half a year, Frictional Games was officially formed January the 1st, 2007.
Working from home means you sometimes need to do multiple tasks at once...
What do I do?When Frictional Games first started I did all the C++ programming, level design, planning, about half of the map scripting (using
Angel Script), most concept art and even some level modelling. As we hired more people the amount of stuff I have to do has (thank god!) gone down a bit, and currently I mostly do design, part of the programming and most of the planning. I also act as a sort of lead artist and decide in broad terms what direction the art should take.
The thing that I spend most of my time doing these days is design work. This includes a large variety of tasks, and the most obvious is simply writing a design document for each level. When making the type of games that we do, a proper design for each level is crucial. We do not have any basic gameplay mechanics that you can simply add in a variety permutations. Every activity must be designed, programmed and often have specific art assets created for it. On top of that, every single part of the game is deeply connected with the story. Actually, when we create our games we do not really separate the gameplay and story, as both stem from the same kind of interactions. The only thing that we take care of separately is the plot, which is something that is written at a fairly early stage and describes the main happenings that the player will take part in.
So when you have a game like this, you cannot just start with a basic ideas and then flesh things out as you go along (as you might do in a shooter). Normally, we have our writer, an artist, a programmer and sometimes even our sound and music people doing assets for a level at the same time. All of these parts are crucial for the final experience and had we not had a written plan that everybody could use as a base, then nothing would work. However, the design document is not something set in stone. It just represent the first draft. As the map is being implemented things evolve and might change quite drastically. This means that the people who are working on the map, writer, programmer and artist, are all part-designers as well. Sometimes it is just not possible to implement something like the design document says, sometimes details are missing and sometimes new ideas that takes things in a entirely new direction pop up.
Example of the amazing ms-paint art I sometimes send as feedback to artists.
This leads to my biggest design related task: feedback. As all of the assets and implementations are constantly in flux it is my job that make sure that they are still coherent with the overall vision of the game. This might sometimes lead to long discussions on what the intentions are, nagging on specific details or just explanations of the bigger picture. While crucial, this sort of things is often annoying to me because it never feels like you are never accomplishing anything. You basically just pester people about changing things. But it is also a great feeling, as you got more of an outside view and can see the entire project coming together, step by step.
The programming tasks I do mostly have to do with subsystems, map scripting and AI. At the start of
SOMA (our current project), I did a lot of tech related programming, for instance terrain, undergrowth and scripting. But ever since we hired a dedicated tech programer I hardly do any of that. I still try and get my hands dirty in tech when I have time for it though, and I implemented an immediate GUI system quite recently. But mainly I just plan out what tech related things to focus on, and help out with some of the high-level design. Since I do most of the gamedesign work, I try and program the more design-sensitive or unpredictable parts when I am able to. I think that if you as a designer only ever supervise the construction of a game, there is a certain magic that gets lost. For certain parts of the gameplay, you cannot say how you want it to work until you see it in action. Therefore I feel it is very important that I build some of that stuff, like AI and certain visual effects, myself.
All planning is done in Google Docs. Here is how end of last year looked like. (Spoilerish stuff cencored!)
Finally, I also do a lot of the planning for the project. Our approach is not to micro manage or waste time on any sort of strict development method. What we do is that every week people get something they should work on and then we have special "Show And Tell"-days when the task should be done and shown to the rest of the team. How to utilize the time during the week is totally up to each and everyone. Despite having this loose attitude towards planning, there is still quite a lot of work to it. Whenever some assignment slips, it often affects the schedule of several other team members and you need to move stuff around.. It is also important to constantly plan far ahead, and make sure that project is on track. It is easy to just get focused on the "here and now" and forget about the overall progress. As early as possible we make a rough plan on when the game is to be completed, and then update that with more detailed information as we go along. This can be really depressing work, as looking a year or two into the future makes it feel like the time ahead is so short, which leads you to thinking life is too short, etc, yada, yada.
There is a bunch of other small stuff that I do, like pr, interviews and booking travel. But all that is not very interesting and I think you should have heard enough now to have a fairly good idea of what it is that I do all day!
Stay tuned for more! In two weeks it will be time for Jens, the other founder of Frictional, to talk about his past and what his job is all about.
