I recently had the pleasure of trying out both of the new cloud-based gaming services, OnLive and Gaikai. My expectations for their functionality were really quite low. Horrible input lag. Awful video and audio quality. Those are the sorts of issues I expected would be bothering me to no end, solidifying my preconception that cloud-based services were a good fit for web backends but had no place in gaming.

After using the services, I changed my tune. OnLive and Gaikai are a clear vision of the future of game content delivery. Take a moment to give one of them a try if you haven’t already. OnLive is the more mature of the two services.

For those of you who don’t know what these systems are all about, both services essentially run games on their server farms and then send you a live stream of the video/audio that their computers are generating. The input you provide on your computer is sent to their server, the game updates, and it sends you back the next frame of video. It’s a throw back to computing in the 60s and 70s; a mainframe computer does the heavy lifting and your dumb terminal simply deals with input and output.

Input latency for most types of games was negligible. This is what I thought was going to be most painful element of cloud gaming but both systems in their current state feel great. There is no doubt that competitive games like first person shooters or fighting games are still best played off the cloud. On the other hand, I was surprised that all third person action games felt just fine even with the added latency of an Internet round-trip. For most types of games, input latency isn’t a problem.

Video and audio quality were much better than I expected, though not perfect. Depending on your connection to the cloud servers, video quality ranges from just ok to abysmal. On a good connection the compression artifacts were ignorable, though video quality zealots will not be happy. If your Internet connection is slow or flaky you will get a much worse experience in comparison to playing locally. That said, my modest home connection, an AT&T DSL connection that runs at less than 5 Mbps downstream, had little problem with the load. As Internet connectivity speeds increase, I’m confident video and audio quality will improve.

Switching from a consumer’s perspective to a developer’s, there is a lot to like. I won’t pretend to know all the technical details of OnLive or Gaikai but I can extrapolate a bit and imagine what they could end up looking like in the future. There are four areas that have me particularly excited.

1. Console-like fixed hardware platform

Let’s assume all the games are running on cloud-based virtual machines (VMs). When you ship your game, you define what hardware you want it to run on, ensuring that the level of quality is high for every player of your game. Just as if you had shipped it on the consoles of today.

2. Hardware platforms can be incrementally improved at any time without bothering players

If a great new CPU or GPU is released, the cloud service provider can incorporate it into their server farm. Players don’t need to buy PC upgrades or new consoles.

3. PC as target platform

Instead of building games for console platforms that start out with an immature set of tools and APIs, a new learning curve for hardware specific quirks, and other assorted growing pains, developers would only need to target the PC. The PC is a highly mature platform with a lot of fantastic development tools. Now that the pain of trying to ship on an extensive list of hardware configurations is eliminated, the classic PC pain area, it feels like a no-brainer to switch off of consoles and back onto PCs.

4. With no extra work, ship on any platform that has an Internet connection and supports your input controls

PC, Mac, Linux, iPhone, iPad, Android, set-top boxes like the Roku or iTV, hell, your TV via embedded software. All of these devices have Internet connections. As long as they have an input mechanism that supports your game, you can ship on these platforms. This is fantastic for getting your games in the hands of as many potential fans as possible.

If the cloud technology continues to improve in the direction I think it will these changes will change the way games are built.

Consider the upcoming PlayStation Vita, a complex piece of mobile hardware that will be released soon. It looks great for gaming, with an ideal control layout and powerful hardware. Now imagine it as a cloud-gaming dumb terminal instead. The challenge of pushing CPU/GPU performance while fighting against heat and battery life with highly complex hardware would be eliminated, making the device extremely cheap to manufacture. Players could purchase one for perhaps $50 or less. You would be able to play super high-end games at any time on the go. Imagine playing Uncharted 3 or the latest Call of Duty at full quality on your little piece of mobile hardware. Incredible.

If I was a platform provider like Sony or Microsoft I would be seriously considering what this shift could mean for business. Instead of shipping hardware platforms to consumers and developers, imagine instead a PlayStation service, where Sony’s best games are hosted. As a gamer you can access it from a multitude of devices at any time, from any Internet connection in the world. That is a fantastic value proposition for the consumer.

I think it’s obvious that Internet streaming is already taking over as the predominant method of delivery for music and video. Services like Netflix, Hulu, Spotify, Amazon, and iTunes offer a plethora of on-demand streaming content. I don’t see any reason why games won’t be next and I’m very excited about the possibilities.

We are currently beating out these other top-10 applications – “Sexy Japanese Girl” at #3, “PeekababeLite” at #6, and “iSashimiLITE” at #9. I can see what our new marketing slogan should be – “More popular than babes and fish!”

The application was not featured by Apple so that wasn’t the cause. It may have been featured on a prominent website or possibly on TV but we have not been able to find out where just yet. Hopefully it will become an Apple featured application now that it has hit the top of the App Store here. If anyone has seen anything about this application in mainstream media in Japan please leave a comment or get in touch with me.

Here’s a graph from our Pinch Media statistics to give you an idea about how much of a change has occurred in the last three days.

My silly drinking minigame Get Dirk Drunk, also known as Hebereke-kun in Japan (へべれけくん), is getting some release press on a number of Japanese iPhone blogs. The minigame was created as a comical play on the spirit of Japanese drinking culture so I’m glad some people are enjoying it and not taking it too seriously.

Here is the direct iTunes Store link if you are interested in checking it out further.

Coverage:

• あいほん野郎: 酔っ払いに酒を飲ませろ！へべれけくん – this guy loves it
• 新着iPhoneアプリ | meet i [ミートアイ] – uniqueness rating 5 out of 5!
• iPhone用よっぱらいシミュレーションゲーム「へべれけくん」
• へべれけくん – 飲みの席で重宝するゲーム [プレスリリース]

If you want to see the game in Japanese first download the latest version (1.2) if you haven’t already and then set your iPhone language setting to Japanese (written as 日本語 in the menu) and you can check it out. Hebereke-kun’s voice comes courtesy of my friend Yoshi to give it the authentic Japanese feel.

First, here’s a screencast I recorded after the live presentation. The voice and picture quality is clear but it lacks the crowd reactions.

Next is the live version. The quality is much worse but it is still watchable. The presentation is a bit different as I played up some things for the specific audience and fed off their reactions. The audience reactions also make the atmosphere more lively and more fun.

Thanks to Jean Snow for the heads up on the opportunity and to James Kay, Paul Caristino, and all friends who showed up to support me live. You guys rock.

As I mentioned earlier this week I gave a presentation at Pecha Kucha 62 in Tokyo last night. I built 10 brand new tiny games in less than 10 hours for the event. I know at least one person was recording a video so there may be video footage soon. If not I will do a screencast of the presentation for the web.

Although the games were mostly (completely) silly they seemed to go over well with the crowd and I got some laughs. A full set of photos is available on Flickr.

Right now I don’t have the time to post all the details of all the games but will do so in the near future. For now here is the game list, in the order they were presented:

1. “Can You Say Pecha Kucha?” – iPhone – Rhythm game
2. “Shinjuku Shame” – Web (Unity) – Homeless staring FPS
3. “Game Developer Life” – Web (Flash) – Game industry wage slave simulation
4. “Scream Test” – iPhone – Screaming competition
5. “Voice Invaders” – iPhone – Voice controlled vertical shooter
6. “Surfing on Sine Waves” – Web (Flash) – Procedurally generated surfing game
7. “Architris” – Web (Unity) – Blueprint Tetris
8. “Para Para Punch” – iPhone – Hooligan punching game
9. “Blind Masseuse” – Mac – Sound based massaging simulation
10. “Basket Bomb” – Web (Unity) – Basketball terrorist physics game

I leave you for now with this photo of the crowd as I was speaking. You can see some laughs as well as some contorted faces filled with horror. :-)

During halftime I was surprised to see the WoW logo.

It was kind of shocking to hear the announcer say the words “World of Warcraft.” That’s the first time I’ve seen a non-sports game being advertised in a sporting event. The game industry has come a long way.

In the “Health & Fitness” section of the Japanese Apple application store the free version of Prescription for Sleep is the most popular application.

The application is much more popular in Japan than it is in the rest of the world currently. I’m not sure why that is given that there are far more iPhones in the US and Europe. Certainly having it localized in Japanese helped immensly but that doesn’t account for its comparatively lower download count in other countries. There may be cultural elements at work here I don’t understand. The idea for the application was conceived by a Japanese person after all and perhaps simply appeals more here.

The application certainly isn’t for everyone but it is nice to see that a good number of users are enjoying it.

“Team Leadership in the Game Industry” was recently written by Seth Spaulding, Art Director at Firaxis Games, and analyzes what it takes to be successful in a leadership role specifically for game development. It includes a number of interviews with game industry veterans who are in lead or executive positions and examines case studies of leadership failures via the author’s experience. I ordered it from Amazon.com and when it came to Tokyo it apparently made it’s way from Germany (yay for globalization!).

The book starts off with giving some examples of the organization of game development companies of various sizes. If you’ve been in the industry for a while this is nothing new but for people new to the industry this is a good overview.

What the book does really well is identify positive leadership traits that earn the respect of your colleagues and get the job done. Perhaps more importantly the book identifies many skills that may appear to be of highest importance but really aren’t in a leadership position. A simple example – the lead artist does not need to be the best artist on the team. Of course they must know the tools and technologies that are being used to understand the work and to earn the respect of the team but the primary goal of the lead is to manage and help the team succeed as a whole (and possibly do production work depending on the size of the team). There is nothing wrong at all if they are also the best artist but it should not be the main requirement as making art is usually not the primary job function of the lead on a large team.

In an interview in the book with Joe Minton, the President of Digital Development Management, he summarizes his thoughts on good leadership qualities and bad which match fairly closely with my views as well. From the book:

S.S.: What are the most common traits shared by other effective leaders in your experience?

J.M.: Openness, communication, trustworthiness, integrity, ability to motivate, willingness to take measured risks, not procrastinating, understanding that being in charge doesn’t mean being the expert.

[...]

S.S.: What are the worst traits a leader has exhibited in your experience?

J.M.: Randomness, thinking one is the expert on everything, being wishy-washy, weak willed, easily overwhelmed, operating from fear, pretending to be a celebrity.

The book is loaded with great interviews with experienced industry veterans (not “celebrity” developers) that are quite valuable.

Continuing on it includes advice on how to craft job descriptions for leads such that responsibilities are well defined and understood. This is something I wish happened more often across the industry. When applying for a job it is usually quite clear what your responsibilities will be when hired but internal promotions that come with new responsibilities should also include very clear expectation setting for the requirements of the role. The author has suggestions on how to accomplish this in a clear way.

There are plenty of specific tips on many smaller scale but important job functions such as running meetings. Overall it is clear Mr. Spaulding has been in the industry for a long time and has accumulated a lot of valuable experience. I wholeheartedly recommend the book for both people interested in becoming a team leader and as a way to see new perspectives for existing team leaders.

Sometimes this is very hard to do. Especially if the task I am doing is useful, technically sound, and/or clever. But even if you are doing something that encompasses all of the above it still might not be worth doing… which can be a tough pill to swallow.

Here’s an example – I’m currently working on a project where graphics need to be sequenced to a music track. I created an XML definition for the sequencing so it is primarily data driven and created a little scripting language via XML tags for doing things like moving/scaling/rotating/fading/tinting sprites. It’s working great and dramatically sped up the initial sequencing.

While working with this further, I started to see lots of cut and pasted XML script to repeat the same kind of action. Just like cutting and pasting runtime code this is terrible for maintainability. I wanted to make subroutines for doing multiple combinations of moving/scaling/rotating/fading/tinting that could then be re-used in 1 line of XML to do something more complex. E.g., scale up an object, move it left 100 units over 2 seconds, tint it red, wait 2 seconds, then destroy it.

There were two clear ways to do this:

1. Add new complex commands to the runtime code – hardcode a list of simple actions into a class that does something complex – and then expose them in XML. Still data driven but more specific to the use case and multiple of these would have to be added over the course of the project.
2. Create a way to define these subroutines in the XML itself. This is more extensible and could then be quickly tweaked without recompiling the code.

Being in a “data drive everything” mood I chose the latter and went to create the ability to define a subroutine of commands in the same XML sheet the sequencing commands live in. Basically this was more or less creating a programming language with subroutine calls and passed parameters (albeit very limited in scope). You can define subroutines in XML that do a bunch of sequenced actions then call that subroutine from the XML in the sequencing block. This is far from the most difficult task I’ve completed as a programmer but it was definitely time consuming to set this up in a generic and parametrized way.

I just spent the last 8 hours working on it and I’m not sure it was worth the time. This is a small project and adding some extra subroutine types in a half-data driven half-hardcoded way may have been smarter as each individual case would have taken about 5 minutes to build (and the number of individual cases is unknown… maybe it is just a few!). If this framework was going to be re-used many times by many developers doing it the fully data drive way would have been worth it for sure. But for something that may end up being a one-off I think I should have waited before committing the time to this unless I was sure it was necessary. The agile programming method would have told me “do the simplest thing that will possibly work, refactor later if you need to” which I don’t think is correct 100% of the time but is correct the vast majority of the time.

Live and learn.