This week it’s time for another tech-post. However, it won’t be about a shiny new rendering technique. Instead it’s about an equally important part of the process of creating a game: the build machine. In my IGS/GDC talks about developing N+ and Scrap Metal I’ve stressed how good it is to have a build machine that can reliably and repeatedly build your game from scratch and package it all up into the exact package you need. There are many different packages you can use to setup your build-machine, but most of the ones I (admittedly briefly) tried were either too complex for my needs or couldn’t do exactly what I wanted. So I built my own! :)
The Slick build system is written entirely in C#, and in essence is just a way to run tasks on a remote machine. So it can build the game, but it can also do non-build tasks such as running tests or re-sizing textures. The system is broken up in to three main parts that communicate through a TCP/IP connection. The three main parts are the Master-Server, the Drone, and the Client. Each of these has a different role, which I will talk about below. First, a rough overview of the build system:
The Master Server
This is the program running on the main build computer. In our case this main build computer is a spare computer we had, running Windows 8.1. It has a few shared directories setup where it puts the completed builds, so that anybody in our work network can access the completed builds. All the master server does is wait for drones and clients to connect, and answer to their needs. It is the center point of the build system. Here’s a screenshot of the master-server program:
On the left you can see the currently connected drones, and because one is selected, it will show the tasks it can do, and the queue of tasks. The queue also shows tasks that were completed in the past, including if they failed or succeeded.
This is the actual program that performs tasks. There can be multiple drones with different sets of tasks they can perform, all connected to the same master server. The drone is a console application, so it’ll look like this when it’s running:
The tasks each drone can do are defined in an XML file. Below is an example of an XML file that can be used by our windows based drone to build the game in rtm (release to manufacture) mode, and it will send emails when builds succeed or fail:
If you look closely at the XML, you’ll see that this build scrip first calls SVN to clean-up and update two directories (one for data, one for code). Then it calls ‘BuildGame.exe’, which is a separate app I created that actually creates the builds, copies the files to the correct directory, creates a versions.txt file, etc. Come to think of it, this is the actual build-machine, really. When it’s done it copies the completed build into the shared directory on the build server. The drone is written as a console app in C#, and runs on windows as well on OSX (using Mono).
The Client is the interface that allows anybody to request builds. It looks like this:
When the client is started, it connects to the master server to request the list of drones. This list of drones is shown in the list view on the left. After you select a drone, the tasks that drone can perform are listed in the ‘Possible Tasks’ list, and the Queue is shown below. To request a Windows RTM build, you simply select ‘Build Windows RTM’ and click ‘Enqueue Task’. The Queue will then show the date and time the request was made, and have the status set to ‘Pending’. Once the build is complete, the Status will change to either Success or Failed, and the information can be viewed on why it might have failed.
So that’s it! We use this build machine for our regular build tasks, such as creating builds for PC and PS4, uploading new builds to Steam, and even to run our automated texture resize task, which resizes textures based on how big they appear on screen in the game (which saves TONS of memory).
Alright, that’s it for this week. Keep those build-machines building!
Viking Squad is a brawler, and what fun is a brawler if you can’t break stuff? When you break an object in Viking Squad, we used to just play an animation. The canned, always-the-same, animation is something your brain picks up very quickly, and things start to look very boring very quickly. There’s something about proper physical movement that catches your eye, and it never gets boring (in my opinion anyway).
This week I’ll be talking about visual polish, and how we implemented Box2D physics for visual polish in a somewhat 3d game. Somewhat 3d you say? Well, as mentioned in previous posts, the game is actually rendered using 3d geometry with flat puppets facing the camera, much like a flip-up book. Because of this flip-up book feel, I decided a full 3d physics engine would be overkill, and it would probably look weird, because flat front facing sprites moving in 3d don’t really feel ‘right’. The solution is to divide the physics up into the 4 game-play lanes. Below is an image that shows the physics objects created for the lanes (the big green boxes), and if you look closely, you can count 4 lanes. There are a few rocks flying around on the front lane.
Instead of spawning 4 separate physics worlds, I actually just spawn one Box2d world and use the collision bits masks to make sure the separate lanes don’t collide with each other.
During Shellrazer, I created a physics editor that allows you to define rigid bodies, joints, etc, and allows you to override specific bones inside a puppet. I moved this editor over into our viking squad editor, and in the screenshot below you can see how the boulder is set up. It has a puppet, and three rigidbodies. Then it has 3 puppet node links (which link the bones inside the puppet to the position and rotation of the rigid bodies).
Also shown is a push actuator. The push actuator is an animatable element that pushes rigidbodies away, and with the right amount of force you can make it look like the boulder explodes:
In game, it looks like the animation below. Note that the parts of the two boulders in the top lane collide with each other, while parts of the boulder on the bottom lane only collide with the bottom lane, even though this is all done as a single Box2d world.
Now it feels quite satisfying to break stuff in our game, which I guess was the whole point of this addition! :)
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 started. Being a lead 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 everything 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:
Welcome back followers of the fearsome! This week it’s time for another tech-post. However, it won’t be about a shiny new rendering technique. Instead it’s about an equally important part of the process of creating a game: the build machine. In my IGS/GDC talks about developing N+ and Scrap Metal I’ve stressed how good it […]