I Hope You Like This

I may not have explicitly said it yet, but this game I’m working on is an exploration into the turn based battle system. Rather than keeping the system tied to it’s typical RPG genre, I want to explore it on a battle-by-battle basis, which will hopefully reveal some interesting depth previously unseen in the system. One difficult aspect of designing battles given these restrictions is giving the player clues as to what they’re supposed to be doing. The following is my current solution, and I think it is more eloquent than I first imagined. Currently, I call it “The Grid” (I really wish Tron wouldn’t have coined that term, haha)

The Grid is a 3x3 square where the competitors reside. There is one grid for the opponents, and one for the player. I decided on a small size because I want very restricted movement (it’s not necessarily the point of a turn-based battle system), but at the same time, there needed to be a way to give visual cues to the player. With a small grid system, the layout of the opponents can be a clue as to how to go about the battle.

Setting up the battles as two opposing grids lead to some interesing design decisions:

• Skills should target groups of squares on the grid, not groups of enemies.
• Effects can be placed on squares, making opponents want to be in certain formations.
• Allow for moving on the grid in place of using a skill. This could be used to make sure your characters are in a position not likely to get hit by certain skills.
• Make skills effect character location. Using a strong skill may push you or the opponent to a new square. Using this in conjunction with other skills can setup interesting combinations.

Lets look at a simple test scenario

Okay, so we’re the squares. As you can see, the squares are pretty close to all being on a single row, which could be dangerous. Likewise, the triangles are close to all being on a single column. This could be an advantage. Lets say that we have a skill to knock that pink triangle back one square. If we can do this, we could use yet another skill that targets a whole column.

Of course that’s just one simple combination. Hopefully, a lot more complex and interesting gameplay can emerge from this sort of system. I’m really interested in creating a versus mode for this. It would be exciting to see two people face off within this system as opposed to player versus A.I. There’s lots of balancing that must be done for player versus player, so I suppose we’ll see how everything progresses.

Expect more info on skills and various other abilities as the battle system improves.

VVVVVV takes the platforming genre and turns it on its head. Instead of jumping, players instead change the direction in which the main character falls. This makes getting across any gap or bump on a path an interesting endeavor, especially when the closest ceiling might be a few screens away. Not only is the very idea genius, but the execution is perfect as well. Each room is designed to be an exploration of how to use this gravity-switching mechanic, and very rarely does the game rely on the same trick twice.

In this video, you’ll see how getting across a small bump in the path is never straightforward. This is actually one of the most difficult rooms in game. The best part is that this room would be an afterthought for a typical platformer.

The game itself is relatively short. I beat it in about 3 hours, but personally I think this is an advantage. It’s refreshing to see every single inch of a game so carefully thought out, and increasing the length of the game might have led to a lot more of the same.

VVVVVV is $4.99 on Steam, and you can check out it’s website here. At the very least, play the demo to see if it’s your kind of game.

Yesterday I spent a significant amount of time working on a cleaner way to access some of the data  I had stored in some classes. Here’s a quick example:

class Character
  attr_reader :stats
  def initialize
     @stats ={:speed => 10,
              :power => 11,
              :bulk => 8 }
   end
end

This stats Hash would be a pretty standard way of storing all the stats, and because of the attr_reader, we have access to everything. Don’t get me wrong, this is perfectly acceptable code right here, but as I was writing, I found myself wanting to “simplify” a bit. I’ll show you:

#What I was writing
character_object.stats[:speed] = 12

#What I wanted to be writing
character_object.speed = 12

The thing is, what I wanted to be writing is entirely possible, for any item in the hash, with a little bit of metaprogramming.

method_missing

Whenever a method can’t be found in Ruby, another method named method_missing gets called. This means that if you define a method_missing method for your class, it’ll get called instead of the one it inherits. Here’s a proof of concept:

class Whatever
  def method_missing(id, *args, &block)
    puts "You tried to call #{id}. SORRY CAN'T DO THAT."
    super
  end
end

var = Whatever.new
var.matt              #=> "You tried to call matt. SORRY"

If you ran that code, you’d expect to see exactly what’s in the comment right before the real method_missing gets called. Notice how method_missing actually receives the id of the method called (just the name), all of the arguments (via *args), and then the block if there was one. Let’s use this to our advantage and write the getters for that hash.

class Character
  def initialize
     @stats ={:speed => 10,
              :power => 11,
              :bulk => 8 }
   end

  def method_missing(id, *args, &block)
    #The getters for the values in our hash.
    return @stats[id] if @stats.has_key?(id)

    super
  end

end

Now that we have that one extra line of code in method_missing, any value inside the hash is accessible by it’s name. Do note that I always call super at the end of method_missing. This is so that a No_Method_Error will occur should you call a method that’s not in the hash or already predefined.

These are what are called “Ghost Methods.” It should be noted that this is a rather slow process, so if what you’re doing is time-sensitive, this might not be the greatest of ideas. Instead you should check out the define_method call, and get a little creative with that.

Update: I forgot to mention that if you are going to write Ghost Methods using the method_missing technique, you’ll want to override the respond_to? method as well. Therespond_to?method allows for you to check if a method exists for that class, so the character class should now look like so:

class Character
  def initialize
     @stats ={:speed => 10,
              :power => 11,
              :bulk => 8 }
   end

  def method_missing(id, *args, &block)
    #The getters for the values in our hash.
    return @stats[id] if @stats.has_key?(id)

    super
  end

  def respond_to?(method_name)
    return true if @stats.has_key?(method_name)

    super
  end
end