Skip navigation

Monthly Archives: April 2009

I decided to go with the maze game for the iPhone/iPod Touch.  It will consist of a target that will either be circular or cuboid that the player must move to the end point using their fingers to guide it.  Touching a wall or object will set the target back to the last checkpoint.  I haven’t decided whether I want to implement lives or a timer.  I will try both and see which one playetesters enjoy more.  I think lives will be best, but that remains to be seen.  Simple game with some decent potential, here’s what I have for the “boring architecture part”:


  • Don’t need texture loading (that I can think of)
  • Simple style of colored shapes
  • View scrolling when the target gets to the edge of a defined area.
  • Will have to rebuild Radiance to make sure all of this works well.

User Interface

  • Basic Cocoa UI elements, using Radiance I can overlay what I need.
  • Want to experiment with different kinds of menus and UI displays.
  • Need to make sure view scrolling is adjustable.


  • Implementing Separating Axis Theorem which requires rebuilding Continuum.
  • Need to detect edge triggers for things like doors and victory conditions.
  • Unit test the crap out of my revamped vector system and rotation implementation.

Game Logic

  • Target resets to last checkpoint after (5) seconds of not being touched.
  • If the target touches an edge or another object, reset.
  • Timer?  Lives?  TBA
  • Later levels will have the target orbit the touch point.
  • Later levels will have multiple targets.
  • Later levels will have multiple targets with independent end points.

Level Builder

  • Grid system to start, build level with “positive” tiles on negative background.
  • Want to implement this in Lua to allow for greatest flexibility.

So, that’s pretty much the gist of it.  I have a lot of work to do.  Already rebuilt the vector class I was using to be a little more friendly.  Looking into SAT implementations.  I understand the concepts, but I’m unsure about implementation.  This is gonna be a lot of work at a difficult time.  Cross your fingers…


That’s right, the end of the semester is rapidly approaching.  For the last few weeks of class we are supposed to pick a personal project that we want to do and run with it.  I have a few ideas for this one.  I already told Prof. Monnens I was going to do one of these, but I am still deciding.  Here are the possibilities:

  • A maze game for the iPhone
  • Help Tim with Mass Effect TTRPG
  • Realistic space combat game
  • 4x TBS game that I have been working on in the past
  • The Speciation Sim outlined in ‘Life, advanced’ below.

I’m probably going to do either the maze game or help Tim.  Both of these are relatively simple and would fit within the purview of the class.  I may just assign them percentage values and roll a d100 like a good nerd.  I’ll be sure to post what I decide and how I got there.  Peace.

EDIT:  I have opened it up to a poll.  I will be deciding shortly, so get your votes in now!

EDIT: For those not in the know, I’ve been working with a simple game creation program called “Scratch”.  This application was made by some guys at MIT in an attempt to create an easy to learn and use game creation tool.  It can be found at  Enjoy, even though I really didn’t…

Scratch is an interesting little program.  It has a very gentle learning curve, but is also limited by some pretty heafty issues.

  1. Only 1 key press is registered at a time.
  2. Duration between initial key press and key repeat is very long.
  3. Pressing a new key while a key repeat is in effect will cancel the key repeat.
  4. You cannot make the play field any larger than the initial size without scrolling (which is pretty darn small).
  5. You have to create and reuse every object that will be in the game at design time, instead of having the option of creating new instances during runtime.
  6. Sprite scaling degenerates a sprite if you scale it too far down and then back up again.

Scratch does have some advantages though:

  1. It’s supported on many different platforms.
  2. It’s very simple and easy to use.
  3. The rotation mechanics are simple and intuitive, very nice.

It’s pretty obvious that Scratch’s intention was for rapid prototyping.  And if it wasn’t, that is all I would use it for anyway.  It has strong potential as a rapid testing bed for gameplay mechanics.  However, it’s shortcomings prevent it from creating high end games that anyone might want to distribute to non-friends…

That may seem harsh, but it’s the truth.  Bravo to MIT for trying to make a game creation tool with a very simple interface.  For what it’s worth, they did a valiant job.  But Scratch is far from capable and I will keep in mind as a test platform for game mechanics, at best.

On to the game… I did the simple space combat game.  While very basic, it was still quite fun and difficult.  There were some aesthetic changes that need to be made regarding ship models, but other than that, the controls really didn’t seem to be much of an issue and gameplay went relatively smoothly.

This challenge calls for the creation of a two-player digital game using Scratch or similar software.  Fortunately, we are allowed to pull other people onto the project, but I’d like to work with some people I haven’t really worked with yet.  That will be difficult to coordinate considering we don’t have class again this week.

As far as ideas, I’m probably going to go with a simple real-time space combat game, or something similar.  Hopefully have some developments shortly.

We had some issues when it came to “any subject matter not covered in the rules is open to interpretation”, actually resulting in physical violence.  So a new rule has been instated: you cannot steal cards from other players and you cannot take more than one card from the deck at a time and you can only draw cards, trade, or fight on your turn.  Other than these simple changes, I really like the “subterfuge rule” as we’re calling it.  It really highlights the chaotic battlefield that is international (and interpersonal) relations.

Other than these changes, I feel the card game is pretty solid.  There had been some rumblings of multi-front fighting.  However, I believe this would be a development for future changes.  Overall fun, crazy, and powerful game.  I’m quite happy with how it turned out.

This challenge was to revise an old game.  I think I will give another try at Entropy, or “War Fish” as it was called.

Stop posting spam comments.  You know who you are.  Stop it.

Game developers, you do not need to award an achievement for every little thing the player does.  Advancing the story in the game and completing levels is a reward in itself.  Achievements/trophies/whatever are for things that are above and beyond the normal play experience.  Stop it.

I’ll have more later, but for now, stop it.

This was a strange turn of events.  The game I came up with for this challenge was poor, to say the least.  After several iterations, I finally decided to throw the whole concept out because it was ineffective at getting my desired messages across: the importance of trade and the waste that could save others.

So, Prof. Monnens, myself, and a few other VA 306 students sat down and thought out a simple way to convey these message with the resources we had on hand.  What we came up with was a surprisingly entertaining and effective card game.


3-8 players

Low complexity

Players are attempting to collect as many four-of-a-kind “pots” as possible.  This game is played with a standard deck of playing cards.  Each player is dealt five cards and play starts with whomever you agree upon.  On their turn, a player can do one of three things:

  1. Trade cards with another player.
  2. Draw a new card from the deck.
  3. Attack a player to attain a named card (suit is not needed).

“Combat” is resolved in a simple rock-paper-scissors style where:

  • Club – BEATS: Spade                          BEAT BY: Heart, Diamond
  • Spade – BEATS: Heart                        BEAT BY: Club, Diamond
  • Diamond – BEATS: Club, Spade        BEAT BY: Heart
  • Heart – BEATS: Club, Diamond       BEAT BY: Spade

IF the “attacker” wins, they keeps the cards that were used to fight them and one of the desired cards in given to the attacker.  The attackers turn is over.

IF the “defender” wins, the defender keeps both cards.  The attacker may continue to push the attack until they give up or they win.

IF the two cards are a tie, they are kept as stakes and the battle is attempted again.

Any rules that are specified here are open to interpretation.  On that note, a funny variation of the game is played by excluding one (or two) random card(s), just to watch the hilarity ensue as a player attempts to evict the non-existent card from some innocent player.  Hyenjoy!

Paper Prototyping is a great article that I wish I had seen *before* I had done my iPhone game.  It has some very useful and interesting insights that I will be sure to use and reflect upon as I continue to develop, not only for the iPhone, but for all my games in the future.

Very useful article, I would recommend it to anyone who is looking into games, especially big budget games where mistakes cost lots of money.

This presentation was interesting to say the least.  The format of the piece made it difficult to follow and the speakers sometimes got side-tracked and distracted by some things.  Overall, though, I thought it was a very informative presentation.  I found it fitting and cool that some of the things that made the best prototypes for them were pieces of software or similar things that were never really intended for prototyping.  Hecker also represents many solid design principles which really make the presentation worthwhile.  His interpretation of iterative design and the idea of frequent, repeated, and observed playtesting is an important part of the presentation.

In general, I would recommend the presentation for anyone with some prototyping experience and about an hour to go through all of it.