Bark of Bark and Fester LLC on Flash, HTML5, technical development on the web. Preliminary to ROTOPO’s beginnings. This post is called “Who killed the web game?”
“I imagine Steve Jobs riddled with tumors and lying on his deathbed, reflecting on his legacy. Sure, he had developed Apple into the most important tech company on Earth, made the personal computer friendly, functional and fashionable, and enlightened us to the virtues of obsessively thin rounded rectangles of the German design school of bauhaus. But all that pales in comparison, he affirms with his dying breath, to his single greatest achievement: He found the final solution to the Flash problem, and it was murder.
Likely, Apple’s intentions were motivated by difficulties implementing flash on tablet devices, and by an effort to remove competition for apps built to run natively in iOS, but the effects of this decision were not limited to mobile. When Jobs pronounced Flash to be passé, shockwaves rippled through the gaming world. How could we have been tempted by the forces of darkness for so long? How could we ever go on to newgrounds or addictinggames and play games like we used to back in high school. (Heck, you may have even played one of mine)?
Web games were dealt a blow that “day” and have never recovered. We look at them with shame and instead load up Candy Crush or Angry Birds on our iPhones when we’re looking for that casual distraction on-the-go. Apps, supposedly, are just faster, easier, more convenient, and so on. Nevermind that all the apps we pay a dollar for today (plus a dollar for every additional 100 gems) are freely available in nearly identical Flash incarnations, and nevermind that there’s only a handful of ways to tap, swipe and wiggle your finger in front of your tablet screen, because your phone is there in your pocket when you need it. If you’re looking for a deep gaming experience instead, you’ll load up Elder Scrolls or Call of Duty on your console of choice. Web games are ostensibly dead, supplanted by apps, and no longer serve a purpose.
While it may seem that web games fill no niche, and that flash, as Jobs puts it in his letter, “was created during the PC era – for PCs and mice,” the reality is that for gamers, the PC has never been more relevant. True, Flash can be considered dead for everything but Farmville, but in its ashes the tremendous HTML5 was born, and I hope to convince you here that the web can once again be an important place for gamers. It has all the qualities of an ideal platform for game distribution: a GPU pipeline, no lengthy downloads, no installations, no proprietary IDEs and app stores, and little to no discrimination between operating systems. It should also be stressed that web games which require a connection to a server are at a much lower risk of being pirated. It’s going to take a lot of work to realize the potential here, from game studios, browser developers, and even financial services making it easier to facilitate payments for web apps, but in the end, I’m predicting there’s oil here to strike.
Apple’s decision to kill Flash and facilitate an era of casual mobile gaming nearly killed the indie web game, but HTML5, (which Apple has supported) provides a means of reclaiming this lost territory. The internet belongs to the people, after all. Let’s make, play, and sell games on our terms.”
“Years back, I experienced the unique pleasure of getting paid to do exactly what I love. Right after graduation from college with a shiny new CS degree and lofty ambitions, I landed a coding job at an ill-fated Silicon Valley startup.
At first I worried that I wasn’t exactly qualified for that job. Sure, I enjoy programming but it’s computer graphics that really gets me out of bed in the morning, and has since I was first introduced to Flash at the age of 10. I’d been making video games ever since, but I was warned by peers in the valley to steer clear of the video game industry, which I had been told by many is where passion goes to die in the 21st century. So I thought I’d cast my lot with the entrepreneurs and their get-rich-quick schemes.
As luck would have it, this particular company had hired the most eccentric designer I expect I’ll ever meet. He was the Michael Bay of UX design. He wanted everything big, and bold, and colorful, and animated, and our young CEO didn’t know any better than to give him free rein. My job was to make his vision a pixelated reality on every platform: gratuitous animations, 3D models, particle effects, buttery transitions, easing curves calibrated to the nth dimension… It was obscene. It was reckless. It was a dream come true.
Ultimately I want to make awesome games and get them in people’s hands. Experimental, novel, heartfelt interactive experiences that anyone with a browser can access. Think of the distribution model – just get the urls circulation on social media and you’ve got instant customers with no downloading or installation. Take advantage of all the nifty features that HTML5 now offers, and you’re really cooking with fire. Sure, I’m not going to be bringing Call of Duty to Firefox any time soon, but the next sleeper indie hit? Why the hell not?
So, in light of that, here’s a technical sales pitch for developing games on the web. I certainly hope a lot more people do this because it will force browsers to keep optimizing, bolster this democratic and non-proprietary distribution platform for games, and spur on outside developers to work on handling the financial aspects to make selling games over the web commonplace.”
“I think it was about the time I read through the Web Audio API that I realized just how thoughtfully crafted things had gotten in just a few short years for us web developers. Here’s a look at all the cool stuff you get right out of the box:
As of writing this, WebGL is supported in the latest versions of all major browsers. Posterity might find this an obvious fact but – for me, this is great news. Even Microsoft has it running smoothly on their new browser, Edge. And, mobile devices are catching up too. Framerates on the newest Androids and iPhones are running webgl games on par with my laptop. Not to mention that packaging your app in a webview (instead of hiring a whole team of Java or Objective-C devs just to translate your code), is becoming more plausible as web performance improves on mobile.
Most people shouldn’t write their own graphics engines. Go ahead and just use THREE.js. It’s got a mountain of useful features and wrappers that make 3D programming easy and some very committed developers (I posted a bug there once and it was fixed by dinner). If you use it and find that there are instances where performance optimizations require you get access to the rendering loop and hack the webgl code yourself, then feel free to modify it, or start from scratch with your own engine, but chances are you just aren’t using THREE correctly and you should study the API.
Canvas is an odd beast. It’s sort of a halfway home between webgl and the DOM, and why you’d ever need to use it is a matter for public debate. I’ve found that canvas can make an excellent texture generator – and isn’t too shabby for 2D animations either. Dynamically generating textures also save you bandwidth.
Use canvas to bring text into your webgl games. Canvas can render fonts (and why not use Google Fonts to get some snazzy ones) to a bitmap which can be loaded into webgl textures and slapped onto a quad.
Similarly, canvas provides a suite tools for making 2D drawings and shapes a lot quicker then you could make them in WebGL, and tasks requiring this sort of behavior pop up quite a bit more often than you’d think.
HTML and CSS take care of UIs. Menus, prompts, HUDs and overlays provide the tools for creating scalable UIs, which can be a struggle in other gaming environments.
CSS is a powerful styling tool, but it takes quite a bit of trial and error and memorization to get the hang of it. Get to the point where it’s second nature that ‘position: relative’ is overloaded to allow child elements absolute positioning, and don’t ask why.
- Ditching types:
- Personally, I recommend embracing the anarchy and power that comes from ditching types. It will take some discipline with naming and organization, but soon your code will be a lot easier to produce, and more concise and more flexible than ever.
Web Audio is beautiful library that grants buffer and source control to developer, along with a suite of processing nodes for nifty effects like audio panning and doppler shift, as well as seamless looping and parameter animation.
The basic model for coding audio systems involves writing buffer data from a sound file, and attaching it to a “source” node, which is then chained across more nodes, (such as volume or effects filters) to the audio destination (the speakers). You can also substitute oscillators for buffer sources to make your own synths, which is a singularly pleasurable experience. The intro music in ROTOPO for example, is generated programmatically with midi-like information sent over to a synthesizer.”
Considerations and Constraints
“HTML5 imposes some constraints on developers, but for indie devs who don’t have a large studio, sometimes working with constraints can be a blessing in disguise. Keeping assets modest, for example, means you can make more content more quickly. If it worked for Minecraft, it can work for you.
The performance hit from running your big, bad 3D game in the browser as opposed to natively is comparable to removing the CPU from the system and smashing it with a hammer. It’s bad. Real bad. I couldn’t possibly convince you otherwise. However, there are two related ideas which caused me to look passed this seemingly devastating fact. One is that modern gaming PCs are so souped up and powerful that even a 50% processing hit is still more than enough power to make a compelling gaming experience the likes of which we all grew up playing and loving. And two, browsers are getting faster and faster by the minute. So much processing happens on the web that Google has invested big bucks into its speedy V8 compiler, which takes out a lot of the burden of an interpreted language by applying multiple doses of magical spells and demonic conjurations – I assume.
Bandwidth and Downloading:
Game developers must consider loading times while making content for the web, so that players don’t need to sit and wait for megabytes of audio and textures to load while waiting to play. Considering other technical limitations to browser performance, this all adds up to the recommendations to make games lightweight and low poly, and to use audio loops as much as possible.
Without reliable means of saving and loading data to disk, (without having a player download files on their own), saving games is left with one obvious solution: upload data to the server and associate it with a user account. Typical save files are not more than a few KB, so the storage requirements shouldn’t bust your server, and this gives customers a reason to make accounts and pay for content rather than download it illegally.
Depending on the sort of game you’re creating, ajax calls could be plentiful or non existent. To make interfacing between frontend and backend easier on developers, I highly recommend using Node.js with Express.js, as this will keep the codebase in a single language, and keep JSON a consistent format. I won’t get into the requirements for database storage and managing many thousands of users, because i’m no expert in those fields, but hope to be soon.
While differences between browsers has been a major impediment to HTML5 apps in the past, Microsoft especially has caught up with their lightweight and powerful new Edge to level the playing field. Now, the latest versions of all major browsers support the above features and more.”