Friday, 27 June 2014

Editor Fly Mode

Hey there! Vacation time is really close now and there's so much to do before it arrives, but I still wanted to drop by and keep you posted on new editor stuff, so I'm gonna keep it short this time.

We have a fly mode for the perspective camera now! Yes, and it works nicely enough. No video today, but enjoy this animated GIF instead:



Monday, 23 June 2014

People of Frictional: Steven Redmond

Eleventh post in the series. You can read the other posts here.

Who Am I?

I'm Steve, another newcomer to the ranks of Frictional Games from the foggy British Isles. I joined around the same time as Ian give or take a few weeks and, like both Ian and Patrik, am responsible for level and gameplay scripting. 

I'm originally from London, having moved out five years ago and settled in a small village in the Midlands. I'm married and have two daughters who I have to keep out of my room for at least 8 hours a day. So essentially, as an adult about to hit 30, my days involve sitting in a corner of my bedroom on the PC playing with editors and programming languages while trying to keep the family out. Life has a funny habit of coming full circle sometimes!

But before we get on to that, here's the photo of my workspace:
Until recently I had a tiny desk!

Background


Most of my career up until the past few years has been spent as a Linux systems administrator both as a contractor and full time with ISPs. I started out using computers as a child when my dad gave me a hand-me-down VIC20. All my friends had games consoles, but I was never allowed one. Instead my dad would set me code tasks to complete which would earn me my next upgrade. I went through a C64, Amiga and then on to various low-end Intel-based PCs until I was old enough to get a job and buy my own.

My dad's friends were completely eccentric hacker-types and he'd take me to visit when I was young. I grew up around people who had hacked valve amplifiers with the cases off and custom-built motion sensors on the doors to their bedsits wired up to a very loud car alarm sitting on top of a bookshelf. There was a semi-constructed motorbike indoors on the first floor of a residential building in Willesden, with lots of computers humming away running Linux all to the sound of Pink Floyd. Hearing my dad and his friends talk about computers and electronics was like listening to some sort of alien language. I didn't understand a word of it, but I wanted to.

At secondary school I met one guy in particular who I'm still good friends with to this day – Robert. We'd copy our QBASIC games on to floppies to swap at school, learning from each other. During this time we also discovered the editors that came with Duke3D and would share levels we had made. Because of Robert, I got heavily in to adventure games and survival horror. Since I didn't have a games console, I had no access to all the games played by cool kids. I was able to run an emulator though. Robert let me borrow his Resident Evil 2 Claire disc and I got hooked. It had all the stuff that we liked in adventure games, obscure puzzles, and it also had this really interesting mix of action and survival. Robert didn't have a memory card, so he would always play these games through on one run without saving. This got us speculating about horror games where you weren't armed and had to survive using just your wits. Of course since we were young, this was just a dream. We'd have to wait for some smarter people to make that game for us.

After school I ended up going straight into work. I started out in PC repair and went through various support roles before spending about 7 years or so as a Linux Systems Administrator. However, that all came to an end when jobs ended up being cut. The timing was pretty bad: we were expecting a baby, and my fiancée and I were some distance apart - she was finishing up her work contract. I did the sensible thing, moved closer to her, and decided to start down a new path.

I started out writing a shmup using XNA, teaching myself C#. Then I got a job as a game tester at Codemasters. There I met a 3D Artist called Ben, who sold me his PC so I could play more up-to-date games. He wouldn't shut up about one game in particular - Amnesia.

I downloaded the demo and that was pretty much it. This was the game I wanted when I was back in school. It was moody and grim like other first person games I'd grown up with and it made me use my brain. I bought it and after gritting my teeth and getting through it, then went back and took a trip through the halls of Penumbra. I realised that I cared more about story in games than I'd believed. I wasn't averse to a good story in games, it's just that it really mattered how well it was presented and whether there was synergy between plot and gameplay. It was a bit of an eye-opener.

After leaving Codemasters, Ben and I decided to have a go at writing games like this. We survived for a while on contract work while trying our own thing, but none of our bigger projects came to fruition. I could handle the mechanics, but it all felt very shallow without solid design. I kept restarting projects trying to get the formula right; but eventually Ben had to move away, and I had to find full time work. So although it never went anywhere, I've still got bits and pieces of prototypes  lying around spanning Japanese folk horror, Asimov sci-fi and dark cyberpunk.

Some remnants that I found kicking around..

Then I stumbled across a job post for Frictional Games; the ideal job, but it took me a while to summon up enough courage to apply. I got stressed out a lot during the long application process and on multiple occasions as the process went on I gave up and told myself I hadn't got the job, retiring to the bathtub for a sulk. But each time I'd get out of the bath to an email telling me I'd gotten further in the application process. I guess that was to be expected when applying to an indie studio renowned for crafting suspense?
  
As I got through to the last part of the application process, things took a turn for the worse. My grandmother who I was very close to passed away. I also had a wedding very soon, so things were all over the place. I had to ask to push the interview back which was yet another worry on top as it's rather unusual to request such a thing during an application process. However as you may guess, the story has a happy ending. I woke up on August 9th ready to get married, and checked my email – I had a job offer. So that turned out to be a pretty good day.

What do I do?

 
Most of my work is at an extremely high level using the in-house editors created by Luis and AngelScript, the scripting language we've embedded. Just like Ian and Patrik, I'm responsible for setting up the events that you're going to encounter in the game and ensuring that everything in the environment is hooked up correctly. At the moment I don't do any C++ stuff, but since I'm surrounded by a lot of smart and experienced programmers, there's a lot of opportunity to learn.

Since other bloggers have already talked about the process of creating the levels and the events that make up our levels, I thought it would be fun to go a little deeper in to what it's like to actually work on an event and some of the cool features in HPL3 that facilitate this high level approach to creating the game. I sometimes play with the older Amnesia toolset in my spare time, so it's quite easy to spot where things have improved.

So let's jump right in to some of the really big differences. One of the most used tools in the scripter's arsenal is the Area. In Amnesia, you needed to place down an area with the type set to “Script” and then in order to hook up a simple player/area collision you'd end up with a section of your script file that looked a lot like this:
void OnStart()
{
     AddEntityCollideCallback("Player", "AreaOne", "CollideAreaOne", true, 1);
     AddEntityCollideCallback("Player", "AreaTwo", "CollideAreaTwo", true, 1);
}
Now with HPL3 while you can still add and remove collision callbacks and connections at runtime the process is certainly a lot tidier and easier to maintain with regards to setting these things up at the start.


 
Your old callbacks such as PlayerLookAtCallback and PlayerInteractCallback can still be found under the Basic Callbacks tab but, as you can see, a lot more has been added in HPL3. To set up a basic collision trigger to use in script, we simply have to specify the entities that we want to take into account for the collision and the function name that we want to have called in script. Keep in mind if you have a number of entities that you want to collide with this area, we support wildcards. So if you have a bunch of red cubes you want the player to throw in to a basket, the entities field would have cube_red* and then this works for all matching entities. Lastly, thanks to the handy “Copy” button, we can automatically copy and paste a skeleton method into our script:
bool CollideAreaOne(const tString &in asParent, const tString &in asChild, int alState)
{
     return true;
}
The boolean return type lets us control whether or not the callback will be removed once it has executed, just like the old callback system. The alState parameter tells us whether the player has entered or left the area - there's no need for multiple functions. Say we want all the lights to turn off when the player enters a bathroom and for the player to remark on just how creepy it was when they exit the area and then disable the callback – we can now do all this inside a single function using a combination of the return value and the state parameter.
bool CollideAreaOne(const tString &in asParent, const tString &in asChild, int alState)
{
     /////////////////////////////
     // Player enters the bathroom 
     // (When alState==1, we've entered the trigger area.)
     if (alState == 1)
     {
          Lamp_SetLit(“Bathroom_Lamps*”,false,true);
          return true; // Allow the callback to run again
     }

     /////////////////////////////
     // Player exits the bathroom and remove callback
     // (When alState==-1, we've left the trigger area.)
     else // alState will be -1
     {
          Voice_Play(“CreepyBathroom”);
          return false; // Remove the callback
     }
}
Obviously while this is one of the most basic events you can script it should hopefully demonstrate that with this new approach it's a lot easier to be able to write your scripts in the order you mostly expect events to happen without having to move around in the file too much. This, along with many other improvements that follow the KISS principle, makes HPL3 a lot easier to work with than its predecessors.
  
Another thing that's particularly useful and considerably easier to implement compared to HPL2 is the timed sequence. Perhaps you remember trying to write an intro sequence and ending up with something that looked like this? Certainly if you've ever looked at some of the existing maps you'll recognise this approach and have probably based some of your own scripts around it:
void TimerIntro(string &in asTimer)
{
     string sEvent = asTimer;
     AddLocalVarInt(sEvent, 1);
     bool bPauseAtStep = false;

     float fEventSpeed = 1.0f;
     switch(GetLocalVarInt(sEvent))
     {
          case 0:
             PlayGuiSound("scare_baby_cry.snt", 0.3f);
             fEventSpeed = 4.0f;
          break;

          case 1:
             FadeIn(5.0f)
             FadeImageTrailTo(1.25f,0.1f);
          break;

          // And many more steps to follow!
  
          default:
               bPauseAtStep = true;
          break;
     }

     if(!bPauseAtStep)
          AddTimer(sEvent, fEventSpeed, sEvent);
}
Although this worked, this was a slightly cumbersome way to work with these timed sequences at the higher level. Now, we have helpers specifically for doing this. How they actually work is a little different. We have a separate helper class which holds the current step as an int and then checks to see if the current step should be run or not. The great thing is that all the inner workings of the sequence helpers are exposed through script so it is always possible to add more functionality and reuse this across all maps.

Here's how a sequence now looks:
cSequenceStatesData mSequenceBabyCry;
void SequenceBabyCry(const tString &in asTimer)
{
     Sequence_Begin(“SequenceBabyCry”, mSequenceBabyCry);

     if (Sequence_DoStepAndWait(4.0f))
     {
          Sound_PlayGui(“scares/scare_baby_cry”, 0.3f);
     }
     else if (Sequence_DoStepAndWait(3.0f))
     {
          Effect_Fade_In(5.0f);
          Effect_ImageTrail_Start(1.25f,0.1f,10,10);
     }

     // More steps!

     Sequence_End();
}
This is much easier to work with and lets you move things around with ease without having to change as many things if you want to add something later.

Another feature which I'll praise at least once a month is definitely worth mentioning here. This is where HPL3 really shines for me compared to some other toolsets.

Often it's been the case where I'd have to stop a game in order to make a change, recompile and then get back to the point that I was at in order to test. This could get old pretty fast, especially when you were after a very specific feel that required some fine tuning.

Almost everything you will ever need is exposed through scripts with HPL3 and if it isn't, you can easily write it in script. Most of these with a few exceptions can be reloaded at runtime by simply pressing F5 to reload the level. However, HPL3 will also reload your level script on task switch if you want it to. So you can alt tab over to your scripting file to make a few changes, save the file and when you alt tab back to the game you can just test your event again. Add a debug key that resets all the conditions and you'll find yourself able to tweak values to your hearts content with minimal downtime. However if that still isn't fast enough for you, the game can be left running and can automatically reload changes in your script file - which is particularly efficient if you're running a dual monitor setup.

There's such an extensive list of new features that HPL3 has it would be impossible to list them all here, but in time I suspect all will be revealed.. In the meantime however, if this has gotten you interested in some of the scripting possibilities - you can check out a little more on HPL3 scripting here where Thomas Grip explains some of the other things you can do:


I think I've rambled long enough, so hopefully now you know a little more about me and what I do with the rest of the team. Cheers!


Friday, 13 June 2014

People of Frictional: Ian Thomas

Tenth post in the series. You can read the other posts here.

Who am I?

I’m Ian, one of the handful of Brits on the Frictional team. Like Patrik, I’m a level scripter and gameplay programmer. I’m a recent recruit - I only joined Frictional in October 2013, and have been on SOMA since then.

Like everyone else, I work from home. I live in Cardiff in South Wales in a house that was once a butcher’s shop. Kind of appropriate for Frictional, somehow. When we excavated the cavernous and partially-flooded basement, we found a door that led to nowhere. It’s that sort of house.

So here’s the obligatory workspace photo:
Yeah, I know, cluttered! Note how I’ve carefully selected the angle of my screen so that daylight glares right off it. Nice for working on dark, spooky environments, huh?

Background

I’m the old man of the company, and got into the industry by a weird set of diversions. I won’t bore you with the whole thing, but here’s a small selection of the official jobs I’ve had:
  • Run a mask and puppet-making company.
  • Worked in a cartoon studio (the one who made Superted, for the Brits!) in the days when animations were still drawn by hand on paper.
  • Worked in a nut-making factory. You know, like nuts-and-bolts. I’ve still no idea who made the bolts.
  • Headed up the team making the official Fireman Sam CD-ROM in the days when CD-ROMs were a new and exciting thing.
  • Worked in a department licensing people to dig holes in roads, and also licensing people to supervise other people digging holes in roads. Oddly enough, the number of supervisor licenses vastly outstripped the number of people actually licensed to dig, which explains the UK road system.
  • Been chief technical architect for an interactive TV company, designing and building the systems behind a series of interactive TV channels on the Sky platform, when the ‘red button’ was a new and exciting thing.
  • Been co-director of a company making educational games for young kids. We released about 40 interactive titles, a bunch of books and a board game.
  • Worked on a bunch of LEGO console and PC games as a game mechanics coder, where I got to write code for Obi-Wan and Jack Sparrow and Harry Potter and the like.
  • Worked on the port of LittleBigPlanet to the Vita, mostly doing the code behind the touch interface.
  • Worked as narrative designer and gameplay/UI coder on the port of Frozen Synapse to the Vita (which, at the time of writing, still isn’t out).
I grew up in Scotland and started out with computers pretty early on: ZX81, Sinclair QL (I was the customer!), then Amiga 500. I coded from the very first because my ZX81 wouldn’t save or load - which meant I’d type in a program, run it a few times, then turn off the computer and would never see that program again. The QL was pretty much a dead-end, but with no real games for it I had to write my own. The Amiga was an astounding machine. I still miss writing for it, and there were so many superb and iconic games on it. For reasons of Windows-hatred I stayed with that Amiga through University (Computer Science in Glasgow), desperately hoping it’d survive - and then moved on to Sun workstations in the computer labs, where I spent too much time creating and running multi-user text games.

After Uni I moved to the middle of nowhere in Wales, which kind of put paid to any aims I might have had to get into the games industry, and that’s why I made a start on that weird list above.

As you can see from those jobs it took a while to get back on track. But games were what I always wanted to do, and when I’d been running the kids’ games company for a bunch of years I finally went ‘you know what? if I don’t get in now, I’ll regret it’ and made the jump to a triple-A studio.

It wasn’t easy. First I had to convince someone in the games industry to take me on. I had years of coding in a bunch of different languages (including C++, very much still the core requirement in a AAA game coder), so I could show off the tech skills; but I also had to convince them that I knew about games and games code. Traveller’s Tales liked my work test; happily I could talk about Monkey Island and Baldur’s Gate for hours. I think they eventually gave in to shut me up.

LEGO Harry Potter. I forget which title.
LEGO Star Wars III. Anakin's acting was so much better than in the movies.
Once I’d had enough of LEGO (I know that sounds unlikely), I moved to Double Eleven in Middlesbrough and worked on the Vita when the Vita was still called some Sony codename or other; oddly enough, collaborating with a Swedish company (Tarsier). After LittleBigPlanet I did a fairly hefty narrative rewrite on Frozen Synapse for the Vita; it’ll be interesting to see what it finally turns into when it comes out.
Converting a gamepad-powered editor to a touch editor can't be hard, right? Right!?
Converting a mouse-and-menu-driven game to sticks-and-touchpad can't be hard either...
Then comes the bit I’m ashamed about. A friend saw a job at Frictional and asked me if I’d be a reference for him if he applied. Of course I said yes; and then I saw the job description. I asked him if he’d mind terribly much if I applied for it too as it looked ideal for me. He said yes, we both applied, and I got the job. I’m not sure if he’s forgiven me yet. (I don't recommend having to do a work test in the spare moments of a project crunch, by the way!)

Ah, I’ve missed something, haven’t I? Why would Double Eleven let me do a narrative rewrite on a title?
Where's My Shoggoth?
Shameless plug!
It’s pretty straightforward. The list of jobs up at the top of the page have been my day jobs. By night *puts on hat and cape* I’ve been doing things with story for about twenty years. All sorts of things. I’ve written feature film scripts - one got made into a full-length film last year, and another shoots this summer. I’ve written books, including kids' books about Cthulhu. I’ve written and designed narrative for games, and have spent many years writing and running live-action events and interactives of all sorts. So it’s nice to be able to bring some of that into the games I’m working on.

I should set the record straight, though, as some games journalists have got that wrong - I don’t do any of the writing or narrative design for SOMA (other than the usual brainstorms the whole company gets into). Mike is our writer, and Mike and Thomas deal with the overall story. I just occasionally edit people’s blogs for typos. :-) I still do narrative design & writing - just not for Frictional.

What do Iwe do?

This section could be a bit bare, because Patrik’s already given you folks a rough idea of the level scripting process for SOMA. And that’s pretty much what I do. So instead, the guys suggested I write a little bit about how we deal with working remotely.

For those who haven’t realised it, Frictional doesn’t have an office. Everyone in the company is remote. While most people are in Sweden, we now have four guys in the UK and one in Spain, and everyone works from home. Everyone also speaks English, which is really useful for me but also brings on the old colonial guilt.

We have textual Skype running constantly, split into a few chat rooms. The main one is normally full of weird links and discussions about which is the best game to be playing on Steam at the moment. I guess it takes the place of people arguing around the coffee machine in an office. Then there’s a chat room for level scripting and design; one for programming; one for art, and we set up whatever other rooms we need for whatever else is going on.

So despite us all being in different places, there’s a constant sense of presence - people are always commenting and chatting via text on Skype, asking each other questions about the game, complaining about bugs, or posting Luis’s Grunt-pinup pictures. 

Then every Friday morning we have a group audio call, where Thomas goes through any general company news and then everyone chats through what they’ve been up to that week. Luis will say he’s been fixing editor bugs in an Eeyore-kind-of-voice, because that’s what he says every week. Someone will be asked to talk, we’ll hear nothing for a while, and then that person will realise they’re on mute. Someone else’s Skype connection will drop constantly. Thomas’s young son will join the conversation with loud squealing, or end it prematurely. Jens, for reasons no-one quite understands, will be mysteriously busy during the meeting. I think he has an allergy. But it all kind of works - it gives you a good overview of what’s going on and it’s good to hear people’s voices. Although it was a weird experience meeting everyone physically for the first time at GDC this year - everyone was about ten years younger than I expected.

Outside of the regular meetings we often have brainstorming audio sessions with Thomas when about to start on new levels or when trying to work through some particularly tricky gameplay problem. (“But look, if Simon could ride a unicycle then this puzzle would be a lot easier - can’t we get Mike to write an underwater circus background into the story?”)

Moving away from Skype, we have a shared wiki where we keep the engine documentation, workflow & pipeline information, and design documentation. We use Google Docs a lot, but generally for more temporary stuff such as the feedback notes everyone in the company gives after trying out a level. All our code and assets are stored in Subversion, along with things like Mike’s scripts. We make use of Dropbox for sharing assets with contractors and freelancers.

For general project and task management we’ve recently moved to Trello, which is a very simple task-management system where you lay out things on virtual index cards - essentially a well-organised Todo list. Before that we were relying on a much more complex task tracker and a series of Google Docs; Trello has simplified that dramatically. Also it has a Pirate mode. Every productivity tool should have a Pirate mode.

We also have something called S&T - Show and Tell. Every so often we have a milestone for a level, after it's been worked on for a few weeks. At that point it should be playable, and everyone in the company spends a couple of hours together playing through it and writing their impressions into a feedback document. So everyone gets a say about whether they think the level is working on all counts - art, gameplay, sound, story, general atmosphere. We'll often have Skype discussion based on that feedback doc and throw ideas around. Then Thomas will do a pass through the comments and mark which things he considers important and which are nice-to-haves. They'll turn into Trello cards for the different people working on the level. (S&T also applies to engine and editor code - it's just that levels are easier to explain!)

This means that unlike some bigger companies, everyone here gets to comment on the direction the game is taking. It's fantastic - you're not just a cog in the machine, faithfully doing what gets handed down to you by the design department. ;-) You also get to see the whole game as it develops instead of working on isolated levels or features.

So, how is it compared to working in an office? It’s really not that different. It’s easier to tune out noise when you’re trying to concentrate on getting something done - you just ignore the ten posts about E3 reveals that have just gone past. It’s very easy to talk to someone else - easier than it was being in an office of three hundred people, really, because by the time you’d trekked down three floors to talk to the rendering team they’d all gone out to lunch. You can play your own music. You can eat garlic-flavoured snacks.

Other companies shy away from remote working, partly because they worry about people being out of the loop. I’ve been in situations in the past where I was the only remote worker and everyone else was in an office. That really sucks. But because there is no central office and none of us really have anyone else to be talking to during the working day, it feels like a nice tight-knit group here.

And that’s the other argument I hear - mostly from bosses - about remote working. “How could we trust that people were getting on with their work?” It’s pretty simple, really - it is about trust. If you don't trust your staff (whether they're in an office or not) then why did you hire them? If you know everyone is into the project, engaged in it, and wants to make a great game, then you don’t have to stand over them checking up on them all the time. 

I’ve waffled on long enough. I hope that gives you a little insight into how we keep it together. Cheers!


Friday, 30 May 2014

ParticleEditor updates

Hey! Today I'm sharing the results of the last two weeks of work on the ParticleEditor with you. I've had loads of time for additions and improvements -- I'm just gonna go over the most notable ones briefly:

  • Live update of particles: No more resetting the whole particle system to see the effect that little parameter you changed actually has!
  • Control of the update speed: Something looks weird but you can't spot what it is? Just slow the whole thing down. Works everytime.
  • Easing functions for fading values: We don't have tweakable curve controls just yet, but these work like a charm in the meantime. 
  • Helper graphs: A really nice addition so you can preview how fades are going to work. Together with easing functions, a slider and the live update, this is fun just to play around with.
Of course, a little video works way better than words for showing these off, so here it is:



Friday, 23 May 2014

People of Frictional: Aaron Clifford

Ninth post in the series. You can read the other posts here.

Who am I?

Hello! I’m Aaron Clifford, one of the artists here at Frictional Games. Right now there are four of us artists and I’m relatively new around here. I started collaborating with Frictional back in April 2012 as a contractor, making props and other smaller bits for SOMA. A few months later I was brought on to the team full-time and, as they say, the rest is history.

Since we all work remotely, I do my stuff from my home in a suburb of London, England. I was the only one representing the British in Frictional for a while, but now we have a few! You'll get to see their blog posts and learn about them soon, I’m sure.


Background

Hanging out at San Francisco pier.
Like any kid back in the 90s I had the pipe dream of one day growing up and making video games. I guess I just clung on to that dream a little longer than some of the others. Games in one form or another have always been with me; I think the first time I got my little hands on a video game must have been on the Amiga 500. I have very vivid memories of California Games, Prince of Persia and a pretty obscure game called It Came from the Desert. I was stuck with that machine and a Sega Master System (for which I only had a couple of games, including the built-in Alex the Kid) long after those became redundant until I was given £100 after my family sold our house. I blew it all on buying a Sega Megadrive/Genesis, only to have it stolen by the people working on our new house. They actually replaced the console inside the box with a couple of bricks!

Fast-forward past a few years of crying and I finally got my Megadrive (which I never let out of my sight), Playstation and eventually a PC which is when I started digging into the inner workings of games.

Inspired by old Sierra games I always wanted to make a point & click adventure. I remember scrawling countless pages of story and scribbling level plans for the game I wanted to make. I can’t really remember what it was, but it was something along the lines of a Broken Sword & Resident Evil amalgamation.

Then Half-Life and Counterstrike were released along with their mod tools and I started playing with the Hammer editor, making maps for CS which me and a few friends would play around in, stuff like “jump maps” (remember those?) and grenade dodgeball arenas. This was when I decided that, in my pipe dream of becoming a game developer, I'd take the path of a level artist. Having people run around inside my creations and enjoying themselves really gave me a lot of satisfaction.
Prometheus - A puzzle game I helped out with on level design.
So after high school I signed up for a college course that centered on computer games, digital art and media. Unfortunately it left a lot to be desired - I came away with just a few basic Photoshop and Flash skills. Undeterred and determined to make it into the industry I took it upon myself to learn the tools of the trade. I grabbed some free 3D programs like Milkshape and Blender and I started making guns, cars, space ships & crates (as is usual for a new 3D artist!) and eventually established myself in the modding community, helping out on various overly ambitious projects that eventually collapsed, but nonetheless making a lot of friends who would become professionals in the industry. A few are still good friends to this day. 
A little tower defense/RTS me and a couple friends made for iOS devices.

Like a few of us at this company I never landed a big job in a proper studio, instead I lent my skills to various projects as a freelancer, making enough money to get by. I did that for a couple of years but the unstable nature of freelancing didn’t really appeal to me. I applied to a few off-site fulltime jobs and some studios in London - due to family stuff I couldn’t really move out of London at the time - but finding a job in games around here is surprisingly tough. I struck it lucky when applying to a job posting at Frictional Games. I remember seeing the Penumbra tech demo and really digging it; Amnesia had just blown up and first-person horror was the order of the day. What Frictional was doing at the time was really quite unique and interesting to me so I was happy to see in the job description that people here work remotely which suited my situation perfectly.

I was always happiest working long-term with a team on a project we all care about. Frictional Games is really fulfilling for me in that respect, it’s like being back working on a project with friends only now I get paid and we actually release things.

What do I do?

An artist at Frictional has to wear many hats. This is something I’ve always been used to, and when friends tell me all they do is make textures all day or work on vehicles, I can never get my head around that. We generally work on whatever graphics that need creating for the project.

Every artist is usually responsible for a level each. We will pair up with a scripter and work on a level for 4-8 weeks bringing it from an empty space into a level in which the player can run around in, interact and advance the story. This doesn’t mean the work is done on the level at the end of our scheduled time on it, it just means by the time the weeks you have on it are up, there should be a decent amount of atmosphere to portray the mood of the level and you should be able to play through it from start to finish with all of the major events and activities in the design document present. At a later date I (or another artist) will come back to it to either change/rework it due to a design decision or if the design is solid, just work on the visuals more and bring it up to a better standard.

The number of tools I use has gone down a lot over the years and as software has improved. Day-to-day I use Modo for all my 3D polygon-pushing needs, Photoshop for my texture painting and HPL3’s toolset for everything game related.

Allow me to take you on a quick journey through the creation of a game asset from idea to game.

It usually starts with having a sketch kindly provided by Rasmus Gunnarsson or David Satzinger, two of our artists who are gifted in the traditional arts and visualisation. Not always, however, a lot of the time we just need to use our own imaginations and come up with designs for things on-the-fly.
Excerpt from concept art of the corpse on the table.
I usually start by making a high resolution mesh of the object. There are no limits on polygon counts here, this mesh is made up of millions and will be used to “bake” down detail to the lower-resolution in-game mesh.
Looking good there, Raznik.
Then I make the low polygon mesh. This will be the one that displays in game, so the polygon count is a factor here. The main objective is to have a silhouette that's as smooth as possible so curves don’t look choppy or faceted. Polygons have been saved by not modelling the torso or any face details, as they will be covered up by the sheet in game. Every little helps!
Poor Raznik doesn't even have a torso now.
Now I’ll “UV Map” the model, which is the process of basically unfolding the mesh into a 2D representation - like reverse-engineering a cardboard box and flattening it all out. That UV Map is then painted over in Photoshop to give it color, texture and make it look real.
In this case, as seen in our debut gameplay trailer, our Raznik is going to thrash around, so he'll need animation. He’s given a skeleton and handed over to one of our talented outsourcers for animating. Mikael Persson brought Raznik to life in the trailer.

The model is then brought into the HPL Model Editor for setup. This includes adding collision so the player can’t walk through it, adding any animations for triggering in script, attaching lights, effects or sounds - whatever's needed for the type of asset you’re creating.
Bringing Raznik back to life.
The model is now placed into the game world by using the HPL Level Editor. This is pretty much the end of the line for the artist. It is now the scripter’s responsibility to make Raznik squirm and scream in pain when the player pokes around with him. Without the scripter’s input, he would just lie there motionless and that’s not very scary at all...
Ready for his 15 seconds of fame.
The finished product as seen in our debut gameplay trailer.

I hope this was an interesting insight into who I am and what an artist does at Frictional Games. If you have any more questions, drop me a line in the comments and I’ll be happy to answer them.

Thanks for reading!


Monday, 19 May 2014

People of Frictional: Luis Rodero

Eighth post in the series. You can read the other posts here.

Who am I?

Hi! I'm Luis Rodero, and I'm the target of all nagging and the shoulder to cry on when everything goes to hell. In other words I'm the tools programmer here at Frictional. I started back in 2006 (that's a while!) as a contributor; I made a few minor additions to the HPL Engine and then not-so-minor ones (like the OpenAL implementation that was added back in the day). I was hired for full-time work in 2008, when work on Amnesia had just started.

I live in Seville, southern Spain, home of the Feria de Abril, the Serranito and the Springmmer season from Hell, which starts in April-ish and spans until late October and can easily melt a human brain if no countermeasures are taken. Since we all work remotely, I've actually tried quite a range of places to do my stuff, like every room in my previous apartment, study rooms at my former school, trains, planes... but nothing beats having a dedicated office space at home.


This here looks nicer than it usually does.


Background

As a kid, I was really into finding out how stuff worked. Generally that involved ripping things open, much to my parents' disappointment of course. I also had an unhealthy attraction to videogames, which meant I vanished into thin air a lot only to be found at the nearest arcade in town. I got my first computer in the 80s and used to play games on it for countless hours; but it also came with these 'intro to BASIC programming' books that I thought were pretty cool, although I had no idea what I was doing when trying out the examples.

Beautiful and still working after more than 25 years (pic by Museo8Bits).

For a few years I moved my focus away from programming and just played stuff on my Master System and a few years later on my Mega Drive, as I was quite a Sega fanboy (you could have killed past Luis by telling him a Sonic game had been released on a Nintendo console, go figure). But as time went on it wasn't fulfilling enough. That's when I targeted my father's PC (sorry dad). I still played a lot of stuff, but I never lost that itch for knowing how stuff worked, so that meant the PC was sent for technical support a load of times (again, sorry dad), but it also meant I learned a lot from trial and error. It wasn't until I found Alone In The Dark that I became determined to learn how a game was made. Man, that game hit me hard.

Before jumping head-first into learning how to program, I tried pretty much everything: drawing pixel art, frame by frame animation, composing music in trackers, 3D modelling... I also created a mods for Doom and Duke Nukem 3D, and, while I learned a lot and had a lot of fun, I realised that if I had a forte, it was not on the artistic side of the craft. So I started to focus on the technical side. I used to open any kind of file in a game with a text editor (and also with a hexeditor, but I didn't know that's what it was until quite a long time later), just to see how it looked. Most of the time it was illegible nonsense, but sometimes I found stuff I could read, and that's how I learned to change strings in EXE files. But this was clearly not enough, so one day I got my hands on a C programming book.

Not my best look, but the tentacles make up for that (wait, that sounded weird).

I must say I never finished a single project I started back in the day, but I got to try out a lot of stuff in the process, and even more so when I found the Allegro libraries. I read lots of books and articles on the subject, and went through lots of source code for projects by others -- that was a great source of knowledge. I managed to do a broken shmup, a base system for a point&click adventure game, and my best work at the time, a Tetris clone that was so crappy I named it "tris-Te" (some basic understanding of Spanish will help you get this one). After that, I carried on with the learning and started checking out stuff like OpenGL, and that's when I came across a little game called Fiend on the Allegro depot, created by some guy called Thomas Grip.

Back in October 2004 (nearly ten years ago), I was still working on getting my degree in CS and looking for projects to work on for hobby, and then I checked this Thomas Grip guy out again, as after playing Fiend I knew he could pull off cool stuff. Turned out he was working on another game called Unbirth. That's when I approached him on the Unbirth forums. The rest is pretty easy to figure out. I had never seriously thought of doing this for a living, and now I feel I wouldn't be able to do anything other than this.

What do I do?

My main task here is to build and maintain the tools we use for creating content for our games. This means I'm in charge of the LevelEditor, ModelEditor, ParticleEditor and MaterialEditor programs. I made these pretty much from scratch, working on top of the HPL engine. This should make everything in the editors look just like it would do in a game powered by it. Occasionally I do bits of level scripting or other kinds of programming, but this is what I do most of the time.

The way the tools evolve is tightly coupled to how the engine changes. If, for instance, a new type of object is added to the map class in the engine, it would be weird if it didn't end up being added as a placeable object type in the LevelEditor. On top of that, we have changes to improve our workflows - for example, when an operation proves to be too time-consuming we look for ways to improve the editors to make that easier.

At the time of this writing, the tools are already huge, growing even bigger every day, but I can't just add features carelessly. One of the main goals of having custom tools is to make them suit our needs as much as possible, and that also implies paying a lot of attention to the user experience.

With this in mind, adding a new feature means that it should:
  • Work properly (would be weird to fail at this one)
  • Be straightforward
  • Be as quick to use as possible (the fewer clicks the better)
  • Have as much visual feedback as possible (where this applies)
This takes time to figure out, and will most probably require a couple of iterations and some feedback from users to become a good enough addition.

And where do these new features come from? Most of the time they are user requests, since when one is working with the tools, it might become obvious that some processes feel cumbersome and could be made simpler. Other requests come up from comparisons to other editors - 'hey, UDK has that feature, can we have it?' Also, if something reasonably simple can be done to save a user from having to alt-tab out of the editor to carry out an external task, that sounds like a good feature to me.

It begins with the description of the feature: what it should do and maybe a little overview on how. Then it's time for a preliminary design, which shouldn't be excessively detailed, since chances are we are gonna run into something at the time of integrating the feature into the system that we never took into account.

Once the first design is done, a first implementation is carried out. This should be done and put out to test as quickly as possible, to find flaws or possible improvements in the first stages.

After the first approach is tested, then any issues or requests in the feedback should be fixed. It's very unlikely that a feature turns out to be perfect or even acceptable before any checking (unless we are talking about really small ones), so here's where the feature is really shaped up.

Once the issues are fixed, it should be tested again. If no bugs or weird stuff pops up after that, then the feature makes it to the toolset. And that's how we make it!

Looking fishy if you ask me.

Of course, the job doesn't come without problems. The main issue I face everyday is the fact that most of the stuff I have is based on code that's been there since we started work on Amnesia, when I had little to no idea on how things should be done. Since then, I've been working hard to migrate to a design that automates as much as possible and makes it easy to add or improve features. I'm kind of happy with what we have currently, but I know I can do way better than this.

Another issue is that we're dealing with software here. If something can break, it will break. And that will mean someone (most probably Marc) will come at me complaining about something broken. And then I'll have to stop what I'm doing at the time and move on to fixing stuff until that someone goes back to their normal happy state again.

So summing up, my workday revolves around keeping people happy (a noble cause, actually), and otherwise adding new stuff or improving the existing stuff. Hope you liked finding out more about what I do here, and see you in the next post on new tool features!


SiteMeter