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: http://www.lawoftime.org).

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:

http://raingod.com/raingod/resources/Programming/Java/Software/Moon/javafiles/MoonCalculation.java

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

http://www.skyandtelescope.com/astronomy-resources/basic-programs-from-sky-telescope/

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

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

Background

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

Motivation

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 is 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 360×320 units. Divided into 20×20 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
  • freesound.org – most the sounds and music came from here
  • the player cannon sound was made using SFXR
  • git + bitbucket.org for version control
  • Processing – for quick sketches to experiment with ideas
  • Trello – for task tracking

Conclusion

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.