Dark Sky

The Original Idea (Before)
The Current Game (After)

Game Demo and Controls


Left Arrow or A moves the player left.

Right Arrow or D moves the player right.

Up Arrow or W moves the player up.

Down Arrow or S moves the player down.

Holding Shift while moving allows you to “sneak”.

Pressing B when over a shop item allows you to purchase it.

Left/Right Click to fire your weapon.

Enemies and Bosses

The enemies of the game began as a simple graphic bug graphic as shown in the “Before” image and were only planned to be used for testing rather than actually being in the game. The bugs became the base for most enemies and the bosses of the game. The code for collision was spread to almost every enemy and modified to suit the enemy’s size. It would select a random direction and go a certain distance. If it hits a wall/enemy/portal, it turns in the opposite direction. If it goes the certain distance, it changes into a different random direction or continues on its path.

Example for Big enemy:

if (x < 50 && randdirection == 0) // Turns the Big left
if (Wallleft == null && Bigleft == null && Launcherleft == null && Portalleft == null) // Checks for collision
setLocation(getX() - speed,getY()); // Moves the Big left
setRotation(270); // Rotates the graphic to look to the left
rand = 1; //Turns the Big right

Some of the enemies also react to “sound”. The sound level changes depending on your movement. If you move without holding shift, the sound level is loud. If you hold shift, you move slower but the sound level is low. If you don’t move at all, there is no sound level. The Big enemy reacts if any sound is made, and stays stationary if no sound is made.


if (!Greenfoot.isKeyDown("shift"))
mode = 2;
if (!Greenfoot.isKeyDown("up") && !Greenfoot.isKeyDown("w") && !Greenfoot.isKeyDown("down") && !Greenfoot.isKeyDown("s") && !Greenfoot.isKeyDown("left") && !Greenfoot.isKeyDown("a") && !Greenfoot.isKeyDown("right") && !Greenfoot.isKeyDown("d"))
mode = 1;
mode = 3;
if (!Greenfoot.isKeyDown("up") && !Greenfoot.isKeyDown("w") && !Greenfoot.isKeyDown("down") && !Greenfoot.isKeyDown("s") && !Greenfoot.isKeyDown("left") && !Greenfoot.isKeyDown("a") && !Greenfoot.isKeyDown("right") && !Greenfoot.isKeyDown("d"))
mode = 1;

The Player

The player has the biggest amount of work put into it than any part of the game. The code for the player controls many aspects of the game including purchasing items, movement, going into different worlds, healthbar, etc. The design of the player graphic went through several iterations before becoming the blue robot that is in the present game. The player, as told below in the problems section and the before image, started off as a human. The weapons for the game were going to be things like a bow, sword, rock, and other things. Then I realized three things. One, making the weapons on the player would be infuriating as I would have to change the hands and the arms. Two, the footstep sound effect (Discussed in problems section) wasn’t working as well as I hoped. Three, the player graphic didn’t really look too much like a human. So I changed it into a robot due to it being easier to make, the weapons wouldn’t be as hard to put on, and the sound effects would be easier.

Weapons and Beginning Area

The weapons of the game have different characteristics but share some general code (Mostly collision code). The first weapon I give the player to use is the laser. It is meant to be a simple weapon with not very good range to start the player off. The weapon is also not given to the player at the start, as it is in pickup form in front of the player. This is to teach the player that when you move the enemies move. The bigs also usually go on ice which shows what ice does when you step on it.


When you run into a problem with your code, its like running into a brick wall. Whether that wall has two paths only a few feet away to proceed or one path that is three miles away depends on the problem.


One of the very first and most persistent problems I ran into was sound. The most common was movement. There are two sounds for movement, which is for sneaking and for regular movement. When I first implemented these sounds, they were meant to be footsteps (Due to the player being a human at this point) but ended up being a continuous noise whenever I walked. I fixed the problem by putting in a “timing” system which basically plays a sound whenever an integer is divisible by a certain number.

wait = wait + 1;
if (wait % 14 == 0)

The problems didn’t stop there, as the sound began to sound annoying. Then, when I decided to change the player into the robot, I had to make new sounds. The sound for regular movement I made almost made my ears explode, but I used them for the time being and kept the sound on low. The sneaking one was great though. Eventually I decided that the sound for regular movement was too loud and I made it so the sneaking sound was used for both regular movement and sneaking until I made a new sound. The sneaking sound was kept until very recently (5/27/14) when I made a new sound which kind of sounded like running over rocks. That was made into the sneaking movement sound. The original regular movement sound was lowered and was made into the collision sound for the lightspike enemy.


The other thorn in my side was the portals. In the holes between two walls is a portal class that is meant to take you to the next level. Of course, the first time I tried to do this the portal didn’t work. I would briefly be in the second world but then it would kick me right back into the first world. The problem that I thought it was is that the getOneIntersectingObject() function was causing something to go wrong. Surprisingly, using a different collision function fixed it. The next problem was to transfer health, weapons, and other variables into the different world. It took about 2-3 days until I figured out I could just use a constructor to transfer the variables. As time went on, more and more variables had to be added to both the player constructor and the world constructor.  Then another problem arose. Putting more than one portal in a room did not work. I figured out a solution that I didn’t like using, but is still used now. The portals are rotated and those rotations decide where the portal is taking you depending on what world your in (Ex. 180 degrees would be the portal in the “after” image at the top). I also had to use an integer to specify where I wanted the world to put me (ex. 1 = put me in preset location 1).

Unused Content

Things are usually made to be used in a game but some aren’t ever put in due to problems with functionality or it no longer being relevant to the game. When I made the game, I had different ideas on what the enemies were going to be, how the game would work as a whole, and other functions and mechanics. These are some things that I never got around to using.




The Shield was going to be an essential part of the game along with the health bar. It would regenerate over time and would give you enough time to either get away or get more health. It wasn’t implemented because, due to the fact you could increase you health and a module idea(Adding effects like regeneration, speed boost, etc. to the player) I had, I decided it wasn’t necessary.



Level-Up System

Before the store system was made, I was going to develop a level-up system. Basically, you would collect experience points from an enemy and each enemy would yield a different amount. After the player collects a certain amount of experience, the player could “purchase” a skill from the experience screen. It was never completed and was replaced with the store.

“Rock” Weapon

playern rockpickup

The “Rock” weapon was a weapon idea to drop from the special variation of the Giga boss. Ideas of what I was going to make this weapon be was a larger rocket/explosion, launching a huge rock, or firing a wave-looking projectile. It was never added and was replaced with the rocket launcher drop.



Special Graphic for the Lightspike 

Originally the lightspike had a special graphic that was bigger than the original sprite. This was too give the player a challenge and the special variety would appear 1/7 times. It was removed when the collision code was not working. The lightspike no longer has a special image and the special image was reworked into the lite enemy of the game.


Enemy Robot

The enemy robot is an enemy that I just never got around to adding. It was to act like the player using both the laser weapon and the blaster weapon. Of course, it looks visually different that the player, making it seem it was more designed for battle than the player.

playere (Blaster weapon for player)

Also, the enemy was also going to have a shield with it as well.


Alternative Constructor for Launcher Enemy

The Launcher enemy has a constructor to turn and change the way I wanted it to. (ex. 2-sided turret that is rotated 90-degrees). This constructor was used until a better and more efficient one was made.
public Launcher(int rot, boolean u , boolean d, boolean l, boolean r, int amt, int s, int wt) //amount of turret sides, rotation
rotate = rot;
if (rotate != 0 && rotate != 90 && rotate != 180 && rotate != 270 && rotate != 360)
System.out.println("The allowed rotations are 0,90,180,270,360. Setting to 0 degree rotation.");
(More variables equaling the constructor variables here)
if (amount == 5)
if (amount == 4)
(More setting images code here)
if (amount != 1 && amount != 2 && amount != 3 && amount != 4 && amount != 5)
System.out.println("Not an acceptable amount of sides. Set to default 4 sided mode.");

The current constructor also isn’t really used, as there is only one variation of the launcher present in any of the worlds at the moment.

One thought on “Dark Sky

Leave a Reply

Your email address will not be published. Required fields are marked *