• entries
    206
  • comments
    217
  • views
    224132

About this blog

Merry Prankster Games: Temple of the Abyssal Winds

Entries in this blog

gdunbar
In Part 1 I described and recommended Mercurial. In Part 2 I gave a quick primer on installing and setting up Mercurial. Here I make my recommendations for setting up your repository and using Mercurial.

(Quick aside: does anyone know how to link to past posts in the journal? The "link" button nicely gives a perma-link to an old post, but it contains "&#", which gets swallowed when I put it into a journal entry.)

OK, at this point, I've gotten Mercurial installed, and from doing the Tutorial I know the basic commands, or at least how to find the documentation. Next, I need to figure out how to store my code. Or, in source control speak, what repositories should I create?

The Mercurial documents suggest making a base repository, and then cloning that repository for each "feature" that I want to work on. Then, merge back these changes into the base repository as the features are completed. Perhaps this is sound advice for distributed teams, but for starting out, I recommend you just make a single repository for your source code. You'll get all of the source control/revision/history management, without having to worry about keeping multiple repositories sync'd, built, and all that.

Now, when using source control, I want to have all of my source code (.cpp files, etc) in source control. But I don't want to checkin any of my built stuff (.obj, .exe, etc). Afterall, I can rebuild that stuff anytime. And keeping track of every version of every object file is going to use up storage space in a hurry!

Further, I want _all_ of my source code to be in source control. If I add a new file, I want that file in Mercurial as well. Unfortunately, Mercurial doesn't automatically add files to source control if I put them in my repository directory (to be fair, neither does any other source control system I've used). So, to use Mercurial effectively, I recommend frequently running hg status. hg status lists non-checked in files in the repository; A for a file that has been added but not checked in, M for a file that has been changed and not checked in, and ? for a file that isn't under source control at all. My strategy is to type hg status often, and eliminate all of the ? files, either by deleting junk or using hg add to add the files to source control.

Unfortunately Visual Studio doesn't play great with this strategy; it wants to put all the generated files in the same directory as the source code. I can think of three reasonable solutions to this problem:

  1. Figure out how to make Visual Studio put generated files in another, parallel directory. Perhaps this is really easy, but I didn't bother to even try.

  2. Switch over to using makefiles; Visual Studio ships with nmake.exe which is a perfectly reasonable command-line building tool, and it should be pretty easy to configure this to put output files where-ever you want. In fact, I would strongly recommend this approach for multi-developer projects, because then you can run an automated nightly build easily. But I didn't bother because I am a one-man band.

  3. Put the Visual Studio project files outside of source control, but point the project at source code in source control. This was my choice because it is (more or less) the easiest.


A drawback of my strategy is that my project files aren't under source control. Luckily I keep my projects pretty simple, and reconstructing one would only take a few minutes. Still, if I ever really expected to do this, I would find some way to get them into source control.

The last recommendation I have is to get in the habit of checking in (hg commit) early and often. Every tiny little change you make, once it is (more or less) working, check it in. I generally check in changes about once a day. Maybe that seems like a lot, but Mercurial stores changes with diffs, so there isn't much storage cost, and I _love_ having all that history to look at. Backing out changes, or comparing new code to old code, to every building version of the code, is really nice.

So, in a nutshell, my recommendations for using Mercurial for a small dev project:

  • One repository for all of your source code.

  • Figure out some way to put your generated files (objects, libraries, executables) in some different path outside the repository.

  • hg status often to be sure you have all of your code under source control.

  • hg commit every change, from the major to the one-line bugfix.


OK, that's all about Mercurial. I'll find something else to blog about in the next edition of RPG Anvil.

gdunbar

Untitled SENG Project

If you've been paying attention to Merry Prankster Games http://www.prankster.com (and frankly, who hasn't?), you've seen that my last release was the demo game To The World Tree http://www.prankster.com/ttwt. So, what have I been up to since?

In the spring, I was doing consulting programming work on an unannounced project at my old employer, Microsoft http://www.microsoft.com. Since then, I've been hanging out with my kids and proceeding forward on making a full game.

My focus this summer has been on making progamming changes to the basic engine, based on feedback and experience with To The World Tree. The game isn't fully designed yet, so I'm proceeding under the name "Untitled SENG Project". (SENG is the name of my engine).

The first change was to eliminate the "infinitely thin" walls, instead lowering the tile size to 2.5 feet, and treating walls as a tile. This is a great simplification, and I think looks better too.

As an example, the old style looked something like this:


Old Walls


And, with preliminary, dev art, the new style looks something like this:


New Walls


More on the engine changes next time.
gdunbar
In Part 1 (https://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=503512&3287731) I discussed source control, and gave a recommendation for using Mercurial. Here I discuss setting up Mercurial.

The main Mercurial website is http://www.selenic.com/mercurial/wiki/index.cgi, and a precompiled Windows install is available at http://mercurial.berkwood.com/. Thankfully the Windows install is actually an install program, and properly sets things up, even adding Mercurial to the %path%.

At the conclusion of Mercurial setup, it pops up the readme (probably C:\Program Files\Mercurial\ReadMe.html), with a couple of final steps/suggestions to finalize configuration, and validate your Mercurial. Follow these through, with one exception. When using Mercurial in a multi-user setup, you need a merge program, to reconcile scenarios where there are multiple changes to the same file that conflict. However, I skipped this step since I am in a single-user setup, and I haven't had to do a merge yet.

There's one more configuration step you probably want to take, not mentioned in ReadMe.html. You'll want to configure the username that gets associated with your checkins. If nothing else, it makes things look neater. To do this, open a new text file %USERPROFILE%\Mercurial.ini, and add:
[ui]
username = Geoff Dunbar


If you are not a command-line user, you'll next want to install an add-on to integrate Mercurial with Explorer or Visual Studio. I prefer the command-line (at least for source code), so although I see that these add-ons exist, I didn't try any of them.

I went through the Tutorial next, http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial, which did a decent job of going over the basic commands. Other recommended documentation:



One other thing that you probably want to do, as a Windows/Visual Studio user, is to setup Mercurial to use windiff.exe for showing diffs between revisions, instead of the command-line diff that it uses by default. I didn't find any step-by-step directions for doing this; documentation for extending diff is here http://www.selenic.com/mercurial/wiki/index.cgi/ExtdiffExtension. Luckily windiff seems to fit right in without trouble, so here are the steps:

Edit mercurial.ini:

1) To the [extensions] section, add:
hgext.extdiff =

2) Add a new section:
[extdiff]
cmd.windiff = windiff


Also, make sure windiff.exe is in your %path% (for me "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\bin" is the path to windiff.exe).

Now, to see revisions displayed in windiff, run "hg windiff" (instead of "hg diff").

That's all for now; one more post on Mercurial to come, describing my choices for setting up my repository. (Repository definition: "place where code is stored in source control").
gdunbar
I'm starting a new blog "feature", "RPG Anvil", for discussion of topics related to the creation of a computer RPG, such as programming, design, writing, etc. Perhaps at some point I'll formally introduce what "RPG Anvil" is meant to accomplish, but for now I'm just going to dive right in.

Today's topic is Mercurial, specifically using Mercurial as source control for a one-man project, on Windows. "What is Mercurial?", you ask. Mercurial is one of the hot new "distributed" source control systems, favored by open-source projects.

But, I see some blank stares; as background let's start with source control. Source control is a system that stores and moderates access to source code; note that source code is a pretty broad term and can include art, documents, or whatever else you want. A good source control system will provide complete history (of all changes or revisions) for all of your code, will allow you to easily retrieve your source code from any particular time, and will provide services for multiple developers to modify the source code at the same time, usually with some sort of merge functionality. Traditional source control systems consist of a "server", which stores the master copy of the source code, and every developer on the project runs a "client", and enlists in some or all of the source code.

For any development project with multiple developers, a source control system is pretty much a must. It's even in the "Joel on Software" Test: http://www.joelonsoftware.com/articles/fog0000000043.html. However, working on large projects at Microsoft, I've grown to appreciate source control, and it's desirable even for a one-man project. Before now, my backup and history strategy has been to make a zip file of the source code every time I complete a milestone (every month or two). This is pretty effective, if crude, on the large scale, but with no granular change tracking, some things are just a pain. For instance, if a feature broke, but I didn't notice for a couple of weeks, there's no way I can go back and find which change broke the feature and why, and instead I'll have to spend more time figuring out the code again. OK, for those of you who haven't used source control, that may not sound like a big deal, but it is.

So, I've decided to run source control on my personal projects. The goals are:

  1. Provide granular history for all source code.

  2. Help prevent accidental loss of code.

  3. Provide some way to "tag" the code for a particular release so I can retrieve it (like the zip file).

  4. Perhaps most importantly, the source control system should not impose significant effort or resources to use. I'm just one guy, so if even a few scant percent of my time is spent futzing with source control, it's not worth it.



I'm used to the traditional source control systems; Microsoft uses something called "Source Depot", which people claim is a modified version of Perforce. It works pretty nicely, although as with all long-lived software systems some parts of it a pretty byzantine by now. Of course it scales madly; lots of people work on the Windows code!

So, I set out to find something like that. The current king of open-source source control systems is called Subversion; a guide for setting it up on Windows can be found here: http://www.codinghorror.com/blog/archives/001093.html It seems to be about what I expected; traditional, client/server as I'm used to. However, while reading the comments, I saw a lot of reference to the new distributed source control systems. Linux uses something called "Git", and other popular options include "Mercurial" and "Bazaar". Since one of the points of my private projects is to learn new things, I decided I would try one of these, if feasible. I probably already have a good idea of how things will work in Subversion, but how about "Git"?

After some brief "research" (does reading blog comments and scanning a couple of web pages really count as research?) I decided Mercurial was my best bet. Git is poorly supported on Windows, and more people seemed to recommend Mercurial than Bazaar. So, perhaps somewhat arbitrarily, that was my starting point. I'll get into some more details of how I'm using Mercurial in a following post. For now, the main Mercurial website is http://www.selenic.com/mercurial/wiki/index.cgi, with various links giving information how to install on Windows.

Now, I haven't been using Mercurial for a long time yet, so I can't comment on its reliability or stability. But otherwise, I can definitely recommend it for a one-man source control system. Some things that I like:

  1. Has all the source control basics in a set of simple, reasonably well documented commands.

  2. There is no need to run a server! The source code (and associated repository) sits in a directory on my file system, and when I need to perform a source control action, I run a command-line tool. Since I'm not sharing my code with anyone, there is no need to have any persistent code running.

  3. By using good practices, it's actually quite easy to make sure that all code is under source-control, which can be a bugaboo for one-man operations.

  4. The "master copy" of the source code is just my source code, same as before. Mercurial stores all of its revision information off in a separate directory.


The "no server" operation is really cool for my purposes. Typical source control systems will need to have a "server" (which might just be a service on the same machine), with it's own copy of the source code and revision information. But with Mercurial, this is completely unnecessary. In fact, even for multi-developer projects, you can operate without a server, though it makes sharing more of a manual process (you have distribute your Mercurial revisions via email or something of the sort). Mercurial supports this system well... at least in theory. Without any other developers on my project, I haven't had occasion to try it out.

My complaints thus far would be:

  1. In a manner typical of open-source projects, you sometimes have to dig around in different web-sites and different places to find all of the information you need, particularly for the Windows version. In fact there appear to be different installs of Windows Mercurial, though the first one I tried worked fine.

  2. There are various (sometimes contradictory) suggestions for organizing your repository. I think I've found something that works for me, but best practices, especially for interaction with Visual Studio, are not clear at first glance.

  3. I'm very much comfortable with command-line source control. There are solutions for Explorer or Visual Studio, but they are separate downloads, and I didn't try them at all.


If you're a one-man project, running on Windows, I'd definitely recommend using Mercurial to store all of your source code. After just a couple of hours of ramp-up, you'll be developing like normal, with very little overhead, but all the benefits of source control. I'll make another post later about some practices for setting up, using, and managing your Mercurial installation.
gdunbar
Welcome to the Merry Prankster Games Blog. GameDev.net is my latest attempt to run an ongoing blog to chronicle my development efforts.

Introduction: I'm Geoff Dunbar, a long-time computer programmer with occasional indie-game flurries of interest. Merry Prankster Games (http://www.prankster.com) is my one-man indie development effort, specializing in single-player RPGs (at least lately). My most recent game (demo, really), was "To The World Tree" (http://www.prankster.com/ttwt), a mediocre entry in the Independent Games Festival. More recently, I've been working on updates to the TTWT engine, with the intention of making a full game at some point.

My goals for this blog are two-fold. To detail my progress on Merry Prankster Games development projects, for the people interested in the nitty-gritty progress on our games. Second, to discuss interesting aspects of game development that I run into in the course of my projects, for fellow indie developers and other interested parties. I will update the blog at least weekly, on one or other of these topics.

So, welcome again, and I hope you enjoy reading!
gdunbar
Welcome to the Merry Prankster Games Blog. GameDev.net is my latest attempt to run an ongoing blog to chronicle my development efforts.

Introduction: I'm Geoff Dunbar, a long-time computer programmer with occasional indie-game flurries of interest. Merry Prankster Games (http://www.prankster.com) is my one-man indie development effort, specializing in single-player RPGs (at least lately). My most recent game (demo, really), was "To The World Tree" (http://www.prankster.com/ttwt), a mediocre entry in the Independent Games Festival. More recently, I've been working on updates to the TTWT engine, with the intention of making a full game at some point.

My goals for this blog are two-fold. To detail my progress on Merry Prankster Games development projects, for the people interested in the nitty-gritty progress on our games. Second, to discuss interesting aspects of game development that I run into in the course of my projects, for fellow indie developers and other interested parties. I will update the blog at least weekly, on one or other of these topics.

So, welcome again, and I hope you enjoy reading!