Dev Blog

Dev-Blog 177: Taking out the trash!



Welcome back, followers of the fearsome!

This week it’s time for a rather mundane task: taking out the trash. Every project I’ve worked on seems to collect a lot of assets that were used in a test or generally assets that are just no longer actually used in the game. In most of those cases, it was actually rather difficult to figure out what is being used, and what isn’t. Often I’d delete an asset, and then two weeks later suddenly somebody notices that it is missing in an obscure part of the game.


I started thinking about how to fix this. Luckily the Slick file system uses a standard way to reference files: Every file is stored relative to a data root. For example, if a texture is located in C:\Games\VikingSquad\Data\Textures\MyTexture.png, the game code and data will always reference it as DATA:Textures\MyTexture.png. The conversion of a full path to an aliased path is done in the editor, and it guarantees that all data files are properly referencing other data files.

So, I figured, I should be able to create a quick C# tool that scans every data and source file for this DATA: tag, and stores the links. It should therefore be able to see whether a file is referenced or not, and as an added bonus it should be able to see which resource is referencing another resource.

The code simply recursively scans all directories and files (excluding specific files and directories, such as PSD files, or svn directories), and for each file it scans the binary file data for the string “DATA:”. When it finds the string, it tries to read the rest of the null-terminated string to determine which file it’s referencing, and stores this reference in memory. The tool scans the entire data directory, and it also scans the entire source code directory, so that any hard-coded references are found as well. Very handy!

Well, I coded it up, and it works really great! The scanning process takes about 10 to 15 seconds to complete, but it scans every single source and data file we have (about 7000 files). The final result isn’t very pretty to look at, but it does give lots of useful information. Click on the screenshot below to see what I mean:


In this case, I’ve selected a background file called DEBUG_NICK. It has 1 parent (meaning, one other resource is using this file), and 6 children. At the bottom you can see which resource is the parent (in this case Debug_Nick.destination), and which are the resources used by this background (in this case a few png’s, a few puppets, and a lighting setup).

To find out which resources are no longer used, you can simply sort by the NrParents column, and go through all of the resources that have 0 parents. If you found a texture that looks like it’s a test texture, you can find it in easily by typing the name in the text-box at the very top, and the list will filter based on the typed name. Then you can see who is still referencing is, and fix the problem. When you’ve determined an asset can be removed, you can delete the asset right from this tool, which will call the proper SVN delete command.

In conclusion, it still takes a bit of manual labour to go through the assets and determine if they are used or not, but it’s a hell of a lot better than guessing whether it can be deleted. We can now delete with confidence.

Alright, that’s it for this week. Keep throwing out the trash!

Also, remember: As always we’ll be Dev-Streaming today at 4pm-6pm PST. We’ll be working on the game and talking to our followers and answering any questions that come up to the best of our ability! It’s been a lot of fun and really rewarding doing the dev-stream so come on down and say hey!



Twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Google+: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk



Posted by: Under: Slick Entertainment,Tech,Vikingsquad Comments: 1

Dev-Blog 176: Blurry vision



Welcome back followers of the fearsome!

This week a bit more tech stuff. When we were play testing our game, we had a problem with the screen being too busy/attention grabbing at times. It was hard to see what to focus on, as your eyes would get drawn to parts of the screen that didn’t necessarily matter to the game play. A trick we used in Shellrazer was to use a blurred background to make the foreground elements stand out more. So I decided to add it to Viking Squad to see how it looks.

The process is fairly easy. We mark the elements in the world as ‘foreground’, ‘background’, or ‘normal’. Now that the elements are marked, we use a number of steps to get the blurred effect we want:

Step 1: Background pass. All background elements are rendered to a render target, and the render target is blurred. The render target is 2/3rd the size of the full frame. The reason it’s smaller is to save video memory, and once the image gets blurred you can’t really tell it’s at a lower resolution anymore.

Step 2: Foreground pass. All the foreground elements are rendered to a render target that is half the size of the full frame. Note that the render target is cleared with RGBA 0x00000000, so that the alpha information stays correct for later. The render target is then blurred.

Step 3: Normal pass. (This pass us using MSAA) In the normal pass, first the background pass texture is rendered as a full screen quad (zwrite off). Then the entire scene is rendered on top of this. After the entire scene is done rendering, the foreground pass texture is rendered over top as a full screen quad using alpha blending.

After these steps, the rest of the post processing steps are performed, like Color Grading, bloom, etc.

The result is subtle in a static image, but when moving around it’s a lot better than before! Mouse-over the images below to see the before and after (click to go fullscreen)



A small addition, but the combination of all these little bits will make the game more and more pretty. Hopefully. :)

Alright, that’s it for this week. Until next time! And don’t forget our dev-stream later today!


Twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Google+: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk



Posted by: Under: Slick Entertainment,Tech,Vikingsquad Comments: 0

Dev-Blog 173: Build O Matic


devblog_header03Welcome 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 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.

The Drone

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:

  <MASTERSERVER HOSTNAME="build_o_matic" PORT="25000" RETRYPERIOD="10">
    <TASK NAME = "Build Windows RTM">
        <ACTION COMMAND="svn" ARGUMENTS="cleanup ..\..\..\..\" TIMEOUT="-1" CONTINUEONERROR="false"> </ACTION>
        <ACTION COMMAND="svn" ARGUMENTS="cleanup ..\..\..\..\..\VikingSquad" TIMEOUT="-1" CONTINUEONERROR="false"> </ACTION>
        <ACTION COMMAND="svn" ARGUMENTS="update ..\..\..\..\" TIMEOUT="-1" CONTINUEONERROR="false"> </ACTION>
        <ACTION COMMAND="svn" ARGUMENTS="update ..\..\..\..\..\VikingSquad" TIMEOUT="-1" CONTINUEONERROR="false"> </ACTION>
        <ACTION COMMAND="..\..\BuildGame\BuildGame.exe" ARGUMENTS="-windows -rtm" TIMEOUT="-1" CONTINUEONERROR="false"> </ACTION>

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

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!

Oh, almost forgot! As per usual we will be Dev-Streaming today! It’s always a great time running into you guys while we work on Viking Squad. Hope to see you there at 4pm-6pm PST!


Twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Google+: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk




Posted by: Under: Slick Entertainment Comments: Comments Off on Dev-Blog 173: Build O Matic

Dev-Blog 160: Physics for polish!



Welcome back, followers of the fearsome!

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! :)

As per usual we will be Dev-Streaming today! It’s always a great time running into you guys while we work on Viking Squad. Hope to see you there at 4pm-6pm PST!



Alright, that’s it for this week. Hope you liked the little peek into our kitchen. Until next time!


Twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Google+: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk



Posted by: Under: Tech,Vikingsquad Comments: Comments Off on Dev-Blog 160: Physics for polish!

Dev-Blog 155: Taking the plunge



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 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.

The buck stops right here!


Twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Google+: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk




Posted by: Under: Slick Entertainment Comments: 1

Follow us!

titlebutton_twitter titlebutton_facebook titlebutton_youtube titlebutton_twitch

Join our mailing list!

/ /

Dev Blog

July 01 2015

Welcome back followers of the fearsome! This week we are out of the office celebrating Canada Day! Hope your guys’ week has been awesome and we’ll be catching you guys up with us next week on all that’s been happening here at Slick!  In honor of our non-offensive country we have drawn it a viking […]