Dev Blog

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

Dev-Blog 111: Procedural Goodness Part 5

05/07/2014

devblog_header03

Welcome back, followers of the fearsome!

Let’s talk about some more procedural tech stuff. First off, we’re not using procedural generation to generate everything in the world. We’re using procedural generation to drastically speed up the handcrafting of levels, and as a nice side benefit, the procedurals generate a slightly different outcome each time we place a chunk of level in the game. So basically we ‘program’ the way we want a chunk to look.

Let’s start off with a screenshot of our editor, and then I’ll talk about some stuff you see in there:

Procedural

This is an example of a procedural lane for Viking Squad. The game creates multiple of these next to each other to generate a level.

On the right you can see a treeview of the procedural. The way the procedural generation works is that each node in the tree gets a list of transforms from the parent node. A transform is a matrix, which holds the position, rotation, scale, etc, for that particular point. The node can do anything it wishes to the transforms, such as add new transforms, remove a few transforms, change the transforms, etc. When it has completed with the transforms, it passes these transforms on to the child nodes. Each child node in turn can do things to modify the transforms again, etc. Some nodes can also choose to use the transform to place an object, like a mesh, sprite, image, sound, effects, etc. That’s pretty much it in a nutshell, but I’ll go through the treeview in the image above a bit more.

It all starts with two transforms from the Root. These transforms are shown as the two little red spheres on the left and right ends of the lane. In the procedural editor, these two points are movable for testing purposes, but in the game these transforms get created based on where we want the lanes to be.

Right underneath the Root node, there’s a LaneMesh node. The lane mesh basically draws the base mesh between the two transforms. If we were to just draw the lane mesh, you’d see the left image below. There’s a bit more to the lane mesh than meets the eye. I’ll get into that a bit later. First, let’s continue with the procedural stuff.

ProceduralBase ProceduralTop

Next there’s an ‘InLane’ folder node. We use these folder nodes purely for organizational purposes, they don’t do anything for the procedural generation.

Then there’s a ‘Repeat every 1 meters’ node. This node grabs the two transforms that came from the parent node (in this case the Root), an it generates multiple transforms in between these transforms, spaced 1 meter (adjustable) apart. So now we have a bunch of transforms that get passed down to the ‘Random Transform’ node.

The Random transform node alters each of the incoming transforms by offsetting, rotating, or scaling the transform by a random range. Now we’re left with the same amount of transforms, but they are all scrambled up into random positions. We’re almost getting to the point of actually placing some stuff!

Next there’s a Random (one of) node. This one is a bit special. It basically selects one of the child nodes to use each time the procedural is generated. There’s a subtlety to it though. If the Random (one of) node would select one of the nodes underneath, and pass all it’s transforms to it, it would basically mean that for each time the procedural gets generated, ONE child node would handle ALL transforms. Sometimes though, we want a different image on each transform! The Random (one of) node actually has a flag to split up the transforms into individual segments, and pass these segments to a random child each time. Now we can get a random image to placed on each incoming transform. Sweet!

Now there’s a Place Image node, which does exactly that. It places an image on each incoming transform node. It has a few parameters such as a random color multiplier, random size multipliers, etc. All in all this means that the procedural can look drastically different each time it gets generated, which is exactly what we want! The result is shown in the right image above.

Alright, now to lane meshes. If you look in the images above, you might have noticed that the perspective we used is PFU. (Pretty Fucked Up™). It’s almost isometric, but not quite. It’s using a 5 degree field of view for the camera, but it also uses a skew on the depth axis (which is the Y axis in our case), so that any lines along the X axis are perfectly horizontal. This weird perspective made drawing textures for the lane meshes quite a challenge.  The lane mesh is actually rendered as a stretched cube along the X axis. Below is an image of the lane with a default coloured texture on it:

LaneMeshOriginal

We first tried drawing the individual textures for the tops, sides, and fronts, but we could never get it to fit properly, and not look stretched or like lines were discontinued. We needed a different approach. Whenever Jesse creates concept art, the lanes look really cool, and that’s the look we were going after. However, drawing the different textures in this faux-3d space created quite a few problems. So to mitigate this, I created a little tool that generates a template texture, for Jesse to draw over. When he’s done, he can import this texture back into the editor, which grabs each piece, unskews it, crops it, and exports it as a separate texture. Here’s the texture the editor generates for Jesse to draw over top of. I’ve added text to show what each part is:

Texture

As you can see, there’s two top lane parts. This is because we want every odd lane to look different from every even lane (so there’s more distinction between lanes).

When Jesse draws over top of this, this is the result:

LaneJesse

Now this texture gets processed in the editor when he imports it, which cuts the hand-drawn texture up into separate parts to wrap over our 3d cube. Now, it’s hard to explain how this works exactly, but here’s a video that shows it all:

First, I show how the procedural generates a new version every time you move the nodes on the sides. Obviously in the game we only generate it once, and then use that for the entire game. Next, I show a normal perspective camera view, and you can see how the texture Jesse drew is wrapped over the 3d mesh. It’s kind of a weird optical illusion, but it works perfectly from the default game camera! :)

Alright, that’s it for this week, gotta get back to work. I hope I didn’t confuse you too much! :)

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

Dev-Blog 102: Water world

03/05/2014

devblog_header03

Welcome back followers of the fearsome!

GDC is coming up, so we’re working hard to get *something* running that we can show off. As we’re a viking game, most of our game will have a lot to do with the ocean and islands, so we need a decent looking ocean. It needs to be able to display many different styles of water: large ocean-like waves, smaller bay-like waves, high winds, low winds, etc. Also, it needs to look cartoony, to fit the style of the rest of the game.

I started looking into shaders for ocean rendering, and found that a lot of methods use a lot of math and large shaders to make them work. This is great, but not really something I want to spend a ton of time on a the moment. The one page that I thought had a pretty good explanation on how they did their ocean rendering is this one: http://hosukchang.com/making-ocean-1/. The interesting part of that page (besides all the cool video’s) is the image with all the circles on it. I figured this was worth a test run in a very simple shader.

So I started working on a subdivided plane, with a vertex shader to alter the position of the vertices over time. I slapped an internet test texture on it, and got to building some simple vertex shader to move the points.

start

Now, to get some wave action, we’ll need to add an offset to the position in the shader. Instead of just adding a sine wave to the Z (up), I’m also adding a sine wave to the X (sideways), with a 90 degree phase shift. Phase shift is simply adding an offset to the sine evaluation function for the X direction. So in a GLSL shader, it looks something like this:

attribute vec4 v_position;
attribute vec2 v_uv;
uniform mat4 wvp;
uniform float time;
uniform float phaseshift;
uniform float xamplitude;
uniform float zamplitude;
varying vec2 f_texCoord;
void main()
{
    vec4 pos = v_position;
    pos.x += cos(time + phaseshift) * xamplitude;
    pos.z += cos(time) * zamplitude;
    gl_Position = wvp * pos;
    f_texCoord = v_uv;
}

As you can see, there are a few variables to play with: phaseshift, xamplitude and zamplitude.  Here are some examples:

sine

The image above has a phase shift of 90 degrees (1/2 PI), so each point will traverse a nice circle. It generates big rolling ocean waves.

sine with phaseshift 

When you change the phase shift to about 125 degrees, and make the xamplitude larger than the zamplitude, you can generate waves that are a bit more like breaking waves (like the image above), with a steeper angle on one side versus the other side. You can go way crazy with this and generate something like this:

sinebreakingwave

In the image above you see one more thing. Blending between textures based on where the ‘cycle’ of the vertex is. I’m using two textures, one quiet water texture, and one frothy foamy water texture (which is also a test image from the internetz), and blend between them using another cosine to get the blend factor.

The last thing to note about these images is that the water kind of appears straight at the back, and the color fades to a different color. This is because I’m fading out the wave heights towards the back, and fade the color to the skybox color behind it.

When all is said and done, it looks like this:

And here’s the whole shader with a ton of tunables in case you’re interested. (Make sure to right-click and save!)

Alright, that’s it for this week, I’ve gotta get back to implementing cool stuff!

Nick_avatar64 Nick

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Follow us on Google: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk

Like us on facebook: https://www.facebook.com/SlickEntertainmentInc

Posted by: Under: Tech,Vikingsquad Comments: 4

Dev-Blog 101: Shellrazer Bugzkrieg 101!

02/26/2014

devblog_header01

Welcome back, followers of the fearsome!

Tomorrow we’re shipping the new update for Shellrazer called Bugzkrieg!

BugzKrieg_Poster02_small

Tons of pesky bugs are taking control of an entire island, so it’s up to you so raze it and free the crashed alien Bloop. We made a cool little video, here it is:

Besides adding  a whole new island to play, we’ve also added localization for 9 languages: French, Italian, German, Spanish, Portuguese, Simplified Chinese, Japanese, Korean and Russian.

The free update will come out tomorrow on Android and iOS. You can get this awesome new update to Shellrazer by clicking either button below:

Get it on Google Play

Please, tell your friends about our update, it’s a big help to us!  

Nick_avatar64 - Nick

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste Caley: @caleycharchuk SlickEntertainment: @SlickEntInc

Follow us on Google: Nick: +NickWaanders Jesse: +JesseTurner Caley: +CaleyCharchuk

Like us on facebook: https://www.facebook.com/SlickEntertainmentInc

 

 

Posted by: Under: Shellrazer,ShellRazer Dev-blog Comments: Comments Off

Dev-Blog 96: Steam Dev Days

01/22/2014

devblog_header03

Welcome back, followers of the fearsome!

This week isn’t really a Waanderful -tech post, though it is about things I’ll need to change in the engine to prepare for future developments. I spent last week at the Steam Dev Days, a fantastic event organized by Valve Software. Talks ranged from how to port your engine to Linux (and SteamOS, which is based on Linux), how to make the best use of Steam features like community sharing and the workshop, as well as what Valve sees as a big thing in future: Virtual Reality. I’ve always been a big fan of VR, so I can’t wait for this to become reality. I wasn’t one of the lucky people to try out their VR system, but supposedly it’s really, really good. 

screenshot46

So what did I learn? Well, actually that my engine isn’t in that bad of a shape to be ported to Linux! Since I’ve got it running on PC and Mac already, and I’m already using OpenGL, a lot of issues are already resolved. There are a few things I want to work on though:

1) I need to learn Linux! I’ve been putting it off for long enough. I’ve installed Ubuntu using Parallels on my Macbook, and I’m playing around with it. I’m having trouble updating Ubuntu to the latest version, but this may  be because of Parallels, it seems have a few quirks. I’ll have to play with it some more. I did manage to install QTCreator, which seemed like a nice way to debug on Linux. 

2) I’m using a homebuilt project/solution creator tool that has proven very useful to port our games to different platforms, but I am getting a bit fed up with maintaining it, especially with new versions of XCode and Visual Studio coming out regularly. I’m thinking of switching from my python based system to CMake, and I’m currently investigating how to convert my current setup to CMake with the least amount of changes. It doesn’t seem that hard, but it’s all about knowing the vocabulary (which I don’t). Unfortunately I haven’t been able to find any clear examples online about how to convert say a Visual Studio solution with multiple libraries to a CMake setup, so if anybody has suggestions, please let me know in the comments! I’ve found snippets here and there, but nothing too in-depth. Maybe I should blog about the conversion process myself, so others have a bit of a guide to follow.

3) I should switch the engine to SDL2. My engine has shipped games on XBox360, iOS and Android, but it has never actually shipped on Windows, MacOSX or Linux. I’ve created code to manage application windows, threads, timers, etc, on most platforms, but I’m a bit weary about adding and supporting Linux myself. On top of that, joystick support tends to be a pain in the ass on OSX, and SDL2 seems to have support for it built in. There are a few things I’ve found out so far that I don’t quite like in SDL2, such as no retina support on the Mac. Hopefully this will be added soon. But, I’m hopeful, and I will probably try to get this implemented as soon as the Shellrazer expansion ships (SOON!), and I can rip up the entire engine to my hearts content. :)

4) VR is awesome. I really need to make some time to experiment with this. 

There are a lot more things I want to fix, but these are the main and most urgent ones. 

Alright, that’s it for this week. Keep those turtle cannons blazing!

- Nick

Follow us on twitter: Nick: @nickwaanders, Jesse: @jouste, Caley: @caleycharchuk, SlickEntertainment: @slickentinc

Follow us on Google+: Nick: +NickWaanders, Jesse: +JesseTurner, Caley: +CaleyCharchuk

Like us on Facebook: https://www.facebook.com/SlickEntertainmentInc

Posted by: Under: Tech Comments: 2

Latest News

July 26 2012

VANCOUVER, British Columbia – July 26, 2012 – Independent development studio Slick Entertainment is proud to announce Shellrazer for iPad, iPod Touch, and iPhone, released on the App Store today for a temporary launch sale of $0.99 (regular $2.99). RIDE YOUR GIANT WAR TURTLE TO VICTORY OVER THE NASTY GOBLINS!! You are a Klang Clan […]

Dev Blog

July 16 2014

Welcome back followers of the fearsome! This week we’ll be diving a little into the story we are building for Viking Squad! We were interested in the idea of an evil viking Jarl that has our hero’s village in a dark grip of greed and gloom. The spooky Jarl sends the vikings out to raid and […]