Accessing game objects by unique ids

Every game keeps its game object in one or more simple collections. These are used for enumerating the objects every frame to update and draw them.

If objects need to refer to each other, they can easily store a reference to another object, and access it directly. This becomes more difficult however, when we deal with a multiplayer environment. In that case, each game will have its own set of object references, which will never be the same.

That means that we need another way of identifying objects.

Further, we want this access to be fast. After all, a network server might send a client the message that a certain game object should be deleted. If we then need to iterate over all objects to find the correct one, we could easily bog down the performance of our game. Those CPU cycles could be spent much better on something else.

Lastly, whatever data structure we will design for this has to be able to respond appropriately to objects being deleted. See this post for a discussion of how this can be done for simple lists.

Continue reading →

Designing a shader loading and management data structure

Last week we looked at how we can use the builder pattern to build shader programs out of individual shaders. We abstracted away all actual functionality in favour of a clean and easy to read interface.

In that post we assumed the existence of a shader manager – an object that held track of all our shaders and that we could ask for any of them given their type and a string name.

Today we will design a system fulfilling those requirements. Our goal is having this system take over as much work as possible, so that we do not have to bother with any of the details when using it.

Additionally we will look at how we can easily and automatically load shaders from code files – though this part of the system could be easily replaced by one loading them from a different source.

We will take an incremental approach to these topics, building our system step by step, according to our requirements.

Continue reading →

Linking shader programs using the builder pattern

This post is the first in a series on design patterns in game programming.

Design patterns play an important role in computer programming. Not every problem can be solved with a pattern, and not every pattern is useful in all circumstances. However, they can be powerful thinking tools when applied to the right kinds of problem and help us understand and design solutions quickly and without reinventing the wheel every time. Similarly, they can aid us in communicating our ideas efficiently to others.

Today, I would like to take a look at the builder pattern.

I will not go into the formal definition of the pattern itself – there are enough other sources for that. Instead we will look at just one example where I use the builder pattern in my C# OpenGL graphics library.

I will first show how I solved the problem in question previously, point out what I did not like about that solution, and then show how we can apply the builder pattern to a much nicer way of doing ultimately the same thing.

Continue reading →

Multi-threaded exception handling

Last week we explored the possibilities of using multi-threading to create animated – or even interactive – loading screens, and drastically decrease loading times.

While we went into a lot of details, using the loading screen of Roche Fusion as an example, there is one important topic we glanced over completely:

What if something goes wrong?

Or more technically: what if one of our threads throws an exception?

Continue reading →

Using multi-threading to animate and speed up loading screens

One feature that almost all games have in common is loading screens.

Many small games can get away with a single loading screen at the start of the game to load all or most assets.

Most larger games have one before every level or environment, or at least for major transitions. The only way to get around loading screens entirely is to have only a small core engine that is loaded at the beginning of the game, and to then load everything else (other engine parts and frameworks, assets, script files..) on the fly.

To make the latter feasible without causing the game to freeze at times, concurrency is a necessity – content has to be loaded in the background while different threads update the gamestate, render it, and keep the interface responsive.

This is a complex topic however, and too big to tackle in this post.

Instead we will look at a smaller problem and how to solve it.

Continue reading →