Following in Darius’s footsteps, I’ve added my blog to the Facebook Blog Network, and you can click here to join. In addition, my blog should now have a very nice Blog Network widget on the side that will allow you to join my blog network, so, that’s great!

In addition, I’m always happy to have new friends on Facebook, so please feel free to add me if you haven’t. That said, please mention in your invite that you’re a blog reader. I do occasionally get friend invites from people I do not know, and I do not generally accept them. If you have already sent me an invite and I have not responded, this is probably the reason. Just resend and let me know how you found me.

This weekend, I was fortunate enough to attend (and present at) Boston Gameloop. I was fortunate enough, partially, because it was co-organized by my boss, but that’s beside the point. I presented two sessions, one on distributed version control (which I gave twice), and the other was a co-talk with me and IF luminary Andrew Plotkin about agency / complicity in games. I’m hoping someone took notes at that talk because I think it was pretty awesome, and being able to basically have a public discussion about agency / complicity with Andrew was pretty awesome. In addition to presenting, I was able to attend talks on implied ethics in game rules, see some demos / a presentation on dynamic animation of virtual actors, and spend a little bit of time in a round table on Scrum, all of which was awesome.

So all in all GameLoop was definitely a great experience, and props to both Darius and Scott who organized the whole thing. I’m looking forward to the conference occurring again next year!

I have a bit more to say on distributed version control, some theories on how it might be used in large agile teams, but I don’t necessarily want to touch on that today. I’ve decided I really need to read the rest of the Mercurial book (I read most of it!), as there’s things in there that help explain how the extension mechanism and hook system works, and how you can use them to promote pre-push process. Right now, though, I quickly want to respond to a few of my initial impressions of Mercurial:

1. Local branches and rebasing are supported in Mercurial through extensions. The transplant extension, Rebase extension, and Local Branches extensions are available and allow you to do everything I mentioned. This is the benefit of using a piece of source control that has a plugin architecture and is easy to extend. You get extensions for everything. That said, I’m convinced I wouldn’t use any of them (save potentially rebasing) now that I’ve worked with mercurial more.
2. There’s an extension for Mercurial that provides an ascii graphical log of branches / merges. It’s pretty awesome. I’m sure there are other GUIs available as well, and hey… maybe I’ll make a WPF one in the future?
3. The internal branching system works fairly well, but after using it I’ve decided they’re almost not worth using. Instead, I’m now using separate repositories, even for long lived branches. This means not necessarily knowing which branch a change comes from, but I’m okay with that.

Also, in the comments, Programmer Joe commented that he’d been thinking about distributed version control, but wants to use me as a guinea pig. Unfortunately, I’m in a very small team of people, so I don’t think I’d be that usefully as a guinea pig for large teams. I certainly have theories on how a large team structure should work (which I will post about), but nowhere to try them out. I’d love to do some large team work with Mercurial to see how it’d work out. Anyone know a large team looking to be adventurous?

So I had a conversation last night with my good friend Steve about my decision to start using Mercurial. Talking to him, I realized I hadn’t really posted much on what I think about distributed version control systems (DVCS), so the switch to Mercurial may have taken many people off guard. So, I wanted to spend a post (maybe two) talking about what I see as the advantages of DVCS over a traditional “central server” (VCS) mentality.

The Leap of Faith

Like many, about the idea of version control without a central server scares me. I don’t trust my own machine, or my developer’s machines, to be in any way fault tolerant. My server, on the other hand, has a RAID 5 controller in it, and is backed up off-site weekly (though if I were checking in more I’d probably back up nightly). Having that central server keep track of my changes feels safer, so I shied away from DVCS, opting instead for centralized version control with Subversion with user branches (more on that here). Even with tools like svnmerge though, Subversion utterly fails at merge tracking, especially from multiple branches bidirectionally. It was just never scaled to do that. Since then, I’ve watched several videos on the design of distributed version control (two on Git (here and here), one on Mercurial) and I made the leap of faith to attempt to see what DVCS is like.

The Centralized Model, Distributed

Now, distributed version control is amazing for open source projects, but what about working in a company where team communication and process is key? Where coordination is a requirement? Well, the nice thing about distributed version control is that it can, if you need it to, support a centralized model. Even in open source projects, you have what you call an “upstream” server, which is what everyone consults for the latest and greatest “official” changes to a product. You could, if you wanted to, push every commit you made to the upstream server, and pull every so often to make sure you have the latest version. In that case it would be exactly like using centralized version control (except it takes a more hard drive space, as you’re holding a repository on your hard drive, not just the source code). Sure, you have to train people to commit, then push, but once they understand that, there’s no issue. In addition, your centralized version of your tree can have pre/post-commit hooks just like any other version control system, allowing you to create check-in gauntlets should the need arise. That said, I’m sure other source control providers make it easier (the new Source Safe and Perforce I believe have GUIs for create check-in gauntlets, but I could be wrong). Still, with an easily extended system (like Mercurial), these additions wouldn’t be hard.

Encouraging Experimentation and Checkpoints

So in this case, why use a DVCS if it’s just going to work like centralized version control. Well, even in this situation, you now have more options available to you than you did before. First is the ability to checkpoint whenever you want, without affecting other developers. The key reason most people give for using version control is the Chinese proverb “The palest ink is better than the best memory.” So what not increase your memory by encouraging your developers to commit as often as possible? And if they can do this even when their build is broken or when they’re not completely finished with something, why can’t we allow them to do this? In a centralized model, this is almost impossible (though packing apparently solves this partially). Then, when a developer is done, their commit can have all of the changes they just made, with a history of what they did. Of course, it doesn’t have to (rebasing is always an option) but having it there can help you see potential problems or flaws in thought process.

In addition, distributed version control can encourage experimentation in branches. The problem I have had with branches in the past is that they are a pain in the ass to manage on a centralized server. Even Subversion, which makes branching easy, doesn’t manage merging well at all, especially bi-directional merging. I’ve even had problems with Perforce merging in the past. Regardless of that, though, working off of branches and creating branches is never easy. Not as easy as it is in distributed version control environments anyway. In Mercurial, branches are just clones of the current repository. You can work in them, share them with others, and delete them without the central server being involved. This may sound bad, but it does encourage developer experimentation and sharing. If I can branch simply off of whatever my current state is, experiment a bit, show that change to other developers and get feedback, then merge back into my main development branch easily, that opens up a lot of opportunities for small team experimental work.

Here’s an example of where I could have used this in the past. One of my former companies did not do and did not encourage unit testing, and I could not convince my coworkers (or the management) to let me try it in some of our newer libraries. I decided, though, to do unit testing on any new modules I wrote anyway. I made a copy of the library into a directory that had a unit test environment set up, worked on the library (writing new tests, making them pass, etc), then copied my changes back over when I was done, and committed them to the central server. The unit test folder, though, was completely unversioned. If I’d had a DVCS, I could have cloned the library, done my work, then pulled changes back, leaving the unit tests versioned in their own folder. In addition, any other developer that was also working on those libraries could have easily pulled the unit tests from me, thus spreading a new practice at the company. This may be an edge case, but it is an example where simple branching and merging would have encouraged experimentation between developers.

Shelving, Packing, Branching

This gets into the second option you have with distributed version control. DVCS makes it easy for developers to share uncommitted changes with each other. Other source control providers give you the option through “shelving” or “packing”, but I can’t see it being as easy as it is with distributed version control. I can pull changes from anyone, on any branch, into a cloned version of my own repository to test things out without talking to a central server. Those changes don’t need to be based off of the same trunk and can easily be merged by whichever developer at whatever point, then pushed to the upstream server, all while retaining who made the original changes. This has to be experimented with to really see the full benefit, and honestly I haven’t done it enough, but I can see where it would be useful. Unlimitted simple branching with the ability to push and pull changes from any developer coupled with a strong revision history just sounds nice to me.

Fault Tolerance

The last thing I want to talk about is when things go wrong. We try to avoid it, but every so often, our central server goes down. Sure, we have backups off site, maybe we have a passive failover server, but if we don’t, our central server going down is very problematic. I have had this happened to me, and at fairly large companies that can afford lots of nice servers. If this happens in a traditional VCS, development (basically) stops for the day. Not so much in distributed environments. Since I can commit to my local repository all I want and share with everyone else without the benefit of a central server, a dead upstream doesn’t affect me at all. This, in my mind, is pretty awesome.

More…

I will say that I’m using a DVCS in a very small team environment, but looking at it, I believe it could scale very easily. I also think there are lots of interesting ways to use DVCS, especially in agile environments where small teams may need to communicate changes without affecting central efforts. I really want to go into these, but this is already too long, so maybe I’ll talk about them tomorrow. Until then, let me know what you think.

So here at Orbus, I’ve decided to move some things over to Mercurial for a bit to try it out. Generally, the whole user branch thing I talked about way back when we started wasn’t working. Setting up each user branch was a huge pain, and merging large changes back and forth was almost impossible, even with a helper tool like svnmerge. Svn supposedly fixed this with 1.5, but if they did it the same way they did it in svnmerge, I’m not going to bother attempting to use it. Bidirectional merges from multiple branches just doesn’t work with svnmerge, and I don’t recommend attempting it. Mercurial, I’m hoping, will at least partially solve this problem.

So, we’ve been converting things over the past few days, and I have some initial impressions. First, the bad:

1. Repository cloning on large repositories, even with the addons that allow windows to use hard links, is fairly slow. I wish mercurial allowed lightweight local branches that could be developed on, and then merged back into a working copy, all in the same directory. This is the git model of doing things. I understand why mercurial doesn’t support it, I just kinda wish it did.
2. I’m sad there’s no rebasing. I would like the ability to do work in a branch, commit, say, 20 changes in that branch, and then rebase it all to one change in the main trunk. Again, I understand why it’s not there, but it’d be nice to have.
3. I’d like to be able to see who pushed what revisions to an upstream server. Having who made the changes is great, but I’d also like to see who pushed them. I’m not sure this data is available to mercurial though.
4. All the interfaces need work. I would love graphical tools that could show branching and merging into various files. Not sure what other distributed software does for this, but it seems like a very hard problem.
5. The internal branching system is extremely confusing, and I’m not sure merging single changes between branches will be any easier with Mercurial or not. Will have to see.

The good:

1. Mercurial was really easy to set up, even integrating LDAP into the push permissions system. I like it when things are that easy.
2. It makes collaboration with other programmers easier, just because of the way it works.

In general, I’m currently just using Mercurial like I’m using Subversion. The tiny bonus is now I can grab changes from other programmers, take a look at them and give comments, all without posting to a server, and that’s really nice. Once I get some more experience, I’ll make sure to hand out more impressions.

Gamasutra has an opinion piece up on suspension of disbelief in video games up. With this article, I feel the author is trying to express something he’s frustrated with in games, but doesn’t know how to express it because I’m not sure he’s fully thought it through. He’s talking about player limitations, but can’t figure out where being limited is okay, and where it isn’t. While he reaches the correct conclusion (”Games shouldn’t imply choices that players cannot actually make”), I feel he’s struggling to figure out why in one case the limitation is warranted, but not in another. In a way, he’s trying to find a way to talk about what a player’s willing suspension of freedom, not his willing suspension of disbelief. That said, even I find that sometimes it’s easy to confuse where a game creator has violated suspension of freedom, and where he has violated suspension of disbelief and thus created a violation of suspension of freedom, since the two can be tied very closely tied together. So what’s the difference, why is it important, and where do they combine?

Suspension of disbelief is “the willingness of a person to accept as true the premises of a work of fiction, even if they are fantastic or impossible.” (Wikipedia). With suspension of disbelief we are specifically looking at aesthetics of a game: plasma ray guns, space ships, magic, monsters, etc. Suspension of disbelief violations occur when a narrative or a game’s aesthetic qualities are not internally consistent (deus ex machina stuff will frequently violate suspension of disbelief).

Suspension of freedom is the willingness of a person to accept limitation in an interactive application. In games, this is mechanical: inability to walk in various areas, jump, break things, swim, place pieces anywhere, etc. Suspension of freedom violation occur when a player believes a mechanic should be possible, but isn’t. In addition, a worse violation is when a mechanic is offered, then suddenly taken away.

The two combine when a game’s aesthetics make you believe a certain mechanic should be available, but isn’t. The example given in the article about Silent Hill 3 is pretty good. Because the game presents itself as “realistic,” and has a graphical quality that reinforces that, the designer has violated suspension of disbelief, which in turn violates your suspension of freedom. You believe that you should be able to break boxes (because of the realistic quality of the graphics and other elements of the game), but you can’t, which is a suspension of freedom violation.

Interestingly, this can also be genre based, and game literacy based. A lot of genres didn’t have, or still don’t have, breakable objects, and we just accept that in that genre. In addition, people who are fairly game literate may look at boxes and realize its code for a wall (which can bite them in the ass if it’s not) and not feel any suspension of disbelief or freedom.

Games don’t have to be realistic, just consistent. Just realize that if your aesthetics are realistic, players will be less willing to suspend freedoms that they would have in real life.

Hot on the heels of me praising the Xbox Live Community Marketplace comes this opinion piece on Gamasutra that’s actually fairly angry at Microsoft’s practices in this regard. I definitely see his problems with the promotion thing, but almost everyone did. That was the single most asked question at GameFest, so I’m sure you’ll see a change in policy about it before the fall launch, or probably very shortly after. The exchange rate issue is… interesting… to say the least, but that said, I can see how it’s very difficult for Microsoft to track how points were purchased and in what country. I’m sure it hurts foreign developers a lot more than it hurts Americans though.

So, although I think a few of Ron’s complaints are understandable, I think he’s missing one key component of the XBLCM vision: lowering the barrier for entry so that anyone can make games for a console. As I pointed out in my last post, this is the first time any console manufacturer has ever done this, so, obviously, they may get a few things wrong. The comparisons to WiiWare / PSN I think were completely misplaced here, since hobbyists can’t actually develop for those platforms without hacking around the systems. Even then, both Nintendo and Sony have tried to stop such hacks, effectively attempting to close off their console as much as possible.

So I think Microsoft took a very brave step in the right direction. Not only that, but I think it’s WAY more than what most hobbyist / community game creators were expecting. To have their games “published” on an actual console, with potential for pretty large returns. I can understand the backlash from indies, since once you have a budget you can get shafted from the XBLA point of view, and price caps, royalty and exchange rates may hurt your actual prospects as a developer, but, honestly, look at this for what it is: a very positive move for creating a new caste of developer who have no budget, no team, and a desire to see their own game on a console, and maybe make some money while they’re at it.

If you have problems with the rest of the system (which you should), that’s something between you and the XBLA team. I feel pretty good about XBLCM.

So, if you haven’t heard, Microsoft announced at GameFest that they’d be deploying a new community market place this fall on the Xbox 360, and that developers will be able to keep (up to) 70% of the revenue generated from games on the community marketplace. While not unexpected, this is pretty huge news.

Before getting on to commentary, I’d like to quickly point out how revolutionary this whole set up is. This is the first time in my knowledge that a major console company has actively encouraged (or even allowed) development on a retail console at any price (Sony had a version of the PSOne you could develop for, but it was not a retail kit). In addition, this is certainly the first time that any console manufacturer has encouraged a community in which to share those games (the Creators Club) and even more importantly, this is the first time a console manufacturer has created a marketplace where anyone can download created games and anyone can make money off of those games. Even with the fact that you are limited to a .NET sandbox, this is pretty huge, and I’m pretty excited about it.

That said, when Community Arcade was announced, and later when they announced Community Marketplace, I was nervous, though I couldn’t figure out why. It struck me when I was at a game store over the weekend. There are a lot of freaking games out there now. A ton. And, honestly, 90% of them aren’t any good. There are also a lot of XBLA games, and, honestly, about 90% of them aren’t any good. With Community Arcade/Community Marketplace, you can be sure 99% of games on there won’t be any good. It makes it really hard and frequently frustrating attempting to find those hidden gems that really make it all worth it. Certainly, community reviews, Metacritic, and similar sites help find games, but what do you do for those games that are fringe (and therefore generally ignored or given low Metacritic and community scores), but awesome? Certainly the viral aspects that Microsoft is putting in (send this to a friend and, hopefully, a rating system) will help, but even then many fringe games get overlooked because there’s just too much else coming out right at the same time. I just hope that the game industry isn’t a victim of its own success, having so much content that none of it makes any real money.

Regardless, I’m not sure it’s an actual issue. You can be sure I’m already working on XNA prototype games. I’m not going to miss this opportunity.

Hot on the heals of the web release of my Game Career Guide article on game engines, the paper / published version is now out, though the whole thing is available online for free. I’m almost always really happy with the print version of Game Career Guide. It has some great articles to help people who want to know more about breaking in to the game industry. It’s just another one of those resources I wish I’d had when I was in high school / college. It also may have helped me price myself property (in terms of salary) both when I graduated and when I entered the game industry, but that’s neither here nor there.

On a side note, I have to remember to put my blog in my bio for Game Career Guide from now on. I frequently get email from people asking questions about the article and almost as frequently I direct them to articles on my blog. I’m just no good at this self promotion thing.

I’m not one to disagree with Joel, but I actually think I will disagree (sort-of) with this post.

Personally, I have no problem with disabling menu items (graying them out), and I have no problem with showing / hiding items in context sensitive areas of your UI (be they right click menus or elsewhere). I think disabled items give a quick indication of what you can and can’t do given your location current context. How horrible would it be to think you’re inside a table and click something to format it, only to get an error saying “You can’t do that because you’re not in a table,” then you click OK, then you click in the table, then you go back to your menu. That extra error box plus OK click can get real annoying real fast, whereas grey text tells you quickly that you’re in the wrong place. Hiding items is fine too, so long as you’re hiding the items in areas the user understand are context sensitive. Right click is always assumed to be context sensitive, but properties windows, and certain toolbars could benefit significantly from some amount of context sensitivity.

I will say, though, that I absolutely agree that a disabled menu item should always be able to display a descriptive reason for why its disabled. In addition, hidden items should only be hidden from areas that are known to be context sensitive. If an item is hidden, a user should still be able to find it in the menu, find that it’s disabled, and get a reason why. I think a tool-tip or similar is sufficient for when you see the grayed out item but have no idea why it’s disabled, but of course in the desktop application world support for that can be fairly limited (last I checked) which is why almost no companies do it, which is what is irking Joel (I think).

So in conclusion, hide and disable all you want because I think even the general user can work faster seeing disabled menu items and hiding unnecessary commands. Just be sure that when you hide or disable, the user can find out quickly why you’ve hidden or disabled the item. That assertion’s nothing new, though. Chris Crawford called for that in his self-published Understanding Interactivity some 8 years ago.