Bark and Fester LLC or BKNFR is an independent games development studio working on its debut game, a 3D-pathfinding-twitch-puzzler with soft sounds and teeth-grinding tension. It’s called roTopo and it’s a pretty great little game.

BKNFR is made of Bark and Fester, who remain anonymous so, on the off-chance that either makes a something-drunken tweet about “Hilldog” or the Emmys, nobody will try to kill them. The third-person voice is just a way to protect Fester’s fragile and dissociated psyche. Bark is being very understanding about it, bless him.

BKNFR will [have the ability to] continue to make games if roTopo is successful enough. That starts with you, crawler/visitor. They want to make games about escaping meteors and hypertext lit and about eating our world, but doing it sustainably and only when roleplaying as frogs.

BKNFR is also developing Frog Fractions 3, God Hand 2, Stars Wars 1313, and the Phantom Dust reboot. Stay tuned.


roTopo – Camera Trick

Bark of BKNFR insists that this post about ROTOPO’s camera be a short one, not one with rambles and one rant after another and another. Just the technical stuff, to get to the point, because developers want this pure information the most. Developers want this the most because it is easily-digested and they are busy. Like other developers, BKNFR is also busy and understands the sentiment completely and doesn’t hold it against other developers to want pure information with no expositions and fluff like there is in BKNFR’s other posts.

By far the most taxing aspect of ROTOPO’s development was animating the camera. Moving a player around a shape was a problem I solved in a matter of hours. Moving the camera to try to balance clarity with whiplash took weeks, and I’ll admit it’s not 100% there, but I’m mostly happy with it. Here’s a bit of what I picked up along the way.

Jesus Hamiltonian Christ, I’ve read the wikipedia article on quaternions (go ahead and read it for a good time) a whole bunch of times but I still wonder if the mathematician himself ever wrote wrote

\mathrm {Slerp} (p_{0},p_{1};t)={\frac {\sin {[(1-t)\Omega }]}{\sin \Omega }}p_{0}+{\frac {\sin[t\Omega ]}{\sin \Omega }}p_{1}.

on a chalkboard, and thought “D’oh, seems so obvious now!”

I remember my computer graphics professor in college flashing this equation on a powerpoint slide and telling us to treat it like magic. You know “some genius figured it out so you don’t have to.”

Basically, a quaternion is a 4-dimensional vector that’s used to store information about an object’s orientation (how it’s rotated), and “slerping” between two quaternions is a way to transition smoothly from one orientation to another (turn a thing). As we all know instinctively, the shortest distance between two points is a straight line or “lerp” (linear interpolation), and so, the shortest distance between two orientations is a “slerp” (spherical linear interpolation).

You might think that the task of picking your hand up off your desk and placing it on your forehead (to rub out that headache), is a simple maneuver, but the mathematics of motion at play here are quite involved. Your mind has to imagine the changing location and orientation of your hand, and then, working backwards, motivate the joints of your shoulder, elbow and wrist just so to avoid smacking yourself in the face.

Now, before you go patting yourself on the back for your ability to pat yourself on the back, keep in mind that your brain’s had quite a lot of practice: think about how many years it took you to develop the coordination to wipe your own backside.

But good thing you did, and with your powers you could theoretically make a decent amount of money moving containers around or even operating a camera in a film shoot. Except that you don’t have to anymore, because the quaternion slerp does it for free.

So with that little explanation out of the way, here’s a neat trick that I used in ROTOPO to solve a seemingly innocent problem that resulted from this topsy turvy puzzler.

On occasion during gameplay, and especially when transitioning between levels, I needed a way to move the camera fluidly from a starting location/orientation to an ending location/orientation (which could be any which way in space) such that the animation wasn’t completely nauseating.

The first idea would be to “lerp” (go in a straight line) the camera’s position from the starting location to the ending location, while lerping a target point (which the camera is always looking at) from start to end as well. (For example, from where the player dies to where the player is respawned).

Unfortunately there are a lot of problems here. For one, the camera might clip (pass) through the center of the puzzle, and two, simply animating the target point doesn’t assure that the camera is oriented correctly. In other words, it knows where to look, but it doesn’t know which way is up.

For the problem of clipping, I realized I needed to mandate that the camera always look in a sensible direction towards, and be at a similar distance from, the puzzling area.

This gave me the me the idea to use a polar representation of the camera’s location, such that the animation would occur by angle and radius around the origin instead of a straight path. (The camera then moves in an arc around the center of the playing area). The target point would animate linearly, and the camera would end up looking in the right place without clipping. Unfortunately, this left me with the problem of computing an up vector on every frame that correctly twisted the camera around its viewing direction (again, which way is up?), and I wasn’t up to the task.

Clearly what I needed to solve the up-problem was some way to slerp the camera’s orientation from the starting orientation to the final one – but how to calculate the location if the orientation is zipping around?


On every frame, I’d slerp between the orientations, find the new direction that the camera is facing, and subtract this vector from the lerped target point by a (likewise lerped) distance scalar to find the camera’s per-frame location.

Let’s see if I can explain that a little better.

Imagine, for example, you have a camera sitting on a tripod and, for whatever reason, it’s set to spin automatically around its pivot point. If you watched the film, it’d be like when you spun around in circles as a kid to get dizzy.

Now imagine a filmmaker is holding the tripod (which she cannot rotate), and is trying her best to reduce motion sickness by keeping the camera pointed at a target (say a cute puppy). She’d have to run in circles around the the puppy she’s to keep it in the center of the frame.

Likewise, the slerping orientation of my camera is treated as a magical force telling my camera how to orient itself around its pivot point, and then it’s a matter of working backwards from whatever I want the camera to be looking at to find its location. I figure out which way the camera is looking on every frame, and move it so that direction lines up with my target point.

roTopo – Camera Trick

roTopo – Development 1

ROTOPO wasn’t BKNFR’s first game. In fact, years of development on games that may never see the light of liquid crystal preceded it. What always halted work other projects was that point in game development when the concept is proven to work just dandy, but the task of creating enough content is daunting. There wasn’t any money to hire artists, nor any time to sit around fleshing out detailed worlds, animations, and gameplay mechanics for even the most modest of game concepts.

So ROTOPO wasn’t the first, but it was the first game BKNFR decided to finish and release, because the scope was just right: Not too big that it could never get made, and not too small that it felt frivolous. Truly, it was conceived specifically for this narrow-minded purpose, yet the result would be quite dear to my heart.

I remember laying in bed plagued by the thought – how do we make something appropriate to our tiny company’s capabilities but not trite or stolen? The migraine of making 3D games is this: there’s a whole lot of shapes moving around – tons and tons of them – and cutting down the amount of work involves cutting out the shape-building. Procedural generation is one approach, but that can take a lot of work to yield satisfying results that don’t either feel too random or too uniform. So I wondered, how might one convince gamers to be grateful for just one damn shape at a time? What could be fun about a single shape?

And that led me to start pondering ideas for a puzzle game based around interacting with a single shape. One thing I knew from the beginning was that the game should serve shapes to the player one at a time, and the player would have to “solve” each one, and then it would explode revealing the next shape underneath like russian dolls. For whatever reason, this much was obvious to me from the start, but the rest took a bit of scrutiny and luck. At first, I imagined players clicking on each face of the shape, and.. and then something would happen. Oh huh, I thought, what about that mini-game in zelda where neighboring “nodes” flipped when you hit a switch. That was… kind of fun right?


Well it was enough to get my creative juices flowing, and the next time I met up with Fester I presented him the idea. “I know we’re working hard on super-kinda-going-nowhere game X, but what about a really simple one-off sort of puzzle game we could make in like, a couple days so we could finally put something out there? Basically it’s like that old shitty zelda minigame… (…)… yeah I know the camera would be a pain, yeah I know it might be impossible to reason through, but.. maybe.”

Eventually, Fester humored me enough to convince me to start building this ridiculous game.

Alright, all set up with a fresh project, gonna start putting some shapes together and.. ah wait a second. Could someone else possibly have had the exact same idea? It seemed unlikely, but a bit of googling later and I discovered, to my surprise, that indeed the game already existed. Someone had made it precisely as I had imagined. Thing was, it was just as awful (No offense random dude) as my worst fears. It was impossible to control, and impossible to wrap your head around. Most of all, it wasn’t anyone’s idea of a good time.

Dejected then, both because the game’s idea was not original and, perhaps even moreso, that it wasn’t a very good one, I shelved the concept and went back to other things.

But something about an endless series of exploding shapes wouldn’t liberate itself from my subconscious, and I started to see these things more vividly in my twilight hours (when i’m attuned most to the spirit world). What if… you walked on the surface? Well, it couldn’t be an FPS, which means it needs 4-direction controls, which would limit the number of shapes available (Who knows exactly how). Hm.. and walking on a tile would clear it.. but you can’t step on an uncleared tile and.. that’s it. Oh and i’d be forced to sit around trying out shapes to somehow miraculously find ones where a path to clear it actually existed.

Well now, If someone made the god damn zelda-flipping-switch-polyhedron-game then the walk-on-shape game certainly must be on it’s tenth iteration right? Lo and behold, this was not the case. I searched and searched but nope, nothing like this has been made.

Wow, great, but was it any fun?

Well, I’ll leave that up to you, but my first prototype, which just involved walking around cubes of increasing subdivision, was actually a pretty clear hit. My friends gave it a thumbs up, and suggested I expand on the idea. It only took a few days until I had something  that plays nearly identically to the game up on ROTOPO.com now.

Something that seems like luck from the geometric lords was just the sheer number of shapes that worked out. I haven’t been able to prove it, but I think every closed polyhedron with tiled square faces has at least one solution from any starting tile. Perhaps there is a geometrist out there who finds that notion self-evident, and if that’s you, I’d certainly love to see a proof, but to me it’s a miracle.

I was ready to ship it after about  a week of development. It hadn’t much polish, sure, but it was functional and I found myself playing it quite contentedly for long stretches. But, Fester insisted we go through the whole rigamarole of fleshing it out and adding content and making an in-game shop and all the rest. What started as a nice little idea turned into months of hard labor, but I couldn’t be happier with what we’ve come up with and I’m hoping you get a kick out of it too.

roTopo – Development 1

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.

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


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: 


Prior to that, like this:


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:


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.



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.


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:


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


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



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


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


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

Privacy Policy

Please read these Terms of Service and our Privacy Policy carefully before using any of BARK AND FESTER LLC’s services.

Whenever you use any services created and/or distributed by BARK AND FESTER LLC, you acknowledge all of the terms and conditions of this Privacy Policy. If you do not agree with these terms, you must not use any of BARK AND FESTER LLC’s services.


  • We/we/our/us = BARK AND FESTER LLC
  • (The) Service(s)/service(s) = Any service provided by BARK AND FESTER LLC
  • Terms/terms = Terms of Service
  • User(s)/user(s)/You/you = Any or all users, defined as having registered of the Services
  • Guest(s)/guest(s) = Any or all non-registered persons

Changes to the Privacy Policy

If you’ve read our Terms of Service, you already know that changes to our Terms and Privacy Policy will never be made maliciously. We value our own information just like you value your own. We will never deliberately place any of your personal information at risk of exposure to third-parties and generally evil people. We’ll try our best to let you know when changes are made.

Account Information, Security, and Privacy

We NEVER automatically store any personally identifiable information of any of our users or guests. We will make use of browser cookies insofar as they are useful identifiers of users, including authorization IDs generated from Facebook and Google’s OAuth services. No personally-identifiable information is gathered. Please refer to Google’s own Privacy Policy, which can be found at https://www.google.com/intl/en/policies/privacy/

For technical support, we will communicate through e-mail if one is provided. Beyond that, you are entirely a mystery to us.

How we use Collected Information

Every bit of user information we store is not personally-identifiable. We use this information for the following:

  1. Ease in Logging-in to our Services
  2. Tracking of User Progress, Unlocks, Purchases
  3. Contacting Users for Technical Support and opt-in Notifications of our Services.

We will NEVER sell or provide any information we do collect from users.

Deletion of User Data

To delete temporary data, including cookies and local storage, please first sign out of your account in the Rotopo landing page, and then clear out cookies using your browser’s privacy settings.

To request deletion of all account information, please first login into your rotopo.com account and then select the button labeled “send us a message” in settings section of the pause menu. To access the pause menu in game, press the spacebar on a PC or double tap on a touchscreen or mobile device. Submit an email with the subject “delete account” and a customer support person will remove your account information from our servers. Note that this will delete all of your game progress and that it cannot be undone.

Collected Information when Logging-in

When logging-in and authorizing with Facebook™, the only information we receive from Facebook™ is a unique identifier token we later associate with that user’s specific game progress, unlocks, and purchases. We do NOT have access to ANY OTHER INFORMATION. It’s dystopic, but in our database our users are only numbers.

We also collect our own unique identifier tokens associated with a user’s cookies. Cookies are ONLY used for quickly logging-in a user based on a previous successful log-in authorization with Facebook™. If a user’s cookies are cleared, the user will have to successfully authorize with Facebook™ before logging-in to our service(s) again.

For information about what Facebook™ collects from a user, please refer to https://www.facebook.com/policies.

Collected Information when Opting-In to E-mail Notifications

A user has the option to opt-in to e-mail notifications about news relating to any of BARK AND FESTER LLC’s services by providing an e-mail address. A user can opt-out of these notifications through a link provided in sent e-mails or through in-game Settings.

Collected Information when Purchasing Content

When purchasing content with Braintree™, we only receive a unique identifier token used to associate with a user’s log-in identifier token. Braintree™ handles all of a user’s credit card information and whatever personal information is required to complete purchases. Braintree™ may share non-financial information with us relating to purchases made. This information will NOT be stored.

For information about what Braintree™ collects from a user, please refer to https://www.braintreepayments.com/legal.

Collected Information when Opening a Support Ticket

When opening a Support Ticket, we may collect a user-entered e-mail address. This is ONLY used for communications related to addressing Support Tickets. We will NOT use any entered e-mail address for uses beyond Technical Support to users.


All advertisements are either served by or are redirected to an Amazon product or service. Please refer to Amazon’s own advertising Privacy Policy for more about what information is gathered and how that information is used to serve user- and site- targeted ads. You can find the privacy notice at http://www.amazon.com/gp/help/customer/display.html?nodeId=468496.

Support Information and Legal Contact

If you have any questions about our Privacy Policy, please contact barkandfester@gmail.com.

Please send any Legal Notices to: BARK AND FESTER LLC, 3 Chalford Lane, Scarsdale, NY 10583.

Privacy Policy

Terms of Service

Please read these Terms of Service and our Privacy Policy carefully before using any of BARK AND FESTER LLC’s services.

Whenever you use any services created and/or distributed by BARK AND FESTER LLC, you agree to be bound to all of the terms and conditions of these Terms of Service. If you do not agree, you must not use any of BARK AND FESTER LLC’s services.


  • We/we/our/us = BARK AND FESTER LLC
  • (The) Service(s)/service(s) = Any service provided by BARK AND FESTER LLC
  • Terms/terms = Terms of Service
  • User(s)/user(s)/You/you = Any or all users, defined as having registered of the Services
  • Guest(s)/guest(s) = Any or all non-registered persons

Changes to the TOS

We also reserve the right to change these terms at any time and we’ll try our best to let you know when changes are made. These changes will never be made maliciously. Part and parcel of starting up something new without many guidelines is that we’re actively figuring things out. In other words, we don’t yet know exactly what needs to be explicitly written here. Thanks for understanding.

Account Information, Security, and Privacy

In using any of our services, users that opt-in to log-in services will be redirected to Facebook™, to whom we defer all responsibilities of account information storage, management, and security. We assume that any user of our services has abided by Facebook™’s age requirement terms. Guests must be at least 13 or have their guardian’s consent. Please refer to Facebook™’s own Terms of Service, found at https://www.facebook.com/policies, for more information.

Users must be responsible for maintaining and remembering their Facebook™ log-ins to access corresponding accounts to our services. If a user’s Facebook™ account log-in is lost or forgotten or disabled, etc., their account and game information, including purchases made, will not be accessible.

These terms also include a Privacy Policy. We NEVER automatically store any personally identifiable information of any of our users or guests. We will make use of browser cookies insofar as they are useful identifiers of users. For technical support, we will communicate through e-mail. Beyond that, you are entirely a mystery to us. You can read more here: http://www.bknfr.com/privacy-policy

Using our Services

We’re trying to be on the cutting edge of browser-based games and popular browsers will often have some gaps in support of newer technologies we’d like to use. You must acknowledge that our services might run poorly depending on your internet browser and browser version and that there’s not all that much we can do about it. We’ll do our best to notify users of preferred browsers to use with our services, but we shoot for having working versions on all major browsers.

The same goes for your computer or mobile device hardware specifications. We try to test out and create compatible versions our services on as many devices as possible, but there are always going to be gaps in our testing. If and when your device cannot properly run our services, we are not held responsible for the experience.

Inevitably, we’ll also run into technical problems that can affect your use of our services. This list is incomplete, we’re sure (because, hey, this stuff is Complicated and Hard To Do), but read on to get an idea of what sorts of issues can crop up:

  1. Services are inaccessible due to, but certainly not limited to, server maintenance and service updates
  2. Account information is damaged, erased, inaccessible
  3. Browser/version of browser not supported
  4. Platform not supported

We will always be as forthright with platform, browser, and hardware compatibility as possible.

Note that because we don’t store any personally identifiable information, whenever something DOES go wrong, you yourself are not at risk of anything other than needing to find another game to play for however long it takes to get things back in working order.

Notices to Users

Users can opt-in to receive e-mail and/or facebook notifications of new services, updates, legal revisions, and all kinds of other BARK AND FESTER LLC -specific stuff. We will NEVER use your notification information for advertising and we will NEVER give your notification information to third-parties.

Users can ALWAYS opt-out of receiving notifications.

User Content

Some of our services allow you to upload your own user content in the form of “puzzles” or “levels.” We have no obligation to monitor the subject matter of this content and fully expect lots of dicks. We reserve the right to edit, to refuse the uploading of this content, or to remove and/or delete this content.

Ownership and Very Serious Things

All services owned by BARK AND FESTER LLC are protected by copyright and trademark intellectual property laws. BARK AND FESTER LLC owns or has obtained the rights to use all content that appears in any of its services.

So long as you abide by these terms and intellectual property laws, and use compatible browsers, platforms, and hardware, we’re granting you, the user, use of our services for non-commercial entertainment purposes only. You agree to not use these services for any other purpose.

If you do not abide by these terms, we may take action against you by suspending or permanently barring your access to our services. Don’t do it. Any attempt by you to undermine or manipulate or steal from our services under the protection of copyright and trademark law may be a violation of criminal and civil laws. Don’t do it.

You do not own any virtual items belonging to your account. These virtual items are available for your use so long as you abide by these terms and our services remain operational.

You are not allowed to transfer or exchange virtual items outside of the service for any value outside of the game. This includes real money. We will suspend your account if we find you in violation of this.

Any user content that you upload, while always your property, is automatically licensed by BARK AND FESTER LLC and may be used in marketing and promoting its services.

Any user content that you upload must respect the rights of others. We respond to notices of alleged copyright infringement that comply with the Digital Millennium Copyright Act and other similar laws that may apply.


Some of our services offer content that is purchasable with actual currency. We use Braintree™ and Paypal™ to collect credit card information, to process payments, and to deliver receipts of payment to us before serving purchased content. Again, we do NOT store personal information or credit card information on our servers. All credit card information, if you so choose to store it, is managed by Braintree or Paypal to whom we defer all responsibilities of said information storage and management. Please refer to Braintree’s own Terms of Service, found at https://www.braintreepayments.com/legal, for more information.

Payment Disputes

Purchased content is generally non-refundable except in cases where payments were made unlawfully or fraudulently, or if the purchased goods were not delivered due to technical error (We will not refund any purchases for any reason after two months have elapsed since time of purchase). If you would like to settle a dispute or problem with a payment on your account, please use the in-app contact system (typically located by the settings menu under the label “SEND US A MESSAGE”) and let us know about your particular case.


We use value-exchange videos to generate revenue and to promote purchasable content of our services. We may offer these videos voluntarily to users in exchange for some in-game reward only. These videos are served by Youtube™ and we abide by all of Youtube™’s terms, to whom we defer the responsibilities of serving and managing all third-party overlay ads, skippable video ads, and non-skippable video ads generated. Please refer to Youtube™’s own Terms of Service, found at https://www.youtube.com/t/terms, for more information.

We also use bespoke and served Amazon advertisements, all of which include an HTML reference tag to the Amazon Affiliate Bark and Fester LLC. These ads are never intrusive and we will never insinuate that any user has any obligation to participate in or consume any advertised Amazon services or products.

Please do not use an ad-blocker. If you are found to be using an ad-blocker, your account may be suspended and/or we’ll frown at you through the internet.

Warranty and Liability Disclaimer

BARK AND FESTER LLC does NOT guarantee that their services will be uninterrupted or error-free.

BARK AND FESTER LLC are not liable for things that can go wrong, including, but definitely not limited to:

  1. Technical errors from use of our services (computer glitches, hardware malfunction, etc.) OR
  2. the conduct of other users potentially impacting your own use of our services OR
  3. excessive use of our services; use that might be construed as “addiction.” Please do not forget that there are things that exist outside of video games .

Support Information and Legal Contact

If you have any questions about our Terms of Service, please contact barkandfester@gmail.com.

Please send any Legal Notices to: BARK AND FESTER LLC, 3 Chalford Lane, Scarsdale, NY 10583.

Terms of Service