Making Glyphs for Blockwick 2

blockwick_2_glyphs

Those little symbols on the floor are called glyphs (pictured above on the left). If you can solve a puzzle (by bringing each color group together) and are able to get all three of the glyphs covered up with the color blocks you’ve achieved “illumination” (pictured above on the right).

In the original game, Blockwick, we used glyphs to identify block type. There were 12 different block shapes, and each shape had it’s own specific color and glyph. Every chapter introduced another block shape with it’s own glyph, shown here:

blockwick_2_glyphs_2

The problem with having a glyph for every block shape in Blockwick 2 was that we substantially increased the number of shapes (from 12 to 70), so putting glyphs on every block type seemed overly impractical. Thus we came up with the idea of making the glyphs a little more integrated into the actual gameplay. Putting them on the floor adds an extra challenge, and another layer of replayability.

So when it came time to design the aesthetics of glyphs, we knew we wanted draw from the original game but obviously stay within the simpler minimalist framework of the new game. The original Blockwick’s glyphs have a soft, organic feel to them. They are hand drawn, a tad sloppy, but definitely still mysterious. Blockwick 2 is crisp and minimal. It’s cleaner with less fuss. An obvious reference point for us was the font Futura. We had used it in the original game and were planning on using it in the sequel. We still used the same symbols from Blockwick, but for Blockwick 2 they are cleaned up, geometric, and very much informed by Futura.

blockwick_2_glyphs_3

Above in this comparison you can see how Futura’s weight and simplicity inform the Blockwick 2 glyph. The glyphs do however maintain their own identity, specifically by their use of rounded corners and unique structures.

blockwick_2_glyphs_4

Blockwick 2 is coming out this Thursday, March 5th. Check out the trailer here.

Blockwick 2 Rounded Corner Collisions

To make dragging blocks user-friendly, rounded corners for our collision objects are key. Getting stuck on a corner is frustrating and detractive. We want people to solve puzzles not fight with the game.

blockwick_2_rounded_corner_collisions

As this was our first project using Unity 3D, I was excited to use the built-in physics and save some time. Setting up the shapes and mechanics was simple enough, but after a week of prototyping, it was clear that standard game physics were not going to cut it. Physics instabilities, catches on invisible corners, extra processing for things like rotations, forces, collision event callbacks, etc. It was too general a solution for a specific problem.

All of the above considered, it was necessary to create a custom physics solutions that only took into account what we needed: rounded corners and non-overlapping collisions.

I just need two types of collision shapes, edges and corners. An edge is simply a box with a normal vector. A corner is a circle and box that defines what quadrant of the circle to use. The one constraint of the system is that blocks should never move farther than the radius of a corner. That’s pretty much it!

Now, all we have to do is move the selected block towards the touch location and iterate over the collider arrays, moving the colliders away from each other based on edge normals and corner quadrants. To move blocks faster do more physics steps each frame.

Blockwick 2 is coming to iOS and Android next Thursday, March 5th. Check out Blockwick.com for more information.

Wall Shadows in Blockwick 2

blockwick_2_half_walls

The idea of short walls was conceived fairly early in the design process, but would require the use of a custom shader if the idea was to work and aid in the illusion of depth.

The first step was to build alpha texture that could be used as a mask. Since the walls are static in each scene we needed only generate the mask once when the puzzle scene is loaded. To do this we create an appropriately large texture based on texture and screen resolutions and render the alpha of each wall sprite to that new texture. Voila.

Second, each frame the scene is rendered normally. After which, a second camera renders only the shadows using a shader that offsets the shadows vertically and multiplies the sprite texture by the mask texture to mask out any pixels that are not over a wall sprite.

That’s it! Fast, easy shadows that look 3D.

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.

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.

What We’ve Been Up To

It has been too long since we launched a new game. We apologize. We’ve been busy getting our ducks in a row with our current brands—the Abca name change, adding the Quick mode to Orba, and other minor changes and updates. Although that stuff was important, we’ve been itching to get a new game out.

These first months of 2010 haven’t been all maintenance though—we’ve been experimenting like mad scientists. In fact, we were half way through a top-down scroller game when we decided it just wasn’t fun enough. Amusingly, this was around the same time we posted our thoughts on Mid-Project Doubt.

For the past month and a half, however, we have been working on an exciting new project. We actually developed the concept and prototype this past winter, but it seemed too ambitious at the time. We adjusted the scope a bit and are now extremely close to getting it up on the App Store.

Although the name is not yet finalized, the core gameplay is set. It’s a mashup of the slider-puzzle and pipe-connecting genres. As far as we know, this is something totally new. We are very, very excited to share this with everyone.

We have some tutorial screenshots over on our Facebook Page—check ’em out!

99.9% Perfect

As creatives, we daily face the predicament of compromise. How good is good enough? I’ve come to a tentative conclusion: nothing is perfect, but you can get extremely close. The key is to stop refining, tinkering, and polishing once you get close enough that anything more is negligible. Does a 1% change in opacity on the icon’s shine really make a significant difference?

[Note: Be careful. As you develop your skills, your concept of perfection keeps evolving. And you can get just as stuck chasing degrees of perfection this way. In order to launch a product, you have to draw the line somewhere.]

How Did We Get into This Stuff?

Every child enjoys playing and pretending, but we were of the curious sort who enjoyed designing the games themselves—their objectives, rules, and playing field. Trampolines, garage rafters, living room floors, and neighborhood street corners all became canvases upon which we could design our games.

Add to this an undying creative obsession. We were never content with being just spectators. Sketchbooks, camcorders, and most of all the family computers became more frequently used than the television.

David and Jonathan got addicted early to the thrilling potential of computers. I think they were nine and eleven at the time when our grandfather introduced them to programs like Adobe Illustrator and Macromedia Director. This was all a bit advanced for me at the time—I stuck with KidPix.

Our concoctions got bigger, more complex, and more ambitious—from simple Myst-like walkthroughs to top-scrolling shooters. As a side note, this is one of the best ways to learn—small, attainable projects that grow incrementally bigger with each success. Enjoy the mini-milestones. It’s okay to pursue big ideas as long as you’re prepared for the many small steps it takes to get there.

Anyway, a decade or so of tech-soaked creative experimentation passed. A year after I got out of high school, the three of us began exploring the potential of iPhone gaming.

It all started with a simple puzzle game, now known as Enso•Dot. I had doodled it into existence one evening thinking it would be great for a puzzle book. David and I developed the brand and created a tiny, prototype booklet with 15 or so puzzles in it. We soon learned that the game required an excessive amount of erasing. We knew it needed to be digital for any sane person to enjoy it.

Within a few days, Jonathan, the true technical genius behind Kieffer Bros., created an Enso•Dot puzzle editor. And after another few days, we were playing puzzles on the iPhone simulator.

And that’s how this experiment began.