Dev Blog

Dev-Blog 146: Light ‘em up!

01/21/2015

devblog_header03

Welcome back followers of the fearsome!

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:

StartGameCamera StartPerspective

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

Clang

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:

LightingClickMeAlright 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:

VS_silhouette44

Nick_avatar64-Nick

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

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

Facebook: https://www.facebook.com/SlickEntertainmentInc

Twitch: http://www.twitch.tv/slickentertainmentinc

Posted by: Under: Tech Comments: 1

Dev-Blog 142: Playstation Experience in Las Vegas!

12/10/2014

devblog_header08

Welcome back, followers of the fearsome!

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:

DSC_1671

Jesse showing the game to Parkitect creator Garret Randell

DSC_1678

People kicking some Snowclaw behinds off the ice raft.

DSC_1679

A huge Jake the dog inflatable statue.

IMG_2009

We’re in good company!

IMG_2011

Screenshot of the game!

IMG_3319

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!

VS_silhouette47

 

Nick_avatar64 -Nick

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

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

Facebook: https://www.facebook.com/SlickEntertainmentInc

Twitch: http://www.twitch.tv/slickentertainmentinc

Posted by: Under: Slick Entertainment Comments: 1

Dev-Blog 128: Color Grading: Another cool rendering trick

09/03/2014

devblog_header03

Welcome back, followers of the fearsome!

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.

photo

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

uniform sampler2D TextureMap;
uniform sampler3D ColorGradingLUT;
varying vec2 f_texCoord;
const float lutSize = 16.0;
const vec3 scale = vec3((lutSize - 1.0) / lutSize);
const vec3 offset = vec3(1.0 / (2.0 * lutSize));
void main()
{
 vec4 rawColor = texture2D(TextureMap, f_texCoord);
 gl_FragColor = texture3D(ColorGradingLUT, scale * rawColor.xyz + offset);
}

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:

editor

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:

color grading test

 

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:

color grading test after

 

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:

editor after

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:

color grading collage

Alright, that’s it, hope it was helpful. Keep color grading them games!

Nick_avatar64-Nick

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

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

Facebook: https://www.facebook.com/SlickEntertainmentInc

Posted by: Under: Tech,Vikingsquad Comments: 4

Dev-Blog 122: Those textures need some polygonizin’, son.

07/23/2014

devblog_header03

Welcome back followers of the fearsome!

You may remember a blog-post I did a long time ago about the texture polygons we created for Shellrazer. If not, here it is. The system we used at the time required hand-editing of each texture, and this quickly becomes WAY too much work. Especially at the rate Jesse is able to crank out art for Viking Squad!

Now, Viking Squad is not meant for mobile devices, but we’re still generating texture polygons. The difference is that we’re only using full opaque texture polygons for viking squad, and we have removed all alpha blended triangles from most triangles that get rendered. This is mostly as a preparation for proper shadows and lighting (which I haven’t implemented yet). Also, by enabling full screen anti-aliasing, the edges of our models are really nice and crisp, especially on a 1080p TV.

The whole process of generating the texture polygons is also fully automated now. The basic algorithm is fairly simple, I first trace the outline of the mesh by checking the alpha of each 2×2 pixel block. I add edges for each edge, and connect them all together. After this step, the mesh would basically look like this:

swordnosimplification

 

That’s a LOT of points! As a clarification, on the right is the image with blue circles representing the vertices, and a green triangles representing fully opaque triangles. On the left is the resulting mesh rendered. As you can see the edges get a bit blocky with this many points, something we’re trying to avoid.

The next step is to simplify the edge, while trying to retain the shape of the outline we just created. This is done by a basic edge-collapse algorithm that calculates the ‘cost’ of collapsing each edge by looking at how much it would alter the original outline. Each turn, every potential edge collapse is given a score based on how much it alters the original outline, and then the one with the lowest score is collapsed. Then another turn is started. This continues until the cost of a collapse is above a given threshold value. The end result looks something like this:

sword

As you can see here, the steppy-blocky edges are pretty much all gone, and they have been smoothed out into nice sharp looking edges.

The triangulation of the outline is the last step in the process. I use OpenTK in our editor (a C# OpenGL, OpenAL and OpenCL implementation), and luckily that has access to the GLUTess functions, which create a tessellation of a given outline. This works pretty well!

There’s another example, this time a tree:

tree

As you see, we’re generating quite a few triangles for each object, and in a whole scene this turns into quite a lot of triangles, but they are all nice and crisp and all ready for some awesome lighting (which again, I still need to implement). Check out this wireframe/solid slide able image to see how many triangles we’re putting on screen: (The second image might take a while to load, just give it some time. It’s mostly because I can’t even HTML)

slider

(Btw, the very cool slider thing we used in the ‘Click me’ image above is from here)

Alright, that’s it for this week. Until next time, and keep those triangles wireframing.

Nick_avatar64-Nick

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

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

Facebook: https://www.facebook.com/SlickEntertainmentInc

 

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

Dev Blog 117: A tour of the Editor

06/18/2014

devblog_header03

Welcome back followers of the fearsome!

Alright, this week we’ll give you a closer look into how we are developing Viking Squad. We develop the entire game in C# using .Net 4.0, and later port the game code to C++. The game is pretty much entirely developed in an editor that I’ve been changing and optimizing since N+. The only part that isn’t inside the main editor is the UI editor. The UI editor is a separate editor for UI-screens. Come to think of it, I should actually integrate the UI editor into this main editor as well… hmmm. Ok, first finish this blog.

I’ve created a base editor that I extend to fit the current game we’re developing. Here’s a screenshot:

Editor

So as you can see, there’s a big main window on the left showing whatever we’re currently editing, and on the right is the tools pane. The main windows is basically just an OpenGL viewport that runs our proprietary engine to render whatever we need to render. We use OpenTK to get OpenGL rendering in the main view-port with C#. It used to require XNA, but when Microsoft announced they would abandon it we decided to switch to OpenGL. This switch actually helped us port Scrap Metal and Shellrazer to mobile devices at the same time!

There are 14 tabs at the top of the tools pane. Activating a tab puts the editor in the proper ‘mode’ for that tab. So when you’re editing the general settings, it will just show a list of settings. If you’re editing a puppet, the main view will change to show only the selected puppet, and provide a UI for easy editing of the puppet. Here’s a list of tabs:

1 global settings Global Settings: This is a tab that just holds a big list of global settings, with things like the Camera settings, physics engine settings, etc.

2 destination Destination: A destination is one ‘level’ in our game. It consists of multiple chunks that are randomly put together. In this tab you can select which chunks are eligible to be randomly selected in the destination, which order they should be in, etc. You are also able to set some settings for the destination, such as which music to play, which background to use, and which puppet the destination should use in the world map view.

3 chunk Chunk: A chunk is a small piece of level. In this tool pane you can edit the layout of the chunk by painting lanes onto a grid:

Chunk Editor

You can also place entities and triggers. Entities are basically anything walking around or sitting on top of the lanes. Triggers can be used to create waves on enemies coming at you.

Chunk Editor Entities

4 lane Lane: In the lane editor you can define which different types of lanes there are, and what the settings are for each of these lane types. You can also select a procedural to represent the lane.

5 procedural Procedural: Procedurals are procedurally generated meshes, which we use for the lanes, backgrounds, and anything else that needs to be generated differently every time. I’ve blogged about this before here. This is where you can do stuff like this:

6 background Background: This is where we edit different backgrounds for  our destinations. This is also where you define the water/waves settings.

7 entity Entity: This is where we setup individual entities, adjust their behaviour, select which puppet they use to render, etc.

8 items Item: In our game, items are objects that can be equipped on an entity. The object can alter the current skin used by the entity, as well as alter the entity stats, such as health, stamina, etc.

9 dojo Dojo: This is where we can test our combat in an easy setting. Caley blogged about tuning the fighting before, and he basically uses the dojo to do this. When in the dojo, the joystick can be used to control your character, while the tools pane can be used to spawn any type of enemy.

10 worldmap WorldMap: This is where we edit our world map. We haven’t blogged about this much, but it is basically where you row your boat around to different islands. More on this in future dev-blogs!

11 play Play: This is the magic button. This button starts the game with a full UI flow. It is basically playing the game as an actual game, rather than just a bunch of separate setups in the editor. We’re able to play local multi-player games in here, and we’re working on getting multi-player over internet working as well.

12 puppet Puppet Editor: This is an editor I’ve built to be able to create and animate skeletal sprites (which we call puppets). You can also attach sounds, visual effects, and camera shakes to specific points in the animation. Another cool feature I added is the ability to set certain bones to be physics controlled. Even though it’s very simple Verlet style physics, it still gives a neat effect when things move in a physical way.

13 visfx Visual Effects Editor: This is where visual effects can be created and modified. I should probably do a post about how our visual effects system works one day. I think it’s pretty neat, and there are an enormous amount of possibilities with it.

14 textures Texture Editor: This is an editor I added for Viking Squad. All our textures are converted to a set of opaque polygons. We do this to get crisper edges, and it also gives us the ability to do proper shadows and lighting, which I haven’t implemented yet. Once I do it will be cool though! :)

 

Alright, I think it’s time to end the tour. If there is anything you’d like to hear more about, please leave us some comments!

Till next time,

Nick_avatar64-Nick

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

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

Facebook: https://www.facebook.com/SlickEntertainmentInc

Posted by: Under: Tech Comments: Comments Off

Follow us!

titlebutton_twitter titlebutton_facebook titlebutton_youtube titlebutton_twitch

Join our mailing list!

/ /

Dev Blog

January 28 2015

Welcome back followers of the fearsome! Recently we’ve been streaming a lot and it’s been a ton of fun interacting with everyone on the Twitch channel. People have asked questions about how I approach artwork more and more so I thought we’d do a refresher on how we tackle art here at Slick! Tech used: […]