About BKNFR

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.

About BKNFR

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?

Aha!

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?

https://www.youtube.com/watch?v=jLkvKhFAxsI&feature=youtu.be&t=4m37s

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