Sinister Soups Serving Musings On Game Development and Play

29May/100

Getting Diablo 2 Working Under Dual-Core Vista x64

Getting a game as old as Diablo 2 to behave on a modern PC can be quite the chore; something I rediscovered today when my buddy and I got a hankering to play it again. Fortunately, I managed to get it working, so I figured I'd document my steps in case someone else runs into the problem and happens to find this, or, more likely, I forget how I got it working and need a place to look the next time the desire to play this game manifests itself.

The problem I encountered was one of massive framerate drops on a pretty regular basis. Not only was the framerate pretty poor to begin with, but it seemed to periodically encounter particularly long frames, drop to near nothing, and then quickly catch back up again, causing everything to zoom by at a stupid-high speed.

Ultimately I found that the only thing that fixed the problem was setting the game to run using DirectDraw rather than Direct3D in the Video Test application that installs itself with Diablo 2.

Diablo 2 Shortcut Compatibility Settings

Unfortunately, changing to DirectDraw caused the game to fail to load; it would just sit there after running the executable, without the game actually even opening a window, though I could see its process in Task Manager.

Ultimately, I was able to get the game to launch and run just fine using DirectDraw by setting the compatibility settings shown to the right on its shortcut.

I'm not sure if they're all necessary, and it may not even be necessary to run the game as Administrator, but since these settings worked out for me without any problems, they're what I'm sticking with for the time being.

I'm not sure why Diablo 2 chokes so stupendously when you try to run it in Direct3D mode. Perhaps the game tries to use some features of old Direct3D drivers so archaic and deprecated that modern hardware chokes and dies on it.

Alternately, it's possible that modern GPU optimizations for multi-core computers like mine cause synchronization issues on these old games that cause the kind of craziness I was seeing. I know my nVidia driver control panel has an option for "Threaded Optimization" that might not be playing nice with Diablo 2's expectations.

In any case, DirectDraw worked for me, and if you're having trouble getting Diablo 2 to run on a modern PC, I hope this helped you out in some way.

Filed under: Games No Comments
25May/101

Objects, Components, and Entities, Oh My!

A new post at last, and it’s that rarest of rare beasts, a programming post!

I’ve been reading and thinking about game system architecture lately. What I mean, specifically, is how objects and actors that take part in a game are represented in code, and what the relationships (in code) between them are like.

The traditional approach follows the Object Oriented programming model of a class hierarchy, where everything is represented by an object containing both data and functions, so that an Orc has both a Size value and an EatPeasant() function bundled up inside it. Furthermore, rather than writing each object from scratch, inheritance is used so that a tree of objects emerges, where specific actors like Orcs inherit much of their data and functionality from object higher up in the tree.

For example, an Orc may inherit its Size from a Monster class, as well as Position, which Monster in turn inherits from MovableObject, which inherits it from GameObject.

This is the naïve OOP approach to managing the actors in a game, and it is almost certainly the wrong approach, at least for a game of any appreciable size or complexity. Don’t get me wrong, it’s an intuitive way to set things up, especially for programmers with experience in other fields, and it can work very well for a small game where the hierarchy can be kept under control and doesn’t grow to massive, unmanageable proportions.

But there are better ways to do things, ways that are much cleaner once you have hundreds of different types of objects in your game, ways that are ultimately just as intuitive once you get used to them.

This is what I’ve been reading about, and pondering, in recent days: component-based architectures and entity systems for representing and managing the actors in your game. While I explain the concepts involved below, if you're really interested in the subject I recommend Mick West's article on the subject, which is very well written and goes into considerable detail.

At its most basic, a component-based architecture eschews a complex object hierarchy in favor of every actor in the game being a collection of components that define what that actor is, and what that actor does. Each actor then, apart from perhaps having some extremely common data such as an identifier, holds a list of components like PhysicsComponent, InputControllable, IsMonster, or whatever else is necessary to define all the operations that the actor can undergo.

These components then hold the relevant data and functions that define the actor, while centralized game systems either iterate over the actors, or even hold their own references to the individual actors’ components, and are able to do whatever updating or rendering the component requires every frame.

The benefits to this kind of setup are many. For one thing, instead of having perhaps hundreds of separate inherited objects, each necessitating its own class with all the upkeep that this entails, actors are simply the sum of their components, and any time a new component is written by a programmer, it can not only very easily be used to create new actors, but can also be trivially added to actors that already exist, giving them new functionality.

This means that with the proper tools, designers can easily redefine behavior on any actor simply by changing what components make up that actor, or tweaking the data that component manages; the only limitation is what components are available. Writing an individual component is also simpler and easier to test than modifying a fully realized, complex, working object that is being passed around throughout the game.

As an example, our Orc from before would be defined by the components that give it a size, and that allow it to eat peasants. If we then decide that Orcs should fly, we can give it a flying component, one which we might already be using for birds, or that we can subsequently use for whatever other actors we think should fly.

It also becomes trivially easy to make other Orc-like monsters, by simply swapping out a couple of components, or simply initializing the new monsters components with different data. For instance, a Goblin monster may be functionally identical to the Orc, but its SpriteComponent loads Goblin.jpg instead of Orc.jpg.

A component system within the confines of an object-oriented language like C++ or C# is all well and good, but what I found particularly interesting while reading on this subject was a method used by Adam Martin, to do away with the pesky and ill-fitting OOP paradigm entirely while designing this sort of component-based architecture.

Essentially, Adam proposes that the actors in a game (which he call entities, a common term that I have not used up until now specifically because he calls his method an Entity System) and their components should be approached using a database model.

Instead of even having an actor class which holds a list of component objects, he advocates divorcing the data and functionality of entities entirely from the traditional OOP model. An entity then becomes nothing more than a unique identifier, a number or a string, and components become packets of data needed by that entity.

Separate systems operate on the data in a component, for instance, a PhysicsSystem might take the data in a PhysicsComponent and use it modify the data in the entity’s PositionComponent, but components themselves merely hold data, not functionality.

The cool thing about this, though it took me a while to make sense of it, is that instead of passing around complex class-based objects in your code, you can simply hold onto an ID for the entity you want, and then essentially perform database-style queries to obtain any data you currently need from the components bound to that ID.

Not only do you get all the benefits of the popular and powerful component architecture, but you also keep your data separate from functionality which comes with a number of benefits; for example, it allows you to perform parallel operations easily on different entities (which are just sets of data) without breaking anything.

I feel like my thoughts about this database-like view of a component system are not yet fully formed, but I definitely feel like there is a powerful elegance to doing things this way. I will need to let the thoughts simmer some more before I have more to say about it, I think.

I recommend checking out Adam’s series of articles on the subject, linked above. It really is quite eye-opening.

16May/100

Red Dead Dastardliness

Red Dead Redemption wasn't really on my radar, and then, for some reason, people started telling me it should be. My only thoughts on the game were that I'd heard the original, Red Dead Revolver, was a pretty uninspired shooter.

Then today I saw this.

Note: I had originally tried embedding the video, but it would refuse to load when you hit play, and there is no YouTube version of the video because it was taken down by the publisher on copyright claim. That's a pretty rotten decision, this is the kind of awesomeness that helps sell a game.

Okay, so now I'm definitely going to have to get this game. Besides, a new Western-themed open-world game sounds like a good time, the only other such game I've played was Gun, and while that was fun, it was also a long time ago.

Filed under: Games No Comments
10May/100

The Silence Is Deafening

I know my update schedule has become erratic, and I haven't been posting on a regular basis, as I would like.

Some upheaval and turmoil at my job has led much of my free time to be consumed by job search related activity, updating my resume and the like, and I haven't been able to devote much time to the blog in recent weeks.

Rest assured that once things settle down a little, I plan to remedy this situation, and I do have a number of half-finished posts ready to go, as soon as I have the time to polish them up to standards.

Filed under: Notices No Comments