Chris Frederick

Nintendo 2DS

August 29, 2013

I don’t know what to think of the Nintendo 2DS. First of all, it has a clever yet strange name: as an overlapping combination of “2D” and “DS” (“dual screen”), it pretty much describes a system in the original Nintendo DS series rather than one in the Nintendo 3DS family (as the Nintendo 2DS is officially being marketed). I wonder if this is a sign that Nintendo is preparing to replace their existing Nintendo DS lineup—the Nintendo DSi and Nintendo DSi XL—with the Nintendo 2DS? That would seem to make more sense than simply releasing a new version of the Nintendo 3DS at a lower price point. After all, at $129.99 the Nintendo 2DS is only $40 cheaper than the Nintendo 3DS ($169.99).

Then again, if the Nintendo 2DS is indeed going to be the spiritual successor to the Nintendo DSi, why will the system be conspicuously absent in Japan? (As far as I can tell, the Nintendo 2DS has only been announced for sale in the Americas and Europe.) The reasons behind this decision are still mysterious to me, but if I were to hazard a guess it would be that the Nintendo 2DS appeals to the price-conscious sensibilities of Americans (and apparently Europeans) rather than the quality-conscious sensibilities of Japanese people. Furthermore, Nintendo’s brand awareness is very strong in Japan and thus the company may not need to constantly reduce prices in order to sell its products. Still, I wonder whether the $40 price difference between the Nintendo 2DS and the Nintendo 3DS is really significant enough to drive sales.

So all that being said, how does the Nintendo 2DS really stack up against its Nintendo 3DS brethren?


GitHub Flow

May 10, 2013

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.

We Built a Booth

April 27, 2013

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.

Xcode 4 - How to Install SDL on Mac OS X 10.7/10.8 Lion

April 11, 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!