Hemisphere Games http://www.hemispheregames.com Games for both sides of your brain Thu, 20 Jul 2017 00:49:21 +0000 en-US hourly 1 https://wordpress.org/?v=4.7.4 Osmos, Updates, and Floating-Point Determinism http://www.hemispheregames.com/2017/05/08/osmos-updates-and-floating-point-determinism/ http://www.hemispheregames.com/2017/05/08/osmos-updates-and-floating-point-determinism/#comments Mon, 08 May 2017 21:12:07 +0000 http://www.hemispheregames.com/?p=5363 We just released Osmos 2.4.0 on iOS – our first release in almost 4 years. Why the long hiatus? Was it because 2.3.1, our previous release, was perfect? No, though it was solid and stable, and we were happy with it. Rather, it was due to our reliance on “floating-point determinism” for multiplayer. And for years afterwards I thought it might be the last version we ever released on iOS.

Desynchronization: A Little Osmos Multiplayer History

It’s 2013. Miley Cyrus is wrecking stuff in her underwear. I was about to submit version 2.3.1 to Apple for approval. This was a minor update from 2.3.0 – just a few fixes. We did a little testing, and all seemed solid. Then, just before submitting, we got a “blobiverse desync” error during a multiplayer test.

What, you may ask, is a “blobiverse desync”? Well at the time it was something I never expected – nor wanted – to see again.

It’s 2011. Everyone is getting into Minecraft. Aaron and I were working hard on creating a multiplayer mode for Osmos – a surprisingly ambitious and tricky project. One technical question we faced was how to synchronize game state between devices over a network. There are a lot of moving blobs in Osmos: It takes roughly 7 kb to represent the game’s state at any given moment. Multiply that by a decent framerate, and the network bandwidth required to stream Osmos state across a network gets into video streaming territory. We wanted to avoid putting that kind of load on people’s networks and devices. Instead, if we could simulate the game locally and identically on each device, transmitting only player input (mass-firing, mainly) across the network, the bandwidth requirements would be minimal. We decided to go that route.

We encountered and solved so many technical challenges in our development of Osmos multiplayer, many of which I found super interesting, but I want to focus on just one here: simulation determinism. It’s actually a huge subject, so I’ll just touch on a couple bits and zoom in on an even narrower subject: floating-point determinism.

For starters, a titch about simulating physics on computer. If you’re familiar with the term “lockstep simulation” – one of the things we implemented for Osmos multiplayer – feel free to skip the rest of this paragraph. Generally, physics is simulated a frame at a time: calculate, step; calculate, step; and so on. If you do it right, the smaller your time-step is (the time from frame to frame) the more precise your results will be. Precision aside, it’s important here to note that a different time-step will give you different results. For example, simulating one second in 60 steps (1/60th of a second per step) will give you a different result than simulating that same second in 30 steps (at 1/30th of a second per step). But so long as the framerate is decent and things are stable, these differences don’t get noticed by most players. In single-player Osmos we simply run as many frames as we can per second. If your device can handle it, this means the game will run at 60 fps, bound by the refresh rate of your display. But for various reasons some frames end up taking longer than others, sometimes due to the complexity of what’s happening in game, and sometimes due to what else the device might be doing in the background. So one frame may take 1/30th of a second, another 1/47th, another 1/60th, etc. And that’s fine. The problem arises when you want two different simulations to give identical results. In that case, the time-step used for calculations must be identical for both simulations. Physics programers call this a “lockstep” simulation, which we implemented for Osmos multiplayer. I won’t dive any deeper into this subject here, but a great resource on all this, including code examples, can be found on Glen Fiedler’s website.

You may ask: is this necessary? Won’t these calculation differences be minor? Who will notice? Well, Osmos falls into the category of sensitive systems that can produce drastically different results from slightly different initial conditions – aka the Butterfly Effect. For example: A tiny difference in mass-transfer between motes on different devices will cause them to exert slightly more or less gravity from that moment onwards, causing trajectories to vary more and more over time, until a near-miss on one device is a collision on the other – a “catastrophic” divergence. A player could die on one device but not the other. Not good.

Moving on, once you’ve implemented a lockstep simulation over a network, how do you know if it’s working correctly? Well, you could run a simulation on two devices and watch… and watch… and watch… until you maybe notice something looks different on the two displays. We did this for a little while, saw differences accumulate over time, and decided to get more rigorous. We computed a checksum / hash of the summed masses, x & y positions, and x & y velocities of all motes on the level (5 floats total), and started to send that across the network for every time-step. The devices would compare their local hash with the remote device’s hash, and if they differed we’d throw an alert up on the screen – blobiverse desync! – and dump a bunch of relevant numbers to a log file to analyze. One by one we found the divergences, and resolved them in various ways. And once we were done we were kind of amazed: devices from different generations, each running different versions of iOS – even the Xcode simulator – they all gave the same results! We had achieved simulation determinism. Huzzah!

I remember chatting with Jonathan Blow at GDC 2012 about what we were up to. We got into some technical details, and I mentioned we were using a lockstep simulation as our multiplayer solution. He made a face I can only describe as “Ugh” with a dash of “Really?” I remember saying “I know. I know. But it’s working well! We got this.”

We happily released Osmos multiplayer and never saw that error message again…

… until that final 2.3.1 build in 2013. What happened with that build? I had actually tested it a lot, and had never seen the desync. But one day right before release Dave and I were testing and – blammo – there it was. After some investigation we realized the desync only happened when playing 2.3.1 against the 2.3.0 store build. But what had changed? It turns out I had recently updated my version of Xcode. I tried reverting back to the previous version, and the problem went away. (I tested this to death.) Something in how the new Xcode was compiling our code gave different results from previous versions. Spooky. So, while Apple was still accepting builds from the older version of Xcode, we slipped it in. All went well with the release. But soon after, Apple stopped accepting builds from that version. We could no longer submit new versions of Osmos without breaking multiplayer. And for several years, we didn’t feel we needed to.

The 32-Bit App-ocalypse

Over the past half-year, Apple has gotten more aggressive about culling “unsupported” apps from the App Store, with 32-bit-only apps slowly approaching the chopping block. It’s pretty clear at this point that Apple will cut support for these with iOS 11. And so this January I rolled up my sleeves and started work on an update. I figured – worst case scenario – I might have to cut multiplayer entirely. I’m not actually sure what percentage of players play multiplayer. In any case I figure single-player Osmos is better than no Osmos.

Modernizing the Osmos project so it would build and run using the latest Xcode and frameworks took some work, but less than I expected. Ditto for 64-bit support. There were only a few glitches related to memory alignment in our rendering pipeline and network protocol. For example, here are a couple before-and-after videos I put together demonstrating the kind of alignment bugs that required squashing.

Pretty smooth work for the most part.

Desync issues aside, bigger changes were required for multiplayer. Apple’s networking and game frameworks have changed a lot over 4 years. And while I was at it I took a cue from Apple and removed all Game Center UI from the game, adding support for “background matchmaking” so players can practice/play single-player levels while waiting for a match. (There aren’t as many people playing Osmos multiplayer these days, so it can be a while before someone else comes along looking for a match.)

Hunting for Synchronicity

Of course, synchronization was the big question / risk in this update. I didn’t expect the new version of Osmos to be compatible with the 2.3.1 store build, and sure enough it wasn’t. So we’d lose backwards compatibility at least. But I wondered if this new version would be compatible with itself across different devices and OS versions, like it was in “the good old days” – specifically, 32 vs 64 bit devices. It wasn’t. Ugh. And so began the deep dive into floating-point determinism.

I tried many things. I spent a good chunk of time tinkering with compiler flags / settings. Turning off optimizations solved most of the desync issues, but I wanted to avoid that if possible. I tried flags like mfpmath and sse2, but they didn’t seem to get me anywhere, and documentation on the web with respect to those and clang is pretty thin. I revisited my understanding of floating-point math. I stared at waterfalls of numbers with many decimal places, trying to figure out where, why, and how things were diverging. I reduced the Osmos physics code to the point where nothing moved and no collisions occurred – at least that stayed in sync! I isolated the problem to the point where I had a single line of code that gave different results on 32 vs 64 bit devices for some (but not all!) input values. Simplified, it looked something like this:

mote.x += mote.vx * dt;

Simply update a mote’s x-position by its x-velocity times the time-step. For example, with

mote.x = 0.00668302644
mote.vx = 2.32162547
dt = 33/1000.0   // time-step in milliseconds

The mote’s new x-position on the iPhone 6 would be 0.0832966641 whereas it would be 0.0832966715 on the iPod 5. (A small difference, but still important.)

Were IEEE standards being ignored? No. This difference only occurred in Final Release builds, with optimizations enabled. Eventually I convinced myself it was due to compiler optimizations causing some intermediate results to be temporarily stored in double / 64-bit registers on 64-bit devices, leading the final float / 32-bit result to be somewhat different. So I tried “unrolling” some simple calculations. For example, I expanded the single line above to

float dx = mote.vx * dt;
mote.x += dx;

This kind of change helped in some sections of code, but not everywhere. In some places the compiler was still optimizing / merging instructions. So, how to tell the compiler not to daisy-chain floating-point calculations? Well, as someone who is absolutely not a compiler expert, I came across a neat trick: the somewhat esoteric volatile keyword. Rewriting the above code as

volatile float dx = mote.vx * dt;
mote.x += dx;

tells the compiler to rewrite the result (as a float) to the dx variable as soon as it’s calculated, and not to use any intermediate / higher-level registers. It’s a nice, code-local solution to the problem that can be applied in a very precise way where needed. I ended up having to do this to about 30 different blocks of code here and there in Osmos. It lengthens those sections of code (in some places from 10 lines to 40 lines of code), giving it more of an assembly-language style, but it works.

Unfortunately that wasn’t the one, magic bullet that solved everything. It took me a while to track down the last couple sources of divergence, and they turned out to be the sqrt() and some trignometry functions. (Osmos is all about circles after all.) When compiler optimizations are enabled, these both give slightly different results for some inputs. For example, acos(0.830012262) returns 0.591666639 on my iPhone 6 and 0.591666698 on my iPod 5. Volatile doesn’t help with this, so I tried rounding the results to the nearest degree, throwing away a bunch of precision, but giving indistinguishably-different results – totally fine so long as results match across devices. That worked. 99.999% of the time. Turns out every once in a while – hours of play on average – the results would end up on different integer boundaries after rounding. Ouch. Rounding can be a more complex operation than you might think, but it’s a solvable problem when there’s a ground truth you’re looking for, like the nearest integer to a given value. But when inputs are different, neither device in isolation has enough information to always come to the same result as the other. I lost days to that one, with much fun staring at streams and streams of tiny decimals. The solution? I went back to some basic circular geometry and came up with some new equations that would give a decent approximation of mote-mote area-overlap without the use of any trigonometry functions. The new approximation always underestimates the overlap, but that’s ok since the mass transfer generally gets spread across multiple time-steps anyways. I didn’t notice the difference, and I doubt anyone else would either.

With that, and after tons of testing, I think Osmos 2.4.0 is solid on this front. All seems good after a few days in “the wild” as well. Can I guarantee there aren’t any super-rare divergences remaining? Nope. Hopefully people will let me know if they ever see it occur.


Overall I spent nearly 4 months working on this update. Most of that was on multiplayer, with one month of that spent in the rabbit hole of floating-point determinism. I hope this blog post helps others avoid some of that pain.

To summarize: Lockstep synchronicity got you down?

  • Try unrolling your calculations, assembly-style, and using the volatile keyword.
  • Watch out for trig and other math functions. Sometimes they give the same results; sometimes they don’t.
  • Don’t try rounding to solve your problem. It’s futile and just makes the problem rarer and harder to track down.
  • Make sure you test with optimizations on.

Moving forward I’m curious if a future version of Xcode will again break our synchronization, or if we’re now more-or-less future proof. Time will tell.

ps. I could go on a lot longer on this and many other subjects related to Osmos multiplayer. If you find this blog post useful and/or interesting, please let me know. It’ll motivate me to blog more than once per year! ;-)

http://www.hemispheregames.com/2017/05/08/osmos-updates-and-floating-point-determinism/feed/ 9
Karmaka’s Art Lived Multiple Lives: Part 2, The Box http://www.hemispheregames.com/2016/02/05/karmakas-art-lived-multiple-lives-part-2-the-box/ http://www.hemispheregames.com/2016/02/05/karmakas-art-lived-multiple-lives-part-2-the-box/#comments Fri, 05 Feb 2016 00:30:27 +0000 http://www.hemispheregames.com/?p=5149 As I mentioned in my last post, after having painted a version or two of all the cards in Karmaka, it was time to tackle the mother of all Karmaka paintings: the one that would be printed on the box.

Dave and Eddy wanted a square-shaped box with an image that encapsulated the game’s characters, themes, and images. I sketched out a few ideas:

We unanimously liked the second and fourth concepts, both of which captured the idea of a journey in which we must slay the dragon and escape castle. Dave and Eddy specifically preferred the scope of the fourth one, where the mountaintop is symbolic of the journey’s end, as well as it featuring more of the epic landscape.

As I remember it, we made an abrupt turn away from finalizing the box at this stage to avoid committing to anything too early. Often in the creative process – like in a good stew – it’s a good idea to let things sit and simmer for awhile. With the momentum from this, though, we turned our focus to creating a banner for the website. It was good timing; we were ready to launch Karmaka’s web presence. For this, I recycled my fourth box concept (note the cheesy logo we were using at this point):

They liked this image, but wanted me to try to squeeze out a little more drama. They also wanted to bring back the idea of the journey’s endpoint. A distant temple, perhaps. Or a mountaintop. So…I did both!

This banner actually appeared on the website for quite awhile. On my end, it never sat exactly right. The monk/temple idea didn’t seem to fit the game (the game has no monks or temples in it, after all).

After working on the banner, and some more card revisions, it was time to set our sights back on the box art. Things were pretty clear now. We knew the art style, knew which animals were important; we knew the feel and had tons of raw material and experience to draw upon. Dave and Eddy weighed in with their final thoughts. With all that information, this painting came out:

It had the epicness, the personal journey; it had the right art style, mood, palette. For the title, I took our basic font and hand-painted over it, creating custom lettering. I added the loops on either end of the word to metaphorically invoke a key principle in the game: what goes around, comes around. 

Ladies and gentlemen, we had our box!

It felt right to tie the visuals together by recalling this image on the card-backs. On first glance you might think this is simply a re-purposing of the box art, but it’s not; it’s a brand new painting:


Dave and Eddy took the near-finished version of the game to conventions. It was connecting with gamers. Karmaka picked up two awards from Boston FIG – Best-In-Show and Best-Artwork. People started talking about it.


But something even more important emerged. After many, many playtests, Dave and Eddy realized that gamers were connecting with the dung beetle. He was becoming something of an icon for the game, emblematic of Karmaka’s journey. They called me up and asked me about the prospect of re-purposing the beetle for the sides of the box, an image which could double as the new website banner.

(As a total aside, I have to tell you how happy I am that a beetle is the icon of this game. My favourite computer game of all time – Riven – also has a beetle as its icon, albeit for completely different reasons. What goes around does come around!)

Dave talked about the Sisyphusesque quality to the beetle’s effort – pushing his dung up an infinite hill. I painted two versions. One more graphic and one more painterly:

Dave liked the painterly one best, since it matched the rest of the art in the game. He began passing it around for feedback. The revision I got was to provide a little more context. Namely, having a mountain loom in the background to make the little guy’s effort feel all the more futile, while also adding scale to the picture.

The hill on the left side was added in too so that when this image is printed on all four box-sides, it turns into an endless loop. Now that’s Karmaka!

And now here we are, almost two years later. I’m proud to have been there from the incipient stages of this game; as I said before, it’s rewarding to see something through the entire creative process. I now play the prototype copy of this game with my friends, and we all really enjoy it. I have faith that this game can go places. I’m excited and confident about its future.

Karmaka still has many, many lives yet to live.

http://www.hemispheregames.com/2016/02/05/karmakas-art-lived-multiple-lives-part-2-the-box/feed/ 2
Karmaka Art-Print Poll Results http://www.hemispheregames.com/2016/01/27/karmaka-art-print-poll-results/ http://www.hemispheregames.com/2016/01/27/karmaka-art-print-poll-results/#comments Wed, 27 Jan 2016 00:03:12 +0000 http://www.hemispheregames.com/?p=5204 On Saturday we posted an online poll to Karmaka’s Kickstarter asking people to pick the top three Karmaka cards they’d like to see converted into art prints. (These will be available for purchase on Society6, alongside the box art and the Karmic Ladder sometime in February.) I didn’t intend to write a blog post about this, but I found the results interesting, so here they are.

Karmaka Art Print Poll Candidates

First a little hacking story: about 5 hours into the poll, I noticed a BIG spike in how Crisis was faring in the results. So I took a look at the data, and found someone had spammed the poll with [Crisis, Crisis, Crisis] as their 3 picks, over 30 times. Sigh. A couple other minor blips appeared as well. (eg. Swindle got boosted a bit.) Here’s a view of the data for the first 8 hours or so.

Poll data, hacky warts and all

Something a little fishy…

I proceeded to change the poll’s settings to require Google login so as to stop this unsportsmanlike behaviour. (I would have preferred to allow anonymous voting, but…) Sadly it’s not possible to remove specific data from a Google form, so the false votes remained, giving a skewed view of the results. But I cleaned it up for my final analysis.

Cleaned to within reasonable doubt

Data, de-hacked

We let the poll run another 3 days, shut it down today, and here are the cleaned results. (I also got tired of how ugly Excel’s graphs look. Google Sheets graphs aren’t beautiful, but they’re better.)

The final tally

The final tally

Embody and Swindle

Embody and Swindle came out as the two favorites! I’m glad we let the poll run for a few days, because at first it wasn’t clear which were the top two, with Destiny clearly in the running. In any case, Marco will polish these up (some of the areas didn’t get as much attention since they’re covered up by graphics on the cards), and they should be available in February.

Before commenting on the results, I should explain my process. I exported the results as a .tsv file (which you can download, uncleaned, from here), wrote a perl script to convert the votes into score-versus-time data, and plotted it. I tried a few different scoring schemes. The first was to assign 3 points to people’s first pick, 2 for their second, and 1 for their third. This gives the graph above.

But I also tried alternate scoring schemes to see if it’d make much difference. Instead of 3-2-1, I tried 1-1-1 (equal weight for first, second, and third picks), and a 5-3-1 scheme. They all gave the same ordering, so the results seem quite clear and not very sensitive to method of analysis.

Alternate scoring scheme, 111

1-1-1 scoring scheme

Alternate scoring scheme, 531

5-3-1 scoring scheme

Finally, our impressions. First of all it was super interesting for us to see “empirically” what art/cards people like best. Dave and I found it fascinating, and so did Marco! I actually expected Thievery and Crisis to score higher. Vengeance as well. Then again, we love them all, and the question wasn’t “what art do you like best”, but “which would you most want on your wall” – which isn’t the same thing. I guess I wouldn’t really want that Vengeance dude staring over my shoulder all the time either. ;-)


http://www.hemispheregames.com/2016/01/27/karmaka-art-print-poll-results/feed/ 2
Karmaka’s Art Lived Multiple Lives: Part 1, The Cards http://www.hemispheregames.com/2016/01/20/karmakas-art-lived-multiple-lives-part-1-the-cards/ Wed, 20 Jan 2016 23:36:20 +0000 http://www.hemispheregames.com/?p=5112 I’m Marco Bucci – I painted the cards, box art, and banners for Karmaka. I’ve been part of the team for two years. As I write this, the game is just weeks away from its kickstarter release. We have high hopes for this thing.

Stolen Dreams

But instead of looking into the future, I’m finding myself going back through Karmaka’s many lives, reliving all the art’s (re)incarnations.

I thought maybe you’d like a taste of that.

Looking at finished artwork is like seeing the creative process in reverse. The final answer comes first, then you extrapolate from there, working backward to uncover the steps you think the artist might have taken. The illusion is that the final piece was inevitable, that it existed from the start. That the artist walked a straight line to get there.

That’s never how it goes.

The artist lives the creative process forwards, and at the beginning there is nothing. Literally no things. Art isn’t magic, but it does do what sounds like magic: it converts nothing into something. It’s a process which is all at once painful, beautiful, tortuous, frustrating, satisfying, and above all, endlessly fulfilling. Doing the art for Karmaka was no different.

So let’s go back…and live the story of Karmaka forwards.

* * *

Dave Burke, one half of Hemisphere Games, called me up one day and said, “Hey dude, wanna work on a game?”

Dave’s bouncy tone is always disarming. “Sure,” I said.

“Let’s meet at Holy Oak for a coffee, man. I wanna show you a concept that Eddy and I are bangin’ out. How’s tomorrow, 10:30 A.M.?”

I showed up at 10:31, and there was Dave sitting there with a coffee, a cookie, an iPad, and a bunch of paper cards spread out on the table.

You might be thinking, That’s Karmaka! Nope. Not then. Not even close. This game had no name, no pictures. The writing on the cards was wildly different. After a big huggy greeting we sat down. Dave handed me a bunch of cards. I browsed through them, getting my first taste of some of Karmaka’s iconic titles… Swindle, Recycle, Dilemma, Hell’s Heart…

“We’re in early stages,” Dave explained, “but I think we’re onto something really cool. It’s based on the concept of Karma.” We played the game, and while the mechanics weren’t totally clicking yet (rules were much different two years ago), I could see the contours of a playable game.

“What did you have in mind for the art?” I asked.

Dave tapped open a gallery of images on his iPad. There were cave paintings, Egyptian friezes, weird abstract collages. Not exactly in my wheelhouse. “These images aren’t right for the game,” Dave said. “But we like their timeless vibe. We’re wondering what you can do with these ideas, but in your natural, Marco-Bucci art style.” Another thing I remember from that meeting was Dave’s vehemence about Karmaka not re-treading tired gaming cliches – dragons, ogres, trolls, fairytale creatures. Instead, they wanted to keep it more reality-based and not place it in any one time or era.

I took four cards home to have a crack at illustrating. My only direction at the time: improvise and paint what the words on the cards meant to me. But Hell’s Heart? Stolen Dreams? How do you paint that? 

Hell's Heart and Stolen Dreams

The term Hell’s Heart seemed incongruous. I thought that Hell shouldn’t have a heart. But supposing it did, it would be a very small one – clenched and under constant stress. Constricted. The phrase Stolen Dreams evoked mental images of the starvation and dessication of would-be empires. So I painted that. Above is a copy of the JPG I sent off to Dave and Eddy three days after our first meeting.

They came back enthusiastic. They liked the originality and energy of the work. But they both thought both cards erred on being too busy, abstract, and, Dave’s choice of word: “slashery”. Stolen Dreams skirted a little too close to the realm of science fiction, too. What was an unexpected hit, though, was the hand-painted interface. They’d never seen that before and thought it was a nice departure from the typical, hard-edged look of existing card games on the market. We also agreed that, style-wise, the hand-painted interface was a natural fit for the imagery.

I moved on to other cards, letting my brain wander and the brush fly. I should note here that I didn’t do all the brainstorming myself; Eddy specifically typed out a bunch of thoughts for different cards. He’d send me links to pictures of birds, insects, or animals he liked with thoughts attached (eg. For Thievery, “A dynamic image could be a vulture stealing a piece of carrion.” For Recycle, “How about a dung beetle pushing his ball of poop?”)

Here are some V1’s of various cards.


Often you mine valuable treasures during the first pass. Looking back at these, I see the bold composition of Dilemma, the calmness of Another Day, the pernicious feel of Spite. Recycle practically hit the bullseye on its first pass – just one of three cards to boast that achievement, Dwindle and Sowing being the other two:

Eddy and Dave provided honest feedback. Here’s Eddy on my V1 of Salvage:

“I like the concept, but I’m not so sure it comes across in this piece. The aesthetics & light are great, and I’m a fan of keeping things somewhat abstract/impressionistic, but I feel like the overall shape and meaning isn’t so clear.”

That’s good feedback. It let me know that the subject matter is fine – i.e. I didn’t have to change the shipwreck idea – I just had to paint it in a way that was more visually clear.

The next version sold.

Revisions ranged wildly. Sometimes Dave and Eddy loved most of the card, but wanted to change one thing. Like on Vengeance:

The only thing that changed was the figure, morphing from Japanese Samurai to primitive caveman. Artistically, I also like how the dark shapes of the cave melt into the dark shapes of his form. A painter lives for that stuff.

Here are some more V1-V2 comparisons:

We were also playing with different interface shapes for each colour. Red’s interface was angular, Blue’s circular, and Green’s parabolic – each of these shapes subliminally identified the overall “attitude” of the colour sets.

There is a fourth type of card in Karmaka – the two “Mosaic” cards. These are chameleons essentially, and count toward whichever colour the player chooses.

A literal chameleon was the obvious choice for Mimic, since not only does the card allow you to mimic the colour of another card, you can also mimic its ability, too.

An interesting thing happened here. During a Skype call, Dave, Eddy, and I puzzled over how to make these Mosaic cards identifiable. We knew we wanted them to represent all three of Karmaka’s colours, but didn’t want to simply paint an image with a broader palette (we thought if we did that, it might make the other cards look too limited by comparison). So the solution was to import the look of actual mosiac artwork. As I painted, I steered away from simply copying the mosaic look, and married it with a luminescent, stained glass aesthetic. We all agreed that this really helped the cards identify as their own subset in the game. There were actually minimal changes to these from my V1’s: just a few drawing tweaks here and there, and a bit more variety of colour imparted to Embody. Here are their in-game finals:

I haven’t mentioned the point-identifiers yet. We started with a “Karmic Coin” which would be colour-corrected to match the card in question (you can see these in use on the original Hell’s Heart and Stolen Dreams.)


We abandoned the coin idea pretty quickly because something about it felt cliched. It was also not an economical design choice: a three-point card needed to have three coins on it, taking up valuable real estate. So we switched to gems. Everybody thought this idea felt more consonant with the game’s feel and theme.


We were months into the project at this point, half a year maybe. All the while, Dave and Eddy had been printing off the latest versions of the game, play-testing it with groups of trusted people. As external feedback came in, rules changed, gameplay changed, cards were born while other cards died or got renamed. One such castoff was this one below. It started off as a Green Card, Longevity. Then it migrated over to a Blue card and was renamed to Off The Record. Then it got cut from the game completely.

(In hindsight, I’m glad this one is gone. It’s uncomfortably close to an image from the movie, Hero.)

At this stage in the project we felt it was time to tackle the box art based on the themes and style we had created thus far. This took some time, and I’ll write about it in a follow-up post.

Meanwhile, back in the land of card-art, Dave and Eddy had bitten the bullet and hired a graphic designer to see what he could do with the interfaces. They still liked my hand-painted one, but doing their diligence, wanted to see if it was at all possible to find something better. It turns out, they did. Designer Scott Nicely came up with what is the final interface for the cards. It was sad to see the hand-painted gems and boxes go; we all still like them. But I do think that we made the right call to have the interface pop out from the card, rather than blend in. Maybe I’ll pull out the hand-painted interface idea for a future project.

The actual art on the cards was now well into their third and fourth lives. Most of the changes at this stage were minimal. Jubilee, for instance, just needed a focal point.

Peek needed a small alteration to make it a bit sneakier.

Some cards did require total re-paints. Dave and Eddy really liked the art on Panic, but felt it didn’t quite fit the card’s in-game meaning. We kept the idea of fire, though, and turned it into this:

The game had some late card entries, too. Denial among them. By this point I knew the look and feel of the game so well that I was able to nail it right off the bat:

There’s more Karmaka art in my archives, and many pieces have stories to tell. But let’s close the book on the cards for now. Up next, the image that glues everything together: the box art.

Karmaka — LIVE on Kickstarter Now!! http://www.hemispheregames.com/2016/01/19/karmaka-live-on-kickstarter-now/ Tue, 19 Jan 2016 22:38:38 +0000 http://www.hemispheregames.com/?p=5191 IT’S ALLIIIIIIVE!!! Back Karmaka on Kickstarter right now!!


2015 Highlights: Karmaka at Boston Festival of Indie Games http://www.hemispheregames.com/2016/01/01/2015-highlights-karmaka-at-boston-festival-of-indie-games/ Fri, 01 Jan 2016 18:06:47 +0000 http://www.hemispheregames.com/?p=4949 One of the key highlights this year for Karmaka was the opportunity to attend the Boston Festival of Indie Games on MIT campus in Cambridge in September. The game had been chosen to appear with about 50 other titles as part of the festival’s tabletop showcase.

After working with Eddy and Marco on Karmaka for nearly two years, we felt proud of our work and were excited to share this game we love with the crowds at BFIG.

My good friend, fellow card gamer, and assistant evangelist for the weekend Nate Enkel and I hopped in a car and drove from Toronto to Boston. It’s a deadshot drive east along I-90 through upstate New York (which is absolutely gorgeous in the fall).

Dave, ready to show off Karmaka!

The tabletop showcase floor was packed with interesting new games and it was rad trying out some of the work from fellow indie tabletop developers. Made some great new friends! Be sure to check out Jake Given’s Dragoon, Michael Orion’s Aura and Tony Tran’s Avalanche. Also of note is Tim Blank’s Oh My Gods! (who we’ll be seeing again at PAX South Tabletop Showcase later this month — more on this later)!

We shared the game over the weekend with a plethora of interested players and were thrilled to receive two awards during the awards ceremony at the end of the weekend.
Karmaka walked away with two ‘Figgies’ awards — Best in Show and Best Artwork! Huzzah!

Overall, a great weekend sharing the tabletop love and a wonderful litmus test for the game.

Karmaka won ‘Best in Show’ and ‘Best Artwork’!

Dave at the awards show

Up next… Karmaka at PAX South!

Karmaka Print and Play http://www.hemispheregames.com/2015/08/28/karmaka-print-and-play/ http://www.hemispheregames.com/2015/08/28/karmaka-print-and-play/#comments Fri, 28 Aug 2015 06:11:41 +0000 http://www.hemispheregames.com/?p=4922 This is a BIG moment in Karmaka’s development: we’re releasing a free Print and Play (PnP) of the game! You can download it from this page.

For those unfamiliar with the PnP concept, it’s analogous to the free demo of a video-game. Download the files to your computer, print up the various components (cards, rules, etc.), and play!

We would LOVE to hear your feedback on the PnP, whether you actually print and play the game or if you just download and peruse the files on your computer. How does everything look? Is it all clear? Spot any typos? Most importantly… was it fun??? We’re hoping to do a small, “preview” production run of the game soon, so your feedback would be incredibly useful!

Email us, comment below, post on our Facebook page – we want to hear from you!

Thanks, and happy playing!


http://www.hemispheregames.com/2015/08/28/karmaka-print-and-play/feed/ 2
Quick Reference Cards http://www.hemispheregames.com/2015/08/28/quick-reference-cards/ Fri, 28 Aug 2015 05:29:40 +0000 http://www.hemispheregames.com/?p=4911 We’re *this close* to releasing a Karmaka print and play!

One thing we just finished creating is a two-sided quick reference card – a handy rules summary for each player:

The graphic design style for these cards is based on the look Scott has created for Karmaka’s rules – coming soon! :)

The NEW Karmic Ladder http://www.hemispheregames.com/2015/08/13/the-new-karmic-ladder/ Thu, 13 Aug 2015 23:23:30 +0000 http://www.hemispheregames.com/?p=4897 Here’s another sweet art update for y’all: the NEW “Karmic Ladder”, by Lane Brown.

We had revealed the original Ladder by Marco in the Spring, but over the course of play-testing we’d gotten a not-insignificant amount of feedback saying the Ladder’s “woodcut” style didn’t quite fit the rest of the game’s art style. We had been going for an ancient, somewhat totem-y look, but that didn’t seem to be working for people, so we asked Marco for a retake. Marco’s schedule has been overloaded lately though, so we sought out a second artist to work with, and discovered Lane Brown. And are we ever glad we did, as we love what he’s created! We hope you’ll agree that it’s gorgeous, and matches Marco’s card and box art.

This brings us one awesome step closer to being design & art complete! We’re very close actually, and plan to release a free Print and Play soon. Stay tuned for more details…

Karmaka Graphic Design Update http://www.hemispheregames.com/2015/07/03/karmaka-graphic-design-update/ http://www.hemispheregames.com/2015/07/03/karmaka-graphic-design-update/#comments Fri, 03 Jul 2015 22:30:31 +0000 http://www.hemispheregames.com/?p=4842 One of the things we’ve focused on over the last month has been the graphic design of the cards for Karmaka. It’s primarily a card game, and we really want the cards to look their best! So we worked on them with a graphic designer, Scott Nicely, and have something we’re really happy with at this point! Here are some before-and-after comparisons:

Recycle, before and after.

As you can see the lines are a lot cleaner now, and we feel that green “lotus” color-symbol is a big improvement over that abstract, green gem/mineral. For a while we were trying to design graphical elements that were as impressionistic as Marco’s beautiful art, but in the end we felt this refined look was really sharp while still setting off the underlying art style nicely.

Another change we made in this latest version of the cards was to rename the “Trash” to the “Ruins“, which felt more thematic while still remaining quite intuitive. The corresponding verb, to “trash” a card now becomes to “ruin” a card. What do you think?

Dilemma, before and after. Also renamed to ‘Crisis’

Another graphical change we made was to use black text on a light background for all elements – titles as well as ability text. We weren’t sure this was an improvement for every card, but it looks great on most of them, and it’s nice to be consistent. It’s also much easier to read in low-lighting conditions when it comes down to ink on card-stock.

In addition to some art & framing tweaks (all the cards got this to a greater or lesser extent), we renamed ‘Dilemma’ to ‘Crisis’. We liked Dilemma as a title for this card ability (making a potentially difficult decision), but the art didn’t really convey the sentiment so well. But since we love this piece of art so much we decided to rename the card to ‘Crisis’, which ties the art and ability together quite well.

Thievery, before and after.

Besides looking much nicer, another great thing about the three new color-symbols is their strong support for color-blind players. The old “gems” had different shapes, but were much less distinct than these new symbols.

We’ve also reworded the phrase ‘topmost Deed’ to ‘exposed Deed’. In our playtesting some people were interpreting ‘topmost’ as meaning a player’s ‘best’ Deed rather than the one sitting on top. Using the term ‘exposed’ – which we explain in the rules – is less ambiguous, and accentuates the point that the Deed sitting on top is vulnerable.

Embody, before and after.

Finally, the new look for Mosaic cards. While the “diamond” was probably our favourite of the old gems, we think this new look drives home the multi-colored nature of these cards better. We also prefer the new borders and backgrounds behind the text.

What do you think of these changes? Possibly a bit detail-oriented on our part. (Bordering on the obsessive?) But hey, that’s our job! :) If you’re like us, you really appreciate fine artwork in your hands when playing a game – hopefully we’re achieving that!

http://www.hemispheregames.com/2015/07/03/karmaka-graphic-design-update/feed/ 3