Based on Kevin van Zonneveld’s (@kvz) article on setting up Octopress, I’ve adapted a Makefile to make building my blog easier… with make. The following Makefile allows me to build and deploy my blog by typing make blog at the command prompt.

What would make a pachinko RPG? Last week, I wrote about how I’m sort of enamored with One Tap Quest’s tap-and-let-them-go interaction, which I think mirrors the play-style of pachinko. In pachinko, you have some control over launching the little metal balls, but once they’re in play, they’re on their own. This mechanism stands in contrast to pinball, where you interact with a single or multiple pinballs with the paddles, and cue sports (especially bumper pool), where you launch a billiard ball repeatedly with a cue.

As I said last week, I think the basic gameplay in One Tap Quest is interesting enough for a 10-minute session. But I’d like to take this concept and run with it, if you’ll let me. What follows are some concepts that, I think, extend the One Tap Quest pachinko RPG model.

Player characters

As I conceive of it, a pachinko RPG is sort of like Wonderful 101. A changing stock of characters go up against an overwhelming group of enemies. Just like pachinko rewards players with more pachinko balls, worth real money, a pachinko RPG would need to reward the player with ever more—and ever more interesting—characters to bolster the stock and the player’s score. A given character can gain levels when unleashed on the board, a little more unique than generic pachinko balls. Perhaps characters added to the stock later in the game come at a higher starting level, sort of like characters recruited in later sections of Final Fantasy Tactics or Ogre Battle.

Environment

Procedurally generated “boards” could make a game interesting. Presenting a variable layout of enemies, terrain, and power-ups can challenge players who are already familiar with the basic gameplay. I don’t think that using roguelike elements, such as varying the effects of power-ups like potions in Nethack would work very well. However, incorporating a quest or narrative adventure framework above the level of boards could be engaging. Here I’m using the word level to refer to a conceptual level of hierarchical relationships, rather than an experience level or a stage in a game. I’m talking about the approach that FTL and the built-in 3DS RPG, Find Mii, take. Each “board” is a gameplay experience in itself, and the “boards” have a larger (in terms of conceptual scope) map that ties them together and gives the player a sense of progression or quest completion.

Obstacles on the “boards” that impair the movement of either player characters or enemies could add another layer of strategy. In effect these terrain elements could construct a puzzle that they player has to solve by starting their player character down the correct “lane”, and being lucky enough to gain the required number of levels to beat the “board”.

This approach to using obstacles to make puzzles would require some clever level design. A puzzle where there is a single right way to complete it would be boring, once you find it you simply wait until you get the required number of levels through sheer luck—pointless repetition without interesting choices. However puzzles where there are (or seem to be) multiple routes to complete the “board” can be interesting.

Interaction

I think it might be cool to maintain control over the character after you launch. In a sense you would be an invisible hand, maintaining control over the pachinko ball as it rolls through the machine. This game would be sort of like an inverted bullet-hell shoot ‘em up. Rather than dodging enemies, you would guide your character toward them. It is probably worth iterating on this mechanic, because Monster Strike seems to use it with relative success. But I think maintaining control over the character would block out the cheering-your-character-on-from-the-sidelines aspect that I enjoyed in One Tap Quest, and would like to emulate.

Enemies

As I mentioned previously, added depth of enemy behavior and power-ups could prolong the experience. I’m not sure exactly what this would entail at this point, but I think iterating on the basic concepts laid out in One Tap Quest could lead to some interesting variation. That sentence pretty much sums up my take on what would make an interesting pachinko RPG. Thanks for letting me spew some thoughts that are little more than design notes.

I recently played One Tap Quest, a game in which you tap to place an RPG character who marches upward, gaining levels by bumping into enemies, to tackle bigger and badder foes. What’s interesting to me, if you’ll bear with me, is that this is a game that amounts to a pachinko RPG. I’ll start by talking about what I liked about One Tap Quest. Next week, I’ll get into what I mean by a pachinko RPG.

It’s rare that I come to a new gameplay experience completely naive these days. The only way I feel I can effectively spend my time with a game is typically after having read some sort of guide because my time is extremely limited.

What the One Tap Quest accomplished so well for me was going from barely being able to read the screen to beating the game over the course of 10 minutes. Admittedly it’s a very short and simple game. But I felt a sense of accomplishment every time my understanding of the mechanics grew.

Oh, these little critters are stronger than these other little critters, better avoid them. Oh these are power ups, not critters, better aim for them. With these skills under my belt it only took a little luck to send my character on a march toward victory.

The place where this idea shines is in the power-ups. I’m not sure whether I’ve encountered all of them, but they range from simple buffs that grant free levels to expanding your party into a 3-character-wide enemy-wrecking plow. For what it’s worth, the power-ups were deep enough to keep me interested over 10 minutes of gameplay. If I were going to engage with this experience over a longer term, I would suggest adding more depth to the power-ups and the enemies, which are as far as I can tell simply harder to kill, and possibly bigger, versions of the puny slimes that move back and forth. Some of the enemies have variations on the simple random walk style movement of the slimes, but a richer variety of movement and behavior from the enemies would increase the required skill to play the game, and add to replayability.

I think the power-up mechanics add a level of depth and strategy to what otherwise would be a hands-off luck-of-the-draw game. By aiming for power-ups you have a sense of agency in the action, just like turning the knob controls the velocity at which pachinko balls are launched. It makes cheering for your lemming-like character(s) more enjoyable: if they could just get a little closer and grab the power-up you aimed at—no. Nope, they died.

Go give this great little game a try. Hopefully it will pique your interest like it piqued mine. Quirky variations on RPGs seem to be part of the Zeitgeist, with Rollers of the Realm and Monster Strike blending pinball and console genre gameplay with the potential synergy Sonic Spinball never achieved.

I’m interested in having some data remain available, even though I’m switching Scenes in Unity. In other words, I want this data to remain persistent. As you’ll see below I was tempted to use PlayerPrefs to store the data, but, according to this Unity Live Training on Data Persistence, PlayerPrefs is not the best way to make data persist over multiple Scenes. PlayerPrefs is an okay place to store non-critical data, like the audio volume, window size, full-screen state–you know preferences. I’ll go ahead and show what I believe to be the correct way to store persistent data before talking about PlayerPrefs later.

According to the Ray Wenderlich Unity 2D tutorial by Christopher LaPollo, Unity’s physics engine builds a simulation based on the Colliders present in a scene. If some those Colliders are declared to be static, then the entire simulation is rebuilt when those colliders move. Of course, rebuilding a physics simulation when it’s unnecessary is inefficient. By declaring objects to have dynamic Colliders, the physics engine does not have to rebuild the simulation at runtime, that is to say when the game is running.

As with a lot of things in Unity, it is not immediately apparent how you should go about declaring a collider to be static or dynamic. It would be great if there were just a checkbox in the Collider component. But there isn’t. It appears that there are some complex things going on under the hood that preclude a simple declaration.

By default a GameObject with a Collider component attached is treated as static by Unity’s physics engine. This would work for a non-moving wall or impassable bit of scenery, but for moving objects like enemies we need to mark them as dynamic. In order for a GameObject’s Collider to qualify as dynamic it requires a Rigidbody component. If you don’t want the normal features of the Rigidbody, i.e. conferring control of the GameObject’s position to the physics system, then you can check the Is Kinematic checkbox. A kinematic object’s position is under the control of the attached scripts, rather than the physics system.

One other trick from the tutorial is to set the Collider component’s isTrigger property to true. This prevents the Collider from being treated as a solid object in the physics simulation, which could lead to unintended bumping and pushing among various Colliders in a scene.

Update: @InvolvingSalmon points out that the instructions here depend on the version of Unity that you are using. This article was written for Unity version 4.5.2f1.

The cinematically inspired Space Is Red is not so much a game as it is a visual novel. Out of the games I tried from the #spacecowboygamejam, it’s one that sticks with me.

I was fortunate enough to catch a screening of Jodorowsky’s Dune, the documentary about visionary director Alejandro Jodorowsky’s failed attempt to adapt the science fiction novel Dune) to the silver screen. Having seen a similar documentary about Terry Gilliam’s attempt at adapting Don Quixote, I consider myself a fan of the genre, despite its niche appeal.

One quick note before we go on. It looks like Jodorowsky’s Dune has hit Netflix on DVD, and seems a likely candidate to be available for streaming. So you can check it out for yourself to see if you agree with my take.

Michael Cook made a “needlessly interactive” playable call for papers for the Experimental AI in Games conference, taking place in October in Raleigh, NC. It’s a minimally expressive Twine story, with really one simple interactive experience of role-playing the interaction a recipient feels upon receiving yet another CFP email, click.

It’s a tricky thing to get right. While it makes sense for a game-related conference to have a text adventure announcement, I don’t want to have to play a game of Frogger to purchase movie tickets from the automated kiosk at the movie theater. It would be nice if the playable CFP included prominent and consistent links to exit the game, in order to read the ordinary CFP on the conference website.

I believe the motivating idea is sound. Turning banal daily routine into a playful interactive experience is a worthy goal for game design. It has the ability to startle the player into paying more attention to mundane activities, which I think is the intended goal—for a CFP to stand out from piles of other CFP emails.

Let me know if you’ve come across games in strange places. I don’t mean finding a boxed copy of Mario Kart at the flea market—I mean conceptually strange places. Hit me up on twitter if you’ve got ideas like this to discuss, because I think this approach of creating small play experiences to “gamify” mundane tasks is an emerging theme of design.

@HobbyGameDev’s long-read “Reasons for Modest First Projects and Incremental Learning” tells the tragic tale of overambitious novice developers.

In 2010, Rich Hickey spoke at Clojure Conj about ‘Hammock Driven Development’. Hickey was talking about the benefit of down-time for noodling about software design. Specifically, Hickey means using down-time after considerably ‘loading up’ your mind with aspects of the problem, in order to leverage background offline processes to solve those difficult problems.