Secret project part 3: On Hiatus

As is goes, Secret Project’s development is currently frozen. It has been for the last two months, actually. Not super for the project, but good for the company.

We decided to freeze development right after coming back from Gamescom, because a big contract got signed and we needed everyone on that job to get the ball rolling. Additionally, since the signed project is in the roughly same genre as Secret Project, it would look bad releasing it while initial development was going on on the other one.

And yet, this may turn out to be for the best after all. I am able to take a few steps back on the design and look at it with fresh eyes (the time before Gamescom was pretty crazy in that regard, we completely overhauled the look of the game in 4 weeks!), and we’re also getting to develop some finer technical infrastructure that I hope will carry over to Secret Project once development resumes.

Meanwhile, we’re also getting good vibes from the few people we showed the alpha to in GC, and I still get to go ahead and fill the backlog while no one’s looking to sneak in more important features.

I hope to report back soon with part 4: the Thawing!

Secret Project part 2: The Prototype(s)

After getting the pitch shortlisted, our first task was to actually prove that the mechanic was viable ASAP. This was a rather unique challenge compared to other selected pitches, since they mostly had to build a regular First Playable.

We had two weeks to make it work. I’m kind of freaking out thinking on how to actually get the mechanic implemented in networked multiplayer under such a short deadline. The project would have most certainly failed its first milestone if it weren’t for the heroic arrival of… El CTO! *cue Mariachi fanfare*

Continue reading

Secret Project part 1: Threading the needle

There have been …interesting… developments at work with some clients, the result of which ended up in our doing a company-wide brainstorm for ideas, geared towards internal development and eventual publication.

One of the selected projects is an idea I pitched, and I now find myself at the lead of that project, one with a very nerdy mechanic.

I kind of need to tell someone of how that goes, even though if I cannot yet share what the project is.

So, here is what has been happening so far…

Continue reading

J.S. Joust: Analog Demake

Most of you have heard about J.S. Joust and want to play it (the few of you who have no idea of what I’m talking about, I suggest you go consume this website). If you want to live the full J.S. Joust experience, your best bet would be to travel to attend one of the events where J.S. Joust is demoed. But if you’re like me and have no money (and don’t live in a future where the game is already released on multiple platforms), you’re kinda stuck. However! If you’re willing to sacrifice some fidelity in order to get a similar gaming experience, let me tell you about my dirt-simple, dirt-cheap analog demake.

Basic version

Materials

For 4 players, you’ll need:

  1. Around 1 meter of PVC pipe or any other rigid tube, between 1,5 and 2 inches diameter (yes, empty TP rolls work fine too).
  2. 4 same-size and same-weight brightly colored balls, not bigger than 3,5 inches in diameter. Ball pool balls are a great fit and are cheap and plentiful.

Preparation

This is where it gets complicated so pay attention:

  1. Cut the pipe in 18 cm segments (that’s roughly 7 inches for you Imperials). Ask an adult for help on this if you’re not confident with a saw.
  2. Place one of the balls on one end of the pipe segment.

Rules

The goal of the game is to make other player’s balls fall from their sticks by any means necessary. Last player with a ball on his stick is declared the winner.

Observations

The main gameplay variable you can tweak is the ratio between the pipe and the ball. A ratio of 1/2 calls for a very sensitive setup. Playtests show that the ratio’s sweet spot is at 2/3 to allow some roughhousing.

Sadly, some original features of J.S. Joust get lost in translation:

  • Ability to play with the controller upside down (gravity’s a bitch).
  • Ability to dynamically modify the controller’s sensitivity to shocks during gameplay.
  • Ability to make the ball change colors to give feedback.
  • Ability to play in the darkness (included in this demake’s “premium” version).

In return for these shortcomings, this demake offers some interesting new gameplay opportunities:

  • Ability to play anywhere, even in the absence of electricity.
  • Gameplay area is no longer constrained by the Move’s communications radius – go wild.
  • Ability to play with an infinite number of simultaneous players.
  • Gameplay can now be influenced by atmospheric events – mind the wind!
  • Ability to cheat.

Premium version

The premium version tries to regain some features lost in the demake, at the cost of being more expensive to build. I haven’t tested all improvements yet, but these are the ideas I’ll be developing to refine the “emulation”.

Luminescence

One of the neatest side effects to the Move’s tracking ball is that it looks very cool in the dark.

The easiest way to replicate this effect is to use a cheap 9-LED flashlight. You can either put it inside the tube or just use the flashlight as tube, since they usually have a protruding ring at one end where a ball could rest. For this to work you need to be using balls made of translucent plastic (again, like ball pool balls), and voilà! Nighttime fun.

Gravity tolerance

The original J.S. Joust loss condition is having your controller shaken over a given threshold, which means that players can try putting their controller upside down (or in any direction other than up) to protect it from other players. To achieve similar possibilities in my demake, the most obvious solution for now seems to be using magnetic force to bind the ball to the stick, thus keeping the ball from falling if upside down all the while allowing both to become separated if shaken strong enough.

Ideally the magnet would be hidden inside the stick, while the ball would have some small metallic object inserted into it or stuck to its surface. I guess the setup should not allow the magnet to touch the ball, otherwise they might become too difficult to separate.

Atmospheric events will still have a diminished influence on the ball, providing some dynamism to the gameplay.

Dangling

If you manage to make the device gravity-independent (see above), adding a lanyard to the end opposite to where the ball goes will allow dangling it to attempt to reduce shocks.

Dynamic gameplay

We’re entering speculation territory here… There are various ways you could do this, depending on your tech solutions…

  • To control the sensitivity to shocks of each device, you could maybe use a centralized computer system communicating by RF to each device. You could also imagine that each device varies independently its own sensitivity and tells the player (maybe dimming the LED lights when the system is more sensitive)
  • Since you’re using electricity, use an electromagnetic coil as magnet and vary its intensity.
  • If you’re using an actual magnet, varying its distance to the ball will vary its attractive power.

There is no practical, easy solution worth implementing that I can think of to mimic this behavior. Maybe you can?

Educabilia—El Blog: Diseño de videojuegos: ¿El sueño del pibe?

I was interviewed along with Daniel Benmergui on what it’s like to be a Game Designer for educabilia Argentina.

Game Design being an awesome thing to do, we both have very different things to say about it.

Oh, it’s in spanish btw.

educabilia:

Conversamos con dos diseñadores argentinos de juegos: una profesión magnética para cualquier amigo de “la Play”, cualquier nostálgico del Nintendo. Después de escucharlos, no estamos tan seguros de que su trabajo sea un sueño hecho realidad. Pero su oficio da curiosidad, y da para la…

Gravimaze

Gravity Puzzle-Solving!

In mid-2011, David Hart approached me with a prototype he had been working on in his spare time. It was fairly simple: you had a Spongebob-like square character in a simple brick maze you could rotate with your finger. Upon each rotation, the character fell to the new “down” direction until it reached the exit.

The prototype had a level editor looked something like this:

20120626-203656.jpg

One of my first tasks was to design new mechanics to expand upon David’s original idea, sort them by feasability and test them once a rough version of it was implemented. As usual, the amount of stuff that didn’t make it in the game far exceeds the amount of stuff that did, but luckily we managed to iterate quickly and reach a stable number of different mechanics in under a month.

At that point, I got serious on the level design. Our goal was to do a first release of the game containing a hundred levels, which we decided to split into five packs. These packs later became temples once we settled on the theme.

By now the game looked even uglier than when we started, so we decided it was time to get serious about visuals. After some searching, David hired Andreas Inghe, who is awesome. Expanding upon the idea of long forgotten temples, he started doing the assets for the different elements and backgrounds, bringing a new dimension to the gameplay.

By now, it had started looking like this:

If you have played the game, you’ll recognize some elements that later became World 2 a.k.a. The Earth Temple, and some early versions of Gravi (the player’s cube) and the exit portal.

When we started thinking about what the game would sound like, Andreas showed us some ideas he had been working on and we were quite frankly blown away! Here are some samples of the game’s music:

With new assets being added almost daily, it became clear that David’s initial choice of tech was becoming too constraining. Previously based on UIKit, David ported the game to cocos2D which gave us a lot more of elbow room to expand and polish the game to what it looks now.

Alabaster TempleEarth TempleTurquoise Temple

 

To say that I’m proud of how it turned out would be an understatement.

Please visit the game’s official site for more information: www.gravimaze.com, or get the game by clicking on the button below.

Critical reception

I’m pleased to report that the game was pretty warmly received by most (if not all) those who reviewed it.

The game currently holds a solid 4.5 star rating on the app store with around 100 reviews. It was also picked up by some specialized sites, garnering generally favorable reviews:

App Store Arcade – “As puzzle games go, GraviMaze achieves almost puzzle perfection as well as being one of the best puzzle experiences that we’ve seen yet from the Apple AppStore.”

iFanzine – “Like any logic puzzler worth its weight in megabytes, GraviMaze stirs in plenty of nuance as the player dives further in.”

Mac Trast – “GraviMaze does a fine job of being simple, yet at the same time, produces a lot of brain challenging levels.”

Motion Game Design: Best practices

The following is a refactored translation of the talk I gave at the EVA10 Expo in Buenos Aires, on 11/12/10. It does not mirror exactly what I said during the talk, but it should give you a general idea. I’ve divided it into three parts: Player limits and systemic constraints, Cheap tricks and easy ways out and Best practices (this post).

To avoid the need to take a design shortcut, I had identified some desirable characteristics of  high quality motion mechanics. Whenever I designed or refined one, I tried to make it understandable, detectable, responsive, permissive, humane and sensuous.

I believe these 6 characteristics to be fundamental to good motion design.

Continue reading

Motion Game Design: Cheap tricks and easy ways out

The following is a refactored translation of the talk I gave at the EVA10 Expo in Buenos Aires, on 11/12/10. It does not mirror exactly what I said during the talk, but it should give you a general idea. I’ve divided it into three parts: Player limits and systemic constraints, Cheap tricks and easy ways out (this post) and Best practices.

I’ve detailed in my previous post all the most evident pitfalls and traps a designer must work around when designing motion mechanics to make them more accessible, fun and engaging. Now I’d like to illustrate by listing some of the most common default solutions (read: bad) solutions that have been used far and wide by most developers (including me, I admit) when time, skill or budget were lacking.

Hopefully you’ll be now able to identify them and at least understand some possible reasons that led the designers in adopting it.

Continue reading

Motion Game Design: Player limits and systemic constraints

The following is a refactored translation of the talk I gave at the EVA10 Expo in Buenos Aires, on 11/12/10. It does not mirror exactly what I said during the talk, but it should give you a general idea. I’ve divided it into three parts: Player limits and systemic constraints (this post), Cheap tricks and easy ways out and Best practices.

The designer tasked with creating a game experience using some flavor of motion control is always fighting a pitched battle against two cunning and deceitful enemies: the tech he’s using, and the player he’s designing for. Both will lay traps for him that might prove dangerous if he designs naively.

Having had some catastrophic encounters with those foes myself, I now attempt to pass on the knowledge I’ve taken from those experiences, hoping you will be able to avoid easy mistakes when designing for motion capture systems. Continue reading