# Cooperative Blokus

We had a fun time playing Blokus this weekend. The object of the game is to place as many pieces on the board as possible, with all your pieces touching by at least one corner and no sides. Rarely are you able to finish with all of your pieces used up, so the winner is usually the the player with the least amount of pieces left. There were four of us playing, and it ended up being a fairly close game, but it got us all wondering, what if the game were played cooperatively? Could everybody use every single piece? Could everybody win?

The board is 20 × 20 (400 squares) and each player has what amounts to 89 squares. So 89 × 4 = 356 squares. That leaves a difference of 44 squares that will not be used up. So mathematically there is enough area.

The trouble is that the pieces are all unique and unwieldy shapes so you can’t just stack them all up like the diagram. Still, it turns out the answer is yes, everybody can win.

We didn’t use any mathematical formula to work it out, we simply worked off the idea that building a tessellation would be the easiest way to succeed. It was strategy mixed with intuition, trying to place pieces that allowed for as much useful area as possible in the negative spaces, and mirroring every play with each color. Here’s a photo of our finished cooperative game.

It actually doesn’t look like much of a pattern, but upon close scrutiny notice every shape that is played has it’s counterpart in every other color played in exactly the same way, but rotated ninety degrees. eg: The blue 1 × 5 piece placed in the bottom right corner has its mirrors in the other corners— green in the top right, red in the top left, and yellow on the bottom left. The symmetry is most visible in the very center of the board.

Technically this end game wouldn’t exactly be a a tessellation, but the underlying idea of symmetry is how we succeeded. Read more about tessellations on Wikipedia. Or, for fun check out the work of M.C. Escher, a master of the tessellation.

| 360 Words

# Goodbye Basics

We’re terrible at making free-to-play apps. Basically, we take a premium experience and slap some ads on it. Turns out we’re just not that interested in developing arcane monetization mechanics and sideways sales pitches. We especially don’t like designing features that exploit people’s psychological soft spots (think Casinos and a sadly large number of games on the app stores).

With this in mind, we’ve decided to take down Blockwick 2 Basics from the various app stores. The main reason we decided to discontinue Basics: it wasn’t working. We weren’t even making pocket money from the ads and not enough people were upgrading to the full version. The numbers just weren’t adding up.

Another big reason we’re abandoning Basics is we dislike ads and so do most players. So why support something that most people aren’t crazy about? And finally, all the Basics puzzles are available in a free puzzle pack in the full version of Blockwick 2. So, all those easy Basics puzzles will still be available for curious and dedicated Blockwick players.

We’re considering making a free primer version of Blockwick 2 similar to the demo versions of Aqueduct and the original Blockwick, but we’ll see. Aqueduct 101 really helped sell the full version of Aqueduct, but Blockwick 101 didn’t have as good of a conversion rate. Again, we’ll see.

At the moment, we’d like to explore new game ideas. We’ve been working on Blockwick 2 for almost a year and a half now, and it feels like it’s time to move on. We may make a few more puzzle packs and fix bugs when they come up, but probably no more crazy big updates.

Goodbye Basics, hello something new!

| 292 Words

# Maintenance Mondays

We are a team of three people, and we’ve been cranking out games for almost seven years. We’ve released over a dozen titles spanning multiple platforms and marketplaces. Having such an extensive library of games brings up a difficult issue. How can a team of only three people continue making and publishing new games all the while maintaining previously published titles?

Our solution to this issue is a protocol we have named Maintenance Monday. Every Monday we set aside a portion of time to work on keeping up some of our older games. Sometimes this means something as mundane as updating compatibility for a new operating system; sometimes it means something larger like adding an entire chapter of puzzles or even a graphics overhaul to support the latest super-high-density display. We then keep the rest of the week for moving forward with our main projects— developing and publishing new games.

Maintenance Monday isn’t set entirely in stone and it isn’t always perfect. If we really need to focus on a crucial project or an emergency we obviously can suspend the side projects. Another issue emerges when deciding which of our older games gets attention. At a certain point, when a game gets so old, we simply have to stop supporting it. There are several games which we’ve stopped supporting entirely, not because we don’t like them, but the cost to keeping them up is no longer paying the bills. Our first game, Enso Dot, is a really nice little puzzle game from 2008 that we had to finally put to rest. No one was buying it anymore, and the cost in time to bring it up to ‘modern’ standards with high-res graphics, system compatibility, etc. was much too high.

Our latest side project is working on an update for Monster Soup. This one is gonna be a big one so it’s going to take quite a few Mondays to get there. The game currently supports high-res graphics for the iPhone 4, but since then devices with even higher pixel counts have been released to the public (Read a bit about that process here). We are also taking a look at a weird issue caused by Apple’s later versions of iOS. We are even contemplating fixing how the level completion mechanic works to try and reward players for making longer chains. All this adds up to quite a lot of work, but hopefully with Monday on our side, we’ll keep all these plates spinning.

| 420 Words

For the past five years we’ve experimented with a bunch of revenue models for apps, free-to-play, freemium, ad-supported, and of course, premium. So why have we returned to premium when most of the top grossing apps are using different models? The short answer: It is a better experience. We are far more interested in design, gameplay, and user experience than using psychological tricks to try to boost revenue. It’s the kind of experience that we prefer as users ourselves.

Why compromise a beautiful design with gaudy and distracting ads and/or constantly pulling a player out of the experience and bothering them with in-app purchase requests and other annoying pop-ups? Maybe free-to-play does work, but it’s not the kind of experience we enjoy, and it’s not the kind of experience we wanted to make for Blockwick 2. We made something we are proud of. Hopefully enough of you feel the same way.

| 169 Words

# The Joy of Work

Having work you love is one of life’s greatest joys. It provides meaning and focus day after day. You can look back at your weekly efforts and be satisfied. Having passion for your work can channel the messy, chaotic emotions of life into purposeful inventions, services, and artwork—enriching your life and the lives of others. Work hard, fellow humans!

| 66 Words

# Studio Evolution

A studio space is just like a business—constantly changing, growing, shrinking, and evolving. It’s never done, never complete, never perfect. Desks and chairs and computers and walls and doors—all come, go, and change. It’s an ecosystem. For us, the workspace is never final.

| 45 Words

# The Importance of Being Curious

When you stop asking questions, looking for answers, and applying what you’ve learned, you cease to grow. It’s easy to get frustrated with a lack of progress in your life, career, or craft. But any stagnation is directly correlated to the idleness of your curiosity. If you’re stuck, you have stopped learning. Education is a lifelong process – stay thirsty.

| 59 Words

# Planning Makes Perfect

Over the past three years, we’ve been slowly refining how we approach the planning phase. When we began making games, we would simply start working on an idea—no prototypes, menu flow charts, or to do lists. Although it was exciting to jump head first into projects like this, it caused more trouble than the initial thrill was worth.

Seemingly small issues— oversights that are easily avoided with careful planning— would pile up. Before we’d get halfway through an app, these tiny problems would become major obstacles, creating complications in other areas of the project.

Soon, we’d be spending more time putting out fires and fixing newly created bugs than making actual progress. This was immensely damaging to our morale. To feel satisfied and energized by a project, it’s important to consistently hit your milestones. But if you don’t set any, you have only a very vague sense that you are moving forward or anywhere at all.

A good plan lays everything out. Someone who knows nothing about your vision should be able to look over your documents, concept art, and prototypes and have a clear idea of what the final product will look like.

Everything should be written down, illustrated, or prototyped. You must capture as many details as possible—down to the menu transitions and the font of the copyright notice.

Here are the basic components of a good plan (for a mobile game at least):

• Synopsis – Describe the objective, rules, gameplay, and strategy. Explain why it’s compelling and what makes it fun. This is also a good place to explore what kind of emotions you want to evoke in the user, and if applicable, what the story is and who the characters are.
• Prototype – A prototype proves that the game is technically possible on your target device and platform. This is also a good place to really test how fun the core gameplay is. It’s not necessary to include a menu in the prototype unless you’re attempting to craft something totally different than what you’re used to building.
• Concept Art – This part of the plan demonstrates the graphical style of the game and more effectively communicates the desired vibe.
• Layouts & Menu Flowchart – Here everything gets drawn out—the main and sub menus, all of the gameplay elements, the heads-up display, the leader boards, the info screen, etc. The uninitiated should be able to the see the game. Menu transitions and loading screens may need to be storyboarded here too. Don’t wait to argue about major design decisions in the middle of the project.
• The Master To Do List – Step-by-step, no detail spared, list everything that needs to be done. Organize it into phases and assign team responsibilities. It doesn’t need to be perfect, but try to be as thorough as possible.

If you know everything basically works from the outset and that all the details will fit together nicely in the end, you have little to worry about. You can simply put your nose to the grindstone and watch the pieces come together. Of course, you will come across some hiccups, you will overlook a handful of details, and you may want to add features mid-project. No worries. Step back, fit it into the plan, and carry on.

It’s extraordinary how easy planning makes a project. Let your brain do the heavy lifting. Grab a pencil and sketch pad, start drawing and writing, and you’ll save yourself from a lot of grief.

| 585 Words

# Pace Yourself

Hemingway tried not to write for any more than six hours per day. After that, he became tired and the quality dropped. If he stopped while things were still going well he avoided the risk of becoming stuck. By setting aside his work until the next day, Hemingway could allow his subconscious mind to continue working without his brain becoming tired.

There’s a ton of wisdom packed into this quote. One, don’t overwork yourself—you’ll just get exhausted and your output quality will drop. Two, stop on a high note. It’s easier to come back to your project when you have something to look forward to instead of a big problem. Three, when you’re not consciously working on a project, it doesn’t mean your brain isn’t. Inspiration can come anywhere, anytime—despite your preferred work schedule. Keeping all of this in mind, it’s easier to enjoy your time off and get more done when you are working.

| 168 Words

# It’s Not Quite Done

Everything is basically working. The graphics are in place, the gameplay is 10x better than the prototype, and your app seems ready to launch. Except it’s not—not quite.

If you expect to get everything right in one draft, think again. It’s easy to forget that the first totally working version of your game is still just the first version. You may have already gone through several graphical revisions, revamped and polished your code more times than you’d care to remember, and it would be so easy and seem so natural to let all your beta testers know they’ll have something to explore in a day or two.

Recently, we realized (or more accurately, took to heart) that the first working version is never the last. Just another one of those start-up lessons we had to learn.

It’s functioning, you’ve squashed most of the big bugs, you’re mostly pleased with the design, and the gameplay seems as addictive as you intended. Why delay the launch?

Because this is the first time you actually get to hold your software in your hands. Looking at designs in Photoshop is totally different than seeing it on your device’s screen. And even that is immensely different than interacting with it. Now that you can you play with your work, it’s time to add the charm and polish that is almost impossible to plan for.

This is something we’re prepared for from the beginning. We don’t get demoralized now when we have a ton of tiny little adjustments to make. We have this time set aside in the project checklist straight from the start.

Instead of seeing all these small jobs as obstacles in the way of launch day, we see them as opportunities to add that extra special something every good game possesses and what will ultimately set it apart.

| 306 Words
{"found_math": false, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 0, "mathjax_display_tex": 0, "mathjax_asciimath": 0, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0, "katex": 0, "math-container": 0, "wp-katex-eq": 0, "align": 0, "equation": 0, "x-ck12": 0, "texerror": 0}