Rauko Dev Blog

Globals Considered Harmful

Thu, 20 Oct 2016 10:06:49 -0600

My design leftover from the 7DRL challenge made use of a bunch of singletons (i.e. global variables) for things like the screen, player, world, log, and so forth. I think we can all appreciate why global variables (even when disguised as singletons) are bad. They introduce coupling between otherwise unrelated parts of code, they introduce concurrency issues, make testing difficult at best, and increase cognitive load on the programmer due to non-locality. The biggest thing I’ve done recently is to get rid of these globals. While these hacks made throwing together the 7DRL challenge a bit easier, long term these changes will actually make it easier to accomplish some of my design goals.

The first global I got rid of was the global logger. With the global logger, each entity that needed to log something would simply access the global logger and send the log message directly. In place of the global logger, I’ve now switched to using a log component on every entity that might need to log. There are a number of advantages to this (in addition to removing the problems with global variables). For example, I no longer have special cases sprinkled throughout the code to determine whether or not the hero could see the logged event. I just have the component handle this, and the everywhere else the code just sends a log event to the appropriate entity. Using log events instead of directly logging also opens the door for more interesting logic around the log event. As an example, suppose the player becomes blind for some reason. Now instead of directly logging a message like “The wolf bites you”, I could have the blind component intercept the log message and replace the message with something like “Something bites you”.

Next I got rid of the screen. I realized that the only entity that actually dealt with it was the player. More specifically, in the player controller there was a call to update the global screen. Now, I simply added the screen as a component on the player entity which knows to update upon receiving an act event. Consequently, the screen gets updated at exactly the right time (i.e. just before we get player input), and there is no coupling between the screen and the player controller.

Finally, I go rid of the global player and world variables. This one turned out to be easy. The only reason I had to have the player be global before was actually due to the coupling between the global logger and every other entity in the game. With that coupling removed, I no longer needed every entity to have access to the player in order to determine what to log. Now they can go back to treating the player as just another entity on the map. Of course the main game loop still uses the player to determine what is going on with the game, but that is easily done without a global.

Overall I’m pretty happy with these changes, and I’m ready to start adding logic around some of the bump events. Hopefully the next post will talk about the basics of combat!

Reviving Stones

Sat, 17 Sep 2016 15:47:48 -0600

I just looked at the date of my last post and holy cow its been a long time since I’ve done any work on Stones. I’m starting to revive my work on it though! Basically what happened is life. I’ve been busy with paper submissions at school. I’ve decided that I really dislike running user studies as they take far more time than I ever would have predicted. Since I last posted, I’ve had an EMNLP paper submitted and rejected, and I’ve been working on submitting elsewhere. I’m also working on another ACL paper. In addition, with our oldest kid out of school for the summer, we got a national parks pass and have been taking advantage of it, leaving even less time for roguelike dev.

Anyways, things are starting to settle down now that school has started up again and I think that I’ll be able to find time to work on Stones. I’ve even managed to stream a few times in the last week! Its been long enough that I felt like the best place to start was with a refactor to refamiliarize myself with the code. I’ve added and fixed some godocs, tackled a few old todos about reorganization, and I think I have my head back in the code base.

I have a few goals. First, I want to revisit the basic structure that I put together during the 7DRL Challenge. I have two main issues. I still feel like I have too much reliance on concrete structs instead of the more elegant entity-component system I’ve worked to set up. I need to rely more on event messages instead of type assertions so I can make specific function calls. This will be more extensible and maintainable going forward.

The other issue I’ve had with the code from the 7DRL is the use of globals. For the 7DRL challenge it was fine. For things like the log, screen, hero and map, making these things globally accessible was the quick and dirty solution. The problem is that this solution is dirty and so for long term Stones dev I want a more maintainable design. I’ll post more about the overall design once I nail it down.

Delta Clock Scheduler

Sat, 17 Sep 2016 15:31:28 -0600

This article presents a simple data structure for scheduling which has the potential to be extremely efficient, while maintaining elegance and simplicity. It is based of the idea of a delta clock, which I first encountered years ago in my operating systems class as an undergrad.

Suppose you have a set of events which you want to resolve at certain times. You could just store these events in a list, along with the intended times like this:

A list of events stored the naive way

The problem is that in order to find all the events you want for the current time interval, you have to iterate through the entire list. Updating the list to advance in time also requires iterating through the whole list. Of course for many roguelikes, O(n) for a scheduler is perfectly acceptable. However, for games like Sticks and Stones, we’ll need to do a bit better. Instead, we’ll store our events like this:

A list of events stored using time offsets

Each event is stored with a delta between it and the previous event. In our example, Event1 is scheduled to fire in 5+15 ticks, while Event6 is scheduled for 5+15+2 ticks. Adding an event to this list is simply a matter of iterating through the list once, decrementing as we go. To advance in time, we simply decrement (or pop) the first item in the list.

Of course in the worst case scenario, our run time for adding an event to the delta clock is still O(n), where n is the number of events. However, at least in Sticks and Stones, a large number of the events (typically a creature move event) all fire simultaneously. By combining simultaneous events into a single node in our list, adding a new event gives us a run time which is O(t), were t is the number of unique deltas.

The implementation is pretty simple too! Here is some code:

type Event interface {
  Fire()
}

type deltanode struct {
  delta int
  link *deltanode
  events []Event
}

type DeltaClock struct {
  head *deltanode
}

func (c *DeltaClock) Schedule(e Event, delta int) {
  var prev, curr *deltanode = nil, c.head
  for curr != nil && delta > curr.delta {
    delta -= curr.delta
    prev, curr = curr, curr.link
  }

  var node *deltanode
  if curr != nil && delta == curr.delta {
    node = curr
  } else {
    node = &deltanode{delta, curr, make([]Event)}
    if prev == nil {
      c.head = node
    } else {
      prev.link = node
    }
    if curr != nil {
      curr.delta -= delta
    }
  }

  node.events = append(node.events, e)
}

func (c *DeltaClock) Advance() []Event {
  if c.head == nil {
    return nil
  }

  events := c.head.events
  c.head = c.head.link
  return events
}

That is really it! There are two additional features that you’ll find inside the GoRL implementation of the delta clock. First, I added the ability to unschedule an event. This was done by having the delta clock store a mapping of every event to its node so I can easily find it later and remove it. Second, GoRL gives deltas as floating point numbers, with the integer part representing the actual delta, and the fractional part used to determine the order in which events should fire.

Moving to Gitlab

Tue, 05 Apr 2016 11:17:17 -0600

I’m moving to GitLab! You can now find all my hobby code (i.e. stuff done under the name Rauko) on GitLab: https://gitlab.com/u/rauko1753.HUGOMORE42 I still have my main GitHub account for non-hobby projects, and I still have my old hobby account, but you’ll find that it is barren.

Okay, so this move probably merits some explanation. Let me first be clear that this post should not be viewed as a call for everyone to abandon GitHub in favor of GitLab. This is merely an explaination for why I personally moved some of my code over to GitLab.

On the surface GitLab is basically GitHub for enterprise. It comes complete with git management, code reviews, issue tracking, and so forth. One cool feature not available on GitHub is that GitLab lets you run on your own servers should you desire complete control over your code. Of course GitLab also have free SaaS offerings if you want your stuff in the cloud too. However, for non-paying individual users like myself, GitHub and GitLab have feature sets of the two products are quite comparable. That said, here are some reasons why a free user might consider switching.

FOSS shouldn’t put all its eggs in one basket
Suppose GitHub suddenly decided to go the route of SourceForge and pull crap like this. Admittedly this scenario is pretty unlikely, but there are scenarios which could conceivably happen. Suppose GitHub changes its pricing model in a bad way, or suppose GitHub gets taken down in a DDoS attack of some sort… Having the entire FOSS community dependant on one code hosting platform seems pretty risky if you ask me.
GitHub is not actually open source
Yup - you read that right, and it feels really strange to say given how GitHub has positioned themselves in the market. GitLab on the other hand is open source, so all the familiar arguments about the advantages of open source actually apply. Admittedly, this probably affects enterprise customers more than individuals, but its still an issue.
Free private repositories
For almost everything, I don’t really care about private repositories at all since I want the code to be easily accessible by anyone who cares. There are a few cases where I need private repositories. For example, my private latex repository is full of unpublished drafts that I intend to eventually publish. GitHub makes you pay for private repositories and collaborators, while GitLab does not.
Sexism and racism seem to be a problem at GitHub
From the outside looking in, GitHub looks like a pretty bad place to work. We’ve had a scandal where allegations of sexism at the highest levels of the company ultimately led to the resignation of it CEO and co-founder. In addition to the sexism, there have been some pretty disturbing reports of racism inside the company. Yes, gender and race gaps in the tech industry are a huge problem which must be addressed, but being racist against white people isn’t counter racism - it is just regular racism. When “it is very hard to even interview people who are ‘white’“, there is a serious problem. To be fair, GitHub seems to be going through a lot of turmoil internally, so it is hard to say exactly what is going on. What I can say though is that I wouldn’t want to work there right now…
GitLab CI is integrated, easy and configurable
Unlike GitHub which requires third-party CI systems, GitLab has CI built right in. You can pretty much setup an arbitrary build process with GitLab. Here is an example config file: gitlab-ci.yml. An immediate consequence of these build files is that GitLab pages are much more configurable than GitHub Pages. GitHub pages are great if you use Jekyll. If you use something else like me (I use Hugo), GitHub is rather annoying. I have to manually run my static website generator and push the generated content up to GitHub. Not only does my repository contain tons of redundancy, its just a hassle to deploy. Due to the way GitLab does CI, GitLab Pages works with any static site generator. Getting my Hugo-based blog up on GitLab was as simple as adding a 5 line yaml file. For me this is a huge win.

In general I believe that most people have two reasons for everything they do: the good reason and the real reason. So which bullet in this list is my real reason for switching to GitLab? Honestly, I don’t know. I guess in this case all of these factors put together have sorta influenced me to want to try something new. Will I be judging you if you decide to stick with GitHub? Of course not - this is not a call to ditch GitHub altogether. In fact most of my ‘real’ work is still on GitHub. Moving my hobby code to GitLab is mostly an experiment to see what else is out there.

7DRL Ideas

Wed, 30 Mar 2016 10:21:11 -0600

It is never too early to come up with ideas for next year’s 7DRL challenge. Here is a compilation of ideas. Some of them are mine, others are I am merely documenting because I liked them. I’ll try to link the source when I borrow ideas. You are welcome to use any ideas here for your own roguelike. They are general enough that even if two people were to use the same concept, the resulting games would likely be radically different.

Sneeze (from a rather silly irc conversation about the worst roguelike ever)
- The original idea was that when you sneeze your soul leaves your body
- You are unfortunately highly allergic to everything, and sneeze often
- You lose if your soul escape, but win if you catch it
- Sneezes also help you
- Certain mobs are killed by sneezing on them
- You can control the sneezes by going on/near plants you are allergic to
- Just don’t lose your soul!
- Potential items
- pepper shaker - instant sneeze without plants
- hanky - sneeze on it keeping your soul, drop for a monster trap
- eye-drops - clear up itchy eyes from allergies
- religious artifact - blesses you so your soul doesn’t escape on sneezing
- antihistamine - the goal item
  - stop all sneezing
  - still have to escape (without sneezes)
  - more points for using it earlier
Battle Arena
- Try to recreate the feeling of LoL, HotS, etc
- Team has creeps and towers - tower defense style lanes
- Hero (and AI heroes) level quickly, try to destroy enemy base
- Could procedurally generate hero abilities
- Alternatively: Dungeon Defenders
- Alternatively: Dungeon Keeper, where you are the boss
Gladiator
- You face off one versus one in a fight to the death
- Should be multiple, incomparable fighting styles
- Combat needs to be tactically interesting
- No bump until dead mechanics
- May be a nice way to prototype a cool combat system
- Could potentially make this an AI challenge too
- Need a pluggable architecture or protocol
- Need a way to simulate lots of matches
Conservationist (from Quendus)
- Quendus suggests a game where you must deal with dungeon conservationist who will try and ensure that you don’t kill more than a certain quota of each monster type
- Could also be fun to play as one of the conservationist trying to save the creatures from poachers
College Games (from HzZ)
- Implement college games as a roguelike
- Requires player to still be students
- Must attend class, eat, sleep, etc)
- Option: Humans versus Zombies
- Option: Assassin
1D Roguelike (from halvorg)
- Same abstraction that 2D figher games make
- Each 2D level amounts to traveling between destinations
- Need interesting abilities in order for tactical complexity
- Cool downs on abilities
- Abilities which are affected by time and space
  - Min/Max range on abilities
  - Delays on abilities
  - Field of view may be a factor too
- Still need interesting level gen, with doors, obstacles, etc
Capture the Flag
- Player and NPC have characteristics like vision, speed, stealth
- You control the team captain, who chooses teammates
- Can give general orders to team like guard an area, explore an area, etc
- Should be a “shout” action which lets you share field of view
Portal
- A top down 2D portal inspired roguelike
- Velocity based puzzles might not work, so puzzle elements need to be majorly reworked for 2D
- Procedural puzzle generation would be amazing, but hard
- Can punt on PCG, and read from file
- File format should be human editable
Superheroes (from Jo)
- Heroes have various RPG stats, which are enhanced by passive super powers
- Active super powers require energy, but energy recovers fairly quickly
- Open world, with baddies doing bad stuff, including super villians
- Can seek inspiration in Hi/Lo Heroes
National Treasure
- Free masons hid some treasure, hero aims to find it
- Generate URR inspired clues and puzzles
- Can add in Indiana Jones style traps
- traps should be dangerous
- but they should be escapable with wits
- Enemies can try to hinder progress
- Can hurt you if too close
- Can steal clue answers
- You should be able to do the same
Arcade Based Roguelike
- Transform an old arcade game into a roguelike
- Snake
- Tron
- Pac-man
- Frogger
- QBert
- Probably need some game play changes beyond switch to turn-based to make the games interesting in the roguelike setting
Story-Telling
- I’ve always wanted a roguelike with procedural and interactive story generation - make a game which prototypes such a system
- Make the hero all-powerful so the focus is entirely on the story
- the real game would take the prototype, and add real mechanics
- A hybrid procedural + scripted could work
- The human writes mad-libs style prototypes
- Human content should be a tree with conditions on branches
  - Details filled in by computer
  - Branch conditions informed in by player actio
Fire Rescue (from TempusFrangit)
- You are a firefighter trying to rescue victims of a fire
- Need to manage oxygen, building collapse, heat, etc
- Need to rescue as many people as possible
- Can call in water, for aid, etc
- Procedurally spreading fire, smoke, etc
- Take inspiration from Flashpoint

7DRL Post-mortem

Sat, 26 Mar 2016 10:06:05 -0600

Okay so I failed at the 7DRL challenge… In fact its been a while since I posted anything here. I’ve basically been coming up for air after a rather crazy week at work. Around day 4 of the challenge we ran into some serious issues with the user study we were running to validate some of the algorithms we developed in Ankura. Consequently, I spent the next week or so working 20-hour days in a desperate attempt to get this paper submitted. I wish I was exaggerating the length of those workdays…

Anyways, I feel like I’ve finally come up for air. I started livecoding again this week, and I’ve actually made small amount of progress. First and foremost, I split off the core package into its own repository available here: https://gitlab.com/rauko1753/gorl. This repository is broken down into a few subpackages as the original core package had an absurd number of exported identifiers. Splitting the roguelike library into its own repository also means you don’t have to clone stones just to get access to the more generalized roguelike functionality, so in future 7DRL attempts, I’ll not be importing anything Stones related.

Going forward, I think I want to use what I’ve learned during the 7DRL challenge to actually start writing the game. I’ve implemented the basic outline of melee combat. Currently the creatures you encounter in the game world are just immobile punching bags. My next course of action is to get a super simple AI for these creatures hooked up.

Starting the 2016 7DRL Challenge

Mon, 07 Mar 2016 10:49:07 -0700

I am officially entered into the 2016 7DRL Challenge! I’m not actually going to write much about what I’m doing until after the challenge is complete. After all, I’ve only got 168 hours to do this thing! However, here are a few links in case you want to follow along:

Dungeons

Sat, 05 Mar 2016 10:36:21 -0700

This week my main accomplishment was getting dungeon generation working. As previously discussed, the basic algorithm involved generating an abstract maze, and then converting that maze into a dungeon by creating a room for ever node in the maze and a corridor for every edge in the maze. There are a lot of parameters to tweak so I can generate very different kinds of dungeons. Some of these parameters are:

run probability - how likely are long runs (as opposed to branches)
loop probability - how likely are we to remove dead ends from the maze
loop weave probability - how often we simulate z-levels by having the maze dig underneath itself
room dimensions - control distribution of the room dimensions
num rooms - controls the size of the dungeon

Another cool thing I did to control how the dungeons look is by making the function that creates the actual tiles of the maze a callback. This callback basically just says it is creating a tile at a certain (x, y) position, and gives the type of tile (wall, corridor, room, or door). There is a default in case you don’t need anything special, but if you want to make a lava themed dungeon or have other special needs you can get it with a custom tile generator. In fact, I added various tile generation callbacks to all the different map generation functions, so overall I think we have a lot of customizability.

Anyways, below is an example of a dungeon you can generate with this code. This particular example was made with a loop probability of 1, a weave probability of 0, and the default tile generator.

Example of a generated dungeon

Now that I’ve got dungeons working, I want to take these maps and carve out some additional spaces using a cellular automata so I can finally make caves for my cavemen. However, this will have to wait a bit since next week is the 2016 7DRL Challenge!

Bug fixing is progress?

Sat, 27 Feb 2016 08:27:23 -0700

This last week was fairly uninteresting for Stones dev. Mostly what I did was track down a visual bug related to weave mazes , or mazes which loop around on themselves to reuse the same (x, y) coordinate for multiple tiles. Essentially what happens is that due to transitivity in connections to the wall, when a maze wraps around a single wall tile then there will be multiple tiles connected to the wall from the same direction. The wall can only connect back to one of the incoming edges, and so visual inconsistencies arise when you query the wall for its adjacent tile with the intent to draw what is next to that wall. Sometimes you would get the right tile, and sometimes you can magically see through the floor to a different z-level. This graph structure is desirable from a traversal standpoint, although typically a moot point since you can’t walk through impassable Tiles. The main fix was to simple adjust my field of view calculations such that it will never query a wall tile for its adjacency if the field source is a non-wall Tile. Sounds easy, and once I realized what was going on it was easy, but figuring out what was causing the visual inconsistencies took me an embarrassing amount of time.

I also started converting my maze generators to generate standard room and corridor dungeons, although this is still incomplete. I ended up fixing another bug as part of dungeon generation. Basically what was happening was that occasionally the origin node in my maze would be removed due to being a dead end, but would still be accessible due to it being the origin node. The fix was easy - just let the origin be an arbitrary node in the maze. Same thing though - while the fix was easy, figuring out why I would occasionally traversing the maze graph would result in nil pointer dereference was tricky.

Mazes

Tue, 23 Feb 2016 14:33:38 -0700

My main focus last week was on maze generation. From a roguelike gameplay standpoint, mazes suck. However, due to the way I have set up my map data structures, I will use maze generation in a more abstract way to generate interesting maps like dungeons and caves.

I figure if I’m gonna have a game with cavemen I better have some decent looking caves for those cavemen to live in. I’ve done cave generation before with a simple cellular automata randomly initialized on a 2D grid. The maps cellular automata produce on 2D grid are surprisingly good and are easily customized just by tweaking the parameters governing the cellular automata. This technique has become my goto method for cave generation on 2D grid maps.

However, for Stones my maps are set up a little bit differently. I got this idea from Jeff Lait’s 2015 IRDC talk on roguelike algebra that made me realize you could do seamless z-levels if you made your map a generalized graph structure. Instead of a 2D grid of tiles, I actually have my Tile struct store a map of Offset to Tile. With this generalized graph structure, rather than looking up in a 2D array of Tile for what Tile is to my left, I instead query the Tile for what is to its left. I can then build any arbitrary structure I want. Rather than having a ‘>’ tile which lets the player to a new level, I can have the cave entrance simply replace one its edges to point to the cave so the player can just walk into the cave. The cave structure ends up overlapping in (x, y) coordinates with the overworld, so we essentially simulate z-levels. While I don’t intend to do this for Stones, you could even do some wonky non-Euclidean topologies complete with portals, ‘bigger-on-the-inside’ rooms, and wickedly intertwined corridors.

This graph-based map has basically forced me to rewrite all the core algorithms I previously had written for grids. I’ve converted nearly everything including path finding, Dijkstra maps, field of view, line of sight, and some basic overworld map generation. Pretty much the last piece I needed was getting caves for my cavemen to live in.

To generate caves on a graph I’m doing it in a rather odd way. One approach that doesn’t involve a grid is to just morph a traditional room and corridor dungeon using cellular automata as seen here. So I need some rooms and corridors. One way I’ve previously done dungeons was by generating traditional mazes and then converting the maze nodes to rooms and maze edges to corridors. So I need some mazes - and that is pretty much what I worked on this week.

Example half-braid maze generated with no weave

Currently what I have working is the ability to generate an abstract maze, and then the ability to convert that abstract maze into a set of Tile. The abstract maze is a graph structure of nodes and edges. I can generate the maze with no loops (i.e. a perfect maze), with no dead ends (i.e. a braid maze), or anywhere in between. I can also specify how much I want the maze to branch. Finally, I can specify how much I want the maze to dig under itself and reuse existing (X, Y) coordinates. I refer to this as ‘weave’, although the term typically means something else in the context of mazes…oh well.

For those interested, I used the so-called Growing Tree algorithm. This algorithm is pretty simple, but also fairly flexible. Here is the pseudo-code for the algorithm:

frontier = list{start}
while frontier not empty:
  node = choose from frontier
  if node has unused edges:
    edge = choose unused edge from node
    dig on edge to adjacent node
    add adjacent to frontier
  else:
    remove node from frontier

Converting this algorithm to work with an arbitrary graph structure is pretty easy. Here are the details that needed some thought:

Normally you choose a random start from a 2D grid. I just start with the origin (0, 0) and allow my nodes to have negative X and Y positions. I will end up translating the maze later on anyways, so this is pretty minor.
Since I don’t have a grid and can grow my graph to any arbitrary size, my frontier will never stop growing. Consequently, I had to change the stopping criteria to track the number of nodes added to the maze rather than if the frontier is empty.
Since my maze allows for ‘weave’, I had to modify the definition of “unused” edge a bit to (optionally) let nodes create edges to nodes sharing the same Offset as other existing nodes.
Choosing a node from the frontier is very important to controlling the structure of the maze. If you always choose randomly, you get a fairly high branching factor, and a maze that looks like Prim’s algorithm with randomized weights. If you always choose the newest, you get a very low branching factor and long runs in the maze. I let the caller determine how often to use a random node, and how often to use the newest node so they can roughly control the branching factor.

Anyways, all of this maze stuff is mostly working. I have just one kink to iron out, which is that I need to figure out a way to properly link all the wall tiles so that field of view works when I try and fix wall artifacts. This turned out to be trickier than I thought, but should be doable. Next week’s goal, besides correcting the wall bit, is to take these mazes, and instead generate room and corridor dungeons.

Hello World

Sun, 21 Feb 2016 10:42:52 -0700

Here is my first blog post! Starting with hello world seemed like the right thing to do… Going forward, this site will serve as the development blog for all things Rauko. Right now everything is pretty darn minimalistic so I am going to spend a bit of time trying to customize everything to my liking as I figure out how Hugo works. Once that is all done, I intend to write roughly once a week on Sticks and Stones development, as well as a few of the other side-projects I have in the works. You may also occasionally see other random content such as reviews of other games, thoughts on roguelike design, discussion about Go (my programming language of choice), and any other things I feel like writing about.

In the meantime, here are some links so you can see what I’ve been up to:

About

Mon, 01 Jan 0001 00:00:00 +0000

I am Jeff Lund a.k.a. Rauko. I am currently a Ph.D. candidate at Brigham Young University. My research has mostly been focused on topic modeling (the automatic discovery of topics or themes in text). I’ve also picked up quite a few other machine learning tools along the way. Along the way, I’ve had the opportunity to intern at various companies like GE, Lucid Software and Google.

This site however, is dedicated to all of my hobby coding and side-projects. Foremost among these projects is Sticks and Stones, a survival based roguelike set in the Stone Age. The dev blog on this site will deal primarily with work on Stones. However, the site will also have random articles and write ups of other stuff as I see fit. In any case, you can watch most of the work on this and other projects live on my livecoding.tv channel here: https://www.livecoding.tv/rauko/.