All the game developers that I’ve spoken with (hobby or pro) tell me, “Making games is entirely different from making generic software.” While I agree with that statement, there are definitely nuggets to mine from the world of game development.
Recently I found myself faced with a new design challenge: to create a digital game interface that uses differentiating hardware and software components to facilitate a fun and social game play experience.
I looked for a framework to help me deconstruct the various aspects of the game into collaborative conversations I can have with client-side engineers, product managers, and marketers. I found the engineers were deeply involved in leveraging the hardware mechanics to design differentiating aspects of the game, while the marketing team was focused on product branding and visual design.
MDA Game Design Framework
I started as many designers do, weeding through the web to withdraw inspiration and artifacts to leverage something that might be pre-existing. That’s when I stumbled on the white paper “MDA: A Formal Approach to Game Design and Game Research” by Robin Hunicke, Marc LeBlanc, and Robert Zubek.
Acceptance testing is hard. It requires thinking through your entire problem and nailing down the expected outputs for a list of inputs. When working on games, acceptance testing becomes even more difficult.
There are certain aspects that cannot be tested: “Is it fun?” “Is it too hard?” Other aspects are just difficult to setup and too brittle to maintain. You don’t want your tests to break on small tweaks, like player walking speed or jump height, but you want to enforce that the core game mechanics are working: “Can I shoot another player?” “Can I jump up on that ledge?” This is the area where tests can be incredibly useful.
Before I came to Atomic, I spent several years working in the video game industry. I left it for a number of reasons, but I wanted to still pursue game development as a side project.
When recently I started up a new game project, I went looking for a good engine. My requirements were:
Cross-platform (PC, Mac, Android, iOS)
Free to try
Using a programming/scripting language I know and like (sorry, Lua fans)
I ended up picking the Unity3D engine. (Unity 4 just came out, by the way. I haven’t upgraded yet, but that’s where I’d start if you want to get into using Unity.)
Because of my work at Atomic, I’ve become a big Ruby fan. There aren’t really any viable cross-platform game engines that use Ruby — or Python for that matter — but when I saw that Boo was Python-like, I decided to try and write a game in Boo. Little did I know what was in store for me.
Here at Atomic Object we have a few game developer hobbyists. I've been tweaking the basic 2D collision detection in Gamebox for awhile now. When Chipmunk 6 released with performance gains, I decided to take a look. Part of the secret sauce was the use of an axis-aligned bounding box tree (AABB tree). Porting this simple data structure to Ruby sounded like fun. I found a lack of simple 2D examples with source code along the way, so I decided to publish mine.
Read more on 2D Axis Aligned Bounding Box Trees...