Sinister Soups Serving Musings On Game Development and Play


Mousing in Diablo 2: An Analysis

Having played some Diablo 2 again a bit ago (as evidenced by my last post, wherein I describe the process I had to go through to get the game running), I started thinking carefully about the design in that game with regard to targeting and attacking.

Since it's a 10-year-old game, I was reminded of some of the many issues I have with the way the interface works in general, and some of the highly questionable decisions they made, in my opinion, just to try to make sure that the game was vaguely playable with nothing more than a two-button mouse, even though every computer has a keyboard.

Still, this post isn't really about that, and rather than complain about questionable UI, I'm going to quickly discuss the way the two mouse buttons target enemies, and activate the skills mapped to them, because I think there are some interesting decisions there.

The left and right mouse buttons are the only method of activating abilities in Diablo 2, and the appropriate LMB or RMB hotkeys must be changed to the skill you want to use, before clicking that button to cast it.

The left mouse button is limited to melee and ranged projectile skills, and passive abilities or abilities that target a specific location or area of the screen are not allowed.

The left mouse button is also intended as the primary method of navigating the world, and clicking on empty space with the LMB results in the player character moving in the direction of the cursor. The character continues to move as long as the button is held, and will navigate around objects or enemies in its way without interacting with them.

It's important to note that this is the functionality of the LMB regardless of the skill that has been bound to that button, and even if a projectile skill (such as Ice Bolt) is bound to the left button, it will not be fired if the player clicks on empty space. In order to actually use a skill bound to the LMB, the player must click directly on an enemy, at which point he may hold the button down to stay locked onto that target and repeatedly use the LMB-bound skill on it.

The other way to use the skill bound to the LMB is by holding the Shift key, which forces the character to stand in place and attack. In the case of a projectile attack, holding shift causes the character to shoot projectiles in the direction of the cursor without moving; while in the case of a melee attack, the character will swing its weapon in place without moving, and will lock onto any target that moves within range of that attack, but will not pursue the enemy if it moves away as long as Shift is held.

The right mouse button is both more complicated and more interesting. For one thing, it is the only way to cast passive spells on the player character, such as buffs or auras, and it's the only way to cast spells onto specific areas of the screen, such as Fire Wall, or even Teleport.

Furthermore, since the right mouse button is not intended to be the primary method of moving around, it treats projectile skills as though Shift were held down. In other words, projectile skills bound to the RMB will cause the character to stand still and cast whenever the RMB is clicked, even if Shift is not being held.

Melee skills have an even more interesting functionality when bound to the RMB.

If an enemy is clicked directly with a melee skill bound to RMB, it becomes a locked target as long as the button is held, and the character chases it around, performing the melee move repeatedly until the target is dead, which is identical to the LMB in functionality. If, however, a melee attack is bound to th RMB but the player clicks and holds in empty space, rather than directly on an enemy, the character will navigate in the direction of the cursor, just like with the LMB, but instead of avoiding enemies, it will lock on to the first one it runs into, and perform the bound melee attack onto this new target until it is dead.

The variable ways in which these two mouse clicks are treated is interesting, especially because at first glance the two buttons seen interchangeable if one has not played Diablo 2 before. These subtleties of design reveal that the left mouse button is meant to be treated more as the "moving around" button, while the right mouse button becomes the "utility and attack" button.

The design also makes clear that Diablo 2 has a concrete implementation of a player's current target, at least as long as the mouse button is held down, which is what make it possible for the "move and lock on" functionality of melee skills on the RMB to work, and for players to simply hold the mouse button down to keep attacking, rather than having to click for every attack on the same enemy.

I think the way the game utilizes the right mouse button in particular is quite clever, especially because I think the "move and lock on" functionality could be adapted quite well to a console controller. Basically, different face buttons would be bound to different skills, and if one of these buttons was held while the player moved with the left stick, the character would lock on to any nearby enemy and start repeating the bound skill.

Action RPGs, and indeed, action games in general tend to emphasize button mashing on the console. However, even a game as old as Diablo figured out that having to constantly click while fighting off waves of enemies is annoying, and instead made it so that mouse inputs were held, and clicks were merely used to select new targets. I could see going this route for a console action RPG, trying to draw the focus of gameplay to strategic skill use, instead of making the player spam a button just to accomplish anything.

Filed under: Game Design No Comments

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

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.


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

Embedded Gaming

That's a game up there. I mean an actual, playable version of the Secret of Monkey Island, embedded directly into the blog.

You can click on the Play Demo button and start playing this classic point and click adventure right now, no need to download anything, no need to install anything, and no need to interrupt your browsing.

Apparently this company, InstantAction, is going to allow you to embed games in HTML just as easily you can currently embed YouTube videos.

Of course, I don't know how practical this sort of thing will really be. I imagine you won't see hardware-intensive games being embedded any time soon, but in the meantime, it's a neat little look into one possible future of online distribution.

So give it a whirl, see what you think. It's Monkey Island after all, you really can't go wrong with Monkey Island.

Filed under: Games No Comments


What is X-Com? Until last week, X-Com was a fantastic little PC turn-based tactical game. A game which let you build up a fancy base, while researching cool technology, and recruiting soldiers. A game where, with your base fully operational, you could send out squads of guys to shoot down UFOs, investigate crash sites, and fight the alien menace.

X-COM: UFO Defense

X-Com is dear to many PC gamers and turn-based game fans, and seeing as I happen to be both of those, it’s a game dear to me, as well. The great mix of genres, the chance to do so many cool things in a single game, and the deep and satisfying turn-based combat are what define X-Com, what make it such a special game.

So hearing, last week, that the X-Com license is being used to make a First Person Shooter did not exactly elicit an enthusiastic response from most X-Com fans, myself included.

Don’t get me wrong, I’m sure it’ll be a decent game. It’s being made by the same people who made Bioshock 2, after all. But do we really need another First Person Shooter on the market? Do we really need to convert a property near and dear to many a gamer’s heart into a genre as far removed from its roots as is physically possible?

The most disheartening thing about all this is probably how eager the online games press is to play this off as a good thing. I realize it’s not in their interest to be skeptical about new game announcements, that it’s better for them to be optimistic about everything the publishers toss their way, but it’s doesn’t make it any less depressing to see them fail to question these sorts of decisions on behalf of the longtime fans, who do not have as public a voice.

The Kotaku article on the subject is a perfect example. They quote the new game’s press release, filled with appropriate buzzwords like “high-stake odds” and “strategic gambits” and then proceed to conclude that “the strategic stuff is still in” and therefore “it’s the first-person stuff that has people angry.”

It’s silliness, old-school X-Com fans aren’t going to be appeased by promises of “strategic depth” from PR material for a game that switched genre from a strategy game to a shooter, and the author shows a profound intellectual dishonesty in proclaiming that the first person perspective is the biggest problem fans will have with the game, rather than, you know, the fact that it’s now a shooter.

Unfortunately, this sort of coverage is pretty much par for the course, though there is some more balanced coverage out there. A PC-focused site like Rock, Paper, Shotgun, for instance, took this opportunity to write a couple of insightful and personal pieces about what X-Com meant to them, and what it means to the many fans of the old games.

Further silver lining comes in the form of extra exposure for indie projects that are apparently trying to fill the X-Com shaped hole in our hearts. Since little hope remains of another turn-based tactical game bearing the X-Com name, these indie efforts have the potential to define the future of the hybrid-semi-genre.

The first such promising project is Xenonauts, currently in development by a small indie studio. It looks like it will be released commercially, and their site shows some very polished concept art as well as design ideas about different aspects of the game. Since it's still in fairly early stages, I recommend keeping an eye on their site if you are interested.

The Geoscape in Xenonauts. Looking good!

The other major project I’ve seen come out of the woodwork with the FPS announcement is UFO: Alien Invasion, an open source X-Com clone or remake based on the Quake 2 engine. Though I just found out about this project, it’s been in the works for quite a while now, is still updating on a regular basis, and looks to be quite mature, not to mention free!

A UFO crashsite in the open source UFO: Alien Invasion

I haven’t tried it out myself yet, but I plan to give UFO: AI a whirl soon. It even supports multiplayer, including cooperative control of one team, or two teams facing off! Maybe I can con a friend into trying it with me, after all, a multiplayer, cooperative X-Com sounds about as close to heaven as I dare imagine.

Filed under: Games No Comments

Direct vs. Derived Statistics in RPGs

In the RPG space, there are generally two ways to handle character attributes or statistics.

Each stat is used and modified directly.

The first, simpler solution defines a set of stats that a character needs for the mechanics of the game to work, and then exposes them directly, allowing items, spells, level gains, and other modifiers to explicitly raise and lower these stats as necessary. Japanese RPGs tend to go this route, with simple stats like Attack and Magic, which are then directly modified by improved weapons or accessories. I will refer to this method of managing character stats as a Direct Stats system in this post.

Damage is derived from Power which is derived from Strength and Agility.

The second common solution, and more popular in western RPGs, is a system of primary attributes like Strength and Dexterity, which are often directly customizable as a part of the leveling process, but which generally do not affect game mechanics directly. Instead, these primary attributes control derived stats like Attack Power or Critical Chance, which are used directly in game mechanics, and which are calculated from the primary attributes according to some formula, which can vary depending on the character class. For example, in WoW, the Attack Power derived stat raises damage from physical attacks and is derived entirely from the Strength attribute for most classes, while Rogues instead use both Strength and Dexterity to compute it. I will refer to this method of managing character stats as a Derived Stats system in this post.

The benefits of a Direct Stats system are simplicity and understandability. As long as a player understands a stat's basic function, it is fairly easy for him to figure out how important it is to his character, and consequently, what items and abilities to concentrate on. If he wants to make a character that is exceptional at killing things by hitting them with a hammer, and knows that the Attack stat directly affects weapon damage, he knows to prioritize Attack over other stats.

A Derived Stats system, on the other and, can be a lot less understandable, since it tends to be cluttered with a large number of stats, some of which seem to represent similar concepts (Strength vs. Power?) and explaining the relationships between them is no small challenge. This is exacerbated when primary attributes are treated differently by different classes, meaning that even if a player learns how a stat works for one class, they may be in trouble when they try another.

The downside of a Direct Stats system is that with such clearly defined stats being the only defining characteristics of a character, it can be harder to differentiate characters. For instance, it is likely that all physically oriented characters will need the Attack stat, despite the fact that they are meant to have different flavors and different powers. With such a clear-cut set of stats, it's hard to put the stats to use in creative ways that still makes sense. Sure you could make a class that loses Attack instead of HP when it is hurt, for instance, but a lot of people are going to complain that such a weird mechanic ruins their immersion.

This is where a Derived Stats system can really shine, you can add a lot of variety to the mechanics governing your classes when you choose to derive stats differently for Rogues than Warriors, for instance. Furthermore, having both derived and primary stats available means that you can bind certain abilities or class features in unexpected ways, sometimes using a primary attribute for an attack, for instance, and primary attributes also work well for role-playing scenarios outside of combat.

The Right Tool For The Job

As is often the case with this kind of thing, neither of these two approaches to character development is necessarily better than the other, instead, there are specific situations where one may be more useful than the other.

The Direct Stats system most commonly shows up in Japanese RPGs which have simplified and distilled the systems they learned from early western computer RPGs like Wizardry and Ultima. Those games, on the other hand, adapted their mechanics from pen and paper RPGs, specifically Dungeons & Dragons, which through four editions has kept and refined the quintessential Derived Stats system of Strength, Dexterity, Constitution, Wisdom, Intelligence, and Charisma.

The origins of these two systems are not a coincidence, and considering them, we can quickly come up with some conclusions about the types of games best served by each system.

Derived Stats are often the best fit for games that share a lot of similarities with pen and paper RPGs. Games where the player only controls one character, for instance, can have complicated derived stat arrangements because the player will only have to master that one character's class to be effective, without having to worry how another class works. Such a system is especially important in a multiplayer game like WoW, where players often have to work together and share the loot they find. Since even classes with similar functions, like Rogues and Warriors again, need different primary attributes to grow their derived stats, you can easily create loot that is more useful to one than the other, reducing conflict over who should get an item.

A Derived Stats system is also a great fit for games which, like pen and paper RPGs, offer a lot of gameplay outside of pure combat scenarios, since the variety of available stats, all important to different types of characters, and all with specific flavors (my character is very Wise!) can be used in conversations with NPCs, in quests, or generally to advance the plot.

The Direct Stats system can be equally valuable, however, and it is often the best choice in games where the player must control or manage a large number of characters. Imagine that you have a roster of 20 characters, each has a slightly different class, and each class derives its relevant stats slightly differently. Do you want to have to remember exactly how each one of those classes uses the Strength attribute every time you need to decide who to give a sword with +Strength on it?

Similarly, a game with a heavy focus on combat, where battle is the primary gameplay mechanic and 90% of your time is spent fighting something is probably better served by a Direct Stats system. This is particularly true if the combat in question is highly strategic, and requires a lot of meaningful choices from the player at every turn. In a game like this, information is one of the most important resources at the player's disposal, and being able to clearly present information about the player's characters, so that it is always clear exactly what a stat does, and how the character will be affected if that stat is buffed or debuffed, can make the game a lot more satisfying and enjoyable.

So there you have it, each of these two systems has their uses, and the key is to consider what kind of game you want to make, and what you want the player's experience with the game to be like.

The next time you are playing an RPG, gentle reader, consider how the designers chose to represent your characters' attributes. Chances are there are good reasons they chose the system they did, and you can learn quite a bit by considering what those reasons might be.

Filed under: Game Design No Comments

Star-Crafting A Fun Online Experience

You realize that this is nowhere near enough pylons, right?

It should come as no surprise that Starcraft 2 will include a matchmaking system as its default method of starting multiplayer games. Blizzard went that route with Warcraft 3, to ensure that players could find good challenges for their teams and be ranked on fair matchups, as is necessary when you have a ladder system to support.

While the system in Warcraft 3 was good for its time, it could also be said that it had its flaws, chief among them its propensity for matching you with people who would proceed to curb stomp you.

At least, as a rather mediocre RTS player, that was my experience with the thing, and judging by the Penny Arcade strip linked above, I wasn't alone.

Luckily, Blizzard seems to be working to ensure that Starcraft 2 doesn't have the same problems. I had already heard that it would have different ladders for different skill levels, so that the more casual fans of RTS, like myself, might actually have a chance to compete with others on their level. Now, a recent article at the Escapist reveals some other steps they are taking to address problems with skill mismatches.

Their first major improvement is limiting each copy of the game to creating a single account, rather than allowing unlimited accounts like their former games. The reason this is important is because there is a certain breed of griefer who likes nothing more than to stomp on newbie players, a practice apparently called "smurfing," which they can only do by creating new accounts with no win history. If they tried this with an experienced account, the game's matchmaking would never match them with the a newbie player, since it tries to match very closely based on skill.

Handily, by limiting you to a single account, you can't go around creating what are essentially griefer or troll accounts, whose sole purpose is to ruin other peoples' experience. It also integrates nicely with Blizzard's recent update to a single-account Battle.netsystem, which now integrates WoW accounts as well, and will definitely be required for future Blizzard products.

The other thing mentioned in the above article, is that they are considering adding some slack to their matchmaking. Apparently, right now, the matchmaking in Starcraft 2 is too accurate, to the point that players are pretty much always matched on an even level. While this is fair, it leads to poor pacing for someone playing a night of Starcraft 2. Every game they play is a breathless, tooth and nail fight, and it doesn't allow the more relaxed play one might get playing a more novice opponent, nor the extreme challenge of facing a better player, which many people swear by as a means of improvement.

Ultimately, I think Blizzard is on the right track here. Exceptional matchmaking, combined with limited accounts to ensure honest skill levels means that both great players, and the really terrible ones (like, again, myself) can have good, exciting games without undue frustration, and I can definitely see the benefits of a slight random component to ensure a more interesting gaming session.

If I were them, I would actually consider going a step further than pure randomness, and think about how they can craft the sort of pacing they want. Since they seem to already be thinking in terms of a series of consecutive games, a session if you will, it wouldn't be too hard to start coming up with heuristic rules to give players the sort of experience that they desire, or alternately, that Blizzard wants them to have.

For example, if a player loses a couple of games in a row, maybe the system adapts to give them a few easier matchups, to give them some breathing space and a chance to try to apply what they might have learned from their defeats against a less demanding opponent. If they are willing to give players this kind of control, they could even allow you to choose from a preset difficulty, or "experience" that they'd like to have that night. Maybe I choose the Relaxed experience, and am only matched with opponents who are my level or lower, while another player wants a Meat Grinder, to hone his skills or just wrack his brains, and is therefore matched only with people of significantly higher level.

Of course, I'm sure Blizzard is already thinking about these sorts of things, and there are challenges there, such as making sure that someone who wants an easy experience is only matched with players who want a hard one, or you just get the same sort of griefing play this whole thing tries to avoid. Still, it'll be interesting to see what lessons Blizzard pulls from the current closed beta, and how the online RTS landscape will change when Starcraft 2 is released.

Filed under: Game Design, Games 2 Comments

Source Control For The Hobbyist Developer

I've been working on an XNA game project with some friends in my free time, and as any professional developer knows, it's much more difficult to coordinate changes to a programming project without some sort of source control solution. While we did without in the beginning, it came to be too much of a hassle, and last night I finally set up source control repository for us. I was thinking that it might be helpful to others, and to myself for future reference, to outline the solution I ended up using, and how I set it up.

Firstly, what is source control? Source control is a way to let multiple people edit the same resources, whether that's documents or source code, without their edits stomping on each other. While there are different ways to accomplish this, the method my friends and I are used to involves checking out files from a central repository, editing them independently, and then checking them back into the repository. If multiple people check out the same file, then the first to check changes in can do so freely, while everyone who checks in after that needs to first correct any conflicts their checkins might have with that first person's changes.

Ultimately, for our home work, we wanted a system with a decent GUI, that was simple to use, and worked more or less how we were used to. Since there are a lot of sites out there that will host repositories using the Subversion (or SVN) source control system, and there is a popular shell integration application called TortoiseSVN which allows you to work with SVN without using the command line, this was the system we ended up going with.

The first thing you need to decide if you want to use TortoiseSVN is whether you want to have a local repository on your computer, which you can use to track your own changes to a project you are working on, but which you can't easily give other people access to, or if you want to have the repository stored on a server so that team members on multiple computers can all access and edit it easily.

In our case, the latter was the only logical choice, a local repository only makes sense if you are the only one working on a project, so we looked for a service site that would let us host a repository easily. We ended up going with XP-Dev, a service we chose because it allows free hosting of up to two SVN repositories with 200 MBs of space available, and also gives you a lot of rather nice tools as part of your account to make project management easier, tools like forums, a wiki, a blog, and bug and task tracking.

There are very many different hosting sites like this, however, so you may be able to find one that gives you even more space for free, if you need it, and they all offer subscription options as well that give you more space and unlock more powerful features.

Once you have an account set up, you will be able to create a repository for your project, and you should get a URL that you can use to access your repository. On XP-Dev, the repository URL looks something like this:

At this point, you are ready to install TortoiseSVN; you can get the installer at their download page. While it is installing, consider where you want your project to reside on your computer, you will need a directory that you designate as the root of your repository, so that Tortoise can download a copy of the repository there for you to edit and then check back into the repository on the server. In my case, I wanted to make sure the repository was obvious and easy to find, so I created a directory called D:\SVN\Projectname.

Once you have your directory ready, and Tortoise successfully installed (you will need to restart Windows for the shell integration to work correctly), you can then start setting up your repository. Assuming your repository on the server is empty at this point, move whatever folders you are going to be managing to your SVN\Projectname folder, right-click on the SVN\Projectname folder and select the TortoiseSVN --> Import option.

Import option, with equally relevant SVN Checkout option above it...

You will be prompted for the URL of the repository, which you should have gotten from your hosting service, and when you click OK, for your credentials to access that repository. Assuming there are no hiccups with your credentials, it should then upload the contents of your SVN\Projectname folder to the repository on the server, and the first revision of your project will be up and running!

While this put the files you want into your repository, it doesn't actually register that this directory is a local copy of the repository, and so you won't be able to use Tortoise to check in file and folder changes yet. To do this, you must now right-click on the SVN\Projectname folder, and select the SVN Checkout option, which will download the files back from the repository, and mark them as local copies that you can edit, and later commit to merge them back into the repository.

Once you have done this, you should see the folders in the SVN\Projectname folder with little green check-mark icons on top of them, indicating that they are fully up to date. If you edit any of these files or folders, the icon will change to a red stop sign, and when clicking on any file or folder in the repository directory structure, you will be able to use the SVN Update command to sync up to the newest version of the repository, and the SVN Commit command to check in any changes you have made.

SVN Update and SVN Commit commands available once you have checked out the repository.

A few other useful tips for working with Tortoise and SVN in general:

  • Since Tortoise is a shell extension, all of its functionality can be accessed through the right-click menu in Explorer. There are many nice options here to help you manage your files and your repository.
  • When you go to commit your changes, you will be given a list of files that will be added with your check in, as well as any modified files. You can double-click on any of the files in this list to see the difference between them and make any changes.
  • If the list of files that will be added on a commit includes files built as part of the project, binaries or obj files you don't actually want cluttering up your repository, you can simply right-click these files in the list and choose to ignore entire directories or specific file extensions. Those files and folders will not be uploaded to the repository, and will not show up in subsequent commits.
  • TortoiseSVN has a very nice manual available in the docs section of their website. The manual not only covers Tortoise itself, but also has some good info about SVN and best practices for setting up your repositories and how to use it on a daily basis.

Hopefully, this has been helpful to anyone out there looking for a quick and easy explanation of how to set up source control for a personal project. It seems to be working out pretty nicely for our team, and I wish you good luck in your own endeavors!


Am I Dreaming?

A heavy, complex RPG? Set in space? With fleet battles, a big focus on ship customization, and the chance to develop and manage ship crews?

Surely this cannot be? Surely such a game could not exist, let along be out right now on the Nintendo DS? Such a thing simply doesn't happen, dreams like this do not come true!

Hopefully I don't wake up before Amazon ships my order...

Filed under: Games No Comments