In Windows (like every operating system), when you’re writing an application or game there are certain things that your application is responsible for handling: some of them are easy, some of them take a little bit more effort. On his excellent blog, Microsoft’s Raymond Chen calls these responsibilities “Taxes”, and there are good reasons why
Virtually all programs have this, a central ‘game’ loop that grabs user input, updates game logic, redraws the screen. At it’s simplest possible level, it usually looks something like this: repeat Input; Update; Redraw; until Quit; The problem mainly comes in that middle section, Update. For any game, there are a variety of different states
Last time, we looked at the inheritance style of object-oriented programming in detail. Now let’s look at the alternative: composition. We’ll use another example from Icefall to illustrate the differences. Icefall has a central ‘world view’ that shows the player and their immediate surroundings (items, monsters, terrain, etc). The world view also shows animations (e.g.
Last time, we talked about two different approaches to designing objects for a game or application: Inheritance and Composition. It’s time to look at the pros and cons in more detail. Let’s start with inheritance. Inheritance When learning OOP, inheritance is what you learn! Create a common, generic ancestor-type class, and create new classes for
Like almost everything else these days, Icefall is designed around object-oriented programming (OOP) principles. Specifically, Icefall uses Classes instead of objects, although the difference is not relevant for this discussion. At any given time, the game will be operating dozens of different classes and hundreds of instances of those classes, with the majority of them