Component / Entity Systems

Note: I’ve put this work on hold and am going another direction with this project. The C++ code is found in the ogre branch. I’ll have a new post about what I’m putting together soon!

If you’ve done any sort of game development in the past 5 years you’ve most likely heard of “Component Systems” or “Entity Systems” for doing object and scene management over an OOP hierarchy. Object Hierarchies may start out clean, but over the course of the development of a game, become a very difficult to work with. Components — very succinctly built self-contained clusters of data and logic that can be added to, or taken away from, anything — are the answer.

There is a ton written about these kinds of systems. A quick Google search of either of the terms in the title will get you to many of the most popular posts describing the why of Component systems, so I’m not going to dive into that myself. Instead, this post will be explaining how I’m implementing Components in Project Slartibartfast, why I’ve made the decisions I’ve made, and how I plan on continuing development with this system.

As an avid supporter of Open Source software, it’s been annoying reading so much about this radically different methodology and find very little code, or code examples that don’t solve the issue I’m trying to solve, concerning Components. Now that I’ve sat down and actually turned an idea in a working system, I realize that these systems really do end up being very specific in their implementation to the product at hand, be it a game, an engine, or something not game related at all. So this isn’t per-say a “this is how you implement Components and Entities” but an exposé of how I’ve decided to implement this in my game.

As an aside, because these arguments come up so often, my personal view of software development and design is that pragmatism beats idealism every single time. As long as you have a good reason for your decisions, build something that works, don’t fret that it’s not a “best practice.”

That said, lets dive into the Component system of Project Slartibartfast.

Read the rest of this entry »

Game design lessons learned from World of Warcraft – Part 3: PvP and PvE

So I’ll be honest. I’ve had a huge rant building up for some time now on how Blizzard has royally screwed up WoW, and continues to do so, because they have a flawed look at how to balance PvP and PvE gameplay together.

I’m not going to write it because frankly, I’d never want to read it. So I’ve condensed my point into three simple words:

BALANCE

PVP

FIRST

You simply cannot have a PvE game and add PvP on top of it. PvP is player skill, PvE is just numbers. One could go to the extreme and say that they can’t co-exist, but I’m not quite convinced this is true. Close, but not quite.

Game design lessons learned from World of Warcraft – Part 2

While Part 1 touched on abstract decisions affecting game design (and admittedly turned into a rant by the end, I’m kind of bad at that), part 2 here will focus on a few of Blizzard’s design decisions for WoW that we can learn from, and in Part 3 I’m going to touch on my ideas and observations on the game’s PvP and PvE.

Now of course I can’t list, or even think about, most of the design decisions that have helped towards making WoW the massive success that it is, but there are a few decisions, both good and bad, that have hit close to home for me, decisions that I have to work with or around every time I play. Were I to be on the WoW dev team, these are some of the things I’d be recommending.

Read the rest of this entry »

Game design lessons learned from World of Warcraft – Part 1

Given that I love gaming, and I love programming, it’s only natural that I put the two together. Now while I haven’t yet gotten deeply into game development and design, I have become acutely aware of design decisions made in the games that I play, and I like to take mental notes of what works, and what doesn’t. I also spend a lot of time watching game-related news and lurk the GameDev forums to keep up-to-date on the latest game development trends and advances.

I figured, now that I’ve got a blog, it’s time to start taking more permanent notes on the design decisions, both good and bad, of the various games I play. To start, I’m going to pick on the 800lb Gorilla in the room, World of Warcraft (known here on out as WoW). This is the first of what will be a multi-part series of articles, as I tend to delve in to rants and ramblings at time. However, I will try to keep it all coherent. So, without further ado…

Read the rest of this entry »