This article was a follow up to the article Logic over Time in which I described why new language features, such as coroutines, can help game programmers write more readable and robust state machines. In it, I talk in more details about the specifics of my implementation of coroutines and its advantages and uses beyond state machines themselves. Specifically, I talk about concurrency and synchronization.
Read the rest of this article on Gamasutra
Source code on Github
I gave this talk at ECGC 2016.
In this session, I took attendees on a tour of C#, as seen from the perspective of a senior developer with years of professional C++ experience. Looking at several specific examples, they learned what makes C# attractive for game development, despite its often-cited drawbacks. From performance and productivity considerations to a broader exploration of the languages' affordances, the audience got a fresh look at both C# and C++, and at how much the language you use affects your ability to do your job as a programmer.
The session was intended primarily for professional C++ programmers who have been either curious, or critical, of C#, but was also valuable for intermediate C# programmers, who got a chance to broaden their understanding of the language.
Slides are available here.
I have been working on games for many years now, and I have written things ranging from simple gameplay and AI logic to complex navigation systems, animation graphs and behavior trees!
One of the things that I have struggled with repeatedly over the years is always the same simple problem: managing the behavior of entities over time.
At its heart, the task is very straightforward: I need an entity to perform one or more actions over multiple frames, and to have some smarts about what it is doing in the process. This could be, for instance, a PowerUp that needs to flash every second until the player picks it up, or a Monster that has to react to the player entering a given radius. In short, most of your day-to-day game logic or simple AI.
Game programmers write this kind of code so frequently that we don’t really give the task a second thought. We even have a well established way of approaching the problem: a State Machine.
And the problem isn't with states machines themselves - they are the right tool for the job - the problem is with how we actually write them.
Read the rest of this article on Gamasutra
