game_2d 0.0.2 → 0.0.3

data/README.md

@@ -2,14 +2,37 @@
 
 A 2D sandbox game, using Gosu and REnet.
 
-There's not much here yet, in terms of actual gameplay.  At this point I'm laying the foundation.  What I have so far:
+## Overview
+
+Built on top of Gosu, an engine for making 2-D games.  Gosu provides the means
+to handle the graphics, sound, and keyboard/mouse events.  It doesn't provide
+any sort of client/server network architecture for multiplayer games, nor a
+system for tracking objects in game-space.  This gem aims to fill that gap.
+
+Originally I tried using Chipmunk as the physics engine, but its outcomes were
+too unpredictable for the client to anticipate the server.  It was also hard to
+constrain in the ways I wanted.  So I elected to build something integer-based.
+
+In the short term, I'm throwing anything into this gem that interests me.  There
+are reusable elements (GameSpace, Entity, ServerPort), and game-specific
+elements (particular Entity subclasses with custom behaviors).  Longer term, I
+could see splitting it into two gems.  This gem, game_2d, would retain the
+reusable platform classes.  The other classes would move into a new gem specific
+to the game I'm developing, as a sort of reference implementation.
+
+## Design
+
+### GameSpace
 
-* The server runs at 60 frames a second, to match Gosu.
 * A GameSpace holds a copy of the game's state.  This is primarily a grid populated by Entities.
 * The dimensions of the GameSpace (in cells) are specified on server startup.
 * Each cell in the grid is 40x40 pixels, but is represented as 400x400 internally.  This allows for motion at slow speeds (1 pixel every 10 ticks == 6 pixels per second).
 * Entity positions and velocities are integers.  Apart from player input, all entities' behaviors are predictable.  This allows the client to make accurate predictions of the server state.
 * New Entities are assigned IDs in order, again, to allow the client to predict which ID will be assigned to each new entity.
+
+### Client/Server
+
+* The server runs at 60 frames a second, to match Gosu.
 * Clients connect using REnet.  The handshaking process creates a Player object to represent the client.
 * Client and server use Diffie-Hellman key exchange to establish a shared secret.  This is used to encrypt sensitive information, rather like SSH (but over REnet).
   * Right now, the only sensitive information is the user's password.  This allows the server to remember who's who.
@@ -18,23 +41,7 @@ There's not much here yet, in terms of actual gameplay.  At this point I'm layin
   * Nothing else interesting here yet, but I fully expect to put an inventory here, once there is anything useful to carry around.
   * This is also where I plan to put authorization data - who's a god player (level editor) and who isn't.
   * Player data is persisted in ~/.game_2d/players/players as JSON text.
-* Keyboard commands control the player:
-  * A and D, or LeftArrow and RightArrow: Hold down to accelerate.
-  * LeftControl or RightControl: Hold down to brake (slow down).
-  * S, or DownArrow: Hold down to build (the longer you hold, the stronger the block).
-  * W, or UpArrow:
-    * When not building: Flip (turn 180 degrees).
-    * When building: Rise up (ascend to the top of the built block).
-  * Left button: Fire a pellet.  Mouse click determines the direction and speed -- closer to the player means slower speed.
-  * Right button: Grab an entity and drag it around.  Right-click again to release.  Grab is affected by snap-to-grid.  *(This will eventually become part of a level-editing mode.)*
-  * Shifted right button, or B: Build a block where the mouse points.  *(This will eventually become part of a level-editing mode.)*
-  * 1 through 7: Shortcuts for building Dirt, Brick, Cement, Steel, Unlikelium, Titanium, Teleporter.
-* Mousing over an entity displays some basic information about it.  *(This will eventually become part of a level-editing mode.)*
-* A simple menu system is also available.  Left-click to select.  Esc returns to the top-level.
-* The menus include a Save feature, which tells the server to save the level's state.
-  * Levels are persisted in ~/.game_2d/levels/<level name> as JSON text.
-  * On subsequent startup with the same name, the level is loaded.
-* The client and server communicate using JSON text.  This is undoubtedly inefficient, but aids in debugging at this early stage.
+* The client and server communicate using JSON text.  This is undoubtedly inefficient, but aids in debugging at this early stage.  I fully intend to replace this, eventually.
 * Every frame is numbered by the server, and is referred to as a 'tick'.
 * Player actions are both executed locally, and sent to the server.
 * If other players are connected, the server sends everyone's actions to everyone else.
@@ -45,7 +52,50 @@ There's not much here yet, in terms of actual gameplay.  At this point I'm layin
   * If the server sends something conflicting, the client discards its wrong prediction.
   * This is intended to compensate for dropped packets or lag, but much more testing is needed.
 
-The physics is (intentionally) pretty simple.  Unsupported objects fall, accelerating downward at a rate of 1/10 pixel per tick per tick.  Blocks assume one of the following forms depending on how many hit points they possess:
+### Player Interface
+
+* Keyboard commands control the player object, which is called a Gecko:
+  * A and D, or LeftArrow and RightArrow: Slide sideways.  Hold down to accelerate.
+  * LeftControl or RightControl: Hold down to brake (slow down).
+  * S, or DownArrow: Hold down to build (the longer you hold, the stronger the block).
+  * W, or UpArrow:
+    * When not building: Flip (turn 180 degrees).
+    * When building: Rise up (ascend to the top of the built block).
+* The mouse is also used.
+  * Left button: Fire a pellet.  Mouse click determines the direction and speed.
+    * When firing up, the pellet's trajectory will peak where you clicked.
+    * When firing down, the pellet will be fired horizontally such that it falls through the place where you clicked.
+* A simple menu system is available.  Left-click to select.  Esc returns to the top-level.
+
+### Level-Editing Features
+
+This will eventually become a separate game mode, accessible only to certain authorized players.
+
+* Menu options let you select the type of entity to build, and turn "snap to grid" on or off.
+  * Snap-to-grid aims to put entities exactly in particular cells, with X and Y coordinates both multiples of 400.
+* Right button: Grab an entity and drag it around.  Right-click again to release.  Grab is affected by snap-to-grid.
+* Shifted right button, or B: Build a block where the mouse points, of the type selected in the menu.
+* Shortcut keys for particular object types:
+  * 1: Dirt
+  * 2: Brick
+  * 3: Cement
+  * 4: Steel
+  * 5: Unlikelium
+  * 6: Titanium
+  * 7: Teleporter
+  * 8: Hole
+  * 9: Base
+  * 0: Slime
+* Mousing over an entity displays some basic information about it.
+* The menus include a Save feature, which tells the server to save the level's state.
+  * Levels are persisted in ~/.game_2d/levels/<level name> as JSON text.
+  * On subsequent startup with the same name, the level is loaded.
+
+## Gameplay
+
+### Block physics
+
+The physics is (intentionally) pretty simple.  Unsupported blocks fall, accelerating downward at a rate of 1/10 pixel per tick per tick.  Blocks assume one of the following forms depending on how many hit points they possess:
 
 * Dirt blocks (1-5 HP) fall unless something is underneath.
 * Brick blocks (6-10 HP) can stay up if supported from both left and right.
@@ -53,21 +103,51 @@ The physics is (intentionally) pretty simple.  Unsupported objects fall, acceler
 * Steel blocks (16-20 HP) can stay up if touching anything else, even above.
 * Unlikelium blocks (21-25 HP) never fall.
 
+Brick and Cement blocks are considered supported from the sides only if the entities present there are at exactly the same height.  Steel blocks are less picky; they only fall if nothing is touching them.
+
 When building a block, the longer you hold the S or DownArrow key, the more HP will be awarded to the block.  Hitting a block with a pellet reduces its HP, until it degrades to a lower form.  Dirt blocks with 1 HP will be entirely destroyed when hit.
 
 Whether a block is supported depends exclusively on its immediate surroundings.  That means two blocks can support each other, and hang suspended.  For example, a dirt block sitting on a steel block will support each other.  A horizontal row of brick, capped at either end with cement, will also be free-standing.
 
-Pellets are fired from the player's center, and are affected by gravity.  They damage whatever they hit first, and disappear.  Pellets won't hit the player who fired them.  So far, only blocks can take damage; players are indestructible (but you know that will change).
+There are also Titanium entities.  They take up space and can be used for support, but they are not truly blocks.  They never fall, and are indestructible.  These are intended for use in designing levels with specific shapes.  They can only be created, destroyed, or moved by using the level-editing features.
 
-There are also Titanium entities, which never fall, and are indestructible.  These are intended for use in designing levels with specific shapes.  They can only be created by using the menu to select Titanium, and then shift-right-clicking.
+The GameSpace is bounded by invisible, indestructible Wall entities.  These are like Titanium, except that they are off-screen, and cannot be altered even with the level-editing features.
 
-Teleporters never fall.  Their only action is to transfer their contents (anything close enough to intersect with their center) to their single destination-point.  This transfer affects location but not velocity.  Transfer doesn't happen if there is something blocking the exit point.
+### Geckos
 
-A player is considered to be supported if their "feet" are touching a block.  Unsupported players will turn feet-downward and fall, until they land on something.  Supported players may slide left or right, and will follow any edges they reach -- going up and down walls, or hanging under ceilings.  The "flip" maneuver swaps head and feet; this becomes useful if the player's head is exactly touching another block.  At all other times, a flip leads to a fall (which can be useful too).
+A player object is called a Gecko, because of how it moves.  A Gecko is considered to be supported if its "feet" are touching a block.  Unsupported Geckos will turn feet-downward and fall, until they land on something.  Supported Geckos may slide left or right, and will follow any edges they reach -- going up and down walls, or hanging under ceilings.  The "flip" maneuver swaps head and feet; this becomes useful if the Gecko's head is exactly touching another block.  At all other times, a flip leads to a fall (which can be useful too).
 
 When building a block, the player and the new block occupy the same space.  This is allowed until the player moves off of the block.  After that, the block is considered opaque as usual.  While the block is still "inside" the player, the Rise Up maneuver may be used.  This moves the player headward (which may not be "up"--it depends which way the player is turned) to sit "on top" of the block.  It's possible to use this maneuver to construct a horizontal row of bricks, carefully.
 
-The GameSpace is bounded by invisible, indestructible Wall entities.  These can also support blocks, or the player.
+### Bases
+
+A base is a spawn point for players, and is also an object that can be moved.  When a game server is started with a new level name, a single starter base will be created in the center (and then promptly fall to the bottom).  New bases can be created using the level-editing features, as many as desired, and placed wherever it makes sense for players to enter the level.  Bases are indestructible (currently).
+
+Like Geckos, Bases can perch on walls or ceilings, as long as their "feet" are pointed the right way.  Unlike Geckos, when a Base gets thrown sideways or upwards, it will turn its "feet" in the direction it's going.  So it will tend to stick to the first thing it hits.
+
+Bases are physical objects, and most other objects (like blocks) can't move through them; but they're transparent to players.  Players who join the game will start out at a randomly selected unoccupied base, in the same orientation as the base.
+
+## Ghosts
+
+When a Gecko is destroyed, the player turns into a Ghost.  This means you're dead.  A Ghost can't touch anything or affect anything, and isn't affected by anything, even gravity.  Ghosts can only float around, and look at things.
+
+One other thing a Ghost can do is turn back into a Gecko, i.e. respawn.  The player gets some choice as to which base to respawn at, if more than one exist and are unoccupied.  The Ghost will move quickly to the unoccupied base nearest to the click position (even if that's really far away).  If the player's not choosy, they may click anywhere.  If all bases are occupied, nothing happens; the Ghost player must wait for those other Geckos to get out of the way.
+
+This is also the solution for allowing new players to enter the game when all bases are occupied: The new player is created as a Ghost.
+
+### Pellets
+
+Pellets are fired from the player's center, and are affected by gravity.  They damage whatever they hit first, and disappear.  Pellets won't hit the player who fired them.  Blocks, slime, and players can take damage and be destroyed.
+
+### Teleporters
+
+Teleporters never fall, and they are "transparent" to most entities; they act as if part of the background.  Their only action is to transfer their contents (anything close enough to intersect with their center) to their single destination-point.  This transfer affects location but not velocity.  Transfer doesn't happen if there is something blocking the exit point.
+
+### Holes
+
+They're black.  Really black.  Against the starry background, they're impossible to see... except that they occlude the stars.
+
+Mostly, holes are detectable just like real black holes: by virtue of the effect they have on everything around them.  Normal gravity makes loose objects fall downward, but in the vicinity of a hole, gravity sucks all objects toward the hole.  If the falling object gets too close to the hole, it will begin taking damage.  Blocks will rapidly be destroyed as they approach.  Pellets can't take damage in this way, but their path will bend around the hole.  Pellets can even be captured in orbit around the hole, though they always escape eventually.
 
 
 ## Installation
@@ -88,6 +168,12 @@ And a client in another window:
 
     $ game_2d_client.rb --name Bender --hostname 127.0.0.1
 
+The client can use the menu to select "Save", telling the server to save a copy of the level.  Subsequent runs of the server can leave off the dimensions:
+
+    $ game_2d_server.rb --level example
+
+Run these commands with --help to see more options.
+
 ## Contributing
 
 1. Fork it ( https://github.com/sereneiconoclast/game_2d/fork )

data/game_2d.gemspec

@@ -4,29 +4,45 @@ $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
 require 'game_2d/version'
 
 Gem::Specification.new do |spec|
-  spec.name          = "game_2d"
+  spec.name          = 'game_2d'
   spec.version       = Game2d::VERSION
-  spec.authors       = ["Greg Meyers"]
-  spec.email         = ["cmdr.samvimes@gmail.com"]
+  spec.authors       = ['Greg Meyers']
+  spec.email         = ['cmdr.samvimes@gmail.com']
   spec.summary       = %q{Client/server sandbox game using Gosu and REnet}
-  spec.description   = %q{Client/server sandbox game using Gosu and REnet}
-  spec.homepage      = ""
-  spec.license       = "MIT"
+  spec.description   = <<EOF
+Built on top of Gosu, an engine for making 2-D games.  Gosu provides the means
+to handle the graphics, sound, and keyboard/mouse events.  It doesn't provide
+any sort of client/server network architecture for multiplayer games, nor a
+system for tracking objects in game-space.  This gem aims to fill that gap.
+
+Originally I tried using Chipmunk as the physics engine, but its outcomes were
+too unpredictable for the client to anticipate the server.  It was also hard to
+constrain in the ways I wanted.  So I elected to build something integer-based.
+
+In the short term, I'm throwing anything into this gem that interests me.  There
+are reusable elements (GameSpace, Entity, ServerPort), and game-specific
+elements (particular Entity subclasses with custom behaviors).  Longer term, I
+could see splitting it into two gems.  This gem, game_2d, would retain the
+reusable platform classes.  The other classes would move into a new gem specific
+to the game I'm developing, as a sort of reference implementation.
+EOF
+  spec.homepage      = 'https://github.com/sereneiconoclast/game_2d'
+  spec.license       = 'MIT'
 
   spec.files         = `git ls-files -z`.split("\x0")
   spec.executables   = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
   spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
-  spec.require_paths = ["lib"]
-  spec.required_ruby_version = ">= 1.9.3"
+  spec.require_paths = ['lib']
+  spec.required_ruby_version = '>= 1.9.3'
 
-  spec.add_runtime_dependency "facets", [">= 2.9.3"]
-  spec.add_runtime_dependency "gosu", [">= 0.8.5"]
-  spec.add_runtime_dependency "json", [">= 1.8.1"]
-  spec.add_runtime_dependency "renet", [">= 0.1.14"]
-  spec.add_runtime_dependency "trollop", [">= 2.0"]
+  spec.add_runtime_dependency 'facets', ['>= 2.9.3']
+  spec.add_runtime_dependency 'gosu', ['>= 0.8.5']
+  spec.add_runtime_dependency 'json', ['>= 1.8.1']
+  spec.add_runtime_dependency 'renet', ['>= 0.1.14']
+  spec.add_runtime_dependency 'trollop', ['>= 2.0']
 
-  spec.add_development_dependency "bundler", "~> 1.7"
-  spec.add_development_dependency "rake", "~> 10.0"
-  spec.add_development_dependency "rr", "~> 1.1.2"
-  spec.add_development_dependency "rspec", "~> 3.1.0"
+  spec.add_development_dependency 'bundler', '~> 1.7'
+  spec.add_development_dependency 'rake', '~> 10.0'
+  spec.add_development_dependency 'rr', '~> 1.1.2'
+  spec.add_development_dependency 'rspec', '~> 3.1.0'
 end

data/lib/game_2d/client_connection.rb

@@ -108,9 +108,9 @@ class ClientConnection
     if you_are
       # The 'world' response includes deltas for add_players and add_npcs
       # Need to process those first, as one of the players is us
-      @engine.apply_deltas(at_tick)
+      @engine.apply_deltas(at_tick) if world
 
-      @engine.create_local_player you_are
+      @game.player_id = you_are
     end
 
     @engine.sync_registry(registry, highest_id, at_tick) if registry
@@ -120,12 +120,12 @@ class ClientConnection
     @engine.tick + ACTION_DELAY
   end
 
-  def send_move(move, args={})
+  def send_move(player_id, move, args={})
     return unless move && online?
     args[:move] = move.to_s
     delta = { :at_tick => send_actions_at, :move => args }
     send_record delta
-    delta[:player_id] = @engine.player_id
+    delta[:player_id] = player_id
     @engine.add_delta delta
   end
 
@@ -144,6 +144,13 @@ class ClientConnection
     @engine.add_delta delta
   end
 
+  def send_delete_entity(entity)
+    return unless online?
+    delta = { :delete_entities => [entity.registry_id], :at_tick => send_actions_at }
+    send_record delta
+    @engine.add_delta delta
+  end
+
   def send_snap_to_grid(entity)
     return unless online? && entity
     delta = { :at_tick => send_actions_at, :snap_to_grid => entity.registry_id }

data/lib/game_2d/client_engine.rb

@@ -61,7 +61,6 @@ class ClientEngine
 
     last_space = space_at(tick - 1)
     @spaces[tick] = new_space = GameSpace.new(@game_window).copy_from(last_space)
-
     apply_deltas(tick)
     new_space.update
 
@@ -78,7 +77,7 @@ class ClientEngine
     end
 
     if @tick - @earliest_tick >= MAX_LEAD_TICKS
-      $stderr.puts "Lost connection?  Running ahead of server?"
+      warn "Lost connection?  Running ahead of server?"
       return space_at(@tick)
     end
     space_at(@tick += 1)
@@ -88,25 +87,13 @@ class ClientEngine
     @spaces[@tick]
   end
 
-  def create_local_player(player_id)
-    old_player_id = @game_window.player_id
-    fail "Already have player #{old_player_id}!?" if old_player_id
-
-    @game_window.player_id = player_id
-    puts "I am player #{player_id}"
-  end
-
-  def player_id
-    @game_window.player_id
-  end
-
   def add_delta(delta)
-    at_tick = delta.delete :at_tick
+    at_tick = delta[:at_tick]
     fail "Received delta without at_tick: #{delta.inspect}" unless at_tick
     if at_tick < @tick
-      $stderr.puts "Received delta #{@tick - at_tick} ticks late"
+      warn "Received delta #{@tick - at_tick} ticks late"
       if at_tick <= @earliest_tick
-        $stderr.puts "Discarding it - we've received registry sync at <#{@earliest_tick}>"
+        warn "Discarding it - we've received registry sync at <#{@earliest_tick}>"
         return
       end
       # Invalidate old spaces that were generated without this information
@@ -135,6 +122,7 @@ class ClientEngine
       add_npcs(space, npcs) if npcs
 
       move = hash.delete :move
+      player_name = hash.delete :player_name
       player_id = hash.delete :player_id
       if move
         fail "No player_id sent with move #{move.inspect}" unless player_id
@@ -144,7 +132,8 @@ class ClientEngine
       score_update = hash.delete :update_score
       update_score(space, score_update) if score_update
 
-      $stderr.puts "Unprocessed deltas: #{hash.keys.join(', ')}" unless hash.empty?
+      leftovers = hash.keys - [:at_tick]
+      warn "Unprocessed deltas: #{leftovers.join(', ')}" unless leftovers.empty?
     end
   end
 
@@ -161,8 +150,13 @@ class ClientEngine
 
   def apply_move(space, move, player_id)
     player = space[player_id]
-    fail "No such player #{player_id}, can't apply #{move.inspect}" unless player
-    player.add_move move
+    if player
+      player.add_move move
+    else
+      # This can happen if, say, the player sent an action just before
+      # death or disconnection.
+      warn "No such player #{player_id}, can't apply #{move.inspect}"
+    end
   end
 
   def add_npcs(space, npcs)
@@ -174,7 +168,15 @@ class ClientEngine
   end
 
   def add_entity(space, json)
-    space << Serializable.from_json(json)
+    space.add_entity (o = Serializable.from_json(json))
+    if o.is_a?(Player) && @game_window.player_name == o.player_name
+      # This can be news, if the server is ahead of us.  The server
+      # promises that we always have exactly one entity assigned to
+      # each authenticated player, and each connected player must
+      # have a unique name at any time -- so this entity has to be
+      # ours.
+      @game_window.player_id = o.registry_id
+    end
   end
 
   # Returns the set of registry IDs updated or added

data/lib/game_2d/entity.rb

@@ -30,8 +30,8 @@ class Entity
     def bottom_cell_y_at(y); (y + HEIGHT - 1) / HEIGHT; end
 
     # Velocity is constrained to the range -MAX_VELOCITY .. MAX_VELOCITY
-    def constrain_velocity(vel)
-      [[vel, MAX_VELOCITY].min, -MAX_VELOCITY].max
+    def constrain_velocity(vel, max=MAX_VELOCITY)
+      [[vel, max].min, -max].max
     end
   end
   include ClassMethods
@@ -57,7 +57,7 @@ class Entity
     @grabbed = false
   end
 
-  def a=(angle); @a = angle % 360; end
+  def a=(angle); @a = (angle || 0) % 360; end
 
   def x_vel=(xv)
     @x_vel = constrain_velocity xv
@@ -66,6 +66,9 @@ class Entity
     @y_vel = constrain_velocity yv
   end
 
+  def cx; x + WIDTH/2; end
+  def cy; y + HEIGHT/2; end
+
   # True if we need to update this entity
   def moving?; @moving; end
 
@@ -115,9 +118,9 @@ class Entity
   end
 
   # Apply acceleration
-  def accelerate(x_accel, y_accel)
-    self.x_vel = @x_vel + x_accel
-    self.y_vel = @y_vel + y_accel
+  def accelerate(x_accel, y_accel, max=MAX_VELOCITY)
+    @x_vel = constrain_velocity(@x_vel + x_accel, max) if x_accel
+    @y_vel = constrain_velocity(@y_vel + y_accel, max) if y_accel
   end
 
   def opaque(others)
@@ -132,6 +135,20 @@ class Entity
     opaque(@space.entities_overlapping(new_x, new_y))
   end
 
+  def slow_by(amount)
+    if @x_vel.zero?
+      self.y_vel = slower_speed(@y_vel, amount)
+    else
+      self.x_vel = slower_speed(@x_vel, amount)
+    end
+  end
+
+  def slower_speed(current, delta)
+    return 0 if current.abs < delta
+    sign = current <=> 0
+    sign * (current.abs - delta)
+  end
+
   # Process one tick of motion, horizontally only
   def move_x
     return if doomed?
@@ -153,8 +170,8 @@ class Entity
       impacts.delete_if {|e| e.x < impact_at_x }
       impact_at_x + WIDTH
     end
+    i_hit(impacts, @x_vel.abs)
     self.x_vel = 0
-    i_hit(impacts)
   end
 
   # Process one tick of motion, vertically only
@@ -178,8 +195,8 @@ class Entity
       impacts.delete_if {|e| e.y < impact_at_y }
       impact_at_y + HEIGHT
     end
+    i_hit(impacts, @y_vel.abs)
     self.y_vel = 0
-    i_hit(impacts)
   end
 
   # Process one tick of motion.  Only called when moving? is true
@@ -202,7 +219,7 @@ class Entity
   # Handle any behavior specific to this entity
   # Default: Accelerate downward if the subclass says we should fall
   def update
-    accelerate(0, 1) if should_fall?
+    space.fall(self) if should_fall?
     move
   end
 
@@ -220,12 +237,17 @@ class Entity
     end
   end
 
-  def i_hit(other)
-    # TODO
-    puts "#{self} hit #{other.inspect}"
+  # Most entities can be teleported, but not when grabbed
+  def teleportable?
+    !grabbed?
   end
 
-  def harmed_by(other); end
+  # 'others' is an array of impacted entities
+  # 'velocity' is the absolute value of the x_vel or y_vel
+  # that was being applied when the hit occurred
+  def i_hit(others, velocity); end
+
+  def harmed_by(other, damage=1); end
 
   # Return any entities adjacent to this one in the specified direction
   def next_to(angle, x=@x, y=@y)
@@ -243,10 +265,18 @@ class Entity
     @space.entities_at_points(points)
   end
 
-  def empty_underneath?; opaque(next_to(180)).empty?; end
-  def empty_on_left?; opaque(next_to(270)).empty?; end
-  def empty_on_right?; opaque(next_to(90)).empty?; end
-  def empty_above?; opaque(next_to(0)).empty?; end
+  def underfoot
+    opaque(next_to(self.a + 180))
+  end
+
+  def beneath; opaque(next_to(180)); end
+  def on_left; opaque(next_to(270)); end
+  def on_right; opaque(next_to(90)); end
+  def above; opaque(next_to(0)); end
+  def empty_underneath?; beneath.empty?; end
+  def empty_on_left?; on_left.empty?; end
+  def empty_on_right?; on_right.empty?; end
+  def empty_above?; above.empty?; end
 
   def angle_to_vector(angle, amplitude=1)
     case angle % 360
@@ -276,10 +306,16 @@ class Entity
 
   # Given a vector with a diagonal, drop the smaller component, returning a
   # vector that is strictly either horizontal or vertical.
-  def drop_diagonal(x_vel, y_vel)
+  def drop_diagonal(x_vel=@x_vel, y_vel=@y_vel)
     (y_vel.abs > x_vel.abs) ? [0, y_vel] : [x_vel, 0]
   end
 
+  # Roughly speaking, are we going left, right, up, or down?
+  def direction
+    return nil if x_vel.zero? && y_vel.zero?
+    vector_to_angle(*drop_diagonal)
+  end
+
   # Is the other entity basically above us, below us, or on the left or the
   # right?  Returns the angle we should face if we want to face that entity.
   def direction_to(other_x, other_y)
@@ -333,6 +369,45 @@ class Entity
     end
   end
 
+  # Apply a move where this entity slides past another
+  # If it reaches the other entity's corner, it will turn at
+  # right angles to go around that corner
+  #
+  # apply_turn: true if this entity's angle should be adjusted
+  # during the turn
+  #
+  # Returns true if a corner was reached and we went around it,
+  # false if that didn't happen (in which case, no move occurred)
+  def slide_around(other, apply_turn = true)
+    # Figure out where corner is and whether we're about to reach or pass it
+    corner, distance, overshoot, turn = going_past_entity(other.x, other.y)
+    return false unless corner
+
+    original_speed = @x_vel.abs + @y_vel.abs
+    original_dir = vector_to_angle
+    new_dir = original_dir + turn
+
+    # Make sure nothing occupies any space we're about to move through
+    return false unless opaque(
+      @space.entities_overlapping(*corner) + next_to(new_dir, *corner)
+    ).empty?
+
+    # Move to the corner
+    self.x_vel, self.y_vel = angle_to_vector(original_dir, distance)
+    move
+
+    # Turn and apply remaining velocity
+    # Make sure we move at least one subpixel so we don't sit exactly at
+    # the corner, and fall
+    self.a += turn if apply_turn
+    overshoot = 1 if overshoot.zero?
+    self.x_vel, self.y_vel = angle_to_vector(new_dir, overshoot)
+    move
+
+    self.x_vel, self.y_vel = angle_to_vector(new_dir, original_speed)
+    true
+  end
+
   def as_json
     Serializable.as_json(self).merge!(
       :class => self.class.to_s,
@@ -360,9 +435,17 @@ class Entity
 
   def draw_zorder; ZOrder::Objects end
 
+  def draw_animation(window)
+    window.animation[window.media(image_filename)]
+  end
+
+  def draw_image(anim)
+    anim[Gosu::milliseconds / 100 % anim.size]
+  end
+
   def draw(window)
-    anim = window.animation[window.media(image_filename)]
-    img = anim[Gosu::milliseconds / 100 % anim.size]
+    img = draw_image(draw_animation(window))
+
     # Entity's pixel_x/pixel_y is the location of the upper-left corner
     # draw_rot wants us to specify the point around which rotation occurs
     # That should be the center