bark and fester LLC, BKNFR, is an independent game studio
based in New York,
founded August, 2015,
and found at:

about bknfr

for press and business, contact

for updates and more, follow

BKNFR is developing its debut twitch-puzzler, roTopo, set to release July, 2016 on all web platforms.
Fri Jun 17 2016 05:41:03 GMT+0000 (UTC)

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
Fri Jun 17 2016 05:14:38 GMT+0000 (UTC)

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 – Development 1
Fri Jun 17 2016 05:12:38 GMT+0000 (UTC)

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 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 Summary
Thu Jun 09 2016 21:12:33 GMT+0000 (UTC)

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 Media
Thu Jun 09 2016 21:09:27 GMT+0000 (UTC)