June 20, 2014

Cards Against Deqmandity

My two very good friends Amanda and Declan are getting married, and to celebrate, Janice and I throwing them a pre-wedding party. (No "bachelor" party tropes here!) By the time this post is published by Blogger, the party should just be wrapping up, and my favorite surprise should already be out of the bag.

Declan and Amanda love games, and Janice and I wanted to have a game-themed part to the party. A little over a month earlier, Janice and I were brainstorming ideas, and stumbled on one that we were really excited about: a custom Cards Against Humanity deck. Now, if you've never played Cards Against Humanity, I'll warn you that it really lives up to its tagline: "A party game for horrible people." It really is a wonderful game.

Janice set up a Google forms page for all of Amanda and Declan's friends to contribute their ideas to the project, and we ended up with a spreadsheet of 95 black (question) cards, and 291 white (answer) cards. Fortunately, their friends are the kind of horrible people that Cards Against Humanity appeals to.

The next step was to get them printed. We went through makeplayingcards.com, who print custom decks of playing cards based on images that you upload to their website. Great.. all we needed to do was to make almost 400 card images. Of course my first thought was to write a script to automate it. If you're interested in trying this out yourself, my (very quick-and-dirty) script can be found on GitHub.

We got the final version of the cards in the mail a few days later, and they look great! Thanks so much to Cards Against Humanity for making such a great game (and for allowing remixes with a Creative Commons license). I'm looking forward to trying them out - what a great way to roast your friends, no?

The finished product!

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.