A few months ago I shared a link to a successful Git branching model, also known as git-flow. I've always considered it to be a very robust and well-designed process for teams that collaborate via Git, but at the same time I've rarely used it for any of my personal projects. Why? I honestly never gave it too much thought, but after reading Scott Chacon's take on the matter (GitHub Flow) I am inclined to agree with him. The git-flow process is just complex enough to outweigh the benefits for many developers.

One of the bigger issues for me is that it’s more complicated than I think most developers and development teams actually require. It’s complicated enough that a big helper script was developed to help enforce the flow. Though this is cool, the issue is that it cannot be enforced in a Git GUI, only on the command line, so the only people who have to learn the complex workflow really well, because they have to do all the steps manually, are the same people who aren’t comfortable with the system enough to use it from the command line. This can be a huge problem.

So the complexity of git-flow is one issue, and another is the frequency with which GitHub releases code (emphasis mine).

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

This makes sense—git-flow does appear to be designed for more traditional release schedules rather than for continuous delivery, as summarized below.

For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.

For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.

I highly recommend that you read the full article. If you're still interested in learning more about Git, I would also recommend Scott Chacon's comprehensive book on the subject, Pro Git.

Polygon does some excellent long-form journalism on the gaming industry, and this article is no exception. If you have any interest in indie games—as I do!—I hope that you will enjoy this report on the making of the Indie Megabooth at PAX East 2013.

I really wanted to install and use the Simple Directmedia Layer to begin building some game prototypes in XCode, but I kept running into the same maddening compiler errors.

Undefined symbols for architecture x86_64:
  "_SDL_main", referenced from:
      -[SDLMain applicationDidFinishLaunching:] in SDLMain.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I naturally searched for a solution on Google and eventually found this video, which explains how to successfully build and run a program in XCode 4 using the SDL. I generally prefer to read instructions, though, so I'm essentially going to transcribe the major steps outlined in the video for your convenience. I hope that you find this at least as helpful as I did!

I love reading articles like this because they give me hope for the future of the games industry. The democratization of the game development process is good for everyone: it means more games, more choice, and thus more art. I think that Penny Arcade's Jerry Holkins said it best in the following quote from his news post on June 1, 2012 (even though he was technically responding to the issue of offensive content in some games, I think that his point is much more widely applicable).

The answer is always more art; the corollary to that is the answer is never less art. If you start to think that less art is the answer, start over. That’s not the side you want to be on. The problem isn’t that people create or enjoy offensive work. The problem is that so many people believe that culture is something other people create, the sole domain of some anonymized other, so they never put their hat in the ring. That even with a computer in your pocket connected to an instantaneous global network, no-one can hear you. When you believe that, really believe it, the devil dances in hell.

With that said, I was really impressed to see that Nintendo is trying to become a much more viable platform for independent game developers. According to the Penny Arcade Report, I'm not the only one to be pleased with Nintendo's new policies.

One developer I spoke with said this change in policy may have come a little late for Nintendo, but it's still a step in the right direction. Being able to control your own pricing, pick your release date, and the affordability of dev kits (Nintendo described the cost as the same as a high-end PC) are all moves that make Nintendo consoles much more attractive to developers.

In fact, I'm going to list what I found to be the biggest takeaways from the Gamasutra interview for anyone who may be interested in developing games for a Nintendo platform (particularly the Wii U). Unless stated otherwise, emphasis in all quotes is mine.

By the way, don't forget that you can follow Dan Adelman on Twitter if you enjoyed his interview and would like to continue getting the latest information on Wii U development.

How many times have we all heard the following mantra?

I work smarter, not harder.

Isn't it seductive? As long as we are smart, we don't have to work as hard, right? After all, who really wants to work harder?

Well, as it turns out you can work both smarter and harder, and you probably should, too, if you want to get any better at what you do. Especially if you're trying to keep up with John Carmack.

I came across this article on a standardized Git branching model some time ago, but I still find it quite useful to reference from time to time. If you're using Git, this is definitely a worthwhile read.

I just finished listening to this old (2002) episode of This American Life, and I couldn't help but imagine that the exact same story could just as easily take place on a starship in the future. I actually found it fascinating to hear about the day-to-day life of the majority of the crew on the ship, who never engage in any combat missions. Here's the summary (emphasis mine):

Life aboard the USS John C. Stennis, an aircraft carrier in the Arabian Sea that's supporting bombing missions over Afghanistan as part of Operation Enduring Freedom. Only a few dozen people on board actually fly F-18s and F-14s. It takes the rest of the crew—over 5,000 people—to keep them in the air.

Because I'm weird, this radio show also reminded me of a question and answer posted on scifi.stackexchange.com about the ships used by the Empire in the Star Wars universe. I particularly liked the following paragraph in the answer.

And the more you scale up, the greater the logistical resource needs stack up, especially if the vessel is going to be on multi-year missions across the galaxy. For psychological and social reasons, you'd need to have even more crew comforts and civic infrastructure, like libraries, entertainment centers, living areas, schools, gyms, hydroponic farms, etc. You'd also have more need for support personnel from electricians and mechanics to nuclear engineers and scientists to security officers, forklift operators and janitors. Conveniently, a large crew and ship will also serve to reduce the psychological stresses of feeling isolated and trapped during extended space voyages.

So whenever we finally get around to building spaceships to explore the stars, they may end up operating a lot like our aircraft carriers do now. Anyway, it's an interesting thought.

I love Gabe/Mike's post on playing Call of Duty on the Wii U. As the Penny Arcade Report's Ben Kuchera has noted before, there has been some confusion about exactly what the Wii U is. I myself have wondered why the Wii U GamePad would be superior to a computing tablet. Gabe/Mike gets right to the heart of the matter and makes a very strong case for why the Wii U matters (emphasis mine).

So what is it about the Wii U version that makes up for losing access to Xbox Live? For me it’s the gamepad functionality. At any time you can tap a button on the Wii U gamepad and shift the video from your TV down to the handheld screen. For a gaming dad this feature is a blessing. You people without kids might be surprised to learn that when you have children you need to alter your gaming routines. First of all the TV simply isn’t always available. Much of the time it’s showing the same Curious George episode for the millionth time or being used to re-watch the entire Lego Ninjago series from start to finnish. The ability to start up and play CoD on the gamepad without ever having to use the TV once is incredible. Normally I’d wait until the kids were in bed to play a game like CoD but now I can sit there on the couch with my kids and play an M rated game without them even noticing. More importantly I’m not playing some bullshit mobile version of CoD, I’m playing the real game and earning real XP! When they leave or go to bed I can tap a button and send the video back up to the TV and keep playing.

This sounds very similar to my own experience of using a smartphone for the first time. At first, I assumed that I was mainly going to use it for maps and web browsing. I was dead wrong. To my great astonishment, I have found that I mainly use my phone for reading. I can pull it out of my pocket whenever and wherever I have a few minutes free, read an article or blog entry, and then quickly put it back. I can shunt my reading from my computer to a portable device and thus free up my computer to do tasks for which it is more optimized (i.e. anything that involves a lot of typing). My smartphone has expanded my computer's capabilities, not replaced them. In the same way, I see the Wii U GamePad expanding the capabilities of the next-generation gaming console. The Wii U GamePad is fundamentally different from a computing tablet because it doesn't require you to buy or download mobile versions of every game; you can use the GamePad as your screen at any time while still playing the exact same game. That's a very compelling feature for any household that shares a TV.