HTML Gaming for Core Gamers
This is part of a blog series discussing my afterthought on attending PAX Dev and Prime 2013 in Seattle.
You can read the others here and here.
I've been a gamer for a really long time. Since the Commodore 64, but particularly when my dad brought home an NES in the late 80's fro the US as they were exceptionally hard to come across in Canada. Having the family over to go swimming and play Duck Hunt and Super Mario Bros. was a defining moment in my life that has lead me down the path to love video games the way I do. I identify as a "core gamer", which to me is someone who looks deeper into video games as a medium, much like movie buffs or cinephiles look deeper into film.
Now that I'm trying to go from business application development to making video games in some capacity, I find myself challenged by the technologies that are discussed
How do you put HTML Games in front of Core Gamers?
This is a big question I've been struggling with since trying to produce and move into the video game development world. It always seemed to me that this is something that JavaScript and HTML game developers needed to clear up to their audience. When I talk to core gamers about the subject of HTML games, they respond with the same sorts of thoughts that plague me:
- I'm not a big Facebook gamer, so they don't really have a future for me.* I'm a fan of deeper gameplay, not so much casual gaming.* I only play games on my TV console, so that doesn't really apply to me.
Up until PAX, I figured these were the questions that needed to be addressed head on when we made a game. I even noticed that a "Lessons Learned from Five Years of HTML Game Development" panel was scheduled. When I talk about HTML gaming, people hear "HTML" and they associate web. I need my game to get past that. How is anyone going to do that?
My answer was found in the first hour of PAX Prime.
Enter Atari Arcade
On the main expo floor, right near the front of the hall you saw a large booth dedicated to the Atari Arcade. It was marked as Microsoft booth on the PAX map, but the focus of the booth was for people to compete for a chance to go to Tokyo by getting the high score in one of the classic Atari games hosted on the Atari website. At first I wasn't sure what to expect, but when I returned I found this:.
A line up. A line up to play an HTML Game at a conference geared towards core gamers. Sure the IE logo was on the booth and on the swag they gave away (which I'll talk about in a minute), but at the end of the day people were lining up to play an HTML game.
This blew my mind, but the secret sauce wasn't in the prize or the swag they gave away. It was simple once I saw the booth: Gamers care about games, not the technology. It's a web-based game, but that totally didn't matter because they playing Centipede, a classic Atari favourite. They could play Missile Command, one of my personal favourites. At end of the day it was the quality of the game, not the technology that they were worried about.
Sure, I've had plenty of conversation with gamers about technology and what can do this, and how something is more powerful than that, but really if the game is great the gamer looks past the weaknesses in the technology and plays the game. Regardless of whether its natively installed, has high preforming graphics code, or if it's just JavaScript and and HTML canvas element. At the end of the day it's about whether ror not it's a great game or not.
The IE team looked past all the questions we hear daily and just put a great game powered by open standards and said: "Hey! Come here and play that game you like from the 80's". The gamers respond with, "Okay". How awesome is that?
Thanks Captain Obvious
I know it sounds obvious, but this is something that I haven't seen in all my reading and observing of the indie game scene over the past year. The HTML development discussion I see is always talking about the simplicity of the game and defending that it's not as powerful as a native technology like Unity. To me not only hearing people play an HTML game they liked enough to line up and play, but also see that nobody was defending the technology to anyone, whether that was HTML or the web browser itself.
This was a real breath of fresh air, and really showed me that my thoughts of continuing down the path of HTML game development is the right way to go.
Developer's Side Note
This all ties into something that I saw at PAX Dev that really blew my hair back. On the floor for the conference, Nintendo had a booth setup for something called the Nintendo Web Framework. It turns out that you can use the Nintendo Web Framework to write JavaScript apps and games for the Wii U. The SDK is based on WebKit and handles web standards, but also provides some custom APIs for using the second screen that is on the Wii U gamepad.
I saw a top-down space shooter game, written using ImpactJS working on both screens. All pure JavaScript running on two canvases, the TV (which was rendering in 720p) and the WiiU controller, which displayed game stats on a second HTML canvas. Not the flashiest demo using the second screen, but amazing that I know all the moving parts to make a Wii U game.
For the full scoop go to https://wiiu-developers.nintendo.com/.
Epilogue
In the end, I am feeling more confident about using JavaScript to get my game idea(s) off the ground. Sure, Unity is a leader and will likely continue to be that, but for now I'm going to use what I think is going to be the next true multiplatform technology: HTML and JavaScript.
Thanks for Playing.
~ DW