DirectX 12 Programming #4: Resources and Resource Binding


Welcome back to the DirectX 12 Programming tutorial series! The previous tutorials was all about getting you up and running with the default DirectX 12 application, understanding the PSO and the Command Lists. We still have some basics to cover before we can move on to the really fun stuff. 

Today we will take a closer look at Resources and Buffers. Most of the common tasks you want to do with DirectX 12 involves the use of resources. This can be models, textures, data and so on. These resources needs to be loaded and bound to the graphics pipeline to use them.

Resource Binding
To use any of these resources, you need to link it to the graphics pipeline. This is called Resource Binding. In DirectX 12, resources are bound by using Descriptors, Descriptor Tables and the Descriptor Heap.

There will be a lot of new terms today, so let’s just dive right in. The first term you will need to know is resource. As mentioned above, a resource is simply any kind of resources your application will use to display what you want. This can be textures, models (vertex data) etc. All resources are derived from ID3D12Resource.

Ultimately, a resource is simply a memory buffer. The difference is only how you operate with it and how GPU sees it.

In our example, we have a few resources identified by ID3D12Resource; our Vertex Buffer, Index Buffer and Constant Buffer. As you know, shader resources are bound directly to the PSO.

Our vertex data could have been loaded from a file exported from Blender, Maya, 3D Studio Max and any other modeling software, procedurally generated or like in our example, a hardcoded list of vertices:


Once we have the data, we need to create a committed resources. A committed resource is created by calling the function CreateCommittedResource(..) on the Direct3D Device. This function will initiate and create the resource object itself, and a heap big enough to contain all of the data. We create the resource using the default heap type using none of the heap flags, we set the size of the resource so it can contain all of our vertices, set the state to COPY_DEST as this will be a destination for the vertex buffer, and the pointer to the memory where our resource will be, the ID3D12Resource object.


Once we got this, we are ready to copy the resource data to it.


The function UpdateSubresourcers(…) updates our buffer with a given set of data. You can read more on Subresources here if you are unfamiliar with it.

The Constant Buffer resource is also created using the CreateCommittedResource.image

DirectX 12 can map the resource without locking it, so GPU operates with the current version while your code on CPU updates the resource data. Once you call Unmap on a resource, DirectX updates the actual resource on GPU.

A descriptor is simply an object that describes a resource stored somewhere in the memory (like the one we created above), and it’s used to describe this resource to the GPU.

Think of them as a view for the GPU into a set of data, like vertices or textures.

The GPU will need to know what it’s looking at, and how to deal with it. A descriptor does just this, it let’s the GPU know what kind of resources we are dealing with.

In previous versions of DirectX, we explicitly created a particular resource (a texture, a buffer) and set the access flags. In DirectX 12, resource binding is not tracked so it’s your job as the programmer to handle the lifetime of the objects. Descriptors is a part of the process you will need to handle.

We have different types of descriptors, like Constant Buffer View (CBV), Shader Resource View (SRV), Unordered Access Views (UAV), Render Target Views (RTV), Samplers and many more (don’t worry if you don’t understand any of these words, we will get to it). A SRV descriptor for example let’s the GPU know what resource to use (a texture for example), and that it will be used in a shader.

In our example we are dealing with a couple of Descriptors, and in the next tutorials we will see a lot more of them. One is the Vertex Buffer that contains all the vertices we want to render, an Index Buffer containing all the indices (the order of how the vertices should be rendered) and a Constant Buffer that is used send data to our Vertex Shader.

Let’s take a look at our descriptors:

D3D12_VERTEX_BUFFER_VIEW				m_vertexBufferView;
D3D12_INDEX_BUFFER_VIEW					m_indexBufferView;


Once these are defined, we can set the Vertex and Index descriptors like this:

As you can see, we set the buffer location for our vertex shader to the resource we created earlier, the vertex layout (we had Position and Color data for each vertex) – this defines the size of each vertex, and then we set the total size of the structure by taking the size of the cubeVertices data structure.

Descriptors are primarily placed inside Descriptor Heap, so let’s look at that!

Descriptor Heaps
These should (although not always possible) contain all of the descriptors for one or more frames, and can be seen as a collection of descriptors. It can limit what types of Descriptors it can contain to Descriptors of a given type, or a mixed set of descriptor types.

Descriptor Tables
These are a group of Descriptors inside a Descriptor Heap –like an array of Descriptors. The graphics pipeline is accessing resources through a descriptor table in a heap by using an index.



Here we can see that a lot of shaders are getting a view into the heap by using descriptor tables using an index. Each of the descriptors inside the heap (D1 – D10) is describing a texture or a buffer. Each of the tables got an index, and an offset.

Putting it together
A Descriptor Heap is defined like this:

Once defined you need to create it using the CreateDescriptorHeap function on the D3D Device. This creates a heap accepting the types: Constant Buffers, Shader Resource Views and Unordered Access Views (UAV), as we will be adding our Constant Buffer to it, and make it visible to shaders:


As you can see, Descriptors of the type CBV, SRV and UAV can share the same Descriptor Heap, while samplers need their own. Vertex Buffers, Index Buffers, Render Targets, Depth Stencil Views and Stream Output Buffers are bound directly on a command list (discussed in the previous tutorial), and thus, not placed inside of a heaps.

In our example, we create one Descriptor Table for our Constant Buffer, and then make it visible in our Vertex Shader.

Descriptor Tables can be seen as a subset of descriptors in a descriptor heap. It’s an offset and length in the heap, and can store Descriptors of one or more types.

All this concepts look like an overhead, but the reason we use is coming from the way GPUs operate internally. So, by using descriptors, heaps and tables we have more control on the resources and can operate faster in a way GPU sees it. Just the way DirectX 12 is designed.

Root Signature
Shaders can use a Root Signature and Root Parameters to locate a resources they need to access. In other words, the graphics pipeline can access a resources through a root signature by using an index in a descriptor table.

Root Signature is a kind of “view” into the heap (using resource tables as the binocular) containing resources that shaders can use. You define what resources it addresses and what level of access shaders get to them.

I our case, we need to use a Root Signature to give our Vertex Shader access to a set of data stored in a Constant Buffer.

We define our Root Signature like this:

Then we need to set up our Root Signature. We start by giving the Input Assembler Stage access to the constant buffer through our Root Signature, and denies access to the domain, hull, geometry and pixel shader. Then we store the Descriptor Table containing our Constant Buffer in our Root Signature.


The CreateRootSignature function takes a serialized version of our root signature, so we first serialize it using D3D12SerializeRootSignature, and pass on to CreateRootSignature.

Direct3D 12 uses Descriptors to describe a resource for the GPU. A set of descriptors used to render a full frame or more are places inside of a descriptor heap, and a descriptor table is used to easily access a set of descriptors in a descriptor heap.

A Root Signature can be used by the shader to easily access these Descriptor Tables.

These are all used in combination for you as the programmer to handle the resource binding in DirectX 12, giving you full control of each step. You are now responsible for the resource binding!

Posted in DirectX12, Tutorial | 3 Comments

DirectX 12 Programming #3: Command Lists


Welcome back! In the previous tutorial we learned about the Pipeline State Object and how to use these to efficiently change the state of our graphics pipeline for rendering.

Today we will take a look at the next feature of DirectX 12, the command list. Command lists are basically a set of drawing and resource management calls generated from one or more threads, and then executed to render a scene; typically in the end of a Render function. This have a performance benefit as we pre-compute rendering tasks that can be executed and even reused at a later time. These command lists can be executed across multiple threads.

Why do I have to care?
As a DX12 graphics programmer, it’s now your job to group rendering calls into work items, and when to submit this work for the GPU – This has to be a part of your engine architecture.

What’s in a command list?
A command list will contain traditional rendering API calls like drawing primitives, changing rendering states, etc. If we take a look at a part of the command list in our example application, we can see that it’s heavily used in our Render() function:


In the code above (I cut the lines on purpose as it’s not needed here), we can see that we are not directly sending the commands to the GPU, but store them in a list named m_commandList. We submit a call the RSSetViewport and ScissorRects to set up our view, clear the render targets, configure our IA shader stage (Input Assembler), and finally draw our 36 vertices as a cube made up by triangles.

At this point, nothing has really happened as we haven’t submitted the list yet.

Above we simply add commands to a command list, and then at a later point, execute it. This is called a direct command list. However, we can also create lists that contains a small group of API calls that a command list can execute whenever, multiple times. These are named Bundles. Bundles are simply a group of API calls ( a “mini-command” list made for reuse).

We won’t go in depth of this topic here, but will come back to this in a later tutorial. Like Bundles, a direct command list can also be execute multiple times, but you are responsible for checking if it has completed before executing it again.

When creating these bundles, the driver will try to pre-process as much as possible for more efficient execution when it’s needed.

Creating a Command List
A command list is created using the CreateCommandList on the Direct3D Device. This function needs to know what type it will be (D3D12_COMMAND_LIST_TYPE contains all possibilities), like if it will be a bundle or a direct list, a command allocator used to manage the memory for the list, and the PSO created in the previous tutorial.

In our sample it looks like this:

We create a direct command list with our one and only PSO.

Filling the Command List with commands
Once the command list is created, we can start adding commands to it. When created, it will automatically be in a record state, ready for you to provide commands to it by using the ID3D12GraphicsCommandList interface.

You typically open it up for Recording using the Reset function, and when done recording, you end it with the Close function.


Executing the Command List
Once your list is full of commands, you can submit it to the command queue by using the ExecuteCommandLists function. When you initialize D3D, a default command queue is created. It is possible to create your own command queues, but I recommend you to stick to the default one for now, which is sufficient in most cases.


The command queue will automatically execute the commands in the list.

Posted in DirectX12, Tutorial | 2 Comments

DirectX 12 Programming #2: Pipeline State Objects


Welcome back! In the previous tutorial we briefly touched on why our Sample Application is looking like it does. In this and the next 3 tutorials we will take a closer look at the various DirectX 12 specific features, like the pipeline state object, command lists and the descriptors. After this, we can start making the cool stuff!

I know it’s a lot of information and many new concepts, but it will all make sense – and when you understand it correctly, it will take you closer to the GPU itself so you can use all of the new performance capabilities DX12 gives you. Smile

Let’s get started. One of the new features of DirectX 12 is the Pipeline State Object (PSO). \m/

Say what?
Putting it simply, this is a way to set a GPU to a state you need it to be in, when rendering. When the GPU is doing its magic, it needs to set a lot of input and rendering settings before the rendering can happen. It needs to know how to blend colors together if there are overlapping pixels (blending), how to handle depth data (depth stencil state), how to read input data to build primitives, what shaders to use and so on, the list is long.

A PSO is simply an object that describes a given state of the graphics pipeline. You can create as many of these as you want, and switch between them when needed.

These PSOs are usually created during initialization, and then switched during rendering. Doing this right will benefit your application when it comes to performance as you can set a lot of these settings at once, instead of randomly when you need to change a fraction of it.

Think of them as a way to put a lot of different pieces of a puzzle together for the final image, but instead to put together how the GPU will handle stuff.


The two pictures above is the same scene, using the same vertex data, but different PSOs.

Creating a PSO
It’s very simple to create a PSO. To do it we follow the typical Direct3D way of doing things, we fill out a structure called D3D12_GRAPHICS_PIPELINE_STATE and submit it with a call to the function CreateGraphicsPipelineState(…).

Let’s take a look at the PSO from our example application from Tutorial 1:


Wow, that’s a lot of properties! Let’s dive right in. In this case we set the input layout to the layout we specified when creating the Vertex Buffer, and we let it know that we want to use our Root Signature instance (covered in Tutorial 4).

We also need to set what shaders we want to use, so we take the byte code from the VS and PS, and set it accordingly. In out example, we are using one vertex shader to transform our cube, and one pixel shader to give it color.

Next we specify that we want to use the default rasterizer state and blend state, set the sample mask to max, and disable the depth and stencil buffer. We set the primitive topology to triangles, as that is how we set up our vertices in our vertex buffer, we set the number of render targets (RTV) to one as we only need one render target for the example scene, set the format of it and sample desc is used to set multisampling parameters.

Once we got the PSO structure filled out, we can set it using CreateGraphicsPipelineState(…) on the D3D device.


This function creates a PSO instance we can use later in our application. We need to use this when we create a Command List in the next tutorial as a parameter to CreateCommandList(…). Then, when we use that command list for rendering, this PSO will be in use.

Switching between PSOs
Although we won’t need to switch between POSs in our sample, I still want to show you how you can change the current POS bound to a command list.

There is a function called SetPipelineState on a CommandList that will take a PSO created during the initialization of the app, and make it active on the command list.

Final result

We still render our cube, but now you know what state the GPU is in, congratulations!

Posted in DirectX12, Tutorial | 4 Comments

DirectX 12 Programming #1: A quickstart!


Windows 10 has just been released, and with it Microsoft’s latest iteration of DirectX – DirectX 12.

I will go more in-depth on the DirectX 12 SDK later in this series, however for now, I would like to show you how you can create a new DirectX 12 enabled project, explain what’s going on, as well as direct you to the resources made available by my friends in the DirectX team.

DirectX 12 brings a lot of new features, and it takes you much closer to the hardware than ever before. This means that you will get better performance and room to do a lot of neat stuff, but it also gives you more responsibility when it comes to handling the low level stuff.

This tutorial is just part 1 in a longer DirectX 12 tutorial series. At a later stage we will dive deeper into buffers, command lists, pipeline and much more.

Note: This series is aimed for beginners on DirectX and graphics programming in general.


1) Get Visual Studio 2015, the community version can be downloaded from free here:

2) Make sure to select the Windows Universal component when installing:

3) Optional: Watch Chas Boyd give a great talk on Direct3D 12 at Intel’s Buzz Workshop

Creating your first DirectX 12 project

Let’s just get started.

Launch Visual Studio 2015 and create a new project. Be sure to select the DirectX 12 App from the project template.


Give it a proper name and hit OK to create a new project. The template will set everything up for you so the app should be all ready to run when Visual Studio completes the setup.

Once it’s complete, you should be able to run the example scene, so go ahead and hit run:

The project will compile, deploy and run. You should see a spinning cube on a blue background like in the picture below:


Now, spend 10 seconds by taking a close look at this scene, try to think of what’s happening, and what you see.

Diving in to the example code


The project tree should look similar to this. It contains the .cpp files and the header files, as well as the Package manifest and tile assets.

The example applications game loop is found in the template class, and can be thought of the core of the application.

This class contains the functions executed by the game loop, where Update and Render is launched every frame. A game usually consists of many different scenes, and this architecture can also be seen here. The class named Sample3DSceneRenderer is where the actual rendering of the cube, the shader setup, screen clearing and so on is happening.

There are many ways to use a scene renderer, you could have one for the intro and main menu scene, one for level select, and another for the game itself (MainMenuSceneRenderer, InGameSceneRenderer….) – it’s up to you to organize your code. You COULD insert all code in the main class as well, if you want…. Smile

In the figure below, you can see the header of our main class, and the scene renderer Sample3DSceneRenderer as a private member.


If we check out the Update and Render functions of the main class, we can see that it simply calls the respective functions from the scene renderer:image

Note: Instead of just calling the Update and Render function of the Scene Renderer here, you could implement a Scene State handler that calls these functions for the current active scene, like Main Menu of the player is starting the game, or it the players hits Start Game, it changes to a loading scene, and then to the In-Game scene.

So, where do I find the Scene Renderer??

Let’s go ahead and find the meat of this example, the code that renders the cube. It’s all done in the scene renderer, and it can be found here:


If you open the Sample3DSceneRenderer.h header file, you can see that it contains a lot more functions and variables that the main class. This is because the main class is currently very simple, and you want to keep it that way. Everything related to the specific scene should be done here, including all needed shaders, resources (images, audio) and so on. The Update and Render functions called by the main class itself can be seen here:

These two functions are doing the main work of our renderer. The Update() function should contain everything logic related like physics, calculations, AI, collision detection, while Render() should only do rendering. Please don’t mix and match here, don’t render stuff from the Update function and don’t calculate stuff in the Render function. This can introduce flickering and weird stuff because some calculations can be out of sync.

The Scene Renderer simply explained

This is not a deep dive on how DirectX 12 works (check the DirectX 12 Programming Guide) but I will try to give you a simple explanation of how the scene is set up.

First of all, we have a timer that keeps track of time, as well as the delta time between each frame. This is used to sync you scene to your clock, to avoid a game running faster or slower based on the power of your hardware.

Secondly, what you see is a cube. This cube is made from vertices read from a Vertex/Index buffer. These buffers are containers that contain data of vertexes. The following list shows the content of the vertex buffer:


Each Vertex got a position (XYZ) and a color (RGB). Then we got an Index Buffer that contains indexes where each index represents one of the vertices above. Each row in the index buffer contains 3 indexes that builds up a triangle that is at a later stage rasterized into a filled polygon.


In the list above, you can see that it’s grouped into 6 groups, where each group got two polygons. These two polygons in combination build up one side of the cube, and the cube got 6 sides.

World, View, Projection Transformations

We also create some matrices that transforms our scene from world space to something that looks like 3d on a 2d plane (what we see on out monitor). The vertices created above and these transformations are then passed into the graphics pipeline, starting with the Vertex Shader. The world transformation is used to position objects in the game world itself, the projection transformation is used to place this into a projected world (giving depth, distance), and the view transformation is used to place objects in a give view window (think of this as your eye or camera into your game world).


The Vertex Shader

Every frame, these 36 vertices are sent through something called the Rendering Pipeline. This pipeline is what makes these numbers into images on your screen. It consists of many stages, where each stage is vital to the final outcome of the rendered image.

The Vertex Shader is executed directly on the GPU for each vertex you pass into it. In this example, the Vertex Shader is running 36 times every frame, and if this scene is running at 60 frames pr. second, this means that the shader is running 2160 times pr. second. A typical game scene rendering advanced 3D models can have hundreds of thousands of vertices, so make sure to optimize your shader code!

So what does this vertex shader do? Let’s take a quick look at the code:

The main function does everything. It’s using a set of global variables in Constant Buffers (set outside from the application itself, since this program is running on the GPU while the application is running on the CPU, there is no direct way to access variables between these).

It takes the data from the Vertex Buffer (position, color) and transforms it to a projection space, sets the color and pass this data further down the pipeline.

The Pixel Shader

The next shader stage we have in this example is the Pixel Shader. This shader is running for every pixel in your game world (not only the ones that you can see on your monitor), so the pixel shader can be a bottleneck for your scenes. Make sure to optimize!

The pixel shader in this example scene is very simple. Let’s take a look:

The Pixel Shader takes the output from our Vertex Shader (Projection Position, Color) as the input, and returns the color of the current pixel. This is simply the color set in our Vertex Buffer. The shader automatically interpolates the color if the pixel is between vertices.

The other stages

There are a lot of stages in the pipeline we didn’t cover, but let me quickly show you how this works. The squared ones are fixed stages, that you can configure, where the round ones are programmable shader stages.

Diagram of the data flow in the Direct3D 11 programmable pipeline

(Image from MSDN:

The Input Assembler stage is where we put stuff into the shader. In our example, this was the vertex position and color data using buffers.

Then we calculate per vertex calculations in the Vertex Shader. The Hull, Tesselator and Domain stages are used for tesselation, and is optional.

Once this is done, an optional Geometry shader can be executed on our vertices – it can create new geometry and a lot of cool effects can be made here.

This marks the end of the vertex specific stages, the output it passed through a rasterizer that clips and prepares our geometry for the pixel shader.

The pixel shader is then responsible for generating the final output image that the player will see.

Command List

To make rendering more effective we are using Command Lists to generate a set of commands that we want the API to execute. This includes clearing the screen, setting what buffers to use, sending this to the Input Assembler, setting the active shaders and rendering the cube.

A 2nd look at the example scene

Run the example again, and look at it with your new knowledge. Was it what you imagined in the first go?

Feel free to reach out to me on twitter @petriw if you got any questions.


The following list contains some good resources that will take your knowledge to the next level:

DirectX 12 Programming Guide


YouTube videos

Posted in DirectX12, Tutorial | 9 Comments

GDC Europe 2015

imageAt this years Game Developers Conference in Europe I had a presentation called “Using Cortana and Speech Synthesis to voice-activate your game worlds!”.

The talk was about adding voice activated trigger zones around NPCs (or areas) with pre-programmed questions the player could ask, and it would respond the given answer.

clip_image001 clip_image001[5]

This was set up using Unity 5, where you simply could drag a scrip on an existing GameObject to give it a voice. Once the player enters its trigger zone, the plugin would start a continuous listening session, waiting for the player to ask one of the pre-programmed questions.


I also added the possibilities to ask Cortana to launch the game, or ask if anyone had beaten your high score. If yes, it would ask if the player would like to play the game now to reclaim it.


You can download the plugin code here:

Thanks to everyone who attended my session!

Posted in Cortana, GDC, Windows 10 | Leave a comment

It’s been a while

I had some changes in my career and ended up moving to Seattle to work with graphics and games in Microsoft, Redmond. It took a while to get settled, but expect to see some more blog posts and tutorials here very soon!

Feel free to suggest what you want me to do a tutorial on! However, you can expect some Unity 5 shader tutorials, as well as a lot of cool stuff around Windows 10 for game developers!

Posted in General | 1 Comment

Microsoft Azure WebJobs in Truck Trials

In my latest game Truck Trials (read the Making of Guide) I’m running a special championship every weekend, named Weekend Champion Cup.

To get this cup started I need to do some simple things in the database:
1 – Friday at 17:00 GMT, Reset the data from the previous competition
2 – Friday at 18:00 GMT, Start the competition
3 – Sunday at 18:00 GMT, End the competition
4 – Sunday at 18:30 GMT, Award the winner

In the early days of this project, I did this manually because I had to prioritize other development tasks. But this meant that I had to make sure this was done every Friday evening, and stress about this during dinner or at a get together with the guys – and the same every Sunday.

Now this has change since Azure WebJobs is doing all of this for me!

It’s very simple – just create a Console application, zip it and upload it to a WebJob on your Azure Web Site project. When creating the WebJob, you can specify to run the application continuously or at a schedule.


The implementation

Developing the Console App:
First of all, you need to develop the console app that will execute the task you want to perform.
To do this, start Visual Studio 2013 and create a new Console project (I used C#). In my case, I added the EntityFramework NuGet package since I was going to do some operations on the games database.


This Solution contains all of my WebJobs, one project pr. job I want to perform. In this post, I’m just going to focus on step 1, resetting the players score. All other steps are implemented in the same way.

So basically, this is what this application does:

It starts a Stopwatch (nice to track the time of the operation), resets the scores and writes the output to the Console.

The cool thing here is that all output from the Console app is displayed on the WebJobs management page, so I can simply just log in to the Microsoft Azure portal, and see the results there. More on this soon!

Now that the console app is done, it’s time to create the Web Job. First of all, we need to ZIP the program. This will then be uploaded as the WebJob package:



Creating the Web Job
Let’s make the cool stuff happen!

1. Log in to Microsoft Azure, go to your Azure Web Site project and click Web Jobs:

2. Click Add


3. Fill out the information on page 1 and click next

4. Fill out in the information on page 2 and click next


5. Wait for the WebJob upload to complete

6. Test it by clicking RUN ONCE:


Checking the output

The cool thing about this is that you can check the console output. Just click the LOGS link on your WebJob.

You will be redirected to the WebJobs page on Microsoft Azure, where you can see a list of web jobs, status and how long time it has gone since it was last run:

By clicking the WebJob, you can dive in to the details, and also see the console output:


And that’s it, you got a WebJob up and running, doing critical tasks for you Smile 

Thanks to Pedro Dias for helping me with this!

Posted in Azure, Truck Trials, Tutorial | 1 Comment

Video Tutorial: Creating a Flappy Bird type game using Unity 4.6

Today I had a webinar named “Developing Games for Windows”, it’s one of my first recordings but I hope to create many more with better quality going forward.

Anyways, I decided to share what I made in case any of you would find it useful.


The goal here is to share how to create a simple game using Unity 4.6, and how to export this as a Windows Store app, and as a Universal App that targets both Windows 8.1 and Windows Phone 8.1

In this post, I want to share the video, and provide you with the source so you can create your own games, and help you publish it to the stores! Smile

I) Check out the video
II) Download the source, create your own version
III) Publish
IV) Check out my “Making of” guides so you can learn how this looks in the bigger picture

I) Learn the basics of Unity by creating another Flappy Bird clone


II) Source
Feel free to use the source however you like, and even reuse the graphics.

Download source

The source contains the Unity Project of the game, the Windows Store export, and the Universal export of the game.

Modify the game as you like, make your changes, try to change the graphics and learn from the process.

Once you have created your own version of the game, go ahead and publish it – and learn from it. You gain a lot of knowledge by just reading the download data, making modifications to the app tagging to see if it increases or decreases download rates and so on.

Note: Make sure you have the latest update for Visual Studio 2014 (Update 4) before you open the Universal export.


III) Publish
I made this simple guide on how to export and publish a Universal app


IV) My “making of” guides
I have created a few games, and for each one of them I created a “Making of” guide explaining how I did it. Click the image of the one you wish to read. Smile

The Making of Truck Trials

The Making of Starcomet Online

The Making of Bandinos

The Making of Binary Man
Binary Man

Posted in Tutorial, Unity, Windows 8, Windows Phone | 2 Comments

The Making of Truck Trials–Multiplayer Racing

Truck Trials - Multiplayer Race skjermbilde 0

Project Truck Trials started back in June 2014, after Starcomet 2 was released. And as usual, with every game release I do comes a making of guide, just to share the process and what I did to end up with the result I have.

Read my other guides


The game takes you to a trial track where you have to maneuver a heavy truck through harsh environment, hills and jumps as fast as you can – or at least faster than your competitor! You are free to design and change the look of your truck, change your name and play both in Time Trial and online 1 vs. 1 race.

Try it out:

image image[8]

The game logo is inspired from the American interstate road signs, with a truck grill and mirrors to make it look a bit like a truck, but at the same time have similarities to the NBA, NASCAR, NHL, MLB, NFL++ logos.

left-43868_640 image

It’s a connected game, so you need to be connected to the internet to be able to play. An account will be created for you when you first start the game – using the GUID of your Microsoft Account.


30 tonnes, 200 km/h, 20 meters up in the air, welcome to Truck Trials, a high pace, side scrolling physics based racing game!

Create, design, and race a heavy truck against random players in the biggest truck trial racing tournament ever!
 Truck Trials - Multiplayer Race skjermbilde 3

Unlock truck parts, put them together and give them a color to create a truck that fits your style! The top three players will see their design nicely lined up on the throne in the ranking screen!

Play against random players, win and earn credits, and become the ultimate truck racing champion!Truck Trials - Multiplayer Race skjermbilde 2

Race against time! Can you beat your personal record?Truck Trials - Multiplayer Race skjermbilde 6




Truck Trials - Multiplayer Race skjermbilde 1
Back in December 2013, my brother and I attended some Hackathons, where we were put up to a challenge to create and implement a game idea over a weekend.

We took this concept to a cottage up on the Norwegian mountains for a weekend where our goal was: “Let’s create 10 games, where we use max 3 hours on each – then all of these prototypes must be good enough for publishing. If we exceed 3 hours, we scrap it.”

7 or our ideas was successfully published on a public Game Jam account, where we could follow the prototype when it comes to stats and downloads.

Two of them stood out with over 100.000 downloads in a short amount of time (and much more later). One of them would take too much time to implement, and the other was a truck game that looked like this:

So basically, we skipped paper prototyping – and instead created a digital game with proper stats, and feedback.



The game is made with Unity3d, a great game engine for creating all kinds of games and interactive experiences. We used this because of the good engine, and the great possibilities it has when it comes to exporting.


Truck Trials is a Universal App. It’s an app that runs on both Windows 8 and Windows Phone, and is connected on the store (basically, is shares everything, including IAP ++).

imageFor the multiplayer part, Photon by Exit Games is used for real-time communication, and Microsoft Azure for all of the services and database. Photon is used because it’s a mature and modern platform, that’s 100% integrated with Unity3d.

When it comes to Microsoft Azure, all of the logic is created trough a custom Visual Studio DLL project that’s used as a plugin with Unity. I had to write one plugin for Windows 8.1 and one for Windows Phone. Most code could be reused, but I needed some custom stuff that’s platform dependent. Prime31 also got some plugins for Azure, so be sure to check them out!


I’m very satisfied with how fast and easy it was to create the services I needed, and how much flexibility I had when setting them up (scale, performance).

What I have online is a couple of services, a web site, a mobile service and a database that connects all the logic together.

There are a lot of different ways to implement all of this, but this was my choice based on earlier experiences. Most of the communication is through REST/Web Services, while the real-time positioning is peer to peer using photon.

The awesome thing about making stuff with Microsoft Azure is the nice user interface to the platform. I can track everything that happens on the server, and see exactly how my queries are performing, how much data is being used and so on.





I started working on the game in June and the core of the game was developed before going on summer vacation. After that there has mostly been content creation, level design and polish – and with very little time on my hands to actually work on this game, it took a while to get it “done”.

I made sure to have a a beta version available from the start so people could try the game, give me some feedback, and post updates to a dedicated beta testing group on Facebook.clip_image002

The first iteration of the game was a simple straight line where one could drive a box with wheels. The box was the truck, and the wheels was the physics system – this was to create the balance, get the correct forces and the feeling I wanted to have. I spent a lot of time playing with different gravity values, to get the “Heavy Truck” feeling. Then I changed the box to a proper model and worked on the scale.

Next was to get the multiplayer part working, so one could see the other player on the same track, set up the correct cameras and make it playable with two players (and get the winner).

clip_image002[5]Once the mechanics was in order, I started to create the first iteration of the menu systems and the truck customization to be able to create the internal logic that renders the customization, stores it to the server, sets the correct colors and basically defining the rules I needed to follow.

Then I started the modeling process on some real trucks and truck parts, and do the level designs on a few levels just to get it started, and see how the mechanics work in a “real” scenario.


I also created the online services that connects everything to a user account, and the plugins that connects the client to the server, and the IAP system.

Most of the game is straight forward and pretty easy to implement, but there are a couple of features I want to highlight.

Here you can see the iterations of the user interface from start to finish:


I recommend you to create and test a protoype of your interface, and work with it. It takes a lot of time to totally re-implement the UI like I did in this game, but don’t be afraid to re-implement it – it will be worth it!



The challenges system was fun to create. After the initial launch of the game I needed to increase the retention rate of my players. So I decided to add a couple of things to do this, and one of them was to add a system that tracks what you do, and give you a reward if you do enough of it.

What’s behind it?
– two database tables that store the data online
– a couple of web services that handles incoming and outgoing data
– a client function that makes progress of a challenge, and one that gets the status of all active challenges.

The challenges system consists of a few tables that is hosted on Microsoft Azure. One is the challenge description itself, and another one is the tracking of a challenge pr. player.


When the player is checking the Challenges status, the client requests the current active challenges from the cloud, gets a reply and renders them.

When the player is completing an interesting activity in the game, like winning a race, loosing a race, buying anything, or simply just completing a race, a function will notify what the player just did, and then the server will do the rest – like checking if it’s true, then handling the updates for all the challenges that are affected by that activity.

The Progress function will also reply to the client if this new progress has made a challenge complete. If so, the reward is added to the account.

Christmas Special Challenge
In addition, I created a special challenge that’s only available during Christmas (but the function can be reused whenever, like Easter, Halloween, summer and so on). This challenge counts the number of challenges the player has completed, and if it meets a certain goal, an item is unlocked for the player.


For this challenge, I unlock a Christmas-special badge and emblem, and enough truck credits to buy a Christmas hat – just to set the mood. Smile

The main menu has also been changed to have a darker blue background, with snow and the northern light – it’s Christmas. Open-mouthed smile



I wanted to test out ads in a game, so I simply used the Prime31 plugins for Microsoft Advertisements (AdMob is also available for Windows Phone).

Before you can start using ads, you will need to register an account at all of the different Ad providers you want to use.

1. Register at Microsoft Advertisement:
2. Register at Google AdMob:
3. …..

Once you have registered here, you are able to create an ad, get the ad ID and then simply using those keys in the Prime31 plugin. The rest is automatic! Smile



The weekend champion cup is a cup that starts every Friday at 18:00 and ends Sunday at 18:00 (GMT). It’s the same type of racing as before, but in addition to getting the normal stats, you also get championship points – and every weekend, I reset the existing championship points to 0, so everybody starts at the same page for every weekend.

These points are used in a dedicated ranking podium that the players can see in the ranking screen. Again, everyone starts from scratch, and the winner gets 2000 Truck Credits to spend on any truck parts they wish, and a unique Champions Cup badge and emblem that they can use to show off to their competitors that they won.

In addition, all the winners are posted on the games Facebook and Twitter page:

This implementation is very simple. It just checks if the server says that the compo is active, and if it is – it changes the normal Race Online button to another button that takes you to the Weekend Champion Cup. The rest of the race is identical to the others.



The badge system is a way for players to show other players what they have achieved. The Badges can only be unlocked by meeting certain criteria like being a game tester, the developer, completing the Christmas challenge, buying a Premium Account, spending real money on the game, winning the Weekend Champion Cup and so on.

A badge is using the same system as the other parts of the truck, but in addition, the lookup id of a badge item (read more on the below) is used to also change the emblem that will appear below your nick when starting a race.



The game features a Premium Account that can be bought as an IAP. If you got a Premium Account, you will get 100% extra in-game truck credits earnings for every match you play, free color painting, access to the Rim Editor, as well as unlocking the Premium Account badge and emblem, 1st person view and a donator badge/emblem (this is unlock to everyone who spends money on the game).

This is a simple implementation. If you buy the Premium Account IAP (durable), the features will be enabled. It’s simply a function that checks the IAP, and then your account – and if everything is OK, it will unlock the items in the database.

The 1st person view is implemented by having two cameras on the trucks, and then using unity logic to enable/disable the correct cameras based on a setting from the Settings menu. Each camera has a rendering layer, so I can specify what the 1st person camera can see, and what it can’t – to hide items like the Christmas hat.

In addition, when playing 1st person, the normal view is displayed in the corner in-case you need to get out of the truck and get a proper reference – just as an aid.





The game uses ID’s to select what items it should render where. One truck is put together by 5 factors:
– Chassis
– Exhaust
– Roof
– Rear
– Badge/Emblem

These items are just an integer that is stored on the player profile, and used as a lookup in the items folder. The system then assembles the car by using the lookup IDs to find the correct prefab, and then Instansiating them in the right place on the truck.

Each chassis contains points of interest, like an empty game object where the roof should be, another where the rear should be and so on – this is spesific pr. car, since the positioning is quite different on each of them.

This chain of ID’s is then communicated between the players you race against, and then built up locally the same way.


NEW+RISING: When publishing the game, it will stay on the “NEW+RISING” list for some weeks. Make sure your game is as finished as possible before it reaches this list. In my experience it usually takes about a week to get there, so you got a few days to test and make sure the published version is working as it should. These first weeks will be very important going forward.

KEYWORDS: When publishing, you can type in some search keywords. Change and test these frequently if you don’t get any downloads. Changing this can multiply your download rates.

ADS: Make sure you have a good fill rate, and a good eCPM. Test your ads at different places, and make sure it wont overlap anything of importance on the screen. Test with different screen resolutions, and orientations.


It’s free to download, so if you appreciate this guide, please help me by testing the game and by giving me a rating – and/or an e-mail to with feedback. Smile

image image[8]



A special thanks to Thomas for helping me when needed, to Tuuli for support and my brothers Olav and Paul for testing.

Also, thanks to all the testers in the Beta Program – more versions are on the way, so be ready! Smile

Posted in Uncategorized | 4 Comments

Truck Trials Update: Daily Challenges, Top 50 Players, 1st Person View, Badges, Trick Boost, Stats and much more!

The latest version of Truck Trials has been published on both Windows Phone Store and Windows Store, with a lot of new neat updates for you to enjoy!

This update brings a lot of news, features and functions.

So, what’s new in this update?
– Challenges
– Top 50 list
– Better results screen
– Badges and Emblems for your truck and name
– Trick boost
– Stats on the main menu
– Premium Account
– 1st person view (for Premium Accounts)
– A lot of bug fixes and polish

image image[8]

Here is a bit more information about each feature:

Mostly daily, but also long term challenges has been added to the game. These challenges will progress automatically, and when you complete it, you will get the reward straight to your player account.

Playing many dailies will also unlock special features like unique badges and emblems for show off towards your rivals.



Global top 50 players list
This feature has been awaited by many, but now you can finally see your own ranking even if you’re not on the top 3 list, or in the top 50 list. Also, the top 50 players list has been added so you can see how much points you need to get on the list, and how much the players ahead of you are leading!


Better results screen
The results screen has got a bit better with a nice litte trophy, a standing list, and icons that show how much you gained after a race.


Badges & Emblems
These special items are not buyable with Truck Credits. They are unlocked of you do something special. One is to be the developer of the game (the golden eagle you can see in the picture below), other is a silver eagle that all testers of the game gets. But also there is many badges that can be unlocked by doing stuff in game like by winning the Weekend Champions Cup, you will get a nice trophy badge and a name embelm so that all your rivals you race against can see that you have previously won the Cup Trophy!

Others are if you spend money on the game you can get the Donator and Investor badge, if you complete all time trial levels with a 3-star rating, unlocking the premium account and so on. You can change between all your unlocked badges in the Garage.image


Trick Boost
Do tricks with your truck for a chance to get a speed boost. This can be a great front flip or a back flip. Remember, you have to land your trick to get the boost!


Stats on main menu
Now you can get direct feedback on how you are performing directly form the start menu. These icons show if you have a premium account or not, your current global ranking, your win rate, and your current time trial rating.

New icons below your driver name.

Time Trial stat shows how many time trial shields you have been able to gather in total.


Premium Account
Premium account unlocks a unique premium account badge, the donator badge, gives you 100% extra truck credits when completing a race, removes ads, and also unlocks the 1st person camera view!



1st person view


You can enable 1st person view from the settings menu after unlocking the premium account.

Posted in Game programming, Racing, Truck Trials, Windows 8, Windows Phone | Leave a comment