• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

About this blog

Random Stuff about this and that

Entries in this blog


[color=rgb(29,33,41)][font='Helvetica Neue']Hey there,[/font][/color]

this weekend I focused on animations. Animations are especially important for character in games as they deform the mesh and make the character "move". There are basically two different ways of animating a 3D model: morph targets and skeletal animations. The former stores the vertex positions (and normals) multiple times for different poses and interpolates them at runtime. This technique is very easy to implement, however, storing each vertex multiple times increases the size of the mesh drastically. This is something I wanted to avoid as download time is very critical in browser games.

When using skeletal animations, a skeleton is created for the mesh and each vertex gets assigned to one or multiple bones. If then one bone is moved, all corresponding vertices are moved accordingly. Thus, you only need to store the transformations for a few bones instead of the positions of all vertices.

Typically, the bones are organised in a tree-like structure and the transformations are stored relative to their parent. So, when the parent bone moves, all child bones move accordingly (e.g. moving your arm also moves your hand). This makes the approach very flexible and the skeleton can also be used to implement other techniques like ragdoll physics or inverse kinematics. However, before rendering the relative transformations of all bones must be converted to a global transformation. This task is usually very CPU intensive as it involves a lot of interpolation and matrix multiplications. As javascript is not really known for its blazing performance, this is something I definitely wanted to avoid.

So instead of relative transformations, I store a 3x4 matrix for each bone that contains the global transformation for a specific keyframe. I lose some flexibility and some accuracy when blending between keyframes, but it simplifies the process a lot. I can store those matrices in a texture so that i don't have to re-upload them every frame and linear texture filtering gives me virtually free blending between keyframes. You can see the results (and some hilarious outtakes) in the video below. However, I still need to implement animation blending and the possibility to add different animations. The former enables smooth transitions between different animations and the latter allows to combine animations (e.g. so that the character can punch while running). Arbitrary complex adding and blending situations can be completely done on the GPU by using the static keyframes to render the final bone transformations to a render target texture that is then used to deform the mesh.

During the rest of the week, I also worked on some other stuff: I wrote an "entity/component"-system, added (de-)serialization functionality and added support for textures and materials. Aside from the textures none of that is directly visible, but it makes my life a lot easier.


DevLog #1

Hello there,

I recently discovered the game TANX (if you don't know it, check it out, it is really fun) and i really liked the format of the game. Like the more popular game Agar.io you simply visit a website and start playing which, I think, works very well for casual games. It has an extremely low barrier to entry as you don't need to download or install it first.

In fact, i find this concept so interesting that I want to try to create a small game like this myself and start to experiment with the new technology. I am fairly new to the whole web development thing, so I first had to figure out how the development workflow in such an environment works. As the programming language I choose TypeScript over JavaScript because all the additional code completion makes life a lot easier and the Visual Studio Code editor has excellent support for it. However, this means that there is an additional compilation step before you can run the game in the browser. At first this was extremely frustrating, but after I familiarised me with some tools like webpack and started using them the workflow became a real breeze. In my current setup I can immediately see the result of the changes I made while coding. This enables extremely fast iteration cycles and lets me test many different things really fast.

So for now, I spent most of my time setting up my development environment and creating a small framework for the game. However, I also started programming the server using Node.js. This was very straight forward and even without any experience it didn't took me long to get some basic communication going. Here is a short video of the current state:

Everything is very basic right now, just a sample model I found on OpenGameArt and a simple untextured terrain generated with perlin noise. However, I still wanted to document the process, mostly for myself to look back to but maybe some of you find interesting as well. For the next step I want to add some animations. See you then!



Hi everyone,

it has been quite some time since my last (and only biggrin.png) journal entry. In the meantime, two friends and I had to develop a game for a game programming course at our university. For that, we decided to create a clone of the old artillery game Scorched Earth. We call it RockReaper!

Here is a short video showing the gameplay:



The game was created from scratch using C++ and OpenGL 4.0. We used the SDL library, GLM and a thin C++ wrapper for OpenGL provided by our computer graphics chair.

Our key features are:

  • Randomly generated, fully destructible terrain
  • Day/night-cycle
  • Weather simulation with wind and rain (not shown in the video)
  • Pixel perfect collision detection
  • GPU Particles via Transform Feedback
  • Dynamic lighting
  • 5 different weapons
  • Turn-based multiplayer (2-5 players)

    At the end, we made it in the top 12 and we now have to give a last presentation and submit a trailer for our game. We have no experience with creating trailers, so if anyone has tips or resources on that topic, please let me know. smile.png

Hey guys,

recently, I had to work on a project for my lecture on global illumination. My partner and I decided to implement a variant of the progressive photon mapping technique, described by Hachisuka et al.[1]: instead of assigning each photon a certain color, we choose to map each photon to a certain wavelength. This allowed us to simulate caustics more accurately and achieve effects splitting a beam of white light into its spectrum of colors:


So instead of using the refraction index, that is often given for transparent materials, we used Cauchys equation[2] to calculate the correct*, individual refraction index for each photon:


Where lambda is the wavelength and B and C are material parameters, controlling the overall refraction and the variance depending on the wavelength.
(*Actually, the correct refraction index is given by the Sellmeier equation[3], but for light in the visible spectrum the presented formula gives a reasonable approximation.)

There were a number of other problems we had to solve and I will probably create another post about this. So if you are interested in more technical details, let me know. smile.png
But now, I want to show you some results.

The first scene is the standard cornell box with two spheres in it:


The image on the left shows the noisy color-artifacts that are introduced with our method. This effect occurs, if the individual points in the scene did not receive enough photons, so that the average color is not the white, that is emitted from the light source. However, simply shooting more photons solves this problem and leads to the image on the right.

This looks pretty nice, but the interesting question was: does our implementation really produce the rainbow effect caused by a prism? So I created a scene with a narrow light source, which emits a beam of light at a prism and it turned out...


...it does! smile.png
Sign in to follow this  
Followers 0