Forem: Jess

Ghost Trap: My TeenyTiny DragonRuby MiniGameJam Entry

Jess — Mon, 30 Nov 2020 04:16:46 +0000

A few weeks ago I wrote a post about the Dragonruby game engine. I mentioned that there was a month-long game jam to make a 20 second game. This post is about my entry: Ghost Trap.

Try it out on itch. If the html version is a little wonky you can download your OS specific version. I tried it on 3 different computers and it was fine on 2 of them, but the older Windows machine could not handle it.

When I was a kid I really liked the Ghostbusters game for the Sega Master System. It's not a great game, but I liked stopping the ghosts from entering buildings, driving and catching the ghosts, and trapping the ghosts at the homes they were haunting. I decided I would make a game that was similar to trapping the ghosts.

In the Sega game, you get to your destination and you have 2 ghostbusters to move. You move one where you want him, then use the other to guide the ghosts between the two of them toward the trap.

I didn't want to make a clone, so I decided to make it so a single "ghostcatcher" catches ghosts in their beam, which get sucked into their backpack. The backpack can only hold 10 ghosts, so the ghostcatcher has to periodically deposit ghosts into the ghost disposal canister. The objective is to trap as many ghosts as you can in 20 seconds. You can earn a combo the more ghosts you catch on your beam at once and your beam energy depletes over time to keep the player from holding the button down the entire 20 seconds. You have to stop shooting to regenerate energy.

Oh yeah, this is a world of dogs instead of people, because why not? Truthfully I didn't want to draw a ghost that looked like a traditional emoji looking 👻 ghost, so I made a dog-ghost. Plus, this gave me an excuse to use my dog Pixel as a reference for my ghostcatcher.

Artwork

I made the art with a combination of Affinity Designer and Procreate on the iPad and Affinity Photo on the Mac. I never used the Affinity software before so I was learning as I went along. Affinity Designer is really cool and I enjoyed working with it once I started to get the hang of it, but I really miss having access to Photoshop which is something I'm quite comfortable with.

Code Organization

I broke my code down into 6 classes and a few helper methods. I think some of the code I wrote was possibly handled by Dragonruby, but since I'm still learning how it all works I didn't take advantage of all of its features.

Entity

The Entity class is the parent for my other game object classes. It has properties for sprite dimensions and attributes, collision, and rendering.

# an excerpt of the Entity class

class Entity  
  attr_accessor :x, :y, :w, :h, :sprite_path, :flip, :alpha

  def initialize(x, y, w, h, sprite_path, flip)
    @w = w
    @h = h
    @x = x
    @y = y
    @sprite_path = sprite_path
    @flip = flip
    @alpha = 255
  end

  def rect
    [x, y, w, h]
  end

  def render
     [
      x, y, w, h, sprite_path,
      0,              # ANGLE
      self.alpha,            # ALPHA
      255,            # RED SATURATION
      255,            # GREEN SATURATION
      255,            # BLUE SATURATION
      0,              # TILE X
      0,              # TILE Y
      self.w,         # TILE W
      self.h,         # TILE H
      self.flip,      # FLIP HORIZONTALLY
      false           # FLIP VERTICALLY
    ]
  end

  def is_colliding_with?(obj)
    self.rect.intersect_rect?(obj.rect)
  end

  #... etcc

end

I made the rect method to pass to the built-in intersect_rect to check for collision, but I believe it might be something I could have handled with Dragonruby natively. That's something I have to research further.

Player

The Player class is a subclass of Entity and handles all the player specific stuff like moving, shooting, catching ghosts, etc.

# an excerpt of the Player class

class Player < Entity
  attr_accessor :total_ghosts_held, :backpack_limit, :beam, :is_shooting, :ghosts_on_beam, :beam_power, :beam_cooldown, :speed, :is_walking, :sprite_frame, :shoot_sound_playing

  MAX_BEAM_POWER = 200
  BEAM_COOLDOWN = 1

  def initialize
    w = 114
    h = 300
    super($WIDTH/2-w/2, 90, w, h, "sprites/player_green_1.png", false)
    @total_ghosts_held = 0 # total ghosts in pack
    @backpack_limit = 10
    @beam = {x: ((self.x + self.w)/2).to_i, y: self.y+h, h: 300, w: 23}
    @is_shooting = false

    @ghosts_on_beam = []
    @beam_power = MAX_BEAM_POWER
    @beam_cooldown = 0
    @speed = 6
    @is_walking = false
    @sprite_frame = 0
    @shoot_sound_playing = false
  end

  def set_sprite
    status_color = self.space_in_pack? ? "green" : "red"
    self.sprite_path = "sprites/player_#{status_color}_#{self.sprite_frame+1}.png"
  end

  def calc(outputs, tick_count)
    self.sprite_frame = self.is_walking ? tick_count.idiv(6).mod(2) : 0

    if self.can_shoot? && self.is_shooting
      play_sound(:shoot) if !shoot_sound_playing
      self.shoot_sound_playing = true if !self.shoot_sound_playing
      self.shoot(outputs, tick_count)

    elsif self.has_ghosts_on_beam?
      self.shoot_sound_playing = false
      add_score(self.total_ghosts_on_beam)

      self.store_ghosts_from_beam_to_pack

      self.ghosts_on_beam.clear

    end

    self.refill_beam if !self.is_shooting && self.beam_power != MAX_BEAM_POWER

  end
end

Ghost

The ghost class handles spawning ghosts, and each instance can keep track of whether or not it has free will (if it's caught in the player's beam or can move freely) and if it's invulnerable. Ghosts flicker in and out and are invulnerable to being caught if they are transparent.

# an excerpt of the Ghost class 

class Ghost < Entity
  attr_accessor :is_flickering, :is_invulnerable, :has_free_will, :is_in_beam, :id

  def calc(tick_count)
    # use different sprite if ghost is on beam
    self.sprite_path = !self.is_in_beam ? "sprites/ghost80.png" : "sprites/ghost_on_beam.png"

    # keep in bounds
    self.y = $HEIGHT if self.y < 0 || self.y > $HEIGHT
    self.x = 0 if self.x < 0
    self.x = $WIDTH - self.w if self.x + self.w > $WIDTH

    self.toggle_flickering if tick_count % 60 == 0

    self.flicker if self.is_flickering

    self.move_freely(tick_count) if self.has_free_will
  end

  def stop_flickering
    # play_sound(:flicker_in)
    self.is_flickering = false
    self.is_invulnerable = false
    self.alpha = 255
  end

  def start_flickering
    # play_sound(:flicker_out)
    if self.has_free_will
      self.is_flickering = true
      self.is_invulnerable = true
    end
  end

  def self.spawn
    x = random_int(20, $WIDTH - 100)
    y = random_int(400, $HEIGHT - 100)

    Ghost.new(x, y)
  end

Disposal

Disposal is the canister where the player deposits ghosts. It keeps track of how many ghosts it contains and its open/closed status to handle which sprite should display.

# An excerpt of the Disposal class

class Disposal < Entity
  attr_accessor :total_ghosts, :is_open, :timer

  def initialize
    super(566, 221, 99, 154, 'sprites/canister.png', false)
    @is_open = false
    @total_ghosts = 0
    @timer = 1
  end

  def deposit_ghosts(total_to_add)
    play_sound(:dispose)
    self.is_open = true
    self.total_ghosts += total_to_add
  end

  def calc(tick_count)
    self.timer -=1 if self.is_open
    self.is_open = false if timer <= 0 && tick_count % 10 == 0
  end

  def open_canister
    self.sprite_path = OPEN[:sprite_path]
    self.w = OPEN[:w]
    self.h = OPEN[:h]
end

  def close_canister
    self.timer = 1
    self.sprite_path = CLOSED[:sprite_path]
    self.w = CLOSED[:w]
    self.h = CLOSED[:h]
  end

  def render
    # set sprite based on open status
    self.is_open ? open_canister : close_canister

    super
  end
end

GhostTrap

Finally, there is the GhostTrap class, which is the game class that handles all the game functionality and pieces everything together.

The defaults method sets up all of the properties in state. Normally I would use instance variables, but Dragonruby has a built-in variable called state that is passed from tick to tick.

def defaults
   state.player ||= Player.new
   state.disposal ||= Disposal.new
   state.ghosts ||= MAX_GHOSTS.map { Ghost.spawn }
   state.mode ||= :title
   state.timer ||= 20
   state.score ||= 0
   state.countdown ||= 3
end

All rendering (drawing to the screen) are organized within the render method, and all updates are handled within the calc method. User inputs are handled in process_inputs. I broke everything down further depending on what game screen the user is on.

def render
   render_title if state.mode == :title
   render_instructions if state.mode == :instructions
   render_credits if state.mode == :credits
   render_play if state.mode == :play
   render_game_over if state.mode == :game_over
end

Problems

I had the most trouble working with sound effects. I was able to get basic sound effects working, but I couldn't figure out how to get an effect that wasn't music to loop and stop when I wanted it to. I wanted a whirring effect for the player's beam but I settled for an initial effect each time the player first presses the spacebar to shoot. I did this by adding an additional variable, shoot_sound_playing which I set to true when the player shoots, as long as it's not already true. Then I set it to false when the player stops shooting.

The Dragonruby docs recommend you go through each sample game thoroughly to really learn the engine, so I went through what I could but I didn't have time to really dig into everything. I think if I go back and look through the code when I get a chance I can probably do some refactoring and make some improvements to my game.

 if self.can_shoot? && self.is_shooting
      play_sound(:shoot) if !shoot_sound_playing
      self.shoot_sound_playing = true if !self.shoot_sound_playing
      self.shoot(outputs, tick_count)

      # ... etc

You can find the full game code on my github

Side note: I know I used self sometimes and not other times. Personally I prefer to use it because then I know exactly where a method is coming from and to me that's more readable, but Dragonruby doesn't use it and I know Ruby is all about being free of clutter. I'm still in the process of cleaning everything up and making it consistent, but I wanted to get this post out asap. :)

Getting to Know the DragonRuby Game Engine

Jess — Sun, 08 Nov 2020 23:00:38 +0000

DragonRuby Game Toolkit is a 2D game engine for making games using the Ruby programming language. I happened to get a license for it as part of the Bundle for Racial Justice and Equality on itch.io back in June but never got around to trying it out. Last week I received an email from one of the creators and it mentioned that there is a beginner friendly Game Jam so I figured now would be a good time to dive in!

The docs are pretty extensive but here I'll attempt to sum up some of the very basics.

Game Loop

The main function in DragonRuby is called tick and it runs 60 times per second (about every 16ms). There is no delta time to worry about; the loop just works at 60fps.

The code below will create a new instance of Dog every 16ms and store it in args.state (I'll come back to this in a bit).

def tick args
  args.state.dog = Dog.new
end

class Dog
  def initialize
    puts "I am a new dog"
  end
end

Being that you only want to create a new Dog instance once and set it to args.state.dog, this isn't ideal. Luckily, there is an easy way to fix this.

def tick args
  args.state.dog = Dog.new if !args.state.dog
end

Here I am using a conditional to set args.state.dog if it does not already exist. By doing this, it will only set args.state.dog the first time and will only create the Dog instance once.

This is repetitive and long-winded, however. Below, you see an example that accomplishes the same thing by using ||= (or equals), which means to only set the value if its value is false or nil.

def tick args
  args.state.dog ||= Dog.new
end

args

args contains all the functionality for making your game, such as a way handle input and output, and store your variables.

args.state

args.state is a data structure where you can store your game data, such as an instance of Dog, or your player's position. What's stored in state is carried over from tick to tick.

def tick args 
    args.state.player.x ||= 120
    args.state.player.y ||= 200
end

args.outputs

args.outputs is used for rendering to the screen.

This creates a red 100x100 square at (100, 250). You can change the color by adjusting the RGB values.

#                               [x, y, width, height, red, green, blue]
args.outputs.solids << [100, 250, 100, 100, 255, 0, 0]

Quick Note on the coordinate sytem: (0, 0) is at the bottom left corner. Positive numbers go up and to the right and negative numbers go down and to the left.

args.labels is used to write text to the screen.

This adds the black text 'This is a red square' slightly below the red square.

#                               [x, y, text, red, green, blue]
args.outputs.labels << [100, 240, "This is a red square", 0, 0, 0]

args.inputs

args.inputs is used for keyboard, mouse, and gamepad input.

Mouse Input

This code initializes a click_count to 0 and displays the total clicks to the
screen. Every time the user clicks and releases their mouse button, the click_count is increased by 1.

 args.state.click_count ||= 0

 args.outputs.labels << [100, 240, "Click count: #{args.state.click_count}", 0, 0, 0]

 args.state.click_count += 1 if args.inputs.mouse.up

Keyboard Input

This code initializes a player's (x,y) position to (100, 100) and creates a red square (just like above) at those coordinates. Then, it increases or decreases the (x,y) values by 1, depending on which directional key was pressed.

def tick args
  args.state.player.x ||= 100
  args.state.player.y ||= 100
  args.outputs.solids << [args.state.player.x, args.state.player.y, 100, 100, 255, 0, 0]

  args.state.player.x += 1 if args.inputs.keyboard.d
  args.state.player.x -= 1 if args.inputs.keyboard.a
  args.state.player.y += 1 if args.inputs.keyboard.w
  args.state.player.y -= 1 if args.inputs.keyboard.s
end

There is a lot more to DragonRuby that I haven't even touched on. If you're interested in trying it out I highly recommend you check out the docs here, and here, which also link to some tutorial videos. There is also a free course you can check out to get started.

Here is a link to the Game Jam if you'd like to join. You can also claim a free Game Jam license.

My Experience Entering JS13k

Jess — Tue, 15 Sep 2020 01:58:57 +0000

I found out about JS13k, a competition to make a JavaScript/HTML5 game in under 13kb, back in July.

I've always wanted to make games; it's a big part of why I got into programming. However, being in the midst of a job search, I feel like I never have enough time to get into it since I'm trying to keep up with learning all of the web technologies and frameworks, practice algorithms, etc. My "hobby" has to sit on the sidelines.

I figured since I primarily code in JavaScript I wouldn't have to overwhelm myself trying to quickly learn a bunch of extra stuff on top of my already stacked list of things I'm trying to learn, so I could definitely try to enter. The competition lasted 1 month, from August 13th - September 13th.

Theme / Brainstorming

This year's theme was 404, as in the Not Found error. I came up with a concept that would be sort of like a point-and-click but I scrapped it because I didn't have a lot of time to come up with puzzles and a story. Then I thought, what about a killer robot with a missing kill.exe file? The player could play as the robot being swarmed by some type of enemy and they would need another way to defeat them. How about bringing them food? I figured I could make a game where food spawns in random locations as enemies swarm around and you have to bring them whichever food they want.

Then I thought, what about that old Bugs Bunny game Crazy Castle? I could make something like that, but instead of avoiding enemies and collecting carrots, you find and bring them the foods they want. If you come into contact with them without the correct food you lose. I really liked this idea, but again I didn't have a lot of time to come up with a bunch of different levels. Finally I thought, what about something like Pac-Man where there is a single map? This idea worked for me; there could be a "food court" and the player could zip around snagging the right food for the right enemies. Oh yeah, I decided the enemies would be aliens who really like tacos and donuts.

Bugs Bunny Crazy Castle (image from Emuparadise)

Creating the Game Art

After settling on an idea I used Aseprite to make my game art. I don't have a lot of pixel art experience so I was just kind of winging it. Thankfully Aseprite is fairly easy and fun to use so I was able to come up with designs that I liked.

This is my final spritesheet. So small, so cute.

Code Time

I decided to make everything from scratch, as opposed to using one of the game engines from the JS13k resource page. I just felt like even if I didn't come up with the best game, I wanted to learn how to make everything myself.

Organization

I created a main.js where I handled the main game loop as well as any event listeners and a few global variables to instantiate a game object and to import sprites and sounds. Depending on the current game.state, gameLoop() either displayed the title screen, game over screen, or called requestAnimationFrame and looped game.update() (which handled game logic) and game.draw() (which handled drawing to the canvas).

Just about every other class, such as Player, Enemy, Food, EnemySpawn, etc extended off of a GameObject class which handled collisions, animations, and variables like x,y, width, height, and the source location and size of each object on the sprite sheet. I'll probably eventually go back and clean some of this up, because many of the child classes don't do anything special or different. It was just easier in the moment to create the child class and keep track of all objects of a certain type using static class variables. For example:

import GameObject from './GameObject.js';

export default class FoodCourt extends GameObject {
  static all = [];

  constructor(srcX, srcY, srcW = 16, srcH = 16, x, y, w, h, type) {
    super(srcX, srcY, srcW, srcH, x, y, w, h, type);
    FoodCourt.all.push(this);
  }
}

This way I could just use FoodCourt.all to loop through only food courts when the player was within a certain range to check for collisions as opposed to looping through all game objects. I could probably go back and just use static foodCourts = [] in the GameOject class, and push all newly instantiated foodCourts to that instead of creating a whole child class.

Planning collision distance to the food courts on my dry erase board

Struggles

I made my sprites 16x16 or smaller and therefore they needed to be scaled up. I also wanted the entire game map to scale depending on window size but it needed to stay in proportion. I spent a lot of time struggling with this. I got the sprites to scale up but then the collisions weren't working correctly and my character kept shooting off the sides of the screen. I did some research and found that basically you're dealing with 2 canvas sizes: the native height and width used for all your game logic, and the canvas height and width used for display. If you're curious how I went about this, I wrote a post here.

As the deadline was swiftly approaching I had to cut a lot of my ideas and just get something working. I added mobile controls, which are okay but could be a lot better, and I was able to create a few sounds using jsfxr.

The game was due at 7AM my time (13:00CEST) on Sunday, September 13. I was as done as I was going to be at around 9:30PM Saturday night. I had used some tips I found in a post by Yvonnick FRIN to compile and zip the game and it was under the required 13kb. Yay!

I started to fill out the form to submit my game and I ran into an error because I didn't have the index.html in the root. It was in src along with all my js files, which is not how I normally organize my file structure, but that's how the guide told me to do it. I didn't follow the entire guide though, so maybe I missed something further on. Anyway, I re-organized the file structure and I could no longer get the game to find my images and sounds. Then when I got it working it wouldn't compress to under 13kb anymore. I was very confused. I tried multiple methods to compress and get everything working. I even copied all my code from separate files into 1 file and tried online minifiers, and I tried another JS13k starter that has scripts to do some high file compression and zip for you. Nothing I did was working and I couldn't figure out why. I dug into the scripts and started trying to learn what they were doing, how Archiver works, etc.

At around 4:00AM I was feeling defeated and I was preparing to give up and just be happy that I made a game. I closed my computer and went to wash up for bed. While I was brushing my teeth I thought about how the first time I zipped the build it was fine, except for the file structure being wrong. I decided I would go back to my computer and give it one last-ditch effort by reverting back to that first attempt and using what I learned by messing around with the scripts. It...worked... IT WORKED! I can't believe I was ready to give up, but I'm so glad I didn't.

You can play it here if you'd like: Kill.exe Not Found