The first thing we needed for our distributed team-based development was a source code version management tool. As we mentioned previously, classic VCSes had a number of limitations we wanted to avoid, so we went with a Distributed Version Control System.
There are a large number of DVCSes available, however, we had a few specific requirements that had to be met.
- First, it had to have a strong support for Windows. Many DVCSes tend to focus on Linux and other Open Source OSes with their Window versions either non-existent or significantly limited compared to their Linux counterparts.
- Second, we needed it to integrate well with Windows proper. This means above and beyond just working on the command-line.
- Third, we needed it to provide us the option of having a central repository for convenience purposes (this is largely as a way to make sharing merge sets easier and to provide our non-developer testers a central place they can pull the code-base from).
is a popular DVCS that is quite powerful, however we found it to be difficult (and often irritating) to use. Additionally, the Windows support previously required installation of CYGWIN
, which we found caused problems in the XNA environment*.Bazaar
is another popular DVCS, however it is one which traditionally has had some serious
performance problems (thus, we've had some bad experiences with it :-) Additionally, Bazaar has some wonky ways of setting up central repositories that tend to require a lot more micromanagement than we wanted (we wanted to spend our time coding our game, not approving other people's bundles or dealing with giving testers temporary and limited shell access to the server hosting our repositories).
At the end of the day, we picked Mercurial
(or "Hg"). We already knew it was fast, powerful, and easy to use from our previous Linux development, but we soon discovered that the TortoiseHG
Windows-specific tool helped it integrate nicely into Windows.
In the above picture, you can see that TortoiseHg provides an extension to Windows Explorer, which gives you Hg GUI access from within your file explorer. This also makes Hg accessible from within Visual Studio, which utilizes the explorer, as you can see in the next screenshot.
And best of all, installing Mercurial/TortoiseHG is complete and total cake. Simply head on over to TortoiseHG's website
and download the installer. This installer provides TortoiseHG, Mercurial's command-line utility, and everything you need to get going.
In order to learn Mercurial, there are plenty of web-based tutorials and help pages online. A couple of good places to start are Mercurial's Tutorial section
and TortoiseHG's gentle introduction to using TortoiseHG on Windows
Using Hg with a Visual Studio XNA project
One "gotcha" with using Hg to host a repository that contains a Visual Studio XNA project is trying to determine what
files to add to the repository and what files to have Hg ignore. Visual Studio tends to fill your project tree with all manner of temporary build, debug, and binary files that you simply don't need to share among your team. Luckily, we can tell Hg to ignore these files so they don't accidentally get added to our repository (and then updated every time you run your game in debug mode, filling your repository changelog with useless changesets).
Inside the root (or top parent) directory of your XNA project's repository you can place a file called ".hgignore" which can be populated with a list of files, directories, or file globs that Hg should ignore. This file is one of the major reasons we recommend installing a command-line text editor like Nano as you probably wont be able to create a file called ".hgignore" in something like Notepad without an extension being added to the file (e.g., "hgignore.txt").
As for what to put in the file, there is a manual page
online which will help with the format, but you will have to know what files or globs will be Visual Studio cruft.
have used looks something like this:
# use glob syntax.
Where "SupaGame" is the name of the project. Feel free to copy this, change the project name to your project, and use it. If your project is not in a sub-directory (e.g., the project just starts in the top-level directory of the repository), then your .hgignore file may look more like this:
# use glob syntax.
One bit of warning however, we are not 100% certain this completely covers everything that we should have Hg ignore. This is what we've used for Duologue and our other work, however it may be overly aggressive or may be missing files that should be included in it. Also, with new versions of XNA and Visual Studio, this list may change.
[*] : Admittedly, when we tried this the only option available was CYGWIN and XNA was only at version 2.0. Apparently, Git now has a non-CYGWIN version. Also, XNA is up to version 3.1 at the time of this writing. So, who knows? Maybe now the conflict is gone.
Before we get down into the nitty gritty of the specific tools we've used at Funavision for distributed development, let's quickly run through some very useful and important items you will likely want.
Remember that our focus is on Indie game development using XNA under Windows.
If you are a Windows developer who refuses to use the command line, then it's probably because you've never used a real
command line :-) This is understandable since the traditional command line interface in windows... uh... sucks
. But never fear, there is something available that is absolutely amazing, and if you have it installed on your Windows box it will make your life using the DVCS tool we will be talking about so
much easier.Windows Powershell
is a neat little extensible command-line shell with an associated scripting language. It integrates well with .Net and provides an environment to perform administrative tasks by execution of cmdlets. By default in includes many cmdlets which actually grant you similar functionality as what you might find in a *nix shell (which may not mean much to some of you, but was a huge
deal to us :-)
The DVCS tool we will be talking about in the next section has a graphical user interface to it which provides most (if not all) of its functionality in a graphical way. However you will find that interfacing with it tends to be much
faster and with more control if you just use the command line interface inside of Powershell.
If you came here from the XNA forums then you probably
already have Visual Studio installed (and probably the XNA development environment). But, just in case you don't, we'll mention you should probably have it installed by now.
And that's all we have to say about it :-)
The final thing you might
want to install is some sort of command-line based text editor. You likely wont be needing this for any sort of code editing (unless you come from a *nix environment and prefer it), but it's nice to have it around as a command-line option for your code commit messages or for editing simple text files not managed by Visual Studio.
You are free to use whatever you're most comfortable with, but we personally would recommend GNU Nano
if you're new to command-line based editors as it's really very
easy to use. Some alternatives would be Vim
and MS-DOS Editor
Fortunately for the Indie developer, these problems have already been addressed by another community that is used to working in highly distributed ways. The Open Source* community.
Open what now?
Defining Open Source is well
beyond the scope of this article, however we can give some key bullet points that are relevant to the Indie developer.
- Open Source software is generally developed by large groups of developers working in extremely distributed and ardently uncoordinated ways (well, compared to traditional closed-source development- Open Source purists will argue that they actually develop in a more coordinated way, but it's ultimately all relative :-)
- Open Source software is generally developed with tools that not only strengthen the distributed development model but also reward developers who work with them in such a way.
- Open Source software typically winds up being gratis, or free as in "no cost". This means that you can use them without having to pay anyone.
- The Open Source development model is generally a meritocracy, which means that the "best" code typically percolates to the surface and you wind up with some very good software.
Open Source development is really a philosophy coupled with licensing and development models. As we said, a full explanation is well beyond this article. If you're curious and would like to know more about it, then we'd suggest Googling for the topic.
Distributed Version Control Software (or DVCS)Version control
in software development deals with tracking and managing changes to software project files over time. There are many
reasons and advantages for doing this, but the ones we're interested in are:
- Gaining the ability to rollback changes
- Gaining the ability to fork a project directory to develop a new branch (revision, version, whatever)
- Track the changes that various developers make to the project
Traditional Version Control System (VCS) choices include tools like CVS
. VCSes work on a client-server model where each developer runs a client that communicates their changes back to a server which holds the project. VCSes do work well in distributed development teams, however they have a number of important limitations:
- They require a central, canonical source code repository where the source code lives. This means that:
- You have a central point of failure
- If someone breaks the code in the central repository, it can easily break the code for everyone
- One developer can block the work of other developers by blocking/locking the central repository
- You can't work on the repository "offline" (you may be able to work on the code, but you can't do anything involving the repository)
- Complicated merges can block the central repository. This means that if two different developers try to commit code that results in a conflict, it can block the central repository until the conflict is resolved.
- VCSes require significant coordination between the distributed developers.
Because of these problems (and many others), a new type of version control system has recently gained popularity (especially in Open Source circles). It is called a "Distributed Version Control System" (DVCS**) and has a number of key differences over classical VCS:
- No central repository! Instead, each developer/user has a full-fledged repository for the project on their local disc. This gives you many benefits including:
- In a distributed project, no single point of failure!
- Developers can work 100% "offline". Sitting on an airplane with your laptop? No problem, you can work on your code, fork it, merge it, branch it, rollback changes, etc and so on without any sort of internet connection
- Merges become effectively peer-to-peer, which means that complicated merges will only adversely affect the people involved in the merge (no blocking the work of others)
- Repository changes are fast as they are effectively only working on the local repository
- Developers can work asynchronously
[*] : Technically, "Open Source" isn't a terribly descriptive term- in reality it's an umbrella term that describes many different licenses and development methodologies. For example, when most people talk about "Open Source Software", what they really are talking about is "Free Software" as the Free Software licenses tend to be the most widely used. There is a great deal of controversy when talking about "Free Software" and referring to it as "Open Source". I have intentionally glossed over this in my document simply because it is a complex and politically charged debate that isn't terribly important to my intended audience. Unfortunately, it is easier to explain what "Open Source" means to someone new to these concepts than it is to explain what "Free Software" means in this context. Personally, I find this distasteful as I am definitely of the "Free Software" mindset, but I long ago learned to just not fight it when I'm trying to get a tangential point across :-)[**] : Alright, more controversy I'm glossing over. Depending on who you ask and how you phrase your question, you will find a large number of different names for what I am calling DVCS (as well as what DVCS stands for). Personally, I prefer "Distributed Version Control System" and the "DVCS" acronym, so that's what I use in this document.
Before we begin, let's take a look at the problems that many Indie game developers face when they want to work in a team.
No central office
When you're working in a large and well funded organization chances are you are working from an office (or cubicle) with other fellow employees. This means that potential team development problems can be easily avoided by simply getting up from your desk, walking down the hall, and talking to someone else on your team. About to work on a particularly hairy bit of code that could break the build or block your fellow teammates? No problem, go and tell them what you're about to do!
In an Indie team, however, chances are you don't have a central office where everyone can be found. If you're anything like most
Indie teams, you're working in a distributed fashion- Each developer working at their desk in their home/apartment/condo/cardboard-box (hey, as long as you have wifi, right?)
, possibly in their underpants, potentially in different cities, states or even time zones. You probably don't hold regular office hours and may even have drastic work schedule differences between developers (maybe one is a night owl who works wonders after mid-night while another is an early bird who does more before noon than most people do all day).
These factors can lead to real problems when it comes to actually working together
in a team.
Working in isolation
This leads to one of the biggest problems people new to distributed team development typically struggle with. It becomes very
hard to effectively work in isolation. How do you handle code skewing (i.e., when two or more developers start wandering off working on different parts of the project) and merging the work of multiple code sources?
Tasks, issues, schedules, and general project management
The final problem is one of general project management. When a new issue or bug is found in the code, how do you handle it in this distributed team, and then how do you track progress on it? If something needs to get done in the code (a task), how do you keep track of not only who is working on it but how well they are proceeding on it?
I saw an interesting post over in the XNA Forums about team based development and I decided to share some of my experiences doing exactly that at Funavision. As I was writing my reply it dawned on me that this is probably a significant stumbling block for a lot of start-up Indie game developers. So I've decided to make this post and share my experience with a broader audience.
In this post I'll cover what we've done for distributed development over at Funavision as well as give some tips and tricks we've picked up that will help you out. The focus will be on Version Control and Project Management tools with a strong emphasis on free (as in no cost) and Open Source tools. It will also be heavily skewed towards XNA and Windows development (largely because if you're, say, a Linux developer then you likely know most of this stuff :-)
The post will be linked from the XNA Forums. Hopefully that will get it around enough people who need it that word of mouth can then take over and the people who could actually use this information will be able to find it.
I do want to say that what we did at Funavision is by no means the end-all, be-all solution for working in a distributed team-based way. There are many different ways to accomplish what we've done, and many different technologies and techniques that can be used (both open-source and proprietary). All I can say is that this is how we've done it, and it's worked very well for us. If you're someone lost and looking for some options, then you certainly could do a lot worse than what I'll be describing. However, if you already have something that is working well for you then I'm not suggesting you should ditch it and try the solutions described here. Each to their own.
Just wanted to make a quick post updating everyone on Duologue's status, as well as explain why I fail at this whole web-logging thing.
First of all, Duologue is still in peer review. If you're an XNA community member then please come on over and help us out. We seemed to be stalled at around 85%, and need something to push us over the limit :-)
Second of all, damn this XNA review process is opaque. Apparently what's holding us up is the fact that we released a bunch of alternate language descriptions of the game. That triggered some extended review being needed from non-English speakers, which is to be expected. What was un-expected (to me, at least) was that there's just not that many non-English reviewers out there and, apparently, some languages are spotty at best in terms of reviewers. Unfortunately, because all I have on the project page is a tiny progress meter I have no clue what's causing our hang-up and thus can't address it specifically. All I can do is beg and plead for more people to drop by and test, hoping that one or more of them will count toward whatever missing ingredient the murky soup that is the XNA review process is needing. Very frustrating.
I'm going to start writing now and then about games that I'm personally playing that I think you should know about. It's a bit narcissistic, I know, but then again, so is having a "blog" at a domain name which is your name.
In this maiden voyage of this series I'll talk a bit about the games that I have recently finished (some of them more than once), those that I am currently playing, and what I plan on playing next. We'll be getting off to a semi-poor start considering my 360 is currently on her journey back to the homeland for repairs, but I'll do my best to include her anyway.
So, without further delay, here are some of the games I've been playing...
FFFFFFFFFFFFFFUUUUUUUUU.... just got a RRoD. What is this.... number 5 for me? (numbers 4 and 3).
At least I got Duologue done before it happened. Well, in peer review at least- it's currently at ~30% and no one has reported any blocking issues, so here's hoping it's fine and we can just release it since development is going to be stalled on everything until I get my 360 back.
It's been a long and hard process, but I'm pleased to announce that Duologue has just entered the Xbox LIVE Indie Games peer review process! If you are a part of the XNA Community, then you can join in this peer review at Duologue's game page.
As an aside, I've finally sat down and found some Indie games to buy on Xbox Marketplace. I've been so busy working on my stuff that I haven't been able to give some love to my Indie brothers. Anyway, I'm going to be making a post one of these days with some gems that I've found that everyone else needs to try. Stay tuned...
In case you haven't noticed, I've emerged from my web-site slumber of several months and begun making posts again. This should become more frequent in the coming weeks.
The reason I've been ignoring the world of the blorg and the twits is because I've been ass-deep in development of my first commercial game, Duologue. The total development time has been roughly 9 months from start to finish (although, that's me including previous starts and stops of other projects that led to Duologue :-) It's been a long and arduous task but I am very close to being done (in fact, I should have a final beta and possible RC drop sometime this weekend). There's only one minor thing to wrap up (the "Buy me! Buy me!" annoyance screen for the trial mode, which is mostly finished at this point but which may need some revision) and then it's feature-complete and basically done aside from any further bugs we may find in it.
This means you can expect to start hearing more and more about the game in the coming week(s). I'll get the game's page done soonish which and upload some screenshots and videos of the game in action. Then, at some point in the future which I can't predict, the game will go Gold on Xbox LIVE Indie Games. When that happens you can be damned sure I'll post, tweet, and post again about it.
Anyway, stay tuned...
So I guess I'm messed up enough to qualify for some program at The Christian Sarkine Autism Treatment Center due to my Asperger's. The program is kind of cool and operates off of some grant which means my insurance isn't billed.
The funny thing is, every correspondance I get from these guys starts with:
To the parents of Sam Hart
I guess they don't get that many adults going into the program :-)
Just read a rather appalling thing at MSNBC:
Seven employees of a state-run home for the mentally disabled in Texas have been suspended for staging fights between residents
Wow... just... wow. Of course, if there was one state where I could imagine this happening, it would be Texas.
Anyway, there was apparently video of the entire thing, and I imagine it looked something like this:
I'm going to hell now, aren't I?
No words, just watch:
My ex-wife hated my beard. This was unfortunate for her because I had a beard for many years while we were married. I had a beard partly because shaving bothered my skin, and partly because I was at the U of A Physics Dept. and everyone had beards.
My current wife, Jessica, likes my beard. She likes me with long hair and a beard... has something to do with her attraction to hippies, I'm sure. However, now I've actually discovered a shaving method that doesn't aggravate my skin (I use a Merkur with shaving soap and a brush which only sometimes results in accidents), so I find I'm actually shaving more often than I used to (much to my wife's chagrin). I primarily stick to a Van Dyke (often incorrectly labeled a "goatee"), so I usually still have some facial hair. But every once in a while I get sick of it and shave it all off and start with a clean slate.
Well, today, I decided to play a little trick on my wife and see if I can find a facial hair type that even she wouldn't like. In the last few months I remember reading something about a "neckbeard", which is a beard so odious that it seems universally disliked.
Naturally, I had to have one.
(Read on for more)
Submitted for your approval, a completely incomprehensible series of websites which Google bombs fairly useless phrases, mixes strange allusions to Christianity with claims that the US Government is somehow criminalizing immortality, and plays bizarre music overlapping with other bizarre music.
I present to you Taking Over The Internet, in all its hideous glory!
This is actually a collection of equally crazily themed websites including Most Important Search Term: Your Immortality, The Most Important Search Term (which must be from the department of redundancy department), Jesus is taking over the internet to create your immortality (complete with a high-res close-up of an actual asshole), Search Engines Manipulation Strategies 4 Children's (that's a great big WTF), All Children's Respectful Synchronous Legal Search Engine Manipulation University (wow, I got nothing for that one), Sedona Psychic Readings Physical-Immortality, and, of course, the one, the only Everything you believed is on fire.
Now, I'll be honest, I'm not certain that this is legitimate crazy, or faux crazy. But in my mind, it doesn't really matter because whether it's real or not because this is some Grade-A insanity.
I simply don't know where to begin on this...
Well, I guess I'll start with this: Magical Bulletins is quite probably the greatest internet forum ever. There are 1090 topics and 2264 posts contained in this forum, and they are all made by one user.
That's right- one user.
This forum is filled with all manner of zaniness including daily agendas, potentially imaginary wedding plans that are ultimately canceled as well as something about being irritated by "federal laws", canceled wedding plans that get suddenly uncanceled, a countdown to the 10th anniversary of Super Smash Brothers, and breaking a window because he's a Raiders fan. Truly, this is a spectacle to behold.
In addition to the forum, he has a rather active YouTube presence, as well as frequenting DailyMotion.com.
Now, before you laugh too hard, realize that this man is actually autistic. In this forum he seems to have created a rather elaborate little world for himself.
Personally, I am in awe of his accomplishment. The level of creativity and productivity is nothing less than astounding. Sure, the end result is quite silly, but it's hard to deny that most wouldn't be able to put such a herculean effort into creating such a thing.
Also, before you make fun of him realize this: How is this different from the millions of web logs out there?
This is just a collection of crazy web sites and other peculiar things from around the web.
I am collecting these things here primarily for my amusement. Don't expect it to be very well organized, and certainly don't be surprised if some of these links drop off of the net.
There's something I've heard a lot over the years. It's a common complaint that Win32 developers express when they first come to an Open Source development environment (such as Linux with its myriad of Free Software/Open Source development tools). This common complaint is that the development documentation is somehow lacking compared to the Win32 development documentation. Generally, they point to MSDN as the gold standard and bemoan Linux's lack of something similar. This complaint is even one of the motivating factors for the LSB project (which, I used to be a part of).
Whenever I have heard this complaint in the past, it has always made me laugh. I've laughed because the development documentation for Linux and its Free Software/Open Source ilk tends to be very good... you just have to know where to look for it. You have to be comfortable reading man pages, browsing info documents, snooping through /usr/doc, etcetera, etcetera. True, it's not all available in one web site, but more often than not it's more convenient to get at in the end (much of it can be accessed quickly from the command line).
Well, after an ordeal I've had today trying to solve a simple, and common, problem with my XNA-based video game using MSDN, I will laugh even harder when I encounter Win32-weenies with this complaint in the future...