Continuing my series of posts on LINQ today we will take a look at another four methods:
Over the last few weeks I have been writing about the basics of LINQ, and how we can use it to organize collections of items.
Today I would like to take a look at a special class of LINQ methods: those returning single elements or values, instead of an entire collection.
I my recent posts introducing LINQ from a game developers point of view, I mentioned several times how the many LINQ methods returning sequences of the
IEnumerable<T> type do not actually return an actual collection.
Instead they return a query that can be executed any number of time on the given input collection.
Of course, there comes a point at which we need to store the results of such queries as regular collections. Today we will talk about how LINQ supports this almost trivially.
Last week I introduced LINQ from the perspective of a C# game developer completely unfamiliar with the framework. Today I would like to continue exploration of LINQ by focussing on a particular set of its functionality: methods to arrange and organize data.
In particular we will look into how we can sort and group our collections of items.
I was recently asked for some pointers on how to get started with LINQ – and to maybe write a post about that. Using LINQ virtually every day I have to admit that it had not occurred to me that a C# programmer may not be familiar with it.
LINQ is a big topic, but this post is the first in a series to introduce the framework and its many uses – all from a game developer’s point of view.
Last time we talked about how we can approximate objects with complex shapes using simpler ones for our game’s physics simulation.
Further, we saw how we can use an often already existing feature: a skeleton for animating sprites – or vertices of a 3d-mesh – to make our collision shapes change position, and even size, as our object deforms.
Today I want to look at how knowing about the behaviour of CPUs – and especially their caches and memory – we can use simple optimisations to implement collisions with such objects very efficiently.
There is hardly a single game that does not need some form of collision between game objects. In many cases it is enough to approximate the shape of an object by a simpler one to simplify and speed up collision detection. It is for example very common – especially in 2D games – to use circles or boxes as colliding shapes.
Today I want to talk about how we can make use of collision code written for simple shapes like circles, and still end up with much more complex collision behaviour.
Today we will take a look at a common task in game development: parsing asset files – from a code design standpoint.
Using the example of Wavefront OBJ files, we will explore the usefulness of thinking about our code using design patterns.
Our goal will not be to use design patterns to create code. Instead, I would like to highlight how much of our code is full of such patterns – whether we think about them or not – and how realising this can help us communicate more efficiently with other programmers.
In this third instalment of Twitter-powered reminiscence we will continue discussing more and more of the different systems I developed for Roche Fusion in the last few months of the game’s development.
We will focus mostly on their technical and graphical aspects, since that is my area of expertise, and the purpose of this series of posts.
We will do so from a technical point of view, exploring some of the various systems I developed for the game. With my role as team-lead and graphics programmer, this mostly means that we will mostly be looking at graphical effects.