C++

Flash is great for stuff that runs in the browser, but for server-side heavy lifting, C++ is my go-to tool.

C++'s many flaws and disadvantages have been carefully documented over the years. The language is too big; the compilers produce lousy error messages; the standard template library is too hard to understand; there is no need for a low-level language in this day and age.  My biggest gripe with C++ is the sheer number of ways to introduce near-impossible-to-find bugs: using uninitialized memory, freeing memory twice, using a dangling pointer, mixing malloc/free with new/delete, leaks, overruns, dereferencing NULL ... the list goes on and on.

However, C++ has one advantage that makes it all worthwhile: predictable, screaming fast performance. The compiler generates real machine code, not bytecode, and the old school manual memory management means that the server will never take a time out to garbage collect. For MMOs, better server performance saves money by reducing the number of machines needed, and it increases the number of people that can play together on the same server. As for the excruciating task of preventing pointer bugs ... I guess I'll just have to live with that.

Flash

I've been using Flash, specifically its programming language Actionscript 3, for about four years now.

I started writing Actionscript code with Alex Carobus back when we founded Wild Shadow Studios. We chose Flash because it was already everywhere -- just about anyone could play a Flash game without having to install a plugin. We believed strongly in eliminating barriers that prevented people from trying our games, and Flash offered one-click, no-hassle access. Surfing to our website would fire up the game automatically.

What a pleasant surprise it was to discover that Actionscript 3 (which was new at the time) was a modern object-oriented language, with compile-time type checking, classes, inheritance, encapsulation, and other language features that engineers look for. It had extensive facilities for moving pictures around the screen in various ways, which is pretty much the main goal in video game development. But what really sealed the deal was Actionscript's support for sockets -- a game written in Actionscript could open a direct connection to a server, which meant we could use Flash to make an MMO client.

I have a few complaints about Actionscript. Its garbage collector has some frustrating quirks. It's not nearly fast enough for computationally intensive code. There are a few syntactic oddities. But on the whole I've been extremely pleased with Flash, and I plan to keep using it.

2D

Everybody knows 3D graphics are awesome, and pretty much every game-playing device has 3D acceleration hardware built in. So why not 3D? It's just one extra D!

From my point of view as an indie making a Flash MMO, there are a lot of drawbacks to 3D. Most have to do with costs: time, money, space, and the big one, opportunity.

First of all, it's difficult, time-consuming and expensive to create 3D models. People spend years learning how to do it. In addition, 3D modeling packages can cost a lot themselves.

Second, textures. They have to be conceptualized and painted, and the UVs have to get mapped correctly, and the texture fragments need to get packed efficiently into rectangular bitmaps. This takes more time, money and human effort.

Next, the models have to move in 3D. This means rigging bones inside the models and painting bone weights on the vertices, then moving the bones around to create an animation. Every limb, facial muscle, u-joint and wheel needs attention from a human animator.

Fourth, 3D stuff is big. All these vertices, textures, UV-coordinates, normal maps, materials, and animations take up a lot of space, which is a big problem for any game that streams content.

Furthermore, the whole game has to become 3D -- not just the models. So many things get harder: collision detection, camera control, user interface. And then there are 3D hardware techniques to consider: hidden surface removal, z buffers, vertex winding, normal mapping, radiosity, subsurface scattering, dynamic level-of-detail optimization, pixel shaders, and so on.

Sixth, realism. When you can render things in realistic 3D, the temptation is to make the game itself more realistic, essentially culling huge swaths of fun but unrealistic gameplay opportunities. Realism is overrated; if reality were so great, we wouldn't be playing computer games at all.

Finally, 2D can be just as awesome. 3D is not necessarily more fun or better looking than 2D. But it is always more complicated and expensive.

Global Game Jam 2012

Today I was a judge at the Pittsburgh edition of Global Game Jam. My co-judges were Rick Sebak of WQED and Joe Wos of Toonseum.

There were over a hundred jammers and 21 completed projects. All were impressive; some were amazing. Some of my favorites included Eternal Guardian, Generations, I Broke the Thing, My Life is Yours, Snakes! Snakes! Snakes!, KaChunk and Super Ouro Bros. However, the judges and jammers agreed that the hands-down favorite was HebiHanabi, a highly polished two-player snake game with a cool fighting mechanic.

Congratulations to all the jammers, worldwide!

Streaming content

Traditionally, MMOs force a big client install, measured in gigabytes, containing not only the game code but also big gobs of assets like 3D models, textures, sound effects, voiceovers, animations, music, etc.

Flash games, on the other hand, must be able to start up extremely quickly, and so they have to be as small as possible. A Flash MMO that has both a small client and a lot of content must stream the content after the client has started up. The trick is to send only what the client needs, just before it needs it.

MMO worlds can be vast, but for any given character, the immediate environment is not that large. An MMO may have thousands of types of creatures, buildings and objects, but a player entering the game won't have too many of them in view initially. If each item is not too large, it's feasible for the MMO to be 100% streamed.

The characteristics of world objects, such as hit points, attack rate and attack damage, are small: just a few numbers. Likewise, 2D vector art can be represented very compactly as a set of colored line segments, with procedural animations. Short sound effects are only about 5k each, and only a few are needed at any given time, based on what types of objects are nearby. Maps and ground terrain are potentially big downloads, but it's possible to procedurally generate the world map identically on both the client and server, with only a random number seed being passed. Music is about a megabyte per minute (depending on bit rate) but it can start playing before it has been fully downloaded, like a YouTube video.

Using a combination of these techniques, the client download can be limited to just the game code itself, with all of the content streamed in on demand. This leads to snappier downloads, quicker startups, and happier gamers.

Vector graphics

I grew up playing the arcade classics of the 1980s, and many of my favorite games of that era use vector graphics instead of bitmaps: Asteroids, Tempest, Battlezone, Star Wars, and many others.

Vector graphics fell out of favor toward the end of the decade, but in recent years they've made a mini-resurgence as part of the retro-graphics trend in downloadable and independent games. My favorite of this crop is Geometry Wars; others include Captain Forever as well as Radiangames' troika of Inferno+, Ballistic and Fireball.

Of course, modern vector graphics are simulated on bitmap displays, and these days they include gorgeous-looking neon glow effects and thousands of sparkly vector particles.

One huge advantage that vector graphics have over bitmaps is that they are very small. This is important for Flash games because loading time is critical. Every extra second of load time means more potential customers giving up and playing a different, faster-starting game.

Another thing I like about vector graphics is that they can often be defined and animated mathematically by an algorithm, which reduces the need for human artists to churn out animation frames. Indie teams are small, and when a computer can do a job it means the precious, precious humans can concentrate on other tasks.

Flash MMOs

I'm starting a new company, Jetbolt Games, this month. I'm very excited about it! For the last few years I've worked with Alex Carobus for a company we co-founded, Wild Shadow Studios. Together we made Realm of the Mad God, a massively co-op browser MMO shooter. Alex is an extremely talented and hard working person and I am very lucky to have had the chance to spend so much time working with him.

I hope to revisit Realm of the Mad God in this blog, but for now I'd like to say a few words about Flash MMOs. I think Flash games are great, and I think MMOs are great, but both have serious weaknesses. But like peanut butter and chocolate, when the two come together something magical happens.

Flash games as most people think of them are quirky, innovative little games you play in your browser, for 10 seconds or 3 hours. They engage the player immediately -- they have to, because there are literally a thousand more Flash games a click or two away. They are single player experiences which you play for a while and then forget about.

MMOs, traditionally, are enormous 3D mostrosities that require hours to download, a serious 3D graphics rig, massive amounts of hard drive space, and a monthly subscription. But MMOs have compelling online communities that engage players for months or years.

In many ways Flash games and MMOs are opposites, but when an MMO becomes a Flash game, an amazing transformation occurs. The download time goes away, because Flash gamers have very little tolerance for something that is not fun from the get-go...and loading screens are not fun. The requirement to register or pay before playing disappears. The hardware demands mostly just vanish. But the community and long-term engagement of the MMO come along for the ride. You get a new, different, better thing.