Monday, September 1, 2014

Dreamspell & Lunar Calendar

I released a new Android app this weekend:

Dreamspell & Lunar Calendar

It is my interpretation of the Dreamspell 13-Moon Calendar (for more info see here:

Each day on the Dreamspell calendar has a "seal" associated with it. There are 20 seals which repeat from the first to the last for 260 days. The 13 times the seals repeat are linked to 13 moons which repeat in a 28 day cycle. The calendar recognizes 364 days to make up a year. The year starts on July 26th and ends on July 24th. July 25th is the 365th day and it is considered a "day out of time". The daily seal algorithm put out by the Foundation for the Law of Time uses look up tables tied to years and months with an epoch of 1858. It is not clear where they got these numbers from. But using the tables I was able to derive an algorithm to calculate any seal starting from the epoch date.

The lunar phases are calculated using a public domain program I found here:

There are several of these algorithms floating around by various authors. I found a good resource for astronomy algorithms at Sky and Telescope magazine:

it is surprising how arcane some of these algorithms are. Very little explanation about how they are derived is available anywhere.

Saturday, June 28, 2014

Dancing Shiva Experiment

Experimenting with Processing and Kinect:

Saturday, August 31, 2013

MegaMega Postmortem

MegaMega was inspired by Tempest. I wanted to do a flat 2d version of the game. The original idea revolved around the player preventing blocks from filling up the play field. The game was to be infinite and the player simply had to survive for as long as possible.

First Version of MegaMega


Back in 2012 I read "Beginning Android Games" and I wanted to test my understanding of what I learned from the book so I wrote the first version of MegaMega. It was a very basic game. The player had to survive until the entire play field was filled with blocks. Blocks could only be destroyed as they fell down. After a month of messing around with the game mechanics the game was shelved due to other projects taking up my time. It was written using the framework found in "Beginning Android Games".

Second Version of MegaMega w/Falling Blocks


Fast forward to the Summer of 2013. After some nudging by a friend I decided to start working on MegaMega again. This time I decided to drop the falling block mechanic and instead use the blocks as barriers which are used by the game enemies to protect themselves from the player. Basically they serve the same purpose the spikes do in Tempest except that the player can not impale himself on the spikes/block. This time around I decided to use libGDX. It has come a long way in the last year and it is being used by a lot of Android games.

Third Version of MegaMega w/Basic Game Play
One of my motivations for making this game was to see if it is possible to create a shoot em up (SHMUP) DPAD on Android that isn't horrible. All the SHMUPs I've played under Android (or iOS) suffer from horrible controls. I figured if I limited the screen space and allotted more space for controls that it would alleviate the problem of bad controls. I noticed that after several minutes of playing your fingers start to sweat and this causes problems with the controls. IMO the sweat problem alone pretty much kills the possibility of playing SHMUPs for long periods of time on touch screen based devices--unless external controllers are used.

Final Version of MegaMega

Game Design

The objective of the game is to survive through 15 zones (levels) of enemies to reach a "treasure".

Originally I wanted to do 100 zones. But due to time constraints I limited the game to 15 zones.

I split the 15 zones into three groups of zones based on difficulty:

  • EASY zones 1 to 4
  • MEDIUM zones 5 to 10 
  • HARD zones 11 to 15

For each difficulty group different music is used to notify the player that the difficulty of the game had increased.

In each zone the player must clear a fixed number of enemies in order to advance.

Since there are so few zones. I decided that the player only gets 3 lives and 3 smart bombs per life.

The smart bombs destroy all enemies and enemy missiles which are see on the play field.

The game play field is 360x320 units. Divided into 20x20 cells. So there are 18 columns and 16 rows.

The game has four types of enemies:

CRAWLERS -- attack the player from all sides. Move down towards the player and try to reach his row and collide with him.

FLYERS -- fly from left to right and right to left dropping missiles on the player. The missiles have a velocity with a x and y component.

TRIGUNS -- drop down and fire three missiles in a striaght line at the player and then leave the play field.

DROPBOMS -- drop down and when they reach the player's row they explode into two smaller dropbombs which move to the left and right of the spot where the dropbomb exploded.

Enemies spawn at different (progressively longer) intervals as the game difficulty increases and the number of enemies spawned per spawn event increases as the difficulty increases.

Where enemies spawn depends on the type of enemy. Crawlers, Dropbombs, and Triguns spawn in columns. Flyers spawn in rows.

Crawlers have an equal chance of spawning in any column. Their attack rate of movement increases as the difficulty of the game increases. I wanted the player to feel like the Crawlers were attacking from all directions and trying to overwhelm the player.

Dropbombs and Triguns spawn primarily in the center columns. They have a lower probability of spawning in the far left and far right columns. This was determined after play testing. If allowed to spawn in any column then game play became impossible for the player.

Flyers spawn primarily in the upper rows. As the game difficulty increases there is a higher chance that the a flyer will spawn at a row very close to the player. Flyers also move from left to right and right to left.

Libraries and Tools Used

I worked on the game on my Linux workstation and my laptop (Macbook Pro). The following tools were used:

  • libGDX - without this great library the game would not have been possible. It nicely abstracts away a lot of the pain of dealing with Android for game programming.
  • Audacity - for audio editing
  • Inkscape - for drawing sprites
  • GIMP - misc image editing
  • Eclipse+ADT - programming
  • - most the sounds and music came from here
  • the player cannon sound was made using SFXR
  • git for version control
  • Processing - for quick sketches to experiment with ideas
  • Trello - for task tracking


MegaMega was a fun project to work on. I started working on it in mid-July and it was finished by mid-August. I estimate I spent between 80 to 100 hours working on the game--with most of my time spent working on assets and tweaking game play. Completing this project fulfilled a long term dream of mine to have written a SHMUP style game for a hand held device.

Tuesday, August 20, 2013

MegaMega Android Game Released

After a month of coding I am happy to announce the release of MegaMega: a retro arcade SHMUP for Android. Postmortem coming soon. Enjoy!

Sunday, April 14, 2013

Game Design Dorkshop Notes

On April 13th, 2013 an introduction to game design workshop was hosted by Clay Ewing and Lein Tran of the University of Miami Interactive Media Program at The Lab Miami.

Clay and Lein started the workshop by having us play a card game called Pit. It is a simulation of commodities trading. Next they did a brief presentation on the basics of game design. Slides are here:

The remainder of the workshop was spent creating board games. Participants formed groups of 3 or more people. Each group got a card with a word on it. The word determined the theme of the game. Each team got to pick any number of random raw materials from a near by table to to build their game. After each team designed their game they had to play test it. Then they invited another group to play test their game and critique it.

My group consisted of four people: me, Chris, Kim, and Vanessa. Our theme was "TRAINS". Our raw materials were: a set of white flash cards, some sharpie pens, a set of post-it notes, a large golden ball (to represent NYC), a couple colored x-shaped plastic pieces, some colored wooden pegs, and a six sided die (d6).

The first game we came up with was:


The objective of the game is to be the first player to connect their starting node with the last node (NYC). The first player to do so wins the game. The nodes represent the neighboring cities to NYC.

 Materials Used:
  • The post-it notes represent: when cut into small sqaures -- nodes (an abstraction of neighboring cities to NYC); and when folded into rectangles -- they represent rails.
  • The colored pegs were used to represent a player's train
  • The wooden blocks were used to represent "blocks" or "barriers" on a node
  • The orange ball was used to represent the goal (NYC)
  • The d6 was used to determine the action for each game turn
Game Play Rules:

Starting from the far left of the board. Players must lay down rails by connecting nodes on the board. Rails can only be placed from an adjacent node. Rails of different players could cross at the same node. The first player to form a complete line from their starting node to the end node (with the giant globe on it) wins.
  1. Players start at node row at far end of the board.
  2. Each player rolls a d6. Player with highest roll gets to place peg on any start node. Repeat until all start nodes filled.
  3. Each player rolls a d6. Highest score goes first. Keep rolling to determine order in which players will play (from highest to lowest roll).
  4. There are five available actions for each turn:
    • AIM TRACK - change the direction of any last laid track in any direction
    • BLOCK NODE - place "block"/"wooden peg" on node w/no edges going out of it. If node is blocked then no further tracks can go out of it.
    • CREATE TRACK - place track between two nodes
    • DESTROY TRACK - destroy any last laid track
    • WILD - perform any of the available actions: AIM, BLOCK, CREATE, and DESTROY.
  5. A roll of a d6 determines what action a play can take on his turn. Here is the mapping of die roll to action:
    4. AIM TRACK
    6. WILD
Start of "NYC EXPRESS". Players at starting positions.
Several turns into the game. Three play test players
Early play testing. Four players.
After the first round of game designs we were told to use our existing materials and create a second game around any theme. After some deliberation we built a second game which was an abstraction on "NYC EXPRESS" and combined elements of checkers.

2nd game "no name" in play. Four players.
The second game used a similar mechanic to the first game. Each action was determined by a roll of a d6. This time we decided to make more use of the blocking mechanic. We also introduced swapping and stunning.

2nd Game "NO NAME"

The objective of the 2nd game was to be the first player to reach the orange globe by what ever means necessary. Each player had one action per turn determined by a roll of a d6.

 Materials Used:

Same materials used a for "NYC EXPRESS" game.

Game Play Rules
  1. Each player starts on the far left of the board on a node numbered from 1 to 4. Each player rolls a d6 to determine their starting position.
  2. Player travels from node to node via edges connected to that node
  3. First player to reach orange globe wins.
  4. Each player gets two "block" power ups.  Represented by a colored wooden peg.
  5. Player order determined by roll of d6. Highest goes first and lowest goes last.
  6. "stunning" if a player moves on top of another player then the player on the bottom is stunned and can not move until the player on top moves off him. A player can also "stun" another player by placing a "block" peg on top of them. Only a swap or a roll of "unblock" by the stunned player can remove the block or if the player who placed the block wishes to remove it an place it on another player or on a node.
  7. Player rolls d6 at each turn to determine their action
    1. MOVE ONE NODE - move player one node away in any direction so long as an edge exists between the current player node and the adjacent node.
    2. BLOCK - place a block on any node or any player.
    3. MOVE TWO NODES - move player two nodes away in any direction so long as an edge exists between the current player node and the adjacent node.
    4. REMOVE BLOCK - remove block from board and keep in your possession. Players can remove blocks placed by other players.
    5. SWAP - swap position with any other player
    6. WILD - perform any of the actions above. Player's choice.
  8. There are six possible actions:
Everyone (including myself) seemed to like the 2nd game best. It played a lot faster and it sort of felt like a video game.

Overall it was a fun workshop. The pace was excellent and the participation was great. Three other groups each created three games: a card game, a seed farming game, and a hidden object/quest game. I only got to play the seed farming game which was based on beer pong. I look forward to the next Game Design Dorkshop. We need more of these types of events in Miami.

Monday, April 30, 2012

Book review

Great book. It makes a call to action for everyone to start making games. It doesn't matter how good or bad a game is. Just do it. Make a game, distribute it, and then make another game. My favorite piece of advice: MAKE WEIRD SHIT.

Sunday, February 19, 2012

BarCamp Miami 2012

Gave talk about Galaga enemy patterns at BarCamp Miami 2012. Here is a photo of me explaining some z80 assembly code. :)