roTopo Summary

roTopo is an HTML5-ROTATION-BASED-PATHFINDING-TWITCH-PUZZLER in which players guide a constantly-moving character over increasingly-complex 3D structures. It’s set to release early-mid July of 2016 on all desktop and mobile browsers. It is free-to-play with youtube ad-enabled content previews and cheap-as-heck microtransactions, which can be read about here.

 
For media, click through here.

For readers, click below to expand posts.

Advertisements
roTopo Summary

roTopo – Monetization 1

Bark and Fester LLC in “A Primer on HTML5 Monetization” with added things about ROTOPO’s development.

Bark is solid good at web things. “The internet is the future”, “it’ll control us” by and by. This is part-way why BKNFR develops on web. Also important, “people, too, don’t move around with their consoles like they do with phones,” and “… sitting at work or at home or at school, at a friend’s poor house…,” of the internet being everywhere. “There’s platform security [, then,] and money all around,” Fester says.

Money is a tough topic for BKNFR. They know the least they need is enough to eat food and make a next game, on and on into the future this way. But Fester has some desire for success for bigger and bigger things, citing “big indie fatboys with games [BKNFR] could make in a week.” Bark says, “just enough is all is needed. No big successes, no popularity; that that would be bad.”

Bad because: Bark graduates into an extremely well-funded startup and watches the kids his age “turn dirtily” into capitalists. The transformation itself is “brutal, inconsistent, and all-of-a-sudden and it seems to be de facto of life.” Over the course of a few hedonistic, delusional years, most fall off as pioneers of a neat experiment that gave lots of money to children to see what would happen. “The enterprise is close to failure now. Investment capital, pure cash, made them through-and-through into morons.”

Bark and Fester’s mixed ambitions aren’t a problem, together. “It’s at least both pointed in the right direction,” says Bark. They’ll “measure ROTOPO’s success and then figure how much more effort goes into a next go-around with another game, if at all any.” Past that, “who knows. It [success] could poison the well, but, god, it better not, right?” says sweating Fester. Bark nods, impervious to it. “Let’s try to get out of our parents’ homes.”

***

For a long time, Fester searched hard for any right, established ways to monetize BKNFR’s web-game ROTOPO. These were things to do with Ad Networks and Publishers and Marketplaces and sometimes Payment Systems too, the whole of which were common enough, though circumlocuted in purpose or implementation.

“It was sort of fun,” Fester recalls, “to peek through other game companies’ legal words [when writing up BKNFR’s own], [and] to pretend to not be surprised at some casual evil legal wit [sic]”. There was no single simple set of words to describe that legal landscape, nor for that of monetizing browser games here, says Fester, where Publishers, Ad Networks, and Marketplaces compete with ambiguity in their taglines and with extravagant legalese in their terms and conditions of service.

Fester is conspiratorial about it, saying “If not a product of using big words to attract investment, then maybe a product of needing to stand out with language alone when in a veritable sea of the same kind of middlemen;” I.e. all are the same and do the same things, but flowery language is more attention-grabbing than the real case is. I.e. they compete for consumers by appearing to be different and appearing to be better because of those differences.

BKNFR has gripes with the lack of clarity in language alone, but neither knows enough about legal anything or business-talk to avoid being embarrassed later when people “call [BKNFR] dummy” for being critical of things they don’t understand.

That said, to protect from this: Fester acknowledges that he isn’t incredibly smart and that this could be wrong: It seems though that no matter the quality of a game above some Publisher baseline, its developers relinquish much of their own control to Distributors (Publishers, Gaming Portals) and Ad Networks too, who ultimately define what kind of audience a game attracts and what kind of game is viable at all.

It’s a common option for developers to avoid the hurdles of total control in marketing and distribution and monetization, presumably because “games are already really hard to make,” something echoed by BKNFR too. “Sad is that they [(games)] get sent to the rest of the world through Publishers who force-fit them into a hundred different demographics with varying successes before retiring quick.” The sentiment between Bark and Fester is of losing a baby to unfortunate circumstance, or because of pre-occupied parenting.

There is still some work in relinquishing control in marketing and distribution and monetization – not being a toss-away thing completely. Developers still can choose which throughput out of a few dozen Publishers (who altogether offer licensing compensation in the range of a couple hundred to nigh a thousand dollars per game) and Ad Networks (who follow a range of dartboard compensation methods), and of course in naming a game at all, or preparing its pitches. Just an example.

BKNFR are avoiding most of what’s established after having done their own research. They’ve luckily got time and they’re working on their enthusiasm for homebrew alternatives. For everyone else, they hope the following rundown of established practices helps. They then detail mobile inspirations and what kinds of monetization are being used in ROTOPO, their debut HTML5 Q-Bert homage from the voxel-ful future.

Bark pleads with the reader: “Please, there are going to be a hundred different elevator pitches for ROTOPO in these posts, let us know which ones are good and which are bad.” Fester: “If they’re all bad, say that too.”

***

The big picture, and the one established and persisting thanks to the 90’s and 00’s Flash wasteland goes:

Developers sell exclusive and nonexclusive licenses to Publishers, who serve advertisements within or paired with licensed games, which are then distributed across a variety of different Gaming Networks and Portals, if more than just its own, depending on the Publisher. This is the most popular practice for monetizing HTML5 games today.

(These examples move from least to most developer control and work.)
You are a Developer attempting to negotiate the cost for a Publisher’s use of your game. ArmorGames, the publisher, would like to purchase a non-exclusive license (meaning other Publishers can purchase licenses too) of your game to host on its own Portal at ArmorGames.com and at various other Portals such as AddictingGames.com. They’ll give you like 500 bucks.
Marketplaces are a similar option, where developers place their games on sale for purchase by Gaming Networks and Portals, essentially skipping over directly interacting with Publishers.

Second to that, Ad Networks are available to serve in-game advertisements for games freely hosted on Gaming Networks and Portals, whose main source of revenue comes from on-site advertising or subscription-based models. Think of Ad Networks as bizdev between Developers and Ad Agencies whose hosted products might fit to be advertised with games. Publishers who distribute games to Portals are sometimes referred to as Sponsors, a term BKNFR has found only used by Ad Networks. Ad Networks generate split revenue based on predefined advertising model rates (read: compensation methods) for themselves and Developers.

You are a Developer whose game is being hosted, for free, at ArmorGames.com for split advertisement revenue. They’ll put ads around your game and you’ll get a portion of that determinant on their terms. Where before all aspects of monetizing your game are left to the publishers who purchase it, here you can then choose to integrate ads within your already-hosted game.
Depending on the compensation method(s) used by the Publisher, you can be paid per impression, per ad click, per video ad watched, etc. The list is growing constantly as Publishers and Ad Networks iterate on their models.

Third, Developers host their own games and get served advertisements by linking with an Ad Network. Some Developers choose to include microtransactions, which many other Developers are adamant about having no place in browser-based games. For one, there is comparatively less trustworthiness in online payments than on mobile platforms. And second, there is a universally not-so-great payment system cut per transaction, which is discouraging for models with small and frequent payments.

You are a Developer without a platform to host your game. You instead host your game on your own website. At this point, you’re more vulnerable to not meeting the traffic conditions set by Ad Networks, because unlike Game Portals, you likely have few views and fewer plays.
You then choose a smaller, self-integrated Ad Network instead. These primarily serve low-quality, poorly-paying advertisements. Note that Google AdSense is NOT provisioned to serve ads to non-Flash-based games. If this term is violated, you are at risk of AdSense suspension.

Fourth, Developers embrace free-to-play. Somehow the traditional tedium of microtransactions in a browser are made to work (something like in Facebook’s own gaming services). Or Developers choose instead to publish their games on mobile platforms, preferring the convenience of one-button payments. Else, monetizing is only as complicated as figuring out how much to charge upfront.

You are a Developer with freemium microtransactions (hopefully) supporting development costs. Or… You’re trying something else, something not entirely covered by the brand of today’s freemium.
Or you are a Developer aiming for mobile and choose one of several HTML5 wrappers for the iOS and Android platforms.

BKNFR don’t really know the actual history of these business practices. Web stuff seems, at least to Fester, like a “two-decade-long hodge-podge scramble.” Web game monetization “… [seems to have] followed the last half of that path, businesses discovering and fitting together ambiguously divvied services all with the intention of monetizing a single small aspect of Flash games. [And that they’ve split these games into pieces (their distributions and platforms and their mechanics) to respond to a growing pressure to make money in an increasingly saturated marketplace.]”

And though Flash is moving off away, still these extremely niche practices remain. Unfortunately, it results in (or highly suggests) a very specific type of HTML5 game: casual, forced-length, addicting, replaceable, manufactured, and attritional. Games in these spaces do not have to be any of these things, BKNFR hopes.

Not like this bares mention. BKNFR thinks that if games are totally defined by how they can be monetized in a specific space, perhaps only because of well-established practices, then they should be described as tools for revenue foremost. Publishers and Ad Networks define and mold games; they do things like “generate revenue” for “middlemen” and “stomp on our weens.” The point is, “Games should define and mold business around them, rather than games around business,” says Bark.

“… worrying to enter a space for a small developer with little backbone and little support and it’s sure there are lots of other devs in this position too that could use encouragement to make web games that don’t resemble every other… [because] they are [necessarily defined] by web-based monetization… but it could just be naive, again thinking that [BKNFR] can be above something.”

BKNFR can’t encourage developers to pursue alternative paths toward success with HTML5 games without committing to do so themselves. So Bark and Fester of BKNFR are committing. Fester says, “Maybe it’ll be a failure and it won’t make anything Cool or money or break new ground and it won’t impress anyone too,” and Bark says, “Or it’ll be really, really fun anyway.” Fester tremolos. If ROTOPO fails, the following is cautionary.

***

BKNFR thinks it’s hard to talk about monetization without any underlying design. They think it’s also tough to treat that part of games, in front of an audience of gamers, as deserving of their attention. They think this because there are lots of negative associations people have with cash-grab games and freemium-model disasters. People don’t like to think that the developers of the games they play should think of them as moneybags.

But business is business and monetization is a part of game development and BKNFR can only feel so bad for so long for wanting support. “It’s always at the forefront to be totally totally aware that whatever monetization is used in ROTOPO is Cool and Fine and not evoking of ‘moneybagging.’” BKNFR wants to respect the player as much as they want the player to play their games and afford them food. It’s a relationship they think is extremely important.

What playtesters were had are gone now because of poor working conditions. BKNFR says, “[we have] regrets… were having them isolated and listening to Bark’s synthy beeps for hours upon hours to see if ROTOPO’s music had any effect on their persons… Fester also another time read to them aloud a series of his poetry and when he asked for and received criticism…” “… then went crazy and fuckin’ kicked me in the shin and then he started crying…,” reveals ████████████, former playtester.

BKNFR takes inspiration from Crossy Road, whose developers “definitely are nicer, more gentle people.” Its model is built on a large amount of individually-priced content with no purchasable currency and is supported by voluntary video ads that make easier the progression of unlocking that same content through in-game means.

Hipster Whale talks in detail about why they were so successful monetizing this way in a GDC presentation. To sum: players are not pulled away from the core of the game with interstitial ads or energy systems or any constant distraction serving social media and marketing. All their advertising, they say, is organic – with no money-in. Their success, attributed to great player retention, re-engagement, and virality.

BKNFR knows nothing about any of those things or how to achieve them. “It’s luck,” says Bark. “:( yeah,” says Fester. Their attempts to monetize ROTOPO are shots in the dark guided by the success of another developer. The parts most influenced by Crossy Road, too, fall short of Hipster Whale’s plea to “please ‘PLEASE’ innovate in F2P systems.” They have some confidence left that “not knowing enough means doing things different.” They also think that maybe it’s not enough to model ROTOPO’s own emulation on another platform, the distance between mobile and web not actually being so great.

rotopo_spendpage

ROTOPO’s monetization model in basic: Points earned during ROTOPO’s play are used for purchasing content. Players can choose to supplement their purchasing power by spending money on this same in-game content and by also voluntarily watching video ads to provide a boost to how many points they earn in the course of play.

Asked if would buy level packs for 10 cents a piece, “I guess… more than would be the case otherwise if they were for big money,” “was principal for offering extremely low-value content,” says Bark. “Lots of content, very low prices, a shopping cart…” “… like a thrill in rummaging through a clearance end-cap for granola bars and squeeze juice,” says Fester.

ROTOPO’s monetization model in detail: The in-game store, filled with content, contains text descriptions paired with a Youtube embed of a short BKNFR-made preview. These preview videos show off specific content – a step off from Crossy Road’s character trial system – and include Youtube’s own ads. Players would evaluate if that content is worth in-game currency, actual currency, or nothing at all. In any case, some small amount of Youtube ad revenue would be earned or some small amount of conversions from previews to IAP would be made and a more informed and multiplier-rewarded player would continue playing ROTOPO. Or is the idea, at least.

rotopo_spendpage_detail

As for why BKNFR is choosing to use Youtube over a professional ad network: BKNFR could not find a single service capable of providing video ads without also applying to ROTOPO the raised conditions of admission reserved for Publishers. ROTOPO could be released with only IAP and BKNFR could hope to meet the Publisher requirements for being served ads sometime afterwards, but they’d potentially miss out on significant revenue during that first month in evaluation where the bulk of many games’ fiscal performance peaks.

“another thing… it’s [a] piss-stain caveat that cc information is to be used with a service that people are [probably] wholly unfamiliar with and don’t trust at all. Doesn’t matter that it’s convenient like a one-click app payment with Apple or [that there’s a PayPal button], it’s that the web is dangerous…,” and that there is nobody evaluating the trustworthiness of websites like ROTOPO’s. BKNFR are trying their best here to be as transparent as possible with monetization because of this.

Even then, thanks to the ambiguity of YouTube partnerships, BKNFR are left in the dark on generating revenue from any hotly-watched videos they upload. “This is an experiment,” they assure themselves. “Experiments can go wrong and can be blogged about for other devs interested in failures… there are at least dozens of dollars to be earned there in IAP conversions,” says Bark. But this experiment isn’t an only option, and the hope is that by the time (and if) it fails, enough telemetry would have been logged by BKNFR’s analytics department to impress upon Ad Networks that ROTOPO is something of a success.

ROTOPO, then, for the foreseeable future, will have no Publishers or Ad Networks serving ads to players. It will have bespoke videos instead. It will also have freemium microtransactions. It will include no purchasing of in-game currency. There will be some priced content of very clear, high value: a level pass to unlock all current and forthcoming levels and a piggybank-like character to boost a player’s access to content. ROTOPO will be totally and completely controlled by BKNFR.

There’s more work because of more control, then stretching out development into months rather than the weeks it would be with a simpler, established route. These are things to do with payment systems and server security and video editing and store UX design and creating more value throughout the entire experience to justify purchases.

***

“This is a lot.” “Yeah, it’s a lot.” BKNFR don’t say anything about it after this. They spent the last few minutes mulling over a list prior to it being condensed above, both thinking they’ve missed a few key points. Both are eager to read them again in each other’s scattered notes. Fester looks anxious, gets up, and begins reading over this post, saying “Can this be done already? This needs to go up with a few more still and there needs to be one about beta testing pretty soon and… “

I stop listening. Bark “just discovered a new kind of puzzle,” one with “reversals and a city block, with birds and lots of other cool things.” It will have more camera angles than ever before, “to make the world more livable as that counts too. Add it to the list: livable,” Bark says. “And making sure us too [two?] are living; add it to the list,” Fester says. They leave a little bit later to get food, unable to decide between expensive and frugal. The next day, Bark sends an email, written, “end it [this post] with a question that BKNFR is made half of children (re: Fester), like another experiment, what will happen when poisoned with success (capital). For posterity maybe intrigue? A told-you-so.”

A last point: Cut from this post was the topic of content pricing. It was discussed between Bark and Fester a hundred times over, for a hundred different reasons. There will be a post about it eventually.

roTopo – Monetization 1

roTopo – Visual Design 1

Bark and Fester LLC, being of both dispositions – pen & paper Bark and crayon Fester -, create a visual design for ROTOPO, their debut video game.

Before BKNFR was a thing made up in an afternoon, Fester spent time alone, “when, back then, it was a blur of making lots of Hammer levels…, none were so great.” In a twitch stream before this too, now lost to space, someone says of designing worlds, “No one ever notices when everything is right; it’s only when something is wrong [that we’re left wanting],” and reaffirms Fester that wanting anything at all is an emotion that he captures profoundly in his own worlds.

The first he hears that this is a problem is when Bark returns from a family adventure and uncle stuff with new babies. Older folks during said, “[ROTOPO] is fun, but something feels missing [, and we feel wanting because of it.]” Bark, correctly, called it a lack of visual interest (and there was some more to do with motivation in being evaluated and having a sense of place in the world too).

Fester was confused by the criticism, thinking it enough that here too, like in other designed things, there was always wonder at the world beyond a blocked-off edge, things of substance cut-off just out-of-sight where no amount of neck-craning could avoid having to use imagination. Fester thought it made these places compelling. Fester says, “I think, actually, well, that maybe it was a baby excuse in my head to continue being okay with being lazy.”

***

There’s the more general belief now, that BKNFR subscribes to, that parts of the universe and, too, parts of games are constantly wrong and then unraveled. BKNFR considers that, if everything were right with video games, there’d only be satiation with Tetris or the fuzz of oscilloscopes in a small industry for physicists. They also consider that, if everything were right in the universe, the two sides of North America would have never curled up to bump Bark against Fester.

More to the point, says Fester, “To the point, more,” there are always words that seem off, cars that are tuned poorly, missed beats in a performance, poorly placed mountains. It’s barely ever obvious the core of these feelings, lacking enough vocabulary (especially for a new developer). They’re always noticeable and they always stand out and they always “add character or something like it,” says Bark.

But what makes these “off things” compelling at all is not a want for more (or in being attentive) like Fester had assumed, but for repair until pristine, is something just realized at BKNFR. Bark and Fester are now trying their best to make everything seem right in ROTOPO and don’t yet rightly know how.

***

ROTOPO looked like and played like (and still now, though BKNFR is beginning polish) this: 

gameplay2

Prior to that, like this:

rotopo_old

And did in fact carry very little visual interest like Bark’s older folks suggested. It was mostly deliberate, that difficulty was so high for ROTOPO’s brand of puzzle-action, that to avoid distracting the player from the visual cues they most needed to succeed (the puzzle’s shape, the player character’s location, and character hazards) BKNFR hedged on simple visuals.

That decision was the end result of near-constant clashing between Bark’s pragmatism in development and Fester’s anxiety to appeal to things visually nice. It was that Bark had done all of this design-into-product translation before at a real job some time ago and that Fester had leftover feelings on spending an hour on a half-second set-piece in one of his worlds.

It was then that, being really business-sense-like, they chose the default approach of the more enthusiastic party because both approaches are too difficult to manage at once. Chosen was Bark’s gameplay-first focus, something singularly useful in game development. Fester knows it now, notes that, “It’s because games need to play well to be good and only need to look good never.”

Something about the two: Bark wears only sweatpants. He is very used to maths and logic and is a profoundly great programmer who is fine with the stereotype. He subscribes to an objective truth that games deserve, above all else, mechanical perfection. Fester therefore needs to be, for a good team-up, very terrible at these things and only wears sweatpants at home, when fall and chilly, and is very used to judging appearances above most all else because “god doesn’t let the colorblind and poorly-dressed into heaven.”

Still, there were plenty of visuals to be designed in response to criticism of “something missing” and Bark dictated the order and the steps in between with pragmatism always in mind. The goal was this: To preserve ROTOPO’s simple appearance, there for the sake of ease of use, while indulging parts of Fester to deliver a pleasing and interesting visual experience.

An aside as an example: An early decision was made on scanlines. Fester imagined they’d give the world some texture and, good for Bark, it also solved a technical problem with transparency.

Bark explains that, as pixel density on modern displays increases, the feasibility of selectively discarding pixels to produce the effect of transparency increases (imagine little photons randomly bombarding a translucent piece of glass. Some make it through; some don’t). Simply drop every third pixel and you’ve got 66% opacity. Drop them in lines or patches to give a material not just some added pizzazz, but variability in its transparency that can provide visual cues in a game where shapes are layered.

One awesome result of this approach is that discarding pixels avoids many of the issues graphics developers run into with blending and depth buffers. That is, rather than trying to blend some faded pixel with everything underneath it (a process which involves knowing the correct order of everything on the screen at that pixel location), it can just be rendered normally at full opacity while its neighbors aren’t.

One big change first: Before unloading on visuals, Bark would make the best rotating, panning player-tracking camera that would ever exist. It was in the convex corners of more difficult puzzles where the camera would often fail to keep with the player’s own want of sight (craning your neck past the horizon does nothing, probably doesn’t inspire wonder, BKNFR apologizes) in balance with slower camera movement to avoid a whiplashing. Clearing this up would prove extremely difficult and extremely useful.

And one tiny change to start: The matted salmon puzzles would get a slight gradient to move further from flatness, which Fester notes is a synonym for blandness. See the changes here:

rotopo_gradient

And a larger change – again about flatness: The negative space surrounding puzzles would be painted with some slight detail. One character would get his star field, another, an ocean. And all would suddenly have some background context without detail being injected into the focal points of play. Unfortunately, then, the slightest camera movement would whip decals dizzyingly back and forth. Any color and detail differences between them and the background were brought close to zero in response. All of it, just a minor change, they say.

ezgif-4073533735

***

In heat on Bronkaid one night and obsessing, Fester pulls up pictures of ocean vents and flat yellow fish and a rock. He sets up a scene for Duncan Plunder, ROTOPO’s very own deep-sea diver.

ROTOPO_duncan_detail

The scenery is broken into two parts: There is the tile displacement – a bottom of the ocean – made slightly angular to add depth to otherwise flat tiles; There is the detail – a coral bunch, some rocks, those fish – also made angular to jibe well with the displacement. “… all done low-poly in the interest of saving time and maintaining the same low, low level of effort in art…,” Fester adds, then, “it’s easiest and there are multiple characters and too much detail would get washed away from a distance anyway.”

There was the thought that low-poly would seem a cop-out. That right next to sprite work, that low-poly 3D is overused and everyone hates it, that it’s a something not worth paying attention to for lack of creativity or inspiration. “It [being a cop-out] is totally not considered in reality, under deadlines and infinite crunch,” Fester says, just two steps about moving away from programmer art, “Now quoting me…?”

Fester gets up. He calls in Bark who left for a call before but was just idled in the hallway instead, thinking. Bark comes in, says to hurry things up, “that I tried the scenery out as just caps, didn’t work – it looked insane,” rushed and then, “then decided that maybe if we let it all loose and scattered across the whole of it…” then to which Fester says, “and maybe too overbearing, distracting visuals, there could be displacement-only tiles as well as ones with all the scenery we can manage…” and Bark then says, “then we came up with:

rotopo_duncan_scenery_final

which worked out just fine. That’s it. No more of this.”

There was a note Fester wanted to cover about iterating in development. He says he does not believe that players make concessions because they imagine design considerations. He says that no matter how clear the goal of a design – like here to introduce more variety in visuals -, its implementation is always more important. That that implementation is up to redesigning, is often a case of again and again pinpointing and subduing a thing from feeling missing. That it’s hardly a science. That it’s a tired and drawn-out course followed until everything seems right. For long stretches, all of it feels incomplete and rushed and unfinishable.

Fester says, “It’s going to be like this until the whole of it is done.”

rotopo_scenery_changes

“That’s it, next topic,” Bark says again.

roTopo – Visual Design 1

roTopo – Technical 1

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.

Fast forward a few years and I’d become fairly adept at making the internet pop. When time came to finally pull my pants up, evacuate the valley, and get to business making the video games I always knew I had to make, I made the careful decision of picking the web as my platform, HTML5 as my game engine, and javascript my new best friend and worst nightmare.

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.”

***

HTML5

“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:

WebGL:

For those who don’t know, WebGL is OpenGL ES 2 (a free graphics framework), albeit slightly modified, and made to work with Javascript. This means we get access to GPUs and can deliver high end 3D content.

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.
Write your shaders in html. Don’t write them in javascript with some heinous concatenated strings. Include them in a script tag and insert them using jQuery. This makes it a lot easier to edit them, keep the code clean, copy and paste code you’re borrowing from the internet, etc.

Canvas:

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.

The Dom:

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.

Javascript:

Javascript is a blessing and a curse and it’d take a long post to describe all of its virtues and shortcomings, but here’s an overview:

  1. Ditching types:
    • From someone classically trained in Object Oriented Programming languages like Java, the shift to a scripting language can feel chaotic and unmanageable. For people that just can’t get over the loss of strict typing, there are compiles-to-javascript languages out there, like Dart, that cut through the madness.
    • 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.
  1. Scripting
    • One of the best aspects of coding games in javascript, or indeed in any scripting language, is that game event scripting, AI scripting, and dynamic code modification are built into the language and don’t need to be interfaced (Say between C++ and Lua) as is needed in most commercial game engines. Consider issuing content from the server to your users in the form of javascript “levels” which have the power to script gameplay, introduce new content on the fly, and even rewrite functions and redefine classes.

Web Audio:

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.

Performance:

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.

Saving Data:

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.

Server stuff:

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.

Browser differences:

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.”

roTopo – Technical 1