Jeff On Games

I've been talking on twitter about working on some stuff involving 2D soft shadows. I was going to write a long blog post about how I got 2D soft shadows working in XNA using the GameDev article in combination with Catalin's implementation and Christian's implementation in D. However, trying to write the post, I wasn't sure if I could make it any clearer, as I'm not sure if I understand it completely myself.

So, instead, I'm just going to post the XNA port I made almost directly from Christian's D implementation without much comment. I will say that, instead of using the images that both Catalin and Christian are using, I've move most of that into shaders. This isn't necessary, but it's in preparation for some other stuff I want to do later with this project.

So if you're interested, my XNA implementation is here. Enjoy!

It's been a while since I posted, but a lot's been happening. If you've visited the site, you probably noticed a theme change, but more importantly, you may have noticed I am no longer at Orbus Gameworks.

There are many reasons I decided to leave Orbus, and maybe some day I'll write a long blog post on the subject, but the short story is that I decided it was time for me to get back into creating games full time. Although Orbus focused on game middleware, the technology we were working on wasn't really game development, and I felt like I was getting more and more behind in the skills and systems that are essential to being a programmer in the game industry.

So I have moved on to another start-up, but this time a game studio: Fire Hose Games.

Working at Fire Hose has been an adjustment, though not a bad one. Because of the size of the team and the schedule, I've been forced to think and program very differently from what I'm used to. It's pushing me out of my comfort zone, which is always a good thing, if only to see different ways things can be accomplished, even if they don't jive with the way you work as a programmer.

Generally, I'm really looking forward to my work with Fire Hose, I'm excited about our product, and I'm looking forward to having shipped another game.

I've been spending a bunch of time reading about continuations and microthreading recently, just trying to wrap my head around them and find areas where they might make sense, specifically in C# using the ISO CLI systems. Of course, the example that most people give is AI, like so the one provided by this article:

 
IEnumerable Patrol ()
{
     while (alive){
          if (CanSeeTarget ()) {
               yield return Attack ();
          } else if (InReloadStation){
               Signal signal = AnimateReload ();
               yield return signal;
          } else {
               MoveTowardsNextWayPoint ();
               yield return TimeSpan.FromSeconds (1);
          };
     }
     yield break;
}
 

Now, implementation details aside (I'm not a fan of the authors implementation of the scheduler), you can then have a scheduler for all of your microthreads that will run each method until it terminates. Run one (or more) of these schedulers in a background thread and everything's awesome right?

Well, I'm not so sure. I have questions about this myself. For example, I would think that this pattern is more useful in cases where you have a lot of things that need to be done in sequence, but potentially in other threads or for multiple frames. For example the "AnimateReload" state from the example. Well, what if that state looked more like this?

 
       if (NeedsReload)
       {
            Signal coverFound = BeginFindCover();
            yield return coverFound;
            if (CoverPoint != null)
            {
                 Signal atCover = MoveToCover(CoverPoint);
                 yield return atCover;
            }
            Signal reloadAnimation = AnimateReload();
            yield return reloadAnimation;
       }
 

This is a more common use case in my mind. Have a procedure that takes many frames of execution and has portions that can be delegated to background tasks (such as path finding, which might take a few frames) and have them written linearly so that it's easier to read.

Here's the problem. Because we've now put the "Alive" check farther and farther away from the actual call, we've ended up in a situation where, at any time, the AI can die, and thus its microthread will need to die with it. To combat this, we'd have to check if the AI is actually alive after every yield, creating this code:

 
     if (NeedsReload)
     {
          Signal coverFound = BeginFindCover();
          yield return coverFound;
          if (!Alive)
               yield break;
          if (CoverPoint != null)
          {
              Signal atCover = MoveToCover(CoverPoint);
              yield return atCover;
              if (!Alive)
                   yield break;
          }
 
          Signal reloadAnimation = AnimateReload();
          yield return reloadAnimation;
      }
 

To say nothing of if the state of the AI was forcibly changed for whatever reason (say, for example, if a Team AI Manager has told him to start running away, or regroup, etc). The only way I can think to combat this is through a special AIYield function which would handle most of that, but even then, I find it hard to think of a way to tell the system it needs to break from the current update thread and start a new one. Reschedule?

What do others think? Am I over thinking this? Am I thinking about this the wrong way? Am I using the wrong tool?

So Xbox Live Community Games went live a few days ago, though I was away at MIGS when it launched, so I missed it. However, already there's a lot of stuff up there and a lot of it looks fairly cool (although, certainly, there's a ton of stuff that's just terrible). However, there's one thing that I want to say to people that are thinking about making community games: really THINK about your trial time. Since you have a set amount of time to play with (unlike non-community games which can kind of decide on their own), you need to use that time wisely. Remember: people are not going to buy your game if your trial isn't good, and so far, I've yet to download a game with a good trial. Some tips:

• Your tutorial should take less time than the trial allowance. Let me actually play your game and I might be more interested in buying it. If you have more rules than you can express in a limited amount of time, think about pushing more advanced tips to farther into the game.
• If your beginning isn't that interesting, don't start me at the beginning of the game. Get me to the most interesting part quickly. Of course, that may be difficult, so, instead, just make your beginning really interesting.
• Honestly, just try to sell me on *something* that makes your game unique.

I'm still excited about the possibilities of Community Arcade, but I'm really not as interested in weeding though all of the crap.

So I picked up a copy of Mirror’s Edge the other day, and I’ll have a full post about how much I enjoyed that game some time in the future (probably after I get back from MIGS), but right now I just want to talk about something that really bothers me about modern applications:Auto Updaters.

Honestly, I have no problem with auto updaters as a concept. If my application needs updating, by all means, update it when it needs updating.My problem is with the auto updaters that run as a background process, constantly, without my approval (usually), and really without any need. Here’s the list of auto updaters currently running on my system as background processes:

• Google Update x2 at 2.6 megs each
• The HP scheduler x2 at 956k each
• The Install Shield Updater x2 at 1.1 meg each
• Antivirus update at 1.5 meg

In addition, if I hadn’t disabled it, I could have the Apple auto update service running as well.Who knows how much memory that would take up (and for each user I’m sure).

In my opinion, there are only two systems that are allowed to constantly check for updates: your operating system, and stay resident protection programs like virus scanners and anti-spyware. All other programs should only EVER query for an update when you run them. All lot of applications I have do this, though even they’re not perfect. Here’s how I see a good auto update system working.

• Never have a stay resident program for updating. If that requires that you compile the same system into multiple programs to check for updates, so be it.
• Never have an auto updater suggest that I download new software. I’m looking at you Apple. I don’t want Safari… got it?
• Check for updates only when the application boots.
• Inform me when an upgrade is available, and ask for on of these three options: “Always Upgrade Automatically”, “Upgrade Now”, “Never Upgrade”. If I select “Always Upgrade Automatically”, all upgrades should be silent. Unless you change something visually, I shouldn’t even know an upgrade occurred.
• If you absolutely must have a stay resident program checking for updates, it MUST understand multiple users. Thankfully, Avast! actually did this right.

In actuality, the best solution here is to have a central system that checks for programs that need to be updated, and where to get information about that. This is where package Linux package management is actually far and away better than most everything else out there. That said, although it’s ridiculously simple to use, I don’t see it being ridiculously simple to develop for, especially if you’re developing an application outside of the bounds of the central repositories. At least there are no upgrade daemons in Linux (that I know of anyway…).

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.

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.

Those of you that know me know that I really enjoy cooking. Well, really, I enjoy eating good food, but I’ve found that the easiest (and most inexpensive) way to get good food it to make it yourself. So, tangentially, I enjoy cooking.

As a result, I spend a lot of time online looking at various interesting recipes on the internet (and through cook books, but this post is mostly about the internet). One thing I’ve found is that most sites that offer a good deal of recipes, are lacking in their actual usability; not because they’re not designed like other sites, but because they’re designed exactly like other sites. Most of them are designed as simple lists of categorized articles or blogs, with ratings and comments. This may be fine for most blogs or new sites, but cooking is this inter-related web of techniques, derivations, substitutions, and adaptations that (in my mind) can’t be served properly by this common model, but does lend itself well to the web in general. The problem is that people get locked into this core method of usability, and don’t realize that it doesn’t work in all situations.

This, in my mind, actually violates a core tenant of usability in information systems: get the information that the person needs to them as quickly as possible, and allow them to access related information quickly and easily. For cooking, this is not just related reciepies. This may mean linking them to information about the techniques required for a particular recipie (creating a roux, blending a soup, searing a piece of meat, grilling, broiling, etc), the potential ingredient substitutions (can I substitute different types of mushrooms, stocks, water, etc) or additions (can I add garlic, Tabasco sauce, or rice to this dish, and where). Additionally, potential side dishes, wines, derivations (versions of the same recipe that use similar but different ingredients) and nutritional information are all common things I want to see with a recipe, but rarely see in any web recipe outlet.

And don’t get me started on comments. 90% of comments of recipe sites are worthless: “This tasted great! I will do it again!” is pretty common. But that last 10% is sometimes useful. “Lightly salt the zucchini to drain the moisture first,” “Added garlic to this dish and it really brought out some of the flavors,” are good comments, and are related specifically to an ingredient, addition, or substitution, so why are they at the bottom of the page instead of where it might be useful to me?

What does this have to do with games? Well, nothing really, but it does point out an alarming trend in general usability: this idea that once you’ve found one system that works, you tend to apply it to other systems where it’s not as useful, or (worse) where it doesn’t make sense. So, when you’re designing your user interface for your next game, just think to yourself for a second: “Am I designing this interface this way because this is the easiest and best way to access this information, or because it’s the way it’s always been done.” You’ll be surprised how often you answer yes for the later, and find another, better way to do it.

A while back, Brenda posted this nice post giving advice for “newbies” who want to keep a blog. So, I totally agree with all her points about how you should keep a blog as a student, but I found it interesting that I’ve basically violated almost everyone one of them: I don’t update on a set schedule, I occasionally will post something completely unrelated, and my blog has kind of shifted focus over the past year from being purely about game design theory to a blog that shifts between programming and game design theory. Am I exempt since I’ve held a game programming job and currently work at a game middleware startup? I’m really not sure, but one thing I have to wonder is whether or not my lack of focus or a set schedule affects my audience or my readership.

Personally, I think the schedule idea mattered more before the days of RSS, when you had the “morning crawl” every day when you got to work. I still do the “morning crawl” but it’s mostly just a crawl of RSS feeds that I didn’t get around to reading the day before or missed articles from. Whether or not they’re on a schedule or not doesn’t affect me, and I wonder how many people are the same. In fact, a blogger that posts too much I just tend to ignore, since I find I usually just can’t keep up. Again, I wonder if this is a common phenomenon.

As for focus, I think that’s an interesting question. I post mostly about programming and weird game design theories, and interestingly the two subjects are about as far apart as I can make them. The programming side is very practical, talking about how I solved very specific problems, whereas the game design stuff is all theoretical: not a single practical piece of information in that category really. The third major category for me is newbie advice, which I’m always happy to hand out. I think more people found my blog from the Top 10 things response than any other single article (mostly because of the Game Set Watch link), and I’m sure some people subscribed to my blog after that expecting more newbie advice. So I’m happy not having a focus per-se. But of course I don’t really jump fields completely, I guess you consider this blog focused if you squint your eyes and cross them a bit.

Anyway, I’m interested to hear what my readers have to say. Would you rather have me update on a set schedule? Would you rather have me focus on (or at least post more about) a particular subject? Would you rather I not talk about agency theory quite so much? I’m interested in what people have to say.

I've attempted to redirect all of my feeds to Feed Burner. As a result, you may see a break in service, or you may not. I"m hoping not, but technology can be confusing some times.

What I'm hoping is that I'll get a better idea of how many people are subscribed to the blog. I mean, I am working at a metrics middleware company, so I guess it's about time I started applying metrics to my own site.