Last week we talked about LINQ, its usefulness, and how to write our own methods to make it even more powerful. Today, I want to look at another couple of methods that I have found handy in a number of different situations. We will look at how to extract the maximum or minimum element of a list by a given key or selector.
LINQ (Language Integrated Query) is one of the most powerful features of modern .NET. Powered by generics, lambda expressions, method chaining, extension methods, and deferred execution it allows to write extremely concise code when dealing with collections.
In this post we will look some useful LINQ extensions I have written over the years to make my work with LINQ even easier and quicker, and help me simplify my code.
Following another object is one of the most basic movement behaviours an item can exhibit – both in the real world, and in games.
There are many different ways in which objects can follow each other, and depending on the circumstances, different kinds of movement may be appropriate.
Today we will look at one particular kind: A number of objects following another in a trail at regular distances. The movement found in games like Snake.
However – unlike the original Snake and many of its spin-offs – we will neither constrain ourselves to a grid, or to fixed time steps.
Instead we want our solution to follow arbitrary paths with arbitrary accuracy.
Over the last couple of months I’ve been working a lot with WPF (Windows Presentation Foundation), the popular user interface framework by Microsoft.
Something that I noticed quite quickly is how expensive it can be to create WPF controls in code. It could take up to several milliseconds to create a new interface element – even simple ones. The interface I was working on had to be very flexible and could change often however, which would cause it to freeze for noticeable durations regularly, which is unacceptable.
The way I solved that problem is by using object pools.
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.
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.
Concurrency has always been a complicated aspect of computer science.
With modern hardware increasing not only in speed but also in parallelism, it has become necessary to use concurrency in applications to fully exploit available resources.
This is done using threads, which can be thought of as independently running sub-programs of a larger program, or process. Each thread has its own state – including its stack – and executes its own code, but stacks within the same process can generally share other resources at will.
With even the most simple applications being multi-threaded these days, games are no exception. As such, one can hardly find a modern game engine or framework that does not use parallelism in some form or another.
However, today I do not want to talk about how to move complex systems like physics simulation, AI, pathfinding, or even rendering to different threads – like many games do.
Instead I will look at a specific low-level problem:
Assuming we have a multi-threaded program, how can the different threads communicate, and specifically: how can we make sure that certain code is always run on certain threads.