OpenAL: an object-oriented approach

in Game Programming, OpenAL

We have already discussed several topics related to OpenAL. This week we will investigate how we can structure the concepts of OpenAL to fit nicely with the object oriented paradigm, so we can write elegant C# code to play sounds and manage sound effects.

In this post we will quickly go over the three main concepts of OpenAL as discussed in my introduction post: listeners, sources, and buffers. In addition, we will also introduce a type for sound data, which comes in handy for sound effect management.

Managing a library of sound effects

in Game Programming, OpenAL

Last time we stepped through the process of loading and playing a sound using OpenAL. In the example we only played a single sound once. In practical applications, in particular games, will have a larger set of sounds they use, and they will be playing these sounds multiple times. They might even play the same sound multiple times simultaneously.

In this post we are going to look at managing a larger set of sound effects.

OpenAL step by step: loading and playing a sound

in OpenAL

In an earlier blog post I introduced the workings of OpenAL. Knowing the theory still doesn’t mean you know how to actually get a sound engine working. Something I found myself struggling with a lot when I started working with OpenAL for our game project was figuring out all the steps required to get a sound to play.

In this blog post I will be talking about the very basics of playing a sound. In the following blog post, I will approach the problem from the other end, and we will look at some of the high level management code that can be used to manage a large amount of sounds.

Random dungeon generation

in Game Programming

Last weekend was spent on creating a game in 48 hours for the Ludum Dare. The final results can be found here. In this post I will highlight on of the techniques I used during the game jam: random dungeon generation.

Orbital physics for games

in Game Programming

Space, the final frontier and a recurring theme in games. The funny thing about space is that things rarely move in a straight line – then again, that all depends on your reference point. Gravity – and in particular orbital physics – forms an important aspect when it comes to movement in space. Many space games include some form of orbital mechanics or even depend on them as gameplay mechanic.

In this post I will talk how orbits in games can be implemented. In particular we will tackle some non-trivial orbits. This post will be very goal-focussed, and we will only discuss the underlying mathematics minimally, since it is primarily aimed to provide an easy reference to implement orbits yourself.

Now you’re talking with components

in Design Principles

Last week we introduced the concept of components as framework for programming game objects. As opposed to last week, this week we will discuss a more technical object: how to add communication between components. I will first describe a few use cases and why we are interested, before discussing several approaches and their advantages and disadvantages.

Now you’re thinking with components

in Design Principles

In an average game there will be a lot of different types of game objects. Since these game objects often share behaviour, it makes sense to categorise them to avoid code duplication. The common solution — in object-oriented languages, that is — is to use inheritance. Inheritance does have limitations however and on further inspection it does not appear to be the obvious choice at all. Switching to a component-based approach resolves a lot of issues. Developers using Unity will probably recognise the alternative I will discuss in this post, and I would lie if I was not heavily inspired by it. My main focus however will be to explain why a component-based approach is used. By explaining the philosophy behind components I am hoping to give existing Unity (or another game engine) users a better picture of the intended use, and new users an interesting new take on game programming.

Complex Finite State Machines

in Technical

Finite State Machines (FSM for short) are a very common phenomenon in game programming. Even if you have never heard of the term, it is unlikely that you have never used it before. While the concept behind Finite State Machines is simple, simple implementations can often lead to code that becomes hard to maintain. In this post we will focus on slowly abstracting from an ad hoc implementation to a simple framework we can apply in many different circumstances.

An introduction to OpenAL in C#

in OpenAL, Technical

Graphics and gameplay are two important pillars to build a game. Audio – both music and sound effects – is another important part of games. Many players and reviewers do not focus on audio much and indeed, if the music and sound effects fit with what is happening on the screen, they will fit naturally in the player’s experience. If you would play a game without audio though, you would immediately feel that something is wrong.

While a lot of game developers – especially programmers – are at least vaguely aware of the workings of an update loop or graphics code, audio is often something that enters the equation at a very late stage. In this post I will introduce the general concepts of basic audio programming using OpenAL.

Continuous procedural generation

in Technical

Games can benefit from procedural generation greatly. It can provide a game with many hours of (re)playability without the effort of designing new content for the game. There are several games that embrace procedural generation and incorporate it as main mechanic. Notable examples are Binding of Isaac and Faster Than Light. These examples however can benefit from the fact that only at a discrete number of points, (randomised) decisions have to be made. In action games like Roche Fusion, the player has to be continuously challenged by a procedural and adaptive algorithm. In this post I will briefly look into procedural generation techniques, and discuss how these can be generalised to be applicable in a continuous game or application.