June 24, 2013

Building a Custom Chorded Keyboard, Part 1

The Belkin Nostromo n52
As some of you might know already, I like to nerd out about input devices. I've had the desire to build and try out a chorded keyboard ever since I first watched The Mother of all Demos. Chorded keyboards have had some popularity with wearable computing enthusiasts due to their one-handed use, but I thought they might also be interesting for ergonomic reasons. Building a chorded keyboard would also be a great learning experience as a deep dive into the workings of USB HID devices.

Inside the n52
One of my initial thoughts was to use the existing hardware from my Belkin Nostromo SpeedPad n52. It's a game controller that I haven't made much use of lately. Opening it up, most of the button connections are extremely simple, so it would be pretty straightforward to put my own hardware inside of the device. The more I research chording patterns, however, the more I think that the keyboard layout on the n52 won't be optimal for use as a chorded keyboard.

So I went about ordering a number of mechanical switches and I'm attempting to build my own from scratch. Building a nice ergonomic enclosure will be difficult, as I've never done anything like it before - I've only ever built square things.

For now, I'm starting with the software. I've built a simple mock-up device using some cheap pushbuttons (they were easier to use with a breadboard), and attached them to an ATMega328. Now I'm working on getting basic keyboard input out of it using Objective Development's open source V-USB stack for AVR microcontrollers.

Next time, perhaps some cardboard enclosure prototyping!

The test button controller, being built.

February 17, 2013

On Journey and Destiny

There's a strange contradiction that I've been wrestling with for a little while. I thought that Journey was an absolutely beautiful and wonderful game. It even won eight awards at DICE this year, including "Game of the Year" and "Outstanding Achievement in Online Gameplay". But here's the thing: I think I might somehow be the only person in the world that absolutely hated Journey's multiplayer system.

If you haven't played Journey, the multiplayer system works like this: you start playing the game as if you were playing a single-player game, and the game matches you with someone else who's playing where you are. Suddenly, you're playing together. The game doesn't offer much in the way of communicating with your new partner - you mostly have to work out a system on your own involving motions and the little visual chime that your character is able to make.

The biggest problem that I have with the multiplayer in Journey is that the game is basically a puzzle game. The enjoyment in the gameplay lies in figuring out the puzzles in the world and completing them. Without exception, every time I played the game and was matched with another player, that person would run ahead and trigger all the actions and solve all the puzzles. It was like watching a movie and having someone constantly whispering in my ear what happens at the end of the current scene.

The other main problem I had with Journey is that it seems to actively discourage cooperative gameplay. The lack of any real communication and the inability to choose who you were playing with discourages teamwork. I do certainly find it interesting that players came up with their own communication schemes, almost as an emergent form of gameplay. This actually would have worked well as an intended form of gameplay puzzle, had there been puzzles that required multiple players and teamwork to complete, but I, at least, never saw anything like that in the game. Admittedly, I did eventually disconnect my PS3 from the internet so that I could enjoy the game solo (I really wish there had been an option for that, so that such drastic measures weren't necessary), so I might have missed some multiplayer-only puzzles later in the game.

So what was so amazing and innovate about Journey's multiplayer? The answer seems to come in one of two forms. First, that the limits on multiplayer in the game were an intentional artistic choice. I can't really argue with that - it didn't quite match my personal taste, but that's part of making interesting artistic choices. The second type of answer usually revolves around the automatic matching with other players who seamlessly appear in your game experience. On a technical level, I think this is pretty cool. But as a design choice, I don't. If you don't give people a reason to work together, you're just adding noise and possible problems to a player's experience. MMO games are often facing similar problems - player retention is much higher when a player has a connection to a guild, or plays in groups, but encouraging players to actually make these connections is difficult. The genre has seen a large number of designs attempt to solve this problem.

Bungie's recently announced Destiny apparently uses a similar concept. Perhaps this type of multiplayer will work better for a combat game, where additional cooperative players might help you through a difficult section, because everyone's goal the same - kill all the enemies and move forward. But online shooter fans are also a demographic known for their harsh derogatory language and griefing behavior, so this could certainly also backfire. Of course, Bungie are very good at their jobs and might have accounted for such problems. With journalists already calling Destiny the future of multiplayer gaming, I will of course be watching very closely to see how these systems work out.

I'm well aware that I could just be completely wrong on this topic. While multiplayer systems do tend to be a focus of my career, the majority game journalism and the Academy of Interactive Arts and Sciences certainly disagree with me, and that's nothing to scoff at. I'd love to hear your thoughts or rebuttals.

February 15, 2013

Windows RT and Microsoft's bad choices

After spending my holiday break playing with my wife's Surface running Windows RT, I decided to pick up my own. Honestly, I've been pretty happy with it as a productivity and media consumption tablet. But, as I am always wont to do after owning a device for a while, I ended up wanting to try my hand at developing for it.

I knew Microsoft hadn't made the best choices regarding development for Windows RT devices, but I hadn't realized how bad they really were until I started looking into actually developing for the device. Keep in mind, I'm someone who likes Microsoft and the Surface enough to go buy one myself. I want the platform to succeed. I would still rather have my Surface than a new iPad.

Given the technical decisions they made, I can only imagine the reasoning being a combination of two things: arrogance in the Windows division that Windows is still the dominant operating system in the world, and either a lack of political clout or an extremely myopic team heading up the Windows RT development effort. I would guess the former, given that it's Microsoft.

As a technology company, when your platform is the dominant one, it's in your best interests to make sure it's hard to develop cross-platform applications. This keeps developers and users using your platform. You can see examples of this in how Apple manages iOS - using Objective-C, limiting development to the MacOS X platform, crusading to get rid of Flash, etc. When your platform is the underdog, however, the opposite is true - you want to make it easy for developers already targeting the dominant platform to port their applications to your platform as well. This is especially critical during the "bootstrapping" part of your platform's life, where developers are asking why they should develop for a platform without an existing base of applications to draw in users.

Microsoft, however, approached the design of the Windows RT development tools (which are really just the Windows 8 development tools) as if they already owned the market. With the iOS and Android platforms already vastly ahead of Windows RT in both market share and number of applications (currently 650,000 on Android, 800,000 on iOS), this seems like a terrible decision on Microsoft's part. As I see it, there are at least three major roadblocks to developers developing for Windows RT:
  • Development environment: Instead of offering an SDK for download to allow developers to target Windows RT, Microsoft decided to only allow development using Visual Studio 2012 on Windows 8. This is potentially a large change in development and build environments and processes, especially given the slow uptake of the Windows 8 operating system.
  • Games: Instead of supporting the OpenGL ES graphics API, Windows RT only supports DirectX. OpenGL ES is the standard for graphics across every other mobile platform. (OpenGL ES is also available on every major desktop platform, since it's a subset of OpenGL.) DirectX, on the other hand, is available on Windows desktop PCs. A quick search on Google will show a large number of game development frameworks that support both Android and iOS, but so far the only such framework to also target Windows RT seems to be an upcoming (and I've yet to see a date announced) version of Unity. Game developers currently wishing to target Windows RT devices need to write their games without the benefit of such frameworks, it seems. Worse, they'll need to make sure their rendering layer is entirely modular and able to use either OpenGL or DirectX if they want to target multiple platforms. This seems like a herculean effort for today's common casual mobile game development studio, and not at all worth the risk.
  • WinRT APIs: To target Windows RT devices (or Windows 8 Metro at all), developers are tied to the WinRT API. While code that targets WinRT is portable to any Windows 8 machine, it makes code even harder to port to other platforms. One major example of this is the BSD sockets API. BSD sockets is the de-facto standard API for network programming, existing mostly unchanged on every other platform. With WinRT, Microsoft got rid of this API in favor of their own. Changes like this not only make a developer's job harder, they mean that many middleware libraries are not compatible, adding further roadblocks to development.

Microsoft, please. I really would like your platform to remain viable. Sure, I'm resisting putting Windows 8 on my desktop PC, but I honestly really like it as a tablet OS. Please go watch everyone's favorite video of Ballmer, and make Windows RT developer-friendly. Because if someone like me, who actually likes and evangelizes your platform, is turned off from wanting to develop for it.. well, it's in trouble.

January 11, 2013

Java and Game Development

It seems like at least once every few days, someone is asking whether Java is an acceptable language for game development over on /r/gamedev.

I'm going say something potentially unpopular: please don't use Java. A lot of people will tell you that the only way to do real game development is in C or C++. I'm not one of them. Honestly, I love high level languages. And, for the most part, I'm a firm believer in saying "use what you already know". You can do game development in a lot of the major programming languages out there, so if you're new to game development, why spend time learning new practices and a new language? Don't. Use what you already know.

Unless it's Java.

I'm not a huge fan of Java myself, and yeah, I've ragged on it a bit before in relation to other high-level languages, but that's not why I'm suggesting that you don't use it.

Java has had a lot of issues since Oracle took over. The installer or application tries to install crapware on every update. Java itself is rife with massive security holes, which come out with alarming frequency. Here's the latest one. It's obvious that Oracle just does not care about Java.

More and more, using Java for your game projects is going to look increasingly unprofessional. Forcing your users to install the JVM and keep it up to date to run your game just doesn't seem very polished. Sure, they might already have it installed, but your game will still be one more pain point every time they see articles like this, and debate whether to uninstall Java or leave their machines vulnerable.

Is Java an acceptable language for game development? For you the developer, sure. For your users, no, definitely not.

January 6, 2013

Now Playing: Anno 2070

Janice and I have been playing a lot of Anno 2070 lately. Getting into it is a bit rough, as there's really no tutorial to speak of, and it's a little on the complex side. But you get the hang of it soon enough. It's worth it once you do - it's a combination of supply chain management, SimCity-style building, and RTS-style combat with diplomacy and goods trading... all in one game. I highly recommend it, it's definitely been scratching that "just one more thing" itch for me, and I've been playing far too late into the night lately.

January 4, 2013

GnuPG Dice!

Many months ago, I wrote a little GnuPG-verified dice CGI page for myself and my gaming group to use when resolving gaming situations over email. (Feel free to use it yourself, you can check it out here.) It's inspired by other verified dice web applications out there. But while other scripts require you check a roll on the site itself, either by cut and pasting into a form, or by finding the roll in a list, I wanted something I could verify easily by looking at the message in my mail reader. Thus, I used PGP to sign the message and ensure its validity. (Well, I also provide a signature-checker form, for when you don't use or have access to PGP.)

Since most of my gaming lately has been around a table, I had almost forgotten about this little project. Today, I wanted to use it again, and ended up making a minor change to the code. Surprisingly, I didn't have it in source control! So I fixed the code, and checked it into git. While I was at it, I decided to write a readme, and put the source up somewhere public.

So, here you go: my little dice page, released under a BSD license. Maybe someone will find it useful, or at least it'll save you some time.

August 20, 2012

Symmetric NAT

I almost titled this post "Symmetric NAT considered harmful", except I promised myself I'd never title something "considered harmful."

It seems like the number of consumer-level routers on the market that implement symmetric NAT (endpoint-dependent mapping) has been rising in recent years. This paper puts it as high as 16% in 2010 (with another 14% blocking UDP traffic, which, while tangential to this post, is really disappointing).

RFC 4787 (Network Address Translation (NAT) Behavioral Requirements for Unicast UDP) is the "Best Common Practices" document regarding developing NAT devices and how they should behave. It has this to say as its very first requirement:
REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

Every piece of hardware or software out there doing symmetric NAT is negatively affecting the usefulness of the internet as a whole. Not only do these devices make the internet less useful for their owners, but users behind symmetric NAT often require extra resources or load on the networks and applications they use. (Using a third party's bandwidth for relay of VoIP streams, for example.)

So why are there still so many symmetric NAT devices out there?

The Manufacturer Problem
The biggest part of the symmetric NAT problem is manufacturers. It frustrates me to no end that manufacturers of consumer-grade routers still to this day implement symmetric NAT. Belkin's latest cheap 802.11n wireless routers (in the $25-30 price range) do, as do a large number of all-in-one DSL modem/router combinations that I've seen.

I have a hunch that this is because these cheaper routers use embedded system-on-chips (like the Ralink RT3050 used in the Belkin N150) where it's cheaper and easier to implement dumb symmetric NAT (one lookup table in memory) than to implement restricted cone NAT (which requires holding filtering state in memory as well).

The Perception Problem
The other part of the problem is with how people think of NAT. Many people seem to think that the problem NAT solves is security, and that symmetric NAT is the most secure. The problem NAT actually exists to solve, however, is translation. While filtering is a part of it, the translation behavior (endpoint dependent or independent mapping) makes no difference to the level of security. I'll say this again, because it's important: the mapping behavior of a NAT makes no difference to the level of security it provides. Security is a function of what packets are allowed to go through the device, not how those packets are translated.

The Solution
Honestly, I don't really have a solution. Thanks to the World IPv6 Launch Day, IPv6 is finally on its way, and should make the whole problem moot. But the day when game and application developers can ignore IPv4 and NAT and focus solely on IPv6 is still a long way off.

It seems the only solution is to make whatever noise we can about the problems of symmetric NAT, and hope other people do the same. Education is key. If you're reading this, write a post yourself about the problems with symmetric NAT. Email your favorite hardware-reviewing website, and ask them to post information about NAT properties when they review routers. Or just warn people away from buying routers you know to be doing Symmetric NAT. I'll be doing all of the above.

People hate hearing "your gameplay will be impacted because of your $20 router", but are much more understanding of "your gameplay will be impacted because of your $20 video card." That's just life for a network programmer. But maybe we can warn people away from buying broken hardware to begin with, and make everyone happy...