February 04, 2020

Every year, I try to partipate in the Seven Day Roguelike Challenge (7DRL challenge). It’s a game jam focused on producing a playable game in the roguelike genre within a seven day period. I’ve done four of them by now, and this year will be my fifth.

Screenshot of the original Rogue

When I first got into building these games, I was in it purely for the fun. Building and playing roguelikes has long been a hobby of mine. Now, however, I see it as an opportunity to invest a lot of time into learning a new technology or building a deeper understanding of one I already know.

In this blog post, I’m going to be talking about my experiences with 7DRL as a whole and what my plans are for this coming year. The next one begins in just under a month (it’s Feb. 28th to March 9th) and I’m already ramping up!

Experiences from my last 7DRL

The last 7DRL challenge I participated in, Son of Yendor, allowed me to really dive deep into functional programming and state management with the Redux architecture.

I was later able to give a talk on this at my company, which was my first public tech talk at the time. The response was encouraging enough that I wanted to give more talks, and as a result of having that comfort / desire, I recently started a meetup in Rhode Island, which I’ve posted about before.

Incidentally, this project is the largest piece of code I’ve written for a noncommercial purpose and open-sourced, and it’s functioned as a great tool for people to learn about my coding style. Even though it was written under pressure, I feel that it’s high quality enough that I don’t mind it representing me.

Other things I learned

It was also an exercise in time management, a lesson in working through burnout, and taught me a lot about the value of a quick break. Some people take the week off from work to focus on getting a game out – doing that in seven days, even working full time, is at best a difficult challenge, and at worst well-nigh impossible.

However, I didn’t want to use any vacation time, so I kept at it while working full time. It was a 70hr+ week and by the end I was experiencing quite real mental and emotional burnout. I hated the game and hated coding. But I think this experience set me up for success the following year when I took two contracts simulatenously and was working 60-70hr weeks for about a month.

Anyway, I’m supposed to be talking about my plans for this year’s 7DRL.

Goals for this year’s 7DRL

My goal this year around is to build a better understanding of React’s underlying mechanics, and to build a complete and polished game with a great UI and fun, simple mechanics. To do this, I’m going to do two things.

First, I’m going to build a library to render roguelikes interfaces with React, inspired by Paul Henschel’s react-three-fiber.

Second, I’m going to attempt to codify and incorporate my learnings from the last seven years or so of game development into this year’s approach, both by writing about them and by planning in advance.

My most successful game was 2014’s “Impera”, a small roguelike where you advanced through successive levels in an arena, fighting opponents with different movement strategies.

The last couple of games since then have really suffered from scope creep and being a little too ambitious. I’m going to tone it down this year, and actually build out the core technologies I want to be using beforehand, as well as plan out the game as thoroughly as possible.

The rest of this post will be devoted to talking about my goals for this coming year. So, goals:

Extremely tactical, balanced, and tight gameplay

…it’s not enough for a game to be mechanically complete; that game must be balanced as well for it to be fun and to really “win”.

I’m not really worried about building a game with a particular large scope, like I was with Son of Yendor. Instead, I want to build a really tight game with as much replayability as I can squeeze out.

To that end, I’m going to focus heavily on content / mechanics rather than on features. Last year I made the opposite mistake and spent a really long time adding features working before worrying about how they factored into the gameplay. As a result, I had a game that had support for a lot of different features, but little to no content, and the features were not balanced in any way whatsoever.

It’s also critical that I keep the scope as tight as possible. I’ll probably be writing posts about how I do each of these things in the coming days, which will be great content for my blog. (One of my goals is to write a blog post every day for the next couple of years. While I’m not fully committed to that yet and won’t be until I land a full-time job, I’m trying to write as much as I can nonetheless.)

Learnings from last time: it’s not enough for a game to be mechanically complete; that game must be balanced as well for it to be fun and to really “win”.

Build a visually stunning game

I’d love to build a really pretty game this year. When I worked on Impera, that was one of my biggest priorities.

I can recall laying awake at night after going to bed, trying to think of ways to make it more visually attractive. To a certain extent, I succeeded, with some really pretty lighting and line-of-sight mechanics.

With Son of Yendor, I also had the chance to develop my UI framework a lot. So I’ll want to reuse as much of that as possible for this game, to avoid reinventing the wheel.

I’ll probably be writing some posts where I think about visual effects that I want to include, maybe even with some Codepen demos / sketches of different ideas.

Blog every day of the week

In the past, I’ve always eschewed blogging during the actual week of development, but I want to spend more time writing about the process this year, for three reasons.

First, it’s great content for my blog. As I said earlier, I want to commit to writing a blog post every day in the coming year (I’ll be writing a whole post about that soon).

Secondly, I think writing things out will really force me to think through any decisions that I make. Writing always forces me to think more clearly.

And last but not least, if I don’t write during this week, I never will — I’ll just forget the details and say “I’ll write about it next year”. Er, that’s what I did last time, and I don’t have a single development blog post to show for it.

Reuse technology from past years

It’s a common growth thing that as developers, we hate to reuse code that we wrote in the past. Whenever I look back at old code, I want to cringe. Not only has my understanding evolved since then, but industry tools have also improved.

For example, you can see in my code from the year before last for the Son of Yendor game that I was really hankering after some sort of typing security. TypeScript and Flow were beginning to be popular around this time, but I’m not really of the early-adopter mentality, preferring to wait instead for new languagues, libraries, and tools to become publicly popular before jumping on board.

Now, of course, I plan on writing this year’s game in TypeScript.

But, having said that, I really would like to reuse as much tech as I can from past years in order to avoid getting bogged down in implementation details and focus more on mechanics, content, balancing, etc.

I say that every year, of course, although I seem to have plateaued a little in my growth as a developer recently, finally, since looking back at my old code from two years ago no longer induces within me an urge to puke. Yay.

Open source more of my work

Finally, time permitting, I’d like to write more of my code in a way that will allow me to open-source it. With the addition of functional programming to my developer toolbox, I think this will be much easier than it has in the past.

Up until a couple of years ago, most of the code I wrote, algorithms included, was far too coupled to the rest of the application to be able to be pulled out and shared.

Now, however, writing all of my algorithms as pure functions will make it possible for me to pull them out much more easily.

Compromise in order of priorities

So, I doubt I can do all of the above things successful, so I’m going to have to compromise in order of priorities. Above all, I’d like to build a really FUN game this year, so that’s what I’ll be focusing on. It doesn’t matter how pretty the game looks if nobody bothers to play it because it just sucks.

And if I can’t blog about it every single day because it’s taking too much time and energy simply to write (I will be working full time throughout the week again this year…) then, well, I’ll give that up and just hope to get as much as I can written post facto.

Etc., etc. I’d like to compromise on goals in the order that they were listed in this blog post, so that even if all else fails I’ll at least have a game people will enjoy playing.

That’s all, folks

Next up: posts about the kind of game I’ll be making, experiments with visual effects, architectural plans (I want to experiment with some sort of Frankensteinian event-driven functional programming and entity component system architecture), and number crunching (I want to balance the game on paper as much as possible before playing it — yay data analytics, probability theory, and spreadsheets!).