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.
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.
The observant under the readers will probably have noticed the missing post of last week. Since I am planning on getting my master’s degree very soon, I have been working in setting a few things into motion, and together with several deadlines, they kept me from writing a new post. To make up, I will give a bit of an update of some personal projects, and next week I will be back with a full post.
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.
I am currently participating in the Ludum Dare. The theme for this weekend is unconventional weapon. Below you can find my day one builds. Feel free to leave me feedback however you can.
- Web (unsupported in Chrome by default, enable NPAPI plugins as workaround)
- WebGL (seems to be broken by Unity compiler, feel free to try)
- Mac OSX
And if you don’t want to download playable versions, feel free to look at these gifs:
The goal of the game is to nudge satellites to hit enemies. Right now there is no generation of satellites or enemies left, so I guess you can only play around with the ones that are there (click the city with the mouse to fire a skyscraper). Right now the biggest problem I am dealing with is getting the gameplay to be fun. It is a bit annoying to actually hit the satellite and hitting an enemy seems to be very impossible.
I am considering changing the controls so the player can just hold the mouse button on a satellite and then drag in the direction they want to push it. Then having a skyscraper launch to make that happen might be a bit annoying, but it makes the gameplay a lot easier and playable. If you have any ideas about how to make it work, please let me know.
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.
I have made several improvements to the blog section of my website. While the visual changes are minimal, the blog pages are now primarily rendered by WordPress itself. This makes drafting and previewing posts easier, and also makes the code a bit less obtuse.
With these changes I am also hoping to introduce a regular schedule. I will be posting a new blog entry every other week on Friday, starting with my post from yesterday. In the other weeks, I will usually be posting on the Roche Fusion dev log instead.
It is now possible to follow my blogposts by using the feed in your favourite feed manager, or you can follow me on Twitter (@tomrijnbeek) where I will also be announcing my blogs in addition to thoughts and images on whatever I am working on or thinking about at the time.
(Almost) no Steam game comes without achievements these days. Achievements are a way to challenge the player in different, sometimes unconventional, ways. Roche Fusion wasn’t any different. For Roche Fusion I wrote a framework to manage achievement in a way that would not be too intrusive in the rest of the code. In this post – loosely based on a dev log I wrote for Roche Fusion – I will explain this framework, and go into some implementation details as well.
A while ago I wrote about the research I was doing on narrative engagement in games. While I finished the research project, I have no yet had the opportunity to write about the results of the research.
Maybe you have heard me talking about it, maybe you want to know what that title even means, or maybe it just sounds interesting and are keen to hear more about it. Either way, as I promised I would do a small write-up about the research project I am currently working on.