GDC2013 - WiiU Application Development with HTML5 and Javascript

• Nintendo announces the Nintendo Web Framework (NWF), a framework that allows you to create applications for the WiiU with HTML5 and Javascript.
• The WiiU offers dual screens (your tv and the gamepad), an internet browser, touchscreen, gyroscope, accelerometer, and support for Wii remote controllers.
• WiiU also launched with web service apps such as Hulu Plus, Amazon, and Youtube.
• Wii Street U is a new app by Google created using the NWF.
• The NWF offers a great way to prototype traditional native games.
• "Gunman Clive" is a 2D platformer game that was released on 3DS and in one month, outsold both its iOS and Android versions. There is marketing value in Nintendo hardware and people demand better controls that the WiiU can offer.
• NWF runs on a Windows PC and is based on the Webkit framework. With Javascript extensions, it allows use of the touchscreen, gyroscope, accelerometer, and any of the WiiU-supported controls. It also supports save data, file I/O, software keyboards, video playback, and access to the Miiverse.
• You can use standard HTML5 libraries like jQuery in your applications. The NWF Dashboard interfaces between your code and the WiiU hardwre. It will convert your gamepad touch inputs to mouse clicks. The Dashboard also comes with a web debugger/inspector.
• NWF uses a fast Javascript virtual machine, GPA accelerated graphics, and a great bitmap/sprite renderer. The hardware can run GUI Mark 3 (a benchmarking program) at 60 FPS even when you increase the number of sprites drawn by 10.
• The logo of NWF contains an image of a bamboo because the codename of the project was Bamboo. A bamboo's roots sprout from the ground very quickly, but it has a solid framework to support its fast growth. Likewise, NWF is a solid framework that supports quick development growth.
• NWF is free to use after getting a WiiU devkit and they have a special introductory program for new developers.
• Their business policy
• No concept approval
• Price and release date are independently set by developers
• Distribution will be following industry standard models
• ​In the future, NWF will also support Unity. Unity for WiiU will be distributed for free to all WiiU developers.

​​The Future of Mobile Gaming: A Conversation with Nickelodeon and EA

Nate Altschul from Nickelodeon talked about a bunch of HTML5 game engines and what he recommends.

• Why use HTML5? It has high reach, ease of development, avoids 30% tax, it's a Flash replacement on mobile browsers, and it offers quick iteration.
• There are a few problems with HTML5 right now though. The tech is a moving target (DOM -> Canvas -> WebGL), it's fragmented, there's few "real" games, there are no big success stories yet, and many tech challenges (audio, animations, etc.)
• There are many HTML5 game engines available today. In fact, there are more HTML5 engines than there are "real" games. When choosing an engine, you should evaluate its traction (how is its growth?), your team size, its toolchain (what IDE, visual editors, debugging tools does it use?), its features (canvas, WebAudio, physics), its reach, the languages you can code in, and its price.
• There are many deal breakers that make some HTML5 engines useless. These include no links or examples of real games developed using the engine, no multiplatform targeting, no WebAudio support, no canvas, no lazy loading, no Flash animation integration, closed source, unresponsive development team, large unoptimized sprite sheets, no language support other than Javascript, no screen scaling without affecting aspect ratio, bloated keyframe animations, no cutscenes, no object pooling, inefficient memory management, missing abstractions from browser quirks, no multiple renderers, no localization, and no embeddable entry point JS file.
• Javascript sucks for development. It has no strong typing, can't cross-compile to native code, it doesn't scale well for big complex teams, it has no compile-time error checking, no code auto-completion, no code navigation, no abstraction layer for browser differences, difficult debugging tools, and it's just plain ugly.
• Here are some HTML5 game engines that are actually recommendable because they have minimal deal breakers.
• PlayN - cross-platform engine, uses Java, optimized for Android browsers, free and open-source, uses Eclipse IDE. Gotchas - buggy Flash and iOS backend, installation and setup is a challenge, no more support from Google, GWT overhead, has about twice as many lines of code. Recommended for Java developers targeting Android.
• CreateJS - deep Adobe CS integration, supports Javascript/TypeScript/Haxe, free, uses MIT license, done by Grant Skinner (Flash expert), toolchain (Adobe Flash CS6, Zoe Spritesheet Exporter, EasleJS). Gotchas - big spritesheets, not multiplatform, no SWF export, relies on Flash's DisplayList metaphor which adds overhead. Recommended for Flash developers.
• ImpactJS - features Canvas/WebAudio/Physics, easy to put into native wrappers, uses Javascript, $100, lots of indie games but no professional games yet, has Weltmeister (visual editor), supports Ejecta (iOS wrapper). Gotchas - large animation files, limited screensize support, not open sourced. Recommended for indie developers who want to make side-scrolling platformers.
• Construct 2 - best visual editor, $390, lots of indie games, requires no programming knowledge. Gotchas - lack of fine control, hard to optimize, large animation files. Recommended for beginners with no programming experience.
• Cocos2D HTML5 - familiar API to Cocos2D, high reach (HTML5, iOS, Android), uses Javascript/Haxe, free, supported by Zynga, toolchain inludes CocosBuilder/PhysicsEditor and other Cocos2D pipeline tools. Gotchas - still early, very small community (but will grow very fast), large animation files. Recommended for Cocos2D developers.
• Spaceport.io - supports vector graphics, features over-the-air updates, reach (native iOS and Android), supports Actionscript 3, a few real games developed using this engine, toolchain (Adobe Flash CS6, FlashBuilder, FlashDevelop), very similar to Adobe AIR. Gotchas - only native support, no HTML5 browser support. Recommended for Flash and Air developers.
• Haxe - cross-platform SDK, reach includes HTML5/Flash/iOS/Android/Win8, free, language is ECMAScript (similar to AS3), the only engine that's truly multiplatform, toolchain includes IntelliJ/FlashDevelop/FDT/SublimeText, integrates Adobe CS6, uses Stencyl visual editor, can create cutscenes using Flash-like timelines, backed by Blackberry.
• Honorable mentions (good engines, but has a few deal breakers) - Tresensa, Ludei CAAT, CocoonJS, Playcraft, Turbulenz, PixilJS, LimeJS.

Aron Sagon from EA also gave a talk about games as service. I'm not really sure what the point of his talk was... outside of complaining how difficult it is to make them.

• Aron is a chief engineer who worked on Pogo, Sims 3, Star Wars: The Old Republic, and most recently, Simpsons: Tapped Out.
• He compares the old business model (sell shiny disks) to the new model (sell a service). The service model can be broken down into three steps: identify the user, collect money, and then deliver the experience.
• In the service model, you have to keep track of the users and what they've bought, then make sure you deliver the service to them. In the traditional model, you didn't have to track users. Once they've bought your product, your relationship with the customer is pretty much over.
• It's very, very hard to track your users. Users don't want to register new accounts and even if they do, they are unlikely to remember their account info. Even with iTunes, Apple does not provide information about who is purchasing or using your app. There is a lot of extra overhead to put in analytic and tracking data into your games.
• Building service games is very difficult. Before, you would develop the game and then ship it. Now, you often ship the game and then develop it. Development timelines can be as long as 5 years. And because of the massive volume of players, small mistakes can become big deals.
• Making a pretty game is important, making a fun game is important... but there is much, much more that goes into game development. You need to integrate monetization, virality, engineer databases, etc.

Shoplifter Shuffle Postmortem: Part 2

I am reposing this article that was submitted to my company blog here: http://blog.arkadium.com/shoplifter-shuffle-postmortem-part-2

We're back today to continue our series on our Shoplifter Shuffle Postmortem! If you haven’t already, check out our Part 1 of the series from yesterday, as we discussed our breakdown of what went well when creating our game. And now, for the not-so-perfect part, read on to discover some of the things we learned that didn’t go so well, and our final takeaways from our game development experience.

 

What Didn’t Go Well

1.       The musician wasn’t on-site

Gary, our musician, had all his recording equipment at his own home and he decided to work remotely. Since he wasn’t physically in the same room as the rest of the team, communication was infrequent and minor tweaks to sounds often took more time than it should.

For example, the first time he sent over the theme song, the volume was far too low and we couldn’t hear a single thing. We asked him to make it louder and the second file ended up being slightly louder, but also too low that the words sounded like muttering. We asked him to make it even louder and he took that to mean that we wanted our ears to be blown out. The third file was SO incredibly loud that we put it in the game and played it at 1% volume. We didn’t bother to ask for a fourth version.

Another problem was that Gary was pretty much working in a bubble, going off verbal descriptions of the game and written descriptions of how we wanted the in-game music to feel like. It would’ve taken us too much time to upload a build for his own eyes to see.

2.       Not testing the demo device earlier

From the very start, we knew we were going to demo the game using the artist’s laptop, since he had the biggest monitor. We built the aspect ratio of our game to match the laptop’s screen. What we didn’t take into account was that he was using a four-year-old machine.

When we finished development, we put the game on the artist’s computer and set it to fullscreen. Unfortunately, all the vector graphics had to scale up more than twice its original size. Tons of vector scaling plus a four-year-old processor meant an input lag that was about two seconds long. That may not seem like a lot, but one major element in our game is the ability to watch the shoplifter’s fingers and try to map it to an onscreen character. The two-second lag made it almost impossible to match key presses to character animations, since a character would often keep scurrying along after the player stopped pressing any keys.

We ended up having to optimize the code and convert a bunch of vector art to bitmaps, which only helped the problem a little. (C’mon, who optimizes during a game jam?) Thankfully, we lowered the computer’s resolution so that the game only scaled up by a factor of 1.2, which mostly got rid of the input lag problem.

3.       Not enough playtesting

Since the game is a battle of deduction and observation between two asymmetrical players, the balance between the shoplifter and the security guard had to be fine-tuned. If it was too easy or too hard for the shoplifter to blend in with the crowd, the game wouldn’t be fun for either player.

We needed extensive playtesting to reach this balance, but unfortunately we lacked both time and available testers. As a result, the game tends to become lopsided after a few rounds of practice: a well-played shoplifter can be almost undetectable, making the security guard’s job too difficult. While we had plans for a few subtle “tells” that could help the guard identify the shoplifter, we didn’t have time to implement them.

Our Final Takeaways

This year, we experimented with a minimalist version of the game jam: a lower-stress, less time-consuming experience that still produced a fun and innovative game. Even better, we all had a lot of fun making our game and are looking forward to doing it again! Remember that the game jam experience is all about you – the game developer – so you have the freedom to approach it in whatever way works best for you.

We’re planning to reassemble some of our team for a few other local game jams later this month, so look forward to more postmortems soon!

Shoplifter Shuffle Postmortem: Part 1

I am reposing this article that was submitted to my company blog here: http://blog.arkadium.com/shoplifter-shuffle-postmortem-part-1 .

Shoplifter Shuffle is a charming little game developed in 48 hours for the Global Game Jam. Two of us here at Arkadium contributed to the project – R&D developer David and game designer Brian– along with three other members from the gaming community.

If you haven’t checked out Shoplifter Shuffle, here’s the premise. It’s an asymmetrical, local 2-player game where one player secretly selects a character to be the shoplifter, trying to blend in with the AI-controlled crowd and get past security. The other player plays the security guard, looking for the shopper who’s acting out of the ordinary. The game doesn’t just take place inside the computer monitor, however. Since the two players are seated directly next to each other, the security player can closely watch the shoplifter’s fingers, while the shoplifter can do what he can to cover his hands or press decoy keys to throw off the security. The unique interactivity and fun presentation charmed the judges and our peers, and the game took home a nomination for the Most Innovative Award and won first place for the Audience’s Choice Award.

Some members of the team were experienced game jammers, but this year, they approached the game jam from a completely new perspective. We're here to give a short retrospective of the things that went well for us and a couple of things that didn't. For our Part 1 of the series, check out our breakdown of what went well:

What Went Well

1.       Using an additional time constraint

The Global Game Jam was 48 hours long, and anyone who’s ever had to make a game in 48 hours can tell you it’s not much time. In previous years at the Global Game Jam, we’d stay up all night working, sustaining ourselves with caffeinated beverages and scrambling until the very last minute.

This year, however, we were less inclined to pull all-nighters; four out of five of us are married and most of us had other obligations for the weekend. David (the programmer) had a sister visiting from overseas that same week, Brian (the designer) had to spend half his Saturday helping his brother move, and Gary (the musician) was repainting his house before his parents came back from vacation. Overall, we knew we didn't have 48 hours to spare.

So we said, “Let’s do it in 8.” That sounds crazy, but for us it was a breakthrough. It’s far too easy to let your scope get out of hand, even with the prior knowledge that you only have two days to work on it. The additional, self-imposed time constraint forced us to keep our scope as limited as possible and throw away any ideas that were even moderately big.

Reducing your scope not only decreases development time, but it has a useful secondary effect: it keeps your game simple. I can’t stress how important that is in a game jam environment where people’s interaction with your game is about 5 minutes long. A simple, concise game tends to “demo well” and leave a more lasting impression.

And yes, we did make our game in 8 hours. Well… we did spend 2-3 additional hours playtesting and fixing bugs, but that doesn't count, does it?

In the end, our schedule broke down this way:

On Friday night, right after the theme was revealed, our team went to dinner for some brainstorming. By the time we finished eating, we had found a concept we all liked, and we agreed to run with it. Rather than begin development that night, we decided to go home and start fresh the next day.

On Saturday, we met in the afternoon at David’s house and did pretty much all the art, programming, sound, and design work in one sitting (besides a short break for dinner). Most of us wanted to head home by midnight, and we cut a few features to make sure the game was code-complete by that point.

On Sunday, we met in the morning and did some polish, bug-fixing, and final balancing before the presentations started.

2.       Avoiding the obvious

In addition to the stricter time constraint, we had a second self-imposed rule going into the game jam, which was to not make the obvious. We didn’t want to present our awesome game only to find out that three other teams had the same idea. But how do we determine what is obvious and what isn’t? One simple trick is to take the first three ideas that come to mind and throw them away.

This year’s theme was the sound of a heartbeat. To us, the obvious three ideas were:

- A game about an actual heart, pumping blood or doing whatever hearts do.

-  A game where your character’s ability is directly mapped to their heart rate, e.g. they can jump higher or hit harder if they have a lot of adrenaline.

- An audio-based game where the sound of heartbeats gives you clues on your objective.

Not to say that these options were bad; in fact, Inde’, Pulse of the Samurai, and Silent Hunter followed these three ideas respectively and all won or got nominated for awards. But our team wanted to ensure we were completely original in both theme and mechanics.

We interpreted the heartbeat theme to mean tension and nervousness, which led us to discuss Edgar Allan Poe’s The Tell-Tale Heart and Chris Hecker’s Spy Party. We were drawn to the idea of one player keeping his identity secret, and having the secret be communicated by a heartbeat.

Jumping off from that point, we decided to make a multiplayer game about deduction, body language, and the tension players feel when they’re sitting shoulder-to-shoulder and competing – especially when one is keeping a secret from the other.

We used the heartbeat sound as a way to increase tension at a critical moment in the game. When the security guard is “looking at” the shoplifter (i.e., putting the cursor over the shoplifter’s character), the shoplifter hears a pounding heartbeat through the headphones. This the shoplifter’s moment to panic and think, “Oh no, they've found me!” and it makes for a more cathartic experience when the tension is resolved.

3.       Playing to the team’s strengths

We had an incredible 2D artist, whose specialty was drawing cute animated characters with tons of personality, and a musician with a quirky sense of humor. So straight off the bat, we knew that making something quirky and weird would be our best bet.

While choosing the theme for our game mechanic, we started off with a generic sniper idea similar to Spy Party, which later turned into a border patrol officer overseeing people crossing a bridge. These antagonistic and perhaps controversial themes didn't really fit our team’s strengths, however. We suggested a lighter paparazzi theme, where a photographer is trying to find a secretive celebrity among a crowd of AI characters. This worked better, though there are already similar paparazzi games out there. Finally, we settled on security guards (or “loss prevention officers”) trying to catch a shoplifter in a department store.

While this theme was unusual, it was also relatable to anyone playing the game – we’ve all had our receipts checked by these loss prevention officers before. Our artist really made the game come to life with his art, creating eight distinctive characters and adding all these little touches (like the NTSC scan lines on the security feed) that maintained a consistent visual style. Our musician also ended up writing a theme song to go along our intro screen, which turned out to be a hit among players.

Shoplifter Shuffle,
Stay out of trouble,Blend with the crowd,And stay in a huddle!

But of course every time you’re trying something new, not all things work out well. Check back tomorrow to see our breakdown of what didn’t go well, and our final takeaways from creating our game and working within a game jam!

Global Game Jam 2013

Participated at the Global Game Jam this year and made Shoplifter Shuffle. It was nominated for the Most Innovative Award and won the Audience's Choice Award.



Also submitted an entry to my company blog to summarize the company's activities at the game jam. Read it here -- http://blog.arkadium.com/global-game-jam-2013.