Skip to content

It’s Been a While

I can’t help but notice that my last post was all the way back in March… half a year ago. I’d rather not go into detail as to the reasons, so suffice it to say that the last 6 months have not been kind to me. Blogging—and even game development—were on the low end of my priority list. However, I’ve finally started making games again, so I figure that I’d better revive this blog, too.

I’m still working on the “Towers” project I mentioned in my last post, but I’m rewriting it from the ground up. The prototypes I built before were promising, but I was starting to hate a lot of the underlying architectural and design decisions. While this does mean that I’m throwing out a lot of work, the lessons the prototypes taught me (both in terms of programming and game design) are valuable in and of themselves. In this post, I’d like to go over some of those lessons, as well as why I felt I needed to discard a lot of the preceding work.

To recap the high concept, the Towers project is centered around the idea of competitive tower construction, with players having to balance building towards a goal with sabotaging their competition. The intended experience is a frantic, strategic game in which players are struggling to keep their unstable towers upright.

This is a pretty vague concept, admittedly. This is why I’ve already gone through a couple prototypes, and intend to go through more to nail down how the game should look, play, and feel.

Prototype #1

The first prototype approached this concept pretty literally. Each player had a junkyard from which they could grab building blocks, and then they would arrange and weld them together to climb higher than their opponent. Some of these blocks were structural, while others were weapons that could be fired periodically at the enemy to deal damage to their tower. As these towers got higher and higher, they would wobble back and forth, and the loss of a structural support (or even a heavy impact on the tower to knock it over) became a more pressing concern.

There was a lot of stuff going for it. Playing with the physics to build a tower is satisfying, and it’s even more fun to knock them down and blast big holes in the sides. However, there were some big problems. The building method was awkward and unwieldy, not really lending itself to quick placement of blocks. The player had to rotate and place each component manually, overlapping them to weld them. This made actually building the tower a frustrating, unwieldy experience when the tower was taking damage, moving around, etc… and since building towers is a central part of gameplay, this was unacceptable. Another problem was that the weapons needed to be fired manually, and this became a babysitting task that took away from the building process even more.

Prototype #2

I made some rather drastic changes to try and address these problems. The original “drag, rotate, and weld” method of building construction was replaced with something more akin to the building method of World of Goo: the player would click near existing parts of his structure, and if there were resources available for building a new “node” was added to the structure and linked with existing nodes. This was a big improvement, because you could rapidly construct and repair your structures even under fire from your opponent, and because the wobbly World of Goo style structures play very nicely with the physics engine and are satisfying to watch.

The weapon systems were also overhauled. Instead of drawing weapons from a resource pool as before, there were “depot” nodes scattered in the environment. Building up to them would allow you to claim them, and once claimed they would generate a powerup on a regular basis. That powerup could be dragged to an existing node to transform it into a weapon. This is great, since it ties building more closely into the combat aspect of the game, and provides a more interesting reason to build upwards. I also removed the manual firing of the previous prototype; weapons would now fire automatically, as they reloaded. The player would only control their orientation, which could be set on the fly. This way, the player could focus more on building and less on babysitting their arsenal.

There were still problems with this design, however. While making the weapons fire on their own helped the babysitting issue, manually orienting the weapons meant that it was still a factor whenever aiming needed to be done… and with both the player and their opponent’s towers swaying around, breaking, and otherwise not staying still, this was distressingly often. The same problem was occuring with the powerup upgrade mechanic, in that players would need to watch the depots and drag the powerups out as soon as they appeared in order to not give up the valuable resources.

Going Forward

My plan to address these issues is to take a page from the tower defense genre. In tower defense games the player will usually have a single pool of resources to draw from which they can use to build or upgrade defensive towers. Similarly, I want the player in my game to have a finite, renewable resource (for brevity’s sake we’ll call it “metal”) which they can use to upgrade nodes in their tower for specialized functions. Further upgrades can be done later on those nodes to transform these specialized nodes into even better versions of themselves, for a price.

This is a better mechanic for upgrades, I feel. The resource it relies upon has no cost for not being immediately exploited, as metal can accumulate in a way that the powerups could not, and the interface is cleaner, with the user only needing to interact with the node in question and not some potentially distant depot. It also makes it much, much easier to add variety into the arsenal, and I have a whole array of potentially crazy ideas on how to take advantage of that flexibility.

I also plan to take another cue from the tower defense games in that the player will have no interactions with the weapons once they’re deployed, as they aim and fire automatically. If the previous prototypes have shown anything, it’s that babysitting an ever-growing arsenal is a lot less fun than building and repairing a teetering tower.

The depot mechanic of the previous prototype is not something that I want to lose in this transition, since it ties the combat and building components of the game together so elegantly. The depots, then, should be changed so that they now increase the regeneration rate of a player’s metal supply. Once can also thing of multiple kinds of depots… maybe they provide different resource types that allow for specialty upgrades, or provide “victory points” that decide the outcome of a match. This is something I’ll be experimenting with.

The Engine

I won’t spend a whole lot of time on this, but as I mentioned earlier architectural decisions in the game engine were a significant factor in me doing a rewrite. The biggest change was moving from a traditional hierarchy of game objects to a component based model. Basically, instead of using inheritance to share functionality between game objects (e.g. a TowerNode object is a type of PhysicalObject is a type of GameObject) I use composition (a game object is just a collection of different components, which together define the behaviour).

I’ve found that this is much better for prototyping, and saves a whole lot of code duplication. I can create a new object by pulling together a whole bunch of existing components. For instance, a tower node might have components for a sprite, physical simulation, object ownership by players, and HP. A new “money generator” node could be just as easily created by adding a “give the owner money every second” script to that same collection of components.

The downside is that collaboration between components is not as straightforward as it would be in a more monolithic class. It requires some extra thought as to how game logic should be implemented. Preferably, one wouldn’t create a new component for every object type, since that defeats the purpose… the challenge is to find a way to combine existing, generalized components to get the desired game logic, or, if that is insufficient, then at least to make the new components required general enough to be reusable.

The whole thing has been a hell of a learning experience, and I hope to be able to post more about it soon!

Posted in Game Design, Game Development.

1 comment

By Ian Morrison – September 25, 2011

Game Design is Hard!

As I mentioned in my last post, I’m working on a new game project. The game is built around the idea of competitive tower building: two or more players construct freestanding structures out of basic components, attempting to meet a goal (for instance, achieving height) before the other player, while using special pieces (rocket launchers, lasers, etc) to stick a wrench in the works for the other guy. The vision I have is of a frantic, chaotic, and often silly competition as two players try their damnedest to kick the other’s tower out from beneath them while simultaneously trying to keep their increasingly wobbly and unstable structure standing upright.

I’m currently in the prototyping stage, and trying to figure out what the details of the design should be. There have been a few thorny technical challenges (not the least of which was figuring out why the multiplayer wasn’t working) but the biggest outstanding issues are design ones. While the concept has a lot of promise, it’s been difficult to nail down exactly where the fun is. My first attempt has been lacking in that regard. That’s not a bad thing—this is why we build prototypes!—but it does mean I’ve got a lot of work ahead of me.

Here’s what my first attempt has looked like:

TowersPrototype1

 

Continued…

Posted in Uncategorized.

3 comments

By Ian Morrison – March 23, 2011

What’s this? A blog? When did I start writing a… oh, right. That blog.

September 7th, 2010. That’s the last time I posted anything to this site. I’ve got a few half baked articles sitting around that I started but never finished, but even those were from late last year. Ah, school, you can be such an effective distraction.

But, enough! Enough shenanigans! Enough delays! There shall be posts! I actually enjoy writing these articles a fair bit, and on the rare instance that someone actually finds my inane babbling useful it’s incredibly rewarding.

At any rate, I’ve got a couple new projects in the works.

Continued…

Posted in Uncategorized.

2 comments

By Ian Morrison – March 9, 2011

The Rationality of Irrationality in Galcon

One of my favourite games is Galcon by Phil Hassey, an incredibly simple little strategy game that’s grown in popularity and been ported to a ridiculous number of platforms. What I love about it is that despite the simplicity of its mechanics, the game has an incredible amount of strategic depth by virtue of the human element.

 

For those unfamiliar with the game, the setup is very straightforward. You own planets, the size of which determine the number of ships they produce each second. You can’t see the number of ships on an enemy planet, but can usually guess from their production rate and their troop movements. Ships accumulate on planets, and can be sent to other planets. When they reach a friendly planet, they’re added to the local reserves. When they reach an enemy planet, they sacrifice themselves at a 1:1 ratio with enemy ships until there are no more opposing vessels, at which point you own the planet (and its production). Neutral planets spawn at the start of the game with ships on them, but do not produce new ships until a player takes them out. The objective is to be the only person with planets at the end of the game.

Thats it. There’s nothing else, no unit types, planet types, and few subtle nuances. It’s the simplest computer strategy game I’ve ever played. Yet that simplicity can translate into a lot of strategic and tactical depth in a multiplayer game. While a 1vs1 is generally speaking just a contest of math, reflexes, and calculated gambles, Galcon really begins to shine in free for alls with 3 players or more. Mind games, bluffing, backstabbing, and guessing the intentions of other players are the skills brought to the forefront. In other words, it’s a game so simple that the majority of the gameplay can be derived from the human elements instead of the mechanics themselves.

The best gameplay emerges when players have the mindset of rational, self-interested parties who are looking for the big prize: to be the last man standing. While this can often turn to a stalemate situation (being the first one to move in a four way stalemate can result in you being torn apart by the guy opposite from the one you’re attacking) there are a lot of mind games, fake-outs, and alliances of questionable authenticity. When irrational players enter the game, sometimes the results are game-breaking (for instance, out-of-game alliances between friends, or a grudge held between matches that results in another player rushing someone at match start to grief them, sacrificing their own chances to screw that player over). However, in most cases, they just play into the hands of the people who can recognize their irrational behaviour. If someone is holding on to ground that they’d be better off ceding to a bigger power, both them and the person attacking them will suffer losses that you can exploit. Likewise, if they lock themselves into a conflict with the second strongest player the big guy just sits back and waits for them both to exhaust themselves. An irrational player can taken advantage of by taking advantage of what is usually a fairly predictable mindset.

Yet there’s an interesting interplay, in which an otherwise rational player might engage in seemingly irrational behaviour by design. A common survival technique when you’re the small player in the scene (and therefore, anyone with half a mind could take you out wholesale) is to bunker down and make yourself too costly to take by massing up troops and ensuring not to waste them on attacks that won’t pay themselves back. The intent, ostensibly, is to defend their small territory to the death. Yet, if an attack comes, defending that ground to the last man will result in your force obliterated as well as losing your planets, ending the game. You would expect that a rational player, therefore, would be bluffing in this instance, and if a sufficiently large attack comes, they’ll simply give up their planets and run away to preserve their fleets. Their posturing is a non-credible threat. Indeed, this is often the case, and players faced with overwhelming force or an alliance of enemies will often retreat.

Yet you’ll also find experienced players digging in, meeting every attack, and ceding no ground… even going on the offensive against a superior foe once attacked! New players often do this simply out of stubbornness and loss aversion, but experienced players are instead employing suicidal behaviour intentionally. Why in the world would a rational player employ behaviour that will likely cost them the game?

Well, it’s not so insane as it first appears. If a player digs in under a sustained attack, other parties will be watching and waiting on the wings. They know that taking your worlds will weaken the aggressor, and will be eager to capitalize on it. This is even more true if the defender takes the fight to the enemy and starts cutting into their least defended planets, forcing the aggressor to fight fires when his forces are out of position, usually resulting in a massive over-correction. It’s a calculated gamble… will the other players intervene soon enough that I can come out ahead, or will I have taken too much damage (or even been destroyed) by the time they sense the opportunity? There is a small, albiet significant chance that an aggressive defensive posture can pay off.

Sometimes it works, and you can end up with a large production base and still have most of your army. Sometimes it doesn’t. Like I said, it’s a gamble.

Yet, another part of this is the metagame. Galcon matches are rarely played in isolation… instead, they’re often played in sequence against the same players, due to the length of a typical match. Making a suicidal play might cost you this game, but in future games your opponents will be more wary about attempting to take your worlds, fearing that the losses incurred gaining your worlds will make them vulnerable. It sends a message to your opponents: you might be able to overwhelm me, but I’ll be sure to take you with me if I can. Likewise, fleeing at the first sign of overwhelming force might be a good move this game, but your opponents will take note of that behaviour and play more aggressively to take advantage of it.

This is why I love Galcon. It’s a game that is not about its mechanics, but about its players.

Posted in Games.

No comments

By Ian Morrison – September 7, 2010

Weekly Development Update #6

This is gonna be a short one. I didn’t do much development this week at all, but the work that I did do on Friday was very satisfying. The camera, movement systems, and user interface systems are all implemented, bringing the project to feature parity with the pre-Ogre version!

I’m finding that putting development off until late at night is a terrible, terrible idea. By then I’m often tired, distracted, or otherwise preoccupied, and the work simply does not get done. The main reason I’ve been putting it off that long is because I try to work “normal” hours at my day job. However, since I work from home and control my schedule, I think I’m going to search for a time slot that works better, earlier in the day. Given that my job is ending soon and school starting, a time block that fits with my class work is best. With luck, it’ll be easier to motivate myself to work when I’m lucid enough that I’m not ready to collapse!

Posted in Game Development, SPX.

No comments

By Ian Morrison – August 29, 2010

Weekly Development Update #5

This one is going to have some holes in it, but this was ultimately a good week. Lessons learned, progress made, etc and so forth. Without further ado:

Wednesday August 18th

First time this week I’ve had a chance to work on SPX, but I FINALLY fixed my issue… turns out that I was creating my ogre window and updating it in different threads, which screws things up. I also got my precompiled headers set up, DRASTICALLY shortening compile times. I am a happy man.

Friday August 20th

Didn’t get into any code today, but I am working on a detailed development plan that I can follow for the next week or so. I’ve been thrown off track by work commitments and that godawful bug I was struggling with, but now it’s time to get moving again. My main priorities, going forward, will be to rewrite the rendering, input, and camera systems, in that order, to achieve feature parity with what I had before the engine port. Afterwards, I’ll begin focusing on making a game prototype.

Saturday August 21st

Started trying to implement graphics. Most of my time was spent on the architecture for managing graphics assets. Nothing to show… yet.

Sunday August 22nd

Eureka! Finally have something to show! Temporary ship graphics, and everything is working again!

Okay, so apparently I’m an idiot.

In the process of switching to Ogre, I made a few game architecture changes without testing them in order to adapt to Ogre’s way of doing things. All this time, I was assuming that the actual game was still intact under everything, but between getting the client and server threaded and altering how the frame-to-frame updates were being done, I cocked everything up. The server was quitting because the client thread hadn’t had time to start running yet, and none of the game objects were updating because the change to the updating cycle meant that the "currentFrameTime" wasn’t being calculated anymore. Both of these were one-line fixes, but I spent a huge amount of time trying to figure out if I screwed up the game OR screw up on the Ogre port, when I could have focused on tracking these bugs down.

Lesson learned: in any large overhaul, do whatever changes you can without breaking the system FIRST so that they can be tested, THEN start breaking things.

At any rate, I can start moving on to other aspects of the port. Once input and camera control are back in, it’s over and done with, and I’ll be able to start working on turning it into an actual game!

Posted in Game Development, SPX.

No comments

By Ian Morrison – August 22, 2010

Weekly Development Update #4

Time for another weekly update, but I’m not going to go with a day-by-day breakdown, since I’ve been struggling with the same issue all week. My window is being tagged by the OS as “not responding”, despite the frame function and the windows message pump being called regularly. I’ve posted to the Ogre3d boards in hope of help, and messed around on my own attempting to isolate the cause, but I can’t see anything in my code that differs from the Ogre test app I wrote except that the update loop is now in its own boost::thread.

I’m going a little bonkers, but them’s the risks when you start programmin’.

Posted in Game Development, SPX.

No comments

By Ian Morrison – August 16, 2010

Weekly Development Update #3

I was much better about keeping logs this week. Starting to get into the daily development habit, and about damned time.

 

Monday August 2nd

Started delving into Ogre tutorials. At least on a basic level, the library appears very straightforward. It’ll be interesting to see how complex it is to work with in the end.

Tuesday August 3rd

I think I’ve got enough of a handle on Ogre to really begin porting SPX over in earnest. I’ll start by splitting off a branch in the repository, as a precaution.

The major sticking points in the port are going to be changing the game to wait for frame and input callbacks, switching from SFML’s Vector2f to Ogre3D’s Vector2 (which, hopefully, will just be a rename + removing the helper functions I needed to write to make SFML’s Vector2f class usable), rewriting the camera system, and rewriting the graphics code. It’s fortunate that none of these tasks seem too herculean on their own, but it’s going to be a while before the game is back in fighting form, as it were.

There’s also the issue of the file structure of the project, which the necessary Ogre files will need to fit into. I’m only including DLLs, libraries, and includes, so that’s fairly straightforward, but I suspect I’ll need to juggle it a bit until it’s something I’m happy with. It’s a good opportunity to rethink the file structure, though, so I’ll make the most of it.

Wednesday August 4th

While it was inevitable that a port of several thousand lines of code to a new graphics engine would cause snags (the act of ripping out SFML and replacing with Ogre has left me with 164 errors and no functioning program) I’m finding more issues than I anticipated (which–in a line of reasoning doomed to go in circles like a merry-go-round—is exactly what I anticipated).

For starters, Ogre3D redefines all the STL containers into the Ogre namespace as structures with the original STL templates as members, which is something that I find utterly mystifying, since it isn’t even retaining their interface. The lines "using namespace Ogre" and "using namespace std" results in a lot of ambiguous symbols that the compiler feels obliged to choke and die on. I can’t think of any reason why this would be done, save driving me nutty, so if anyone can enlighten me that would be appreciated!

At any rate, it’s high time I got rid of the using namespace calls anyways, they’re bad form, and there’s only a few places where the extra characters are more painful than the potential errors… those can be dealt with using typedefs to get rid of the namespace.

By the end of the day I’ve gotten to the point where there are no compiler errors. I had to gut all the graphics code, and there isn’t a WORKING piece of software, but it’s a good position to begin Ogre implementation.

Thursday August 5th

Unexpectedly, the switch to Ogre has necessitated a change in the main() function. I previously ran two separate GameManager classes on the same machine in a serial fashion, but the way Ogre handles frames (hit go, wait until it returns instead of hit go, then run an update loop) means that I needed to put each of those classes in their own thread. This was the eventual plan anyhow, so it’s hardly wasted effort, but it did require me to do some research. I had to learn the boost::thread library, but it’s a fairly straightforward piece of software and I’d been meaning to learn it anyways. Hopefully the process of threading won’t bite me in the ass.

Friday August 6th

Finished off the Ogre initialization code… kinda. Crashes when OIS (Ogre’s Input System) loads, need to find the source of THAT error. Haven’t been able to figure out if the threading works as designed yet.

Saturday August 7th

I’ve got a window rendering, and the threads all seem to be cooperating. It’s now a matter of getting basic functionality back into the game so that I can move forward from there. However, the program currently crashes with OpenGL, so that’s a point of concern. However, since I can run with DirectX, it’ll do for now.

Sunday August 8th

Basic input functionality is in. Mouse moves around, application quits when you hit escape. Not perfectly happy with the mouse behaviour… it’s locked to the window, so you can’t click anything outside it, so that will need fixing. I’m also running into strange issues where it won’t receive mouse inputs if I run it without the debugger active, but it WILL if I do, so I’m going to need to dig into Visual Studio and figure out exactly what changes when debug mode is on… the configuration hasn’t changed, so it’s executing the same code.

I did, however, spend much of the day struggling with an error caused by erroneously linking to the debug dlls in the release build. Talk about a dumb mistake… lesson learned: doublecheck that release AND debug builds are both properly set up!

 

That’s it for this week. If anyone is actually reading these, it’d be great to know if the format and content of these logs are at all interesting. Let me know in the comments!

Posted in Game Development, Game Systems, SPX.

No comments

By Ian Morrison – August 9, 2010

Weekly Development Update #2

Slightly delayed, because I am easily distracted by Starcraft 2 and shiney new graphics libraries.

What I’ve found this week is that I haven’t been very studious in terms of keeping this habit. There are extenuating circumstances, but it’s best not to use those as an excuse. Going forward, I need to make daily work more consistent.

Continued…

Posted in Game Design, Game Development, SPX.

No comments

By Ian Morrison – August 2, 2010

Weekly Development Update #1

One of the problems with hobbyist game development in your spare time is that it’s easy to become distracted. There’s no shortage of other tasks that need doing, or ways to find excuses to avoid a piece of tedious development. It’s not uncommon to suspend development for weeks or months at a time if enough is going on to serve as a rationalization.

This doesn’t serve my purposes. Every day I spend not working on game development is another day delay on me doing it professionally. It’s imperative to be working every day, to make it habit.

As such, I’ve resolved that I’ll do the following:

  1. I will make one commit to the source repository each day.
  2. I will keep a log of my progress and design decisions, and post it on a weekly basis.

“One commit a day” is a nice metric to use. It gives me a lot of flexibility as to the size of the commit, but it’s also very easy to measure and very clear as to what I need to make a daily habit: I have to make progress—any progress—on my code daily. Because the metric is clear, it’s very easy to turn into a habit. The weekly update is a little harder to make a habit of (this first one is already a little late), but is nice as a way of making me keep good logs of my work… and giving me content to post on this blog!

Yeah, I’ve been bad about that lately, haven’t I?

At any rate, I figure I should start by outlining the project I’m working with at the moment. The project is using the temporary name “SPX”, an acronym I can’t even recall. It’s completely utilitarian in the sense that it’s meant to be convenient to refer to but not something I might get attached to. The basic concept of the game itself is a 2D, multiplayer top down strategy game set in space revolving around a single large capital ship, its weapon systems and its fighter craft. The specific details are completely up in the air, since the actual kind of gameplay that will be involved is going to be fully explored only once a working prototype is available to tweak, but it will involve huge, heavily armed vessels blasting holes in each other with space-age weaponry.

On the technical side, the game is using SFML for graphics, input, and sound, and RakNet for network functionality. SFML is a library that I was unfamiliar with, but which looked full-featured enough, and RakNet is something I’ve worked with before (and found to my liking). Both libraries are free to use and multiplatform, which are useful aspects to have!

But enough about that, on to the logs.

Continued…

Posted in Game Design, Game Development, SPX.

4 comments

By Ian Morrison – July 25, 2010