:: ethergrind ::
:: distribution (source and win32 .exe) ::
:: source requires pygame and pgu ::

:: keys ::
:: arrows - move ::
:: space - shoot ::
:: enter - accept powerup ::
:: f - turn on high-quality visual effects ::
:: esc - quit (why would you want to do that?) ::

:: start main.exe or main.py with the -f switch to run in full screen mode ::
:: timelapse ::

More below the cut.

Why Calculate Line of Sight?

Line of Sight is a concept that is extremely useful in not only Roguelikes, but strategy games of all sorts. In a game like Starcraft, where fog of war is an important part of the mechanics of the game, it is necessary to calculate what area of the map is ’seeable’ for each player.

Doing this is simple if we’re dealing with a terrain where there are no blocking obstacles: we simply use the distance formula to determine whether or not each cell is inside the line of sight radius for the particular unit we are examining. If it is, we mark that cell seeable; otherwise, we do not. In order to avoid iterating over the entire map, we can perform our operations on a subsection of the map of height R and width R, where R is the line of sight radius for the unit we’re examining. This algorithm will generate something like this:

where the blue tile is the player, the grey tiles are unseeable, and the box is the area of the map we are iterating over.

As I said above, this is great for games with no obstructing obstacles. When you start modeling walls, mountains, hills, and other types of terrain, this algorithm fails to work. You need to start thinking about raycasting.

What We Expect

In general, we can expect that walls in a level will block visibility whenever a line from the player’s cell to the cell in question intersects a wall.

In short, we want this:

This shows a wall being viewed by a player with an infinite vision radius. Some limitations probably apply here. You usually do not want to calculate LOS for your entire map; that would be too costly. It is usually reasonable to assume that your player has a fairly limited range of vision (in general, the more claustrophobic your setting, the more stingy you can be here). So what we will end up with is a situation like this:

Line of Sight

For each cell that encloses the field of view, we want to find all cells that lie along a line with its origin at the player. In other words, we want to walk along the lines starting at the player and ending at each square that encloses the field of vision. We will mark any cells visible that lie along these lines up until the point where we find a cell that blocks vision, at which point we will mark that cell visible and then stop traversing this line.

Here’s an illustration of a “line of sight” iteration in 2d:

Our main tool in drawing these lines will be Bresenham’s Algorithm, a well known method for choosing cells in a grid to represent lines. Here’s a brief summary of the algorithm in english:


### Initialization step:
Begin with x1, Y1 being the coordinates of the starting point, and X2, Y2 being the coordinates of the ending point.
  Initialize the flag steep to true, and begin with an empty list of coordinates.
  Calculate the delta values dx = (x2 - x1) and dy = (y2 - y1)
  If dx is greater than 0, set sx = 1. Otherwise, set sx = 0. This will be the direction we iterate over the x axis.
  If dy is greater than 0, set sy = 1. Otherwise, set sy = 0.
  If abs(dy) > abs(dx), swap the following values: x1 and y1, x2 and y2, dx and dy, sx and sy. This is responsible for making sure the line is drawn in the right direction (from start to finish). Set the flag steep to true.
  Calculate the starting offset d = (2 * abs(dy)) - abs(dx).
  Begin with x = x1 and y = y1.
  ### Main loop:
  For each value between 0 and abs(dx):
    If steep:
      Push (y, x) onto the result list.
    Else:
      Push (x, y) onto the result list.
    While d >= 0
      y = y + sy
      d = d - (2 * abs(dx))
    x = x + sx
    d = d + (2 * abs(dy))
  Push (x2, y2) onto the result list.
  Return the result list.


If you don’t follow this completely, don’t worry. You can find this algorithm written in most every programming language that exists. What matters is that you understand that when we feed Brensenham’s a start and end coordinate for a line, it will give us the series of coordinates that best correspond to a line between those points.

We could modify this algorithm to check the visibility of each coordinate before it is plotted, and then return the list if the coordinate blocks visibility. Alternatively, we can parse through the list after it’s plotted to check visibility. Here’s an example of that, in Python this time:


def lineofsight(x1, y2, x2, y2):
  for i in brensenham_line(x1, y2, x2, y2):
    x, y = i
    maptiles[x][y].seeable = True
    if (maptiles[x][y].obstructing):
      return False


This will step through the list of coordinates returned by Bresenham’s, setting map tiles seeable, and stop when it finds an obstructing tile.

Field of Vision

In order to turn our line of sight algorithm into a field of vision algorithm, we just have to draw LOTS of lines of sight. There are a number of ways to handle this, but I’ll just describe one of the simplest ones here.

iterate i from 0 to ((max_vision_length*2)+1):
  lineofsight(player.x, player.y, player.x-max_vision_length+i, player.y-max_vision_length)
  lineofsight(player.x, player.y, player.x-max_vision_length+i, player.y+max_vision_length)
  lineofsight(player.x, player.y, player.x-max_vision_length, player.y-max_vision_length+i)
  lineofsight(player.x, player.y, player.x+max_vision_length, player.y-max_vision_length+i)


You should be able to see on inspection that this code will generate something like this:

Which, when combined with the line of sight algorithm that we created above, is exactly what we want.

Next Steps

There’s a lot further to explore here. Here are some links that might help you further expand your ventures into this territory. One drawback to this technique is that as the visible radius is increased:

• more artifacts will begin to show up. (ie: walls that should be visible, but aren’t)
• the cells around the center will be visited multiple times.

There are many solutions to this, one of which is discussed here. Another solution is to draw lines to every square within the field of vision. This is more costly but will eliminate artifacting.

Other implementations of field of vision include creating raster shapes of shadows cast by different objects and combining them to make a custom raster based on the position of seeable objects. This can be super fast, because no actual math is done aside from copying the shadow map onto the field. A discussion of this can be found here.

Cypress Tree Manor is one of those games that makes you click the X button in frustration, cursing and swearing, only to double click on ‘run.py’ again seconds later (still muttering expletives).

For this reason alone, Nils Fagerburg should consider it a success.

The basic premise of the game is that there are zombies loose in an old manor house. Despite the popularity of the zombie meme, I’m getting a bit tired of all the zombie-based games these days. The real challenge in Cypress Tree Manor is getting past your fellow survivors. An individual zombie by itself poses little threat to an adventurer armed with a shovel or a chainsaw.

The real difficulty in Cypress Tree Manor is the win condition: search the many crates, bins and chests in the house and find the bunker key, then get to the bunker downstairs (which only has room for 1). Your computer opponents will murder each other (and you) on their way to find the key and get to safety.

This isn’t to say Cypress Tree Manor doesn’t have issues: on top of being fairly hard, it is controllable only with vim-keys. While this reviewer grew accustomed to the control scheme fairly quickly, it would be nice to see controls extended to the numpad. Additionally, it is possible for the game’s (admittedly bad by the author) random level generator to create unsolvable levels: see the screenshot included. However, in my 20+ games before writing this review, I only noticed this happening once, so I would guess it is pretty rare.

There’s also a strange AI glitch where some enemies will simply walk back and forth in place. This can be really irritating if you’re trying to kill them off. It’s a tribute to the design of this game that these bugs and limitations aren’t an immediate turnoff: but the gameplay and humor endeared themselves to me immediately.

Cypress Tree Manor has plenty of good stuff too: the zombies die leaving pools of ascii blood. The weapons include hammers, chainsaws, and shovels, and you can find chocolate chip cookies and sausages lying around. The title art and “you die” screens are hysterical (by the way, your brains were delicious).

If you’re looking for a complex dungeon crawler, this isn’t it. But if you’re looking for a way to kill 5-10 minutes while waiting for your coffee to brew, you should consider checking out Cypress Tree Manor. Don’t expect perfection; it was, afterall made in just 7 days. And don’t expect to win everytime either.

Cypress Tree Manor - Website

Whispers in the Void 0.666 - Linux (python, pygame and pgu required)
Whispers in the Void 0.666 - Windows (stand alone executable)

- Update: If you downloaded this shortly after release, there was a bug included that crashed the game when you switched to fists or knife. This has been fixed.

Oh wow, it’s almost time to release.

Okay, I’ve got a demo version for playtest purposes. There are some limitations in it, so just try to be gentle. If you find any bugs that I haven’t listed here, let me know!

Known limitations/bugs:

• You have to close the game when you die.
• The game crashes after you descend from dlvl12 (this is the last level)
• You can’t move in diagonals.

There were a few things I haven’t managed to get into the game, but I don’t know how much more of them I’ll be attempting. The majority of tomorrow will be spent smoothing out the experience - adding intro screens, cutscenes with plot text, and other things to make the overall experience better.

Please leave comments!

Whispers in the Void 0.666b - Linux (python, pygame and pgu required)
Whispers in the Void 0.666b - Windows (stand alone executable)

So close!

A bunch of new stuff today, cramming for a final night of testing on Friday. My 7 day deadline is Saturday at 8:00pm EST, and I won’t be releasing it until a few hours before that. Stuff that got done today:

• Three types of grenades!
• Adrenaline!
• Ability to infrequently sense when monsters are nearby
• Corpses

Tons of new stuff:

• More weapons
• Lots of new tiles
• All enemies are in
• Armor
• Combat is nearly complete
• You can progress to new dungeon levels
• Powerups

Time for another quick screeny. Some preliminary weapons stuff is in!

Making progress. Monster AI and pathfinding is in (mostly), status system works, time to start on combat!