The very first week, all we had was a single @ moving about on the screen:

A week later and we already have caves, with nice pools and underground trees (that’s never really made that much sense, has it?):

In week 3, the caves get quite a bit more dangerous with the introduction of rats, rats, everywhere:

Unfortunately (or perhaps not), a rat without an AI isn’t much of a threat at all. So after that, we started work on making the enemies a bit starter and added a few more dangerous sorts:

In week 5, we shifted gears to get into gear, adding weapons, armors, and potions (oh my!):

Then in week 6, we brave the depths, finally getting away from those infinite caves and starting out on the surface. Granted, we went right back down, but still. Onward and downward!

Finally, last week we managed to rid our player of that pesky x-ray vision:

It’s been a long strange road already, but where does that leave us now?

Well, there are a few things that I’d definitely like to implement before moving on:

• Ranged weapons
• Animations decoupled from player movement (to allow for arrows, fire, explosions, etc)
• Terrain modification (in particular: burrowing for monsters and/or players)
• More content! (levels, entities, and items; each is just waiting for more definitions)

I’ve already started on the first two of those. Granted, as a wise man once (may or may not have) said:

I have not failed 1,000 times. I have successfully discovered 1,000 ways to NOT make a light bulb.

I will figure it out, it’s just taking longer than I’d like. Unfortunately¹, all that’s going to have to wait. It turns out I’m getting married in a week². Believe it or not, that takes up rather a lot of time. After that, I’ll be taking a bit of a vacation from the mad, mad world of academia for a couple of weeks. My intention is to avoid the Internet as much as possible. We’ll see how that goes.

The takeaway from all of this? This series isn’t over. If anything, it’s only going to get a lot deeper in the next few posts–sometime in the third week of June. I hope to see you then!

1. Or really not.
2. It’s amazing how something like that can sneak up on you…

• Top 100 overall: Compo, Jam
• Top 25 by categories

And then here are my game’s (VTanks) ratings:

Overall, I know that I can do better. But given that I only had about 6 hours to spend, I don’t think I did half bad. I’m a bit amused that I somehow managed to place better than about half the entries on humor… given that there was no humor to speak of in the game. I guess getting yourself buried is funny?

Even weirder is audio. I came in at 38% audio… and I didn’t have any. I’m pretty sure that the policy is just not to leave a score in a category if it doesn’t make sense, in which case I wouldn’t get a rating. So yeah… That’s strange.

All that being said, it was a lot of fun to participate in Ludum Dare for once. After that, it was just about as much fun to play some of the games. It’s amazing what some people put out in 24 hours. I’ll have to do this again!

(If you’d like to play my entry, you can do so here.)

A few years ago, I decided that I was doing myself a disservice as a self-identified geek¹: of Star Trek, I’d only seen Voyager and a few of the movies. Of course I had to remedy that fact.

Over the course of a summer, I watched it all². 10 movies. 3 seasons of The Original Series; 7 seasons each of The Next Generation, Deep Space Nine, and Voyager³; and finally the 4 seasons of Enterprise. Yet, I still don’t consider myself a Trekkie (or a Trekker).

I guess my entire point is that I do have at least a bit of a leg to stand on when talking about the new Star Trek movies. That being said, feel free to ignore me. Everyone has their own opinion and I’ve certainly seen the entire spectrum when it comes to this movie…

Overall, I really liked it.

On the negative side, the pacing was pretty bad at times, with long slow stretches that just didn’t feel like they needed to be there⁴. There were a few scenes that just seemed so strange, particularly Alice Eve’s underwear scene⁵. Still, the action scenes were nicely “actiony” and the scenery looked amazing, both the shine of the ship and the destruction of the later acts.

As many people the internet over have said, there were more than a few ‘huh’ moments that really fought against my suspension of disbelief. Without getting too spoilery: Isn’t saving the natives in the first place a violation of the Prime Directive? Other than looking cool, why didn’t they just wait in space? Later on, why did they go to Kronos in the first place? And why did it only take them about 30 seconds to get back? And for that matter, where was the rest of Starfleet when they did get back? Does the doctor make a habit of randomly injecting things? And why his blood specifically, not his crew’s? … Yeah. I’m done. It’s a good thing I don’t really think of myself as a Trekkie or a lot of that would drive me even more up the wall.

You know what my biggest nit to pick with the movie was though? J.J. Abrams’ marketing. Everyone who knew Trek knew exactly who Cumberbatch was playing no matter how hard they tried to deny it… The only people who wouldn’t know wouldn’t care. Sigh.

Like I said though, for a summer action flick, it was a rather enjoyable movie. Barring the aforementioned marketing, there were a few neat twists. There were more than a handful of callbacks to The Wrath of Khan, which was nice at first, although it a bit old by the end⁶. The action was nice and the characters are actually starting to finally feel like a crew now. Zachary Quinto, Karl Urban, and Simon Pegg all carried over strong performances from the first film. I can’t really get into Chris Pine as Kirk, but then again I never really liked the original Kirk either. But really? Benedict Cumberbatch carried the show. Sherlock just jumped up rather a few places up my TV queue⁷.

Despite my earlier grumbling, I really did enjoy the movie. It’s not quite up to Iron Man’s standards and I still think The Croods was more fun, but I have no problem putting it into the #3 spot. If you have the time, I’d say it’s worth seeing.

My 2013 Movie Rankings

1. Iron Man 3
2. The Croods
3. Star Trek Into Darkness
4. Django Unchained
5. Parental Guidance
6. Oblivion
7. Beautiful Creatures
8. Jurassic Park (3D!)
9. Oz the Great and Powerful
10. Hansel & Gretel: Witch Hunters
11. Jack the Giant Slayer
12. Warm Bodies
13. G.I. Joe: Retaliation
14. Pain & Gain

1. Is there any other kind?
2. Yes, in order
3. Still my favorite. Feel free to tell me how I’m wrong right in the comments
4. Although it was a later showing than I generally go, so that might have played a role
5. Which even Damon Lindelof has said was “gratuitous”
6. The inverted Kirk/Spock yell was particularly weird…
7. Also, did you know he was in The Hobbit as the Necromancer? The more you know!

* – Particularly important issues, purely in my opinion.

In the end, I stayed with Firefox for about two weeks. Right now, I’m back to Chrome. It just seems to work more smoothly. Given that the majority of my day is spent either on the command line or in a web browser, I need one that will work well and not crash. Firefox just doesn’t quite work for me right now. Perhaps I’ll try again in a few months.

1. Which can also be a con when trying to figure out total useage
2. Lifehacker and io9 in particular
3. Yes, I’m still bitter about Google Reader…
4. DownThemAll / NoScript / Zotero

Let’s fix that.

(If you’d like to start at the beginning, click here: Racket Roguelike 1: A GUI, screens, I/O, and you!)

This week, we want to add a dynamic lighting system to the game. If we were using a pre-built framework (like Doryen’s excellent libtcod), lighting would be done for us². But that’s not the case. Luckily, the framework we’ve built already makes lighting relatively easy.

First, we need some way of representing which tiles should be lit. Technically, we could calculate this on the fly every frame. This isn’t actually a terrible way of doing things and might just be more efficient than what we’re doing (don’t even bother rendering tiles you can’t see), but since we want to have a ‘fog of war’ type system–where you can see the terrain you’ve passed, just not what’s there–that won’t quite work.

Instead, let’s add it to the tile definitions:

; levels.rkt
 
(define-thing tile
  [character #\space]
  [color "black"]
  [items '()]
  [lighting 'dark]    ; Dark: Invisible; Fog: Only show tile, not NPC or item; Lit: Everything
  [walkable #f]       ; Can the player walk on this tile?
  )

As it says in the comment, we have a lighting parameter with three possible states:

• dark – don’t draw the tile
• fog – draw the tile, but no items or NPCs in it (used once we see a tile then leave)
• lit – draw the tile, items, and NPCs (used when the player is nearby)

Easy enough. But how do we actually add that to our drawing function? Head over to game-screen.rkt:

; game-screen.rkt
 
(define gray-background (make-object color% 32 32 32))      
 
...
 
; Draw the tiles around the player
(for* ([xi (in-range (send canvas get-width-in-characters))]
       [yi (in-range (send canvas get-height-in-characters))])
  (define x/y (recenter canvas (- (thing-get player 'location) (pt xi yi))))
  (define tile (send world tile-at (pt-x x/y) (pt-y x/y)))
  (define lighting (thing-get tile 'lighting 'lit))
  (cond
    ; Draw nothing on dark tiles
    [(eq? lighting 'dark)
     (void)]
    ; If it's in fog, draw with a gray background
    [(eq? lighting 'fog)
     (send canvas write 
           (thing-get tile 'character) 
           xi yi 
           (thing-get tile 'color) gray-background)]
    ; If it's lit but there are no items, draw the tile
    [(null? (thing-get tile 'items '()))
     (send canvas write 
           (thing-get tile 'character) 
           xi yi 
           (thing-get tile 'color))]
    ; If it's lit and there are items, draw the item
    [else
     (send canvas write 
           (thing-get (car (thing-get tile 'items)) 'character) 
           xi yi 
           (thing-get (car (thing-get tile 'items)) 'color))]))

Basically, we draw nothing on dark tiles. This relies on the clear just above this code. If it’s foggy, we have a background, defined at the top of the file³. Otherwise, we fall back on the methods that we already had.

Next, we need to actually calculate this lighting. Essentially, every tile starts dark. Then, if a tile is near to the player, light it up. If it’s already lit but no longer near the tile, fade to fog. For now, we’re just going to use a simple radius around the player (parameterized below). Here’s the new update-lighting function and friends:

; entities.rkt
 
; game-screen.rkt
(define-thing entity
  ...
  [view-range 5])
 
; Draw the game itself.
(define/override (draw canvas)
  (define player (send world get-player))
  (send canvas clear)
 
  ; Update lighting
  (send world update-lighting)
 
  ...)
 
; world.rkt
 
; Update lighting
(define/public (update-lighting)
  ; Turn any lit tiles to fog
  ; Turn any tiles within the player's view limit to lit
  (define player-location (thing-get player 'location))
  (define player-view (thing-get player 'view-range 5))
  (for-tile
   (lambda (x y tile)
     (cond
       ; Light tiles near the player
       [(<= (distance player-location (pt x y)) player-view)
        (thing-set! tile 'lighting 'lit)]
       ; Fog previously lit tiles
       [(eq? 'lit (thing-get tile 'lighting))
        (thing-set! tile 'lighting 'fog)]
       ; Otherwise do nothing
       ))))

For that, we need the for-tile function. You can check it out on GitHub, but essentially it takes a function of the form (lambda (x y tile) ...) and applies it to each tile on the current level. It might⁴ get inefficient on more explored levels, but if people keep heading down, we should be good. So in this case, we’ll just light the area around the player. How does that look?

Starting out, not too bad. We’re out in the middle of a nice grass field like always. Just this time, we can’t see much of it. Perhaps it’s night time?

Wander around a bit until we find a way down. You can see the gray background of the fog. That actually looks pretty nice, particularly as you’re moving around.

Okay, now we’re into the caves. Let’s explore for a bit.

Hmm. Well, this is a problem. It turns out… we can see right through walls. Perhaps we should work on that a bit.

This is when a pre-built framework would really come in handy. But the algorithm isn’t too bad. Essentially, we want raycasting. We’ll start with a series of lines out from the player and light tiles as we go. If we hit something that can’t be lit up, stop. Sounds like a nicely recursive function to me!

Before that, let’s modify the tile definitions again. We’ll add the solid property. If a tile is solid (like a wall or a tree), you can’t see through it. Otherwise (like empty space or over water), you can.

; levels.rkt
 
(define-thing tile
  [character #\space]
  [color "black"]
  [items '()]
  [lighting 'dark]    ; Dark: Invisible; Fog: Only show tile, not NPC or item; Lit: Everything
  [walkable #f]       ; Can the player walk on this tile?
  [solid #f]          ; Does this tile block light?
  )

So how do we write a raycasting function?

The basic idea⁵ is to start with four rays, one in each of the cardinal directions. Give each ray its own direction. Then as we pass each tile, branch out in each direction for a total of three branches per iteration. It’s certainly not optimal (we’ll light some tiles more than once), but it does look nice.

; world.rkt
 
; Update lighting
(define/public (update-lighting)
  ; Turn any lit tiles to fog
  (for-tile
   (lambda (x y tile)
     (cond
       [(eq? 'lit (thing-get tile 'lighting 'dark))
        (thing-set! tile 'lighting 'fog)])))
 
  ; Spread lighting from the player
  ; x/y current tile to light
  ; xd/yd direction to spread light:
  ;  if xd != 0, spread to (x+xd y-1) (x+xd y) (x+xd y+1)
  ;  if yd != 0, spread to (x-1 y+yd) (x y+yd) (x-1 y+yd)
  ; spread is initially set to player's light radius
  (define (spread-light x y xd yd spread)
    ; Light the current tile
    (define tile (get-tile x y))
    (thing-set! tile 'lighting 'lit)
 
    ; Recur
    (cond
      ; Don't spread pass solid tiles (spread to them though)
      ; Don't recur past the spread (vision range) value
      [(or (<= spread 0) (thing-get tile 'solid #f))
       (void)]
      ; Spread in the x direction
      [(not (= xd 0))
       (spread-light (+ x xd) (- y 1) xd yd (- spread 1.41))
       (spread-light (+ x xd) y       xd yd (- spread 1.00))
       (spread-light (+ x xd) (+ y 1) xd yd (- spread 1.41))]
      ; Spread in the y direction
      [else
       (spread-light (- x 1) (+ y yd) xd yd (- spread 1.41))
       (spread-light x       (+ y yd) xd yd (- spread 1.00))
       (spread-light (+ x 1) (+ y yd) xd yd (- spread 1.41))]))
 
  ; Spread in the four directions
  (let ([player-x (pt-x (thing-get player 'location))]
        [player-y (pt-y (thing-get player 'location))]
        [player-v (thing-get player 'view-range 5)])
    (spread-light player-x player-y -1  0 player-v)
    (spread-light player-x player-y  1  0 player-v)
    (spread-light player-x player-y  0 -1 player-v)
    (spread-light player-x player-y  0  1 player-v)))

Hopefully that all makes sense. One sneaky trick is reducing the spread by 1 on the orthogonal moves and 1.41 (roughly ) on the diagonals. This will give us a nice circle.

Let’s see what an effect that has on the game:

Starting out, we have a nice circle. So far, it looks pretty much the same as it did last time.

Shadows! I can’t tell you how excited this makes me.

And it works perfectly with water as well. We can see over the water, but we can’t walk through it.

Unfortunately though, I haven’t had any luck yet finding a staircase…

Finally, we’re down a level. It’s nice to see⁶: no more x-ray vision! It does look a bit weird to have all the nice thin walls around, but it looks a lot better once you get used to it.

Theoretically, the player shouldn’t be able to hear updates from entities that aren’t visible. That would actually be pretty easy to implement (just check for the lighting in the logging function), but for the moment, I like the atmosphere it gives.

All that time wandering about and I still haven’t actually found any of those rats to fight. I wanted to show that it won’t draw them unless they’re in a lit area. Sigh. So it goes.

Well, that’s all we have for today. It’s kind of amazing how much difference so few lines can make⁷.

As always, if you’d like to see all of the code for this project, you can do so on GitHub:
- Racket Roguelike – Day 7
- Racket Roguelike – Up to date

If you’d like to try it yourself, you’ll need to have both Git and Racket and run the following series of commands:

git clone git://github.com/jpverkamp/racket-roguelike.git
cd racket-roguelike
git checkout day-7
git submodule init
git submodule update
racket main.rkt

1. Always a good sign when you find yourself actually playing your own game…
2. Perhaps I’ll add it to AsciiPanel some day
3. And defined only once to save just a bit on performance; we’re going to have to look at that soon…
4. Read: will
5. Which may or may not be the standard way of doing it
6. Believe it or not, pun not intended
7. According to the git diff, 26 lines removed and 111 added

Pain & Gain is a pretty good example of the American Dream gone wrong…

Which I guess is exactly what it’s supposed to be. So I’ll give it credit for that.

That’s really all it has though. There’s a decent smattering of violence and nudity, if you’re into that sort of thing, but personally I just found it painful to watch. Halfway through, I was actually considering walking out which, for me, is really saying something.

Basically, it’s a kidnapping gone wrong and it proceeds pretty much exactly as you’d expect. Everything starts out innocent enough (or as innocent as a kidnapping can be) and just spirals out of control. And yet the protagonists never really just quite how incompetent they are. Mark Wahlberg¹ is actually pretty believable as Lugo–absolutely convinced that he’s deserving of a better life and is just reaching out to take hold of it. Dwayne Johnson does rather well as an ex-con who found Jesus in the loosest sense of the word.

Really, I think the worst part is that this is all based (loosely!) on a true story. I read up on the details and they’ve changed a fair bit (which reminds me of Argo). It’s always amazing just how terrible human beings can be to one another.

Overall, I have no qualms putting this movie dead last for the year. In 20/20 hindsight, I wish I had gone to see Iron Man 3 again…

My 2013 Movie Rankings

1. Iron Man 3
2. The Croods
3. Django Unchained
4. Parental Guidance
5. Oblivion
6. Beautiful Creatures
7. Jurassic Park (3D!)
8. Oz the Great and Powerful
9. Hansel & Gretel: Witch Hunters
10. Jack the Giant Slayer
11. Warm Bodies
12. G.I. Joe: Retaliation
13. Pain & Gain

1. He looks remarkably familiar considering I don’t think I’ve seen anything else he’s been in…

Moria… You fear to go into those mines. The dwarves delved too greedily and too deep. You know what they awoke in the darkness of Khazad-dum… shadow and flame.
– Saruman, Lord of the Rings

Today, we dig too deep.

(If you’d like to start at the beginning, click here: Racket Roguelike 1: A GUI, screens, I/O, and you!)

Essentially, what we’re going to do today is to tear out that placeholder we had for level generation and add a proper abstracted level generation script. With that, we might as well add the ability to generate a bunch of levels and just dig deeper and deeper.

Okay, so what’s first? Well, the current code for level generation is in that huge, ugly get-tile function in world.rkt. Instead, let’s make a new file: levels.rkt. This will have all of the level generation code. So what’s first? Let’s pull out the code generation:

; levels.rkt
 
; Generate a simple cave with water and trees
(define (shallow-cave x y)
  (define wall?  (> (simplex (* 0.1 x) (* 0.1 y) 0)         0))
  (define water? (> (simplex (* 0.1 x) 0         (* 0.1 y)) 0.5))
  (define tree?  (> (simplex 0         (* 0.1 x) (* 0.1 y)) 0.5))
  (cond
    [wall?  (make-thing wall)]
    [water? (make-thing water)]
    [tree?  (make-thing tree)]
    [else   (make-thing empty)]))

This will represent the first few levels under the ground, with the same basic cave systems we’ve been using forever. There’s on problem with that–it turns out that using the noise functions is both a time saver and will be our undoing. Since the function always returns the same values, given the same arguments, every level of our cave system will be identical. Not something we want (at least not for the caves).

The fix?

Add another parameter!

Technically, there are two ways that we could do this:

• Add a z-coordinate that corresponds to depth. This feels like some nice parallelism, but it means that every single time we play the game, the caves will be the same. Sub-optimal for a roguelike.
• Add a random seed that is set once per level. This will generate levels random (albeit consistently within a single playthrough), so this is the option we want.

This actually turns out to be really easy to implement:

; levels.rkt
 
; Generate a simple cave with water and trees
(define (shallow-cave seed x y)
  (define wall?  (> (simplex (* 0.1 x) (* 0.1 y) seed)      0))
  (define water? (> (simplex (* 0.1 x) seed      (* 0.1 y)) 0.5))
  (define tree?  (> (simplex seed      (* 0.1 x) (* 0.1 y)) 0.5))
  (cond
    [wall?  (make-thing wall)]
    [water? (make-thing water)]
    [tree?  (make-thing tree)]
    [else   (make-thing empty)]))

Now we’ll get all sorts of interesting levels. For example:

(Yes, there are only rats and basic gear. I’ll get to that in a second.)

So we can make caves, just like we always have, but what about other sorts of terrain? Well, all we have to do is copy/paste/tweak. Let’s say instead of caves and walls, we want grassland (but still with trees and small ponds). We’d get something like this:

; levels.rkt
 
(define-thing grass tile
  [character #\.]
  [color "green"]
  [walkable #t])
 
; The surface level with grass, water, and trees
(define (surface seed x y)
  (define water? (> (simplex (* 0.1 x) seed      (* 0.1 y)) 0.5))
  (define tree?  (> (simplex seed      (* 0.1 x) (* 0.1 y)) 0.5))
  (cond
    [water? (make-thing water)]
    [tree?  (make-thing tree)]
    [else   (make-thing grass)]))

We can easily tune this to make any sorts of levels. Even better, we don’t necessary need to use the noise functions. We could theoretically make levels based on something like cellular automaton or even scripted levels (perhaps loaded from external files?). All we have to do is be able to generate a specific tile when asked and our framework will generate the rest. Speaking of which, how do we tie this into the previous get-tile function?

Well, we need a bit of abstraction first. First, how do we want to represent z-levels? Theoretically, we could use the same hash that we’ve been using, only using (list x y z) instead of (list x y). But keeping all of that in one hash seems like a recipe for trouble, so instead, we’ll store a hash of hashes. Each outer hash will be indexed by depth, the inner by the point. Then we can have a local variable referring to just the current level.

While we’re at it, let’s all refactor some other code. We need to store the seed that I mentioned earlier for each level. In addition, we want to store the generation functions for tiles (and later NPCs and items). Finally, so we don’t have an ever-growing list of NPCs all acting each tick, let’s move the NPC lists into the level. In the end, something like this:

; levels.rkt
 
; Level defintions
; tile-gen : x y -> tile
; npc-gen  : x y -> npc or #f
; item-gen : x y -> item or #f
(define-struct level-definition (tile-gen npc-gen item-gen))
 
; All levels 
; (pt x y) : tile
; 'npcs    : list of npcs
; 'gen     ; level definition (see above)
; 'seed    ; a random seed [0,1) generated once per level
(define levels (make-hasheq))
(define current-depth (make-parameter 0))
 
; Generate a new level (if it doesn't already exist)
(define (get-level depth)
  (unless (hash-has-key? levels depth)
    (define level (make-hash))
    (hash-set! level 'seed (random))
    (hash-set! level 'npcs '())
    (hash-set! level 'gen
      (cond
        [(= depth 0) 
         (level-definition surface nothing nothing)]
        [else
         (level-definition shallow-cave rats-only base-items)]))
    (hash-set! levels depth level))
  (hash-ref levels depth))

With this, get-level mirrors get-tile. If a level doesn’t currently exist, it will generate a new one. In this case, we have our two generation functions. If the level is 0 (the ground level), use the grassland generator. If it’s less than that, for now always generate caves. There are a few other generators (nothing, rats-only, and base-items) but I’ll get to those in a moment. (You can get a pretty good hint for what those will be by looking at the level-definition struct.)

With this, we have what we need to rebuild the get-tile function:

; levels.rkt
 
; Fetch a tile
(define (get-tile x y)
  (define current-level (get-level (current-depth)))
  (define seed (hash-ref current-level 'seed))
 
  ; If the tile doesn't already exist, generate it
  (unless (hash-has-key? current-level (pt x y))
    ; Get the new tile
    (define new-tile ((level-definition-tile-gen (hash-ref current-level 'gen)) seed x y))
    (hash-set! current-level (pt x y) new-tile)
 
    ; NPCs and items are only on walkable tiles
    (when (thing-get new-tile 'walkable)
      ; (Potentially) generate a new npc
      (define new-npc ((level-definition-npc-gen (hash-ref current-level 'gen)) seed x y))
      (when (and (not (void? new-npc)) new-npc)
        (let ([new-npc (make-thing new-npc [location (pt x y)])])
          (hash-set! current-level 'npcs (cons new-npc (hash-ref current-level 'npcs)))))
 
      ; (Potentially) generate a new item for that tile
      ; Do not generate an item if there already is one (generated by the tile generation routine)
      (when (null? (thing-get new-tile 'items '()))
        (define new-item ((level-definition-item-gen (hash-ref current-level 'gen)) seed x y))
        (when (and (not (void? new-item)) new-item)
          (let ([new-item (make-thing new-item)])
            (thing-set! new-tile 'items (cons new-item (thing-get new-tile 'items))))))))
 
  ; Return the tile (newly generated or not)
  (hash-ref current-level (pt x y)))

It has the same structure it always did, but now it’s nicely abstracted. The first chunk just generates a tile using the generation functions we defined earlier (surface and shallow-caves). The code to do that ((level-definition-tile-gen (hash-ref current-level 'gen)) seed x y) is a bit ugly, but it works well enough.

After that (if and only if we have a walkable tile), try to generate an NPC. The NPC generation functions are going to look exactly like the tile functions, except the return entities rather than tiles and can return either void or #f if there’s no NPC in that location. So if we just want an empty world, we can always return #f:

; levels.rkt
 
; No NPCs (also works for items)
(define (nothing seed x y) #f)

If we want a world full of rats (roughly 1% of the time):

; levels.rkt
 
; Look up a thing from a vector by 'name
(define (lookup vec name)
  (let/ec return
    (for ([thing vec]
          #:when (equal? name (thing-get thing 'name #f)))
      (return thing))
    (return #f)))
 
; Rats. All of the rats.
(define (rats-only seed x y)
  (when (zero? (random 100))
    (lookup *entities* "rat")))

The lookup function is so I can reuse those vectors of things I’ve been defining in entities.rkt and items.rkt. Basically, it finds the first thing with the given 'name field.

Items work much the same way. If we want just the basic tier of items, we can do this:

; levels.rkt
 
; Only basic items
(define (base-items seed x y)
  (when (zero? (random 100))
    (case (random 4)
      [(0) (lookup *armors* "leather")]
      [(1) (lookup *weapons* "club")]
      [(2) (lookup *potions* "health potion")]
      [(3) (lookup *coins* "copper coin")])))

(I added a new kind of item: stackable. Rather than replacing other items of a given type, they stack with them, combining quantities. Coins are currently the only stackable and at the moment, they’re completely worthless. But it’s a neat proof of concept. Check out the code on GitHub for more details.)

Okay. That’s basically everything to actually generate the levels. But we still have two fairly big problems:

• How does this hook up to the code we already have?
• How do we get to different levels?

For the first problem, we need to tweak world.rkt. Essentially, we renamed the get-tile function as tile-at and just wrapped get-tile from levels.rkt. Likewise with update and update-npcs. It’s pretty straight forward, check out the code on GitHub for more details.

The more interesting challenge is getting to different levels. The traditional way to do that in roguelikes is stairs. So we need a new tile type. But right now, we don’t have a way to attach events to tiles. So we’ll do both at once. Now, any tile can have an (optional) on-enter event, much like the on-pickup and on-drop events on items. Something like this:

; levels.rkt
 
(define-thing stairs-up tile
  [character #\<]
  [color "gold"]
  [walkable #t]
  [(on-enter entity world)
   (when (eq? (send world get-player) entity)
     (ascend)
     (hash-set! (get-level (current-depth)) 
                (thing-get (send world get-player) 'location)
                (make-thing stairs-up)))])

stairs-up will be much the same. Essentially, when the player enters a tile (the when keeps those pesky rats from using the stairs for the time being), they will call ascend which just sets the current-depth variable we defined earlier to one higher, which is all we would need, since the next rendering step will call get-tile which in turn calls get-level. Since there is no level yet (unless we leave the level and come back), a new one will be generated. That’s the beauty of the lazy tile generation setup we’re using.

The final chunk is particularly amusing. Basically, when you code up the stairs, it will generate the matching stairs on the next level. This isn’t perfect, since if you go back to a level you’ve already been on, the stairs will appear from nowhere. For now, we’ll consider this a ‘feature’. Hidden stairs. Another problem is that there’s nothing stopping the stairs from popping up in the middle of a wall. Since stairs on only triggered by entering them, that will be game over. Clearly sub-optmimal, but that’s something we can save for later.

Speaking of which, how do we implement on-enter? Well, that’s where the try-move function in world.rkt comes in. Find the one place where the player can move (where the target is walkable and not otherwise occupied) and add this code:

; world.rkt
 
; Look for an on-enter item
(define on-enter (thing-get tile 'on-enter #f))
(when on-enter
  (on-enter entity this))

And that’s all we need. Bam, z-levels. And it should be really easy to add more level definitions with all sorts of varied properties. One of these weeks (soon probably), I should actually work on balancing and adding a bunch of new content. That will be the last step for making a full game. But really, we’re basically there. All we really need still to have a game is more content and a way to win (It’s perfectly possible to lose right now, but winning? Not so much).

Before we go, how about a few more screenshots with stairs and all?

Starting out, we’re in a nice peaceful field. All we really have to do is find some stairs (or wander off into infinity (and beyond!)).

Found some stairs. Down we go!

A nice little cavern. There are rats south and east and one of those nice new coins up north.

Here we’ve grabbed the coin up north and killed the rat over by the potion. The coins have values based on the “gold standard” (1 gold = 10 silver = 100 copper, yay D&D!), so it’s really not much. But since they don’t do anything anyways, it’s as good as gold!

Let’s try heading back up. Remember that other set of stairs? What happens if we take those?

Oops. Yeah, I really should fix that. Now I’m in the middle of a wall and thus stuck. I really should add a way to manually trigger on-enter actions. We’ll see how that goes.

Well, that’s it for today. It’s really starting to look like a game now.

As always, if you’d like to see all of the code for this project, you can do so on GitHub:
- Racket Roguelike – Day 6
- Racket Roguelike – Up to date

If you’d like to try it yourself, you’ll need to have both Git and Racket and run the following series of commands:

git clone git://github.com/jpverkamp/racket-roguelike.git
cd racket-roguelike
git checkout day-6
git submodule init
git submodule update
racket main.rkt

(Note: Sorry I’m a day late this week. Life’s been crazy between conference deadlines and getting married. One of these days I’ll actually actually write one of these posts ahead of time… Or not.)

For part 7, click here: Racket Roguelike 7: Into darkness!

Go see Iron Man 3. I’ll wait.

(There may be spoilers below, but hopefully nothing that wasn’t already in the trailers.)

Based on the trailers, I wasn’t quite sure about Iron Man 3. I hoped it would at least be better than the second (which I originally enjoyed but on later viewings, particularly post Avengers, seems rather lacking) and at least as good as the first (still probably my favorite of the stand alone Marvel movies). I’m still digesting this new entry and will probably have to watch it at least a few more times to be fair, but I think it may actually do just that. It may even be better…

As always, Robert Downey Jr. did an excellent job. he brought a touch of humor to the scenes that sorely needed it and played a worn Iron Man remarkably well. I’ve heard rumors that he may not do an Iron Man 4 (although there’s still the second Avengers) and, honestly, if that was the case, I wouldn’t be that upset. I’m not sure where they could go with Iron Man after this and I thought they did a pretty good, really surprisingly good job of wrapping everything up.

As for the rest of the cast, I think this was Gwyneth Paltrow’s best Iron Man movie as well. I won’t give too much away, but her parts in the middle (around the attack on Stark’s house we see in the trailers) and at the end are amazing. And she really helps ground the movie in her reactions to Stark’s behavior. It’s about time.

Ben Kingsley as The Mandarin really steals the show though, for the parts that he’s in. I haven’t actually read his parts from the comic books, but I’m pretty sure that the movie version is a fairly significant departure–and it works great. He really has a strong progression throughout the movie and Ben Kingsley did an amazing job on that.

It was a little weird that the movie is set around Christmas time, particularly given an early summer release. I realize that it’s very much a summer blockbuster and they they never would have gone for a winter release, but it’s still a little disorienting. Perhaps I’ll re-watch it again in about 7 months and see if it changes at all.

One thing that did seem a little strange was how they basically went directly against the idea of the second film though. In the second, the entire point seemed to be that a man in a suit would always be superior to an AI-controlled robot. Yet that’s pretty much what saves the day when Stark activates his ‘reinforcements’. Theoretically I guess they could have been controlled by Stark himself somehow, but I think the strong implication is that Jarvis is in the driver’s seat (which is really pretty impressive when you think about it…).

On an only semi-related note, I knew that since I was seeing it opening weekend, the theater would be crowded. I was a little amazed though at just how many young kids there were though. I’d say easily half of the audience was under the age of 13… And there was even at least one infant that I saw. Really, that’s a decision that every parent has the right to make and I can’t make it for them–but think about it this way, the movie isn’t going anywhere. It will still be there when they’re older.

Overall, Iron Man 3 takes my top spot. It’s great fun, particularly if you’ve seen all of the other Marvel features. It may or may not end up the best movie of the year, but given what’s in theaters right now, it’s certainly worth your time and money.

My 2013 Movie Rankings

1. Iron Man 3
2. The Croods
3. Django Unchained
4. Parental Guidance
5. Oblivion
6. Beautiful Creatures
7. Jurassic Park (3D!)
8. Oz the Great and Powerful
9. Hansel & Gretel: Witch Hunters
10. Jack the Giant Slayer
11. Warm Bodies
12. G.I. Joe: Retaliation

If you’d like to start at the beginning, click here: Racket Roguelike 1: A GUI, screens, I/O, and you!

This time around, let’s start with the kinds of items that we want to support. As you may have guessed from the post title, we’ll start with three: armor, weapons, and potions for boosted attack, defense, and temporary effects in turn.

First, we need a base thing on which we can base all of the rest of the items:

; items.rkt
 
; All items have:
; - a display char/item if they're on the ground
; - if they're consumed or not (picked up)
; - methods for:
; -- being picked up
; -- being dropped
(define-thing item
  [character #\x]
  [color "white"]
  [consumable #f]
  [category 'unknown]
  [(on-pick-up item entity world)   (void)]
  [(on-drop item entity world) (void)])

First, we have the basic display features all of our items have. Then we have a flag that basically identifies if you can wear an item ((not consumable)) or if you consume it immediately (consumable).

Next, we have a category. Basically, our model will be that you can hold one item of each category at a given time. This way, you can have one kind of armor and one weapon and that’s it. That will save us from having to make any sort of complicated inventory, although this same system could be adapted to a more flexible category to maximum count mapping.

Finally, we have two methods. I really do love functional programming when things like this come up. Basically (as should be obvious from the names), the first method will be called when them item is picked up (also when a consumable item is used), the second when it’s dropped (never called for consumables).

So how does this work for an armor definition?

Well, we’ll start with this:

; items.rkt
 
; Armor protects the wearer
(define-thing armor item
  [character #\]]
  [defense 0]
  [category 'armor]
  [(on-pick-up item entity world)
   (thing-set! entity 'defense (+ (thing-get entity 'defense)
                                  (thing-get item 'defense)))]                               
  [(on-drop item entity world)
   (thing-set! entity 'defense (- (thing-get entity 'defense)
                                  (thing-get item 'defense)))])
 
(define *armors*
  (vector
   (make-thing armor [name "leather"]   [color "brown"]  [defense 1])
   (make-thing armor [name "chain"]     [color "gray"]   [defense 2])
   (make-thing armor [name "plate"]     [color "white"]  [defense 3])
   (make-thing armor [name "enchanted"] [color "purple"] [defense 5])))

Basically, we set the character, category, and behavior in a base thing. Then all the further definitions have to do is override the name, color, and specific value. The behavior will be copied over just fine.

Similarly, we can define weapons (the base definition is the same except using 'attack instead of 'defense):

; items.rkt
 
(define *weapons*
  (vector
   (make-thing weapon [name "club"]        [color "brown"]  [attack 1])
   (make-thing weapon [name "dagger"]      [color "gray"]   [attack 2])
   (make-thing weapon [name "battle axe"]  [color "white"]  [attack 3])
   (make-thing weapon [name "longsword"]   [color "white"]  [attack 3])
   (make-thing weapon [name "magic sword"] [color "purple"] [attack 5])))

Finally, we have the actual consumables. Specifically, potions. Right now, there’s really only one potion that makes sense, but the framework is more than flexible enough to do just about anything. Perhaps next week I’ll start in on mutable terrain.

; items.rkt
 
; Potions are single use and consumed on contact
(define-thing potion item
  [character #\!]
  [category 'potion]
  [consumable #t])
 
(define *potions*
  (vector
   (make-thing potion
     [name "health potion"]
     [color "red"]
     [(on-pick-up item entity world)
      (thing-set! entity 'health (+ 10 (thing-get entity 'health)))])))

Now all you have to do is walk over a potion and you’ll feel much better.

So now we have a bunch of items, how do we tie them into the rest of the framework?

First, we need to be able to store them. Since we eventually want any entity (player or enemy) to hold an item, we’ll add the inventory all of the way back at the base entity thing:

; entities.rkt
(define-thing entity
  ...
  [inventory '()])

That will cascade through to all players and enemies.

Next, we need to do the same to tiles on the ground so that we can have items just lying about:

; world.rkt
(define-thing tile
  ...
  [items '()])

Now, we have to actually generate some items lying around. Luckily, we can use almost exactly the same code that we used to generate the wandering monsters. Any time a tile is generated, there’s a small chance of generating a random item as well.

; world.rkt
 
; Sometimes even more rarely, generate some sort of treasure
(when (and (thing-get new-tile 'walkable)
           (< (random 1000) 1))
  (define new-item
    (let ([base (vector-choose-biased (vector-choose-random *all-items*))])
      (make-thing base)))
 
  (thing-set! new-tile 'items (cons new-item (thing-get new-tile 'items)))))

As we did with the new creatures and tiles, we wrap the items with a call to make-thing, making this item distinct from the base definition. Right now, there’s no way to mutate items, but in the future we might want to have durability or some such–this will prevent all swords in the world from breaking when you swing any one of them.

So now we have items in the world, but we still can’t see them. So we need to go over to the game-screen and modify the draw routine. Where previously the lowest layer was to draw the tile, now it will draw the tile if there’s no item or the first item if there’s at least one.

; game-screen.rkt
 
(define tile (send world get-tile (pt-x x/y) (pt-y x/y)))
(cond
  [(null? (thing-get tile 'items '()))
   (send canvas write
         (thing-get tile 'character)
         xi
         yi
         (thing-get tile 'color))]
  [else
   (send canvas write
         (thing-get (car (thing-get tile 'items)) 'character)
         xi
         yi
         (thing-get (car (thing-get tile 'items)) 'color))]))

It’s a bit ugly (so much duplicated code), but for the moment it will work.

Well, now that we’re generating them, what does it actually look like?

If you look to the left of the player, there’s a nice gray ] just sitting there. If I remember the definitions correctly, that’s chain armor. If only we could actually pick it up…

(I made the screen a bit larger so we have room for the player inventory to print, which we’ll get to shortly. It should still be reasonable on most people’s screens.)

Well, for that, we can tie into the movement code. The only time that we could pick up an item is when we walk into it, so it has to be a walkable, unoccupied tile. We want to pick up any items we walk over, drop any items that have the category of one we just picked up, and directly consume and consumables. It’s a bit of code, so let’s just take a look first:

; world.rkt
 
; If it's walkable and not occupied, update the location
; Also, pick up any items there, exchanging if types match
[(null? others)
 (thing-set! entity 'location target)
 
 (define (pick-up item)
   (thing-set! entity 'inventory (cons item (thing-get entity 'inventory)))
   (thing-set! tile 'items (remove item (thing-get tile 'items)))
   (thing-call item 'on-pick-up item entity this))
 
 (define (drop item)
   (thing-set! entity 'inventory (remove item (thing-get entity 'inventory)))
   (thing-set! tile 'items (cons item (thing-get tile 'items)))
   (thing-call item 'on-drop item entity this))
 
 (define (consume item)
   (thing-set! tile 'items (remove item (thing-get tile 'items)))
   (thing-call item 'on-pick-up item entity this))
 
 ; For each item on the ground
 (for ([item (in-list (thing-get tile 'items))])
   ; Remove same typed items from the inventory
   (for ([in-inv (in-list (thing-get entity 'inventory))]
         #:when (eq? (thing-get item 'category)
                     (thing-get in-inv 'category)))
     (drop in-inv))
 
   ; Pick up or consume the item
   (if (thing-get item 'consumable)
       (consume item)
       (pick-up item)))]

That should be relatively straight forward. And it actually works out great:

Here’s another nice bit of chainmail just lying there for us.

Walk right over it to put it on. You can see the armor we’re currently wearing in the top left, along with the boost in defense we got (note: Things are totally unbalanced right now. That’s a post all to itself.)

Then we wander about a bit more. Hit a few bombs (those things hurt!). A bit of a pick-me-up would come in handy about now.

Walk over it and drink it up:

Everything seems to be working well.

That’s all we have today. I’m thinking about doing some line of sight calculations for next week (the screen is getting rather cluttered…). We’ll see if I haven’t changed my mind by then though.

As always, if you’d like to see all of the code for this project, you can do so on GitHub:
- Racket Roguelike – Day 5
- Racket Roguelike – Up to date

If you’d like to try it yourself, you’ll need to have both Git and Racket and run the following series of commands:

git clone git://github.com/jpverkamp/racket-roguelike.git
cd racket-roguelike
git checkout day-5
git submodule init
git submodule update
racket main.rkt

For part 6, click here: Racket Roguelike 6: Dig deeper!

For the most part, Jurassic Park¹ has held up amazingly well over the intervening 20² years. Some of science is a bit dodgy–for example, we’re now pretty sure that dinosaurs would have had feathers³–but it’s still a nicely intense look at how dinosaurs and people just really wouldn’t / shouldn’t mix.

Two things that really did annoy me about the movie (now just as much as the first time I watched it) were Jeff Goldblum’s Dr. Malcom and Wayne Knight’s Dennis Nedry. For the former, his constant obsession with chaos theory despite just sort of spewing words that only vaguely relate to the field he’s supposed to have a doctorate in. Logically, I know that it’s yet another instance of knowing more about a field that I’m personally very interested in than the film’s producer’s did⁴, but it still irks me. Chaos theory is fascinating. He just makes it sound annoying.

Speaking of which… Oh Dennis Nedry. I know that we’re supposed to dislike him, but eesh. Granted, it was a different world back in 1993. I was only barely getting into computers myself⁵. But if he really thought he was being treated so absolutely terribly, why didn’t he just leave? There was probably some sort of contract in place, given the nature of the park and all, but then why did he take the job in the first place?

As a side note though, I’ll actually speak against the crowd and say that I really liked the scene where Lex (the sister) ‘hacks’ into the Unix machine and turns on the door controls. People give that scene a lot of crap, saying that of course that’s not how computers really work. But it turns out that it actually was an experimental 3D file system viewer known as fsn or ‘fusion’. Granted, it was never actually finished, but I really can imagine someone like Nedry installing it on the system, mostly just as a form of job security. People also say that even if the line “It’s a UNIX system! I know this!” is a bit over the top, it’s not that far off from how you would actually go about making use of an unfamiliar system in a time-critical environment: make your best guess based on domain knowledge and what the system is telling you and hope for the best.

On a positive note, the technology that made the movie famous–the dinosaurs–has held up really well. In parts, the dinosaurs do look a bit fake (mostly the eyes and when they don’t have quite a large enough field of motion), but I’m frankly amazed at how good a lot of the action scenes look even now. Say what you will about the differences between modern CGI and the effects of days gone by, but I really didn’t have a problem believing that they really were about to be eaten by dinosaurs.

Overall, it’s a solid movie. If you liked the original, go ahead and check it out in 3D. The conversion was well done (even if I don’t get the full effect due to an imbalance in my vision) and added a lot. It was nice to have 3D scenes that worked without a reliance on being in 3D⁶. Still, this year has been pretty good for movies. Based purely on my own enjoyment (which is, after all, what this rankings are based on), Jurassic Park fits right down the middle of the line.

My 2013 Movie Rankings

1. The Croods
2. Django Unchained
3. Parental Guidance
4. Oblivion
5. Beautiful Creatures
6. Jurassic Park (3D!)
7. Oz the Great and Powerful
8. Hansel & Gretel: Witch Hunters
9. Jack the Giant Slayer
10. Warm Bodies
11. G.I. Joe: Retaliation

1. I still have problems spelling that correctly…
2. Holy crap
3. A fact that the upcoming Jurassic Park sequel is apparently going to happily ignore
4. Or, if you want to be generous, than they thought that the audience could handle
5. I’ll leave that as an exercise for the reader to work out just how young I was back then
6. Any scene ever that throws things at the audience, I’m looking at you!