Over the years, and a few times recently, I’ve had people ask me what made me decide to quit my job in the AAA games industry, and start my own game-studio. Many people expect there to be one definite short term reason, but in reality there are multiple long term reasons. It all ties into what your life-experiences are, and what you want to do in your life. I guess a little history is in order.
Before I started working in the games industry I was creating PC demos. Mostly parts of demos actually, I didn’t ship that many actual products. I sure started a lot of them though! By building these little (parts of) demos, I taught myself how to program in Basic, Pascal, X86 Assembler, C and later C++. I learned about programming graphics, audio, input, file management, data compression (‘this has to fit in 64Kb!’), encryption, and many more topics. The thing I loved the most about it was the freedom to create whatever I felt like creating. Sharing what you created with like-minded people at demo-parties, exchanging ideas, it was awesome.
Then the whole 3D movement started with Castle Wolfenstein, Doom, Descent, etc. This made me start work on my own 3D engine, and soon after I teamed up with a friend who had a company and was also working on his own engine. We combined the two, and in 1997 Digital Infinity was formed. A few years later Digital Infinity merged with Orange Games and Formula Games (a division of Lost Boys Interactive), to form a company called Lost Boys Games. Suddenly we were working with around 60 people, and everything changed. We still worked in three teams roughly made up out of the original companies, but we were all working in the same building. This was awesome as well as not so awesome. Awesome because I was working with a lot of talented people whom I learned a lot from. Not so awesome because suddenly there were managers and bosses that were to be kept happy.
In early 2002 the decision was made to cancel two of the three games in development, and focus on one game instead. Unfortunately the game Knights was one of the cancelled games, and most of the team working on it was laid off. I was allowed to stay and work on the remaining project, but I decided it was time for a change. In that day there weren’t many alternatives to Lost Boys Games in the Netherlands, so searching outside the Netherlands was pretty much required, and I sent out application letters all over the world.
One of the companies I sent my application to was Relic Entertainment Inc. I was a huge Homeworld fan, so I was really excited when I got a phone interview with them. They invited me over to Vancouver, BC, Canada. They showed me around the studio, and showed me Impossible Creatures, their new endeavour in the RTS space. Then they took me to a different room in the building and showed another game they were working on: Homeworld 2. (OMGWFTBBQ!!) They were looking for a physics programmer, which happened to be my thing, and they made me an offer at the end of the interview. I walked back to the Hotel deciding what to do. Should I accept the offer? Do I take the plunge?
Well, what’s the worst that can happen? I move, somehow it doesn’t work out, what then? I had enough money for a ticket home, so I’d fly back, and find a job somewhere. Didn’t seem like that big of a problem. I got my work visa in April 2002, and I hopped on the plane and flew to Vancouver, BC, hoping for the best.
And the best it was. Relic was a fantastic company to work for. I met so many super talented people at Relic, many of which I am glad to still call good friends. I learned a lot about adopting a different code-base, different coding techniques, saw amazing producers at work, and shipped a bunch of projects. While working on Homeworld I met another coder called Jamie Cheng. We talked a bit about side projects, and he told me he was working on a game in his spare time, just for fun. A few months later Jamie quit and started his own company Klei Entertainment. I told him that I really admired his choice, and that I’d want to do something like that at some point.
About 2 years after I started at Relic, THQ bought the company. The company quickly grew from about 70 people to about 200 people, while a lot of the old-timers left. This drastically changed the culture, and I felt the mandate was no longer ‘make the best games’, but ‘make the best game within this budget and timeline, preferably with this license’. We still worked on cool games, but something did definitely change. I was the Lead Programmer on Dawn of War – Dark Crusade, and Dawn of War 2 had just staretd. Being alead meant exchanging actually creating code to leading a team of programmers to finish a game. Though in reality it always was, lately it had really started to feel like ‘work’. I missed the days where I was actually excited to go to work and get cracking on some cool piece of code. Then the phone rang. “Hey it’s Jamie. I’ve got this proposal to do N for XBox Live Arcade on my desk that I don’t have the manpower for right now. Want to start your own company?”.
Well, what’s the worst that can happen? If eveything fails, I’d just find another job in games somewhere. It was early 2007, and at that time the games industry in Vancouver was pretty much booming.I had saved up some money, and I made some money off some Lost Boys Games shares when Sony Entertainment bought them and renamed them to Guerrilla Games. I had about $30,000 in my savings account, so I could live for a bit if it all went south. Also, I should note that I didn’t have a mortgage, nor kids, so there wasn’t really a big constant cost in my life other than food and rent.
I decided to take the plunge. I had seen how to create games, how to finish them, and I was pretty confident I could manage finishing a relatively small game. Also, this might be the chance to create my own thing, work on my own projects after the starter project was done, and get back to that demo-scene feel! So in 2007 Slick Entertainment Inc was created, and I’ve been running Slick ever since, and hopefully for many more years to come.
A few of the things where my expectations of running my own company are different from reality:
- The buck stops with you. At bigger companies, there’s always somebody else who can take on a task. Not in your own small company. All those tasks that need to be done? Guess who’s doing them. This requires a certain type of discipline that I didn’t need as much at the AAA studios I worked for. I think my early days in PC Demos helped, since I was quite self-motivated to learn programming, something that comes with a lot of mundane tasks.
- Working at a AAA company is frowned upon by some indies. I think it was an amazing experience, and I wouldn’t want to miss it. I learned so many valuable lessons on how to ship games, both technically as well as organizationally, I don’t think Slick would still be around without this experience.
- Stability is a myth. When I announced that I was starting my own thing, many people said ‘Oh that is awesome! I wish I could do that. It’s too risky for me though.’. I honestly think it wasn’t that risky. I felt like everybody was saying ‘but the water is so deep!’, and I felt like ‘I can swim, so the water depth doesn’t matter!’. Strangely enough only a year later (2008) the shit hit the fan, and a lot of ‘stable’ game companies went under. A lot of people were laid off at bigger companies. Meanwhile, I was plugging away in my own company, making decent coin.
- The freedom to create anything you want is paralyzing! It is really hard to decide what to commit to if there are no limitations. Sometimes it’s really nice to have somebody tell you what to do, and you just do it. Instead, you end up making decisions all day, every day, which can be very exhausting. It’s actually a real thing in game design as well. Giving the player too many choices makes the player not want to make any decisions.
- I do miss working with many super talented people in my field. I work with really talented people right now, but none of them are hardcore programmers. I miss being able to bounce ideas off fellow programmers. Luckily I’ve built up a fairly big Skype contact list, with many technical people I can bounce ideas off. Still, there’s something cool about absorbing new ideas from coworkers simply by walking by their desk and seeing what they are working on.
Alright, I think I’ve rambled on for too long. I think I might be procrastinating this network programming I need to do.
As you probably know from previous updates, we’ve been working hard on our ‘GDC’ build. The real reason we were working so hard is because we’re in the Indie MEGABOOTH at PAX East! Check out this sweet trailer: (we’re at 0:36s)
I’m happy to say that we’re currently putting the final touches on the game demo. We’ve been working insane hours for the past few months, but we think it’s all coming together now. We’ll be showing our game on a 60″ TV, so it better run well!
The plan for next week is to fly to San Francisco first, and be at GDC for 2 days for the Independent Games Summit (my favourite part of GDC by far). Then on Wednesday we’re flying to Boston, which by then will be completely free of snow, and be just as sunny as San Francisco… yea… Anyway, we’ll be setting up our booth on the Thursday, and then Friday, Saturday and Sunday will be demoing our game to the fine people of PAX East! We are super excited!
Here’s another little boss teaser, this time from within the game, and with some nice lighting:
So come check out our booth (nr 5176) and try to beat this mean boss!
Oh, one more thing, our usual Wednesday-dev-stream will be moved to tomorrow. Jesse is off today, and Caley and I think we’re nowhere near handsome enough to be on camera.
It’s been a while since the last Tech post, so it’s about time I wrote some stuff down again. Lately I’ve been working mostly on porting the engine to PS4, as well as keeping the DirectX and OpenGL versions up to date. Not really something that is super interesting to write about!
Now with those excuses out of the way, let’s talk about lighting. I’ve been wanting to add proper lighting to our game for a while, but since it’s a 2d(-ish) game where we ‘cheat’ with the perspective quite a bit, most of the ideas I had about lighting wouldn’t really work. To illustrate what I am talking about, have a look at the scene below. The left image is the game camera perspective, the right one is the perspective from an independent 3d camera:
In the game camera (left image), the entire scene is skewed by an angle of about 30 degrees, much like an isometric view. However, it is actually a perspective view with a very low camera field of view angle, and a skew matrix applied to the world. So you still see a bit of 3d, yet it looks like a hand-drawn flat 2d game.
In the 3d camera (right image), you can see that we’re cheating quite a bit to get the look we want. The boat for example is built up out of a few flat facades, much like the buildings in a Hollywood movie set. Characters in the world are flat camera facing sprites. Also, the background is actually a big flat texture that is pretty close to the back of the boat.
When you apply conventional lighting methods to this, a few things start to go wrong. First off, most lighting methods use the surface-normal to generate proper lighting. We toyed with the idea of generating normal maps for all our textures, but when we looked at the amount of work required to create normal maps we quickly axed that idea. Yes, we looked at tools like Spritelamp, but we are just 3 guys trying to make a pretty content heavy game here! We have to pick our battles.
So I tried implementing simple omnidirectional lights that just ignore the normal of the surface entirely, but still applied a nice falloff based on the distance to the light. That actually looked quite decent! I added omni lights to our puppets and made them animatable, so we can easily add lighting effects to characters. For example, check out the Clang lighting effect (somewhat crappy gif compression, but you get the idea):
With omni’s out of the way, I started looking at directional shadows. Luckily for us, all our textures are polygonized, so the edges are actually triangle edges. If you’re wondering what I am rambling on about, check this blog post. This means generating a proper depth texture for shadow casting lights is quite trivial, and doesn’t involve any texture lookups for alpha testing at all. Now, when applying shadows to a flat world like this, you DO want to look at the surface normal. You only want to apply light to surfaces that are not-in-shadow, and facing the light. To clarify: I just determine if the light is coming from behind the pixel or in front of the pixel, and either apply all lighting or no lighting at all.
Because of our flat camera facing sprites, the only shadows that look good are shadows coming from the front or from the back of the world, so we are a little limited with how much we can do with the shadows, but it does add a cool effect to our world. Check out these examples below. You have to click them and move your mouse left/right to see the before/after:
Alright that’s it for this week, I hope it was informative. If any questions pop up, feel free to ask away in the comments, or even in the chat during our stream later today on Twitch!
Also, since it’s a Wednesday, don’t forget to tune into our devblog later today! Jesse will be streaming from 4pm-6pm PST today, and it’s always a blast to see him drawing and chatting with the viewers. It’s a good time, I promise. Come check it out. Click the image below to go straight to our twitch stream:
This week there isn’t too much to say about the actual development of the game, as we were super busy getting everything ready for the Playstation Experience in Las Vegas. We left for Vegas on December 4th, setup our stand on the Friday, and showed the game to the public on Saturday and Sunday. The show was super fun, and really well organized. We received lots of valuable feedback from players, and we met a lot of fellow indie developers. Here are some impressions from this weekend:
Jesse showing the game to Parkitect creator Garret Randell
People kicking some Snowclaw behinds off the ice raft.
A huge Jake the dog inflatable statue.
We’re in good company!
Screenshot of the game!
Group shot after a super fun show! Huge thanks to Kevin (far right) and Gordon (horizontal) from PowerUp Audio for helping us out at the booth!
Alright, that’s it for this week. We have lots of feedback to integrate into our game, so we are getting back to the grind. Till next week!
Oh, and of course, tune in to our weekly Twitch cast from 4-6pm today!
On Monday we showed our game off at the Seattle Indie Expo, and it was super fun to meet a bunch of Seattle indie developers, as well as meeting all the people checking out our game! We’ve gotten a lot of feedback, and we’re going to be incorporating all of that into our game to make it even better. Here’s a quick pic I snapped of Caley and Jesse and our setup.
Alright, now to the tech stuff. This week I put in something I’ve been wanting to put in the game for a long time: Color grading. Color grading isn’t new, and I am definitely not claiming this is something unique. However, it is very cool, and I wish more people knew about it. Every artist I show this too reacts as if their mind is blown, and every programming is like ‘yea, I knew that’. There have been many games that are using this already, like The Witness, and a lot of AAA games. There’s a great description on how to use it on Code Laboratorium, and this week I’ll try to give you my version here as well.
The basic idea of color grading is to map every possible color to another (color graded) color. In other words, you basically want to be able to call a function in the form of:
Color GetColorGradedColor(Color rawColor)
One way to map each possible color to each other color is to use a huge array. If we’re using 8 bits per color channel, that means 256 steps per color channel, so we’d need an array of 256 * 256 * 256 different mapped colors. That’s a lot of memory, and a lot of cache misses to deal with! Luckily there is an easier and faster way.
Imagine that there was a way to store all these mapped colors in a cube. the X axis could be the Red value, the Y axis the Green value, and the Z axis the Blue value. Now, if we had a color value, we could just use the RGB value as the XYZ coordinate in the cube, and get the color graded color. Now also imagine that the color grading is pretty smooth, and neighboring colors in the cube are very close together. That means we could just take a lower resolution cube, and interpolate for any colors in between.
I’ve just described the exact behaviors of a 3d-texture. For my implementation I’m using a 3d texture of 16x16x16 pixels as my color grading look-up texture (also called a LUT). I’ll get into how to create these textures later, but for now, imagine we’ve got a color grading 3d texture completely set up. What actually needs to happen to get the screen to show up completely color graded? It’s simple: Render the entire screen to a render target, then render this render target to the screen using the color grading pixelshader.
The color grading pixel shader is very simple (this is GLSL, but it should be pretty easy to convert this to HLSL):
Note that the alpha of the color isn’t used in this shader, as the screen is drawn without Alpha blending. The scale and offset parameters are there because of the way textures are interpolated. There’s a great explanation in GPU Gems about this.
Alright, so now that we’re able to combine an input texture (from your render target) and a 3d color grading look up texture into a final color graded output image, we need to start worrying about how to create these color grading textures. (This is the part that usually blows the artists mind). The basic process is this:
1) Create a screenshot of your game, and insert the color cube information to the image.
2) Load the screenshot into photoshop, aperture, paint .net, gimp, or whatever color correction application you prefer, and change the colors of the image using whatever plugin you want.
3) Save the screenshot once you’re done
4) Load the screenshot back into your tool, and extract the color cube information.
That’s it! Pretty simple, right? Here it is in pictures:
This is the interface we have in the editor for generating the color grading textures. The button ‘Generate Screenshot’ will create a screenshot of the game, attach the color cube information at the top, and save it out to disk as a png (you’ll want to use a loss-less image format, don’t use jpg!). This is the image it generated:
Notice the color grading information in the top left. To generate this screenshot, all existing color correction and bloom in the engine was turned off, so the image is as close to the raw data as you can get.
Now, I’ve loaded this image into paint.net, and changed the color, then saved it out to this image:
I didn’t change these colors to look particularly good, just enough to show a difference between the incoming and outgoing image. Next, this image is loaded back into the editor, which extracts the colors from the image, and puts them in a 3d texture to use as the color grading LUT:
That’s all there is to it! I’ve added a few extra things like being able to blend between color gradings within a level, which creates really cool mood changes when you walk into a cave or when you get into a village. Here’s a few more extreme color gradings:
Alright, that’s it, hope it was helpful. Keep color grading them games!
Welcome back, followers of the fearsome! Over the years, and a few times recently, I’ve had people ask me what made me decide to quit my job in the AAA games industry, and start my own game-studio. Many people expect there to be one definite short term reason, but in reality there are multiple long […]