I’ll be blogging about my progress in the 7DRL Challenge, but I don’t want to waste time during that week posting all the stuff in this post which can be done now. If you don’t recall what a roguelike is why you should play them, see these posts: Why Play Roguelikes? and Thoughts on Permadeath. If you are interested in this challenge, there is still time to pull it together! The week is March 7-15.
Where I’m Starting:
Part of the rules of the 7DRL Challenge allows you to use generic pre-existing graphics/algorithms/game engines/etc. To be fair to the finished game, you should cite these sources. Here’s what I’m starting from (for why, see the sections below).
I’m building the game in C# through the XNA/Monogame framework and using a module called RogueSharp designed for making roguelikes in C#. The main use will be data storage and drawing of the level. For a generic template to start from, I’ve gone through this tutorial. My game will take this sample game and (radically) modify it.
See the section Core Idea for how I plan to build my own map generation if there is time. If there is not time, RogueSharp also has a built in algorithm I will use. As for graphics, I’ve spent some time playing with pixel art and learning to do animation in Monogame.
I will redo every one of these during the 7DRL week, but I needed some practice so that I wasn’t going in both learning to do pixel art and creating the sprites on top of programming the whole game. This seems fair, because anyone that has done any art for a previous game will go in with more experience than the couple weeks of practice I got from this.
My game will be a traditional grid based movement (only up, down, left, right) and turn based (the enemies don’t move until you do).
I’m choosing to make the game a variant on the “One HP Model.” A pure one HP mechanic says that everything in the game has one hit before they die. This includes you. This makes the game similar to a game of chess. If you move a piece to where another piece is, this “attacks” and the other piece dies.
This turns the game into one of strategic positioning. As more and more enemies appear with various movement patterns, you must figure out places to stand where you will not be killed and a good order to kill the enemies.
Each game will basically be a sequence of increasingly difficult, randomly generated puzzles to solve (so it is completely different every time). Part of the initial fun is that you must work out what the AI movement patterns are for each type of enemy.
I will use a variant on this model that allows certain items to increase your health which will allow you to take two hits (I probably won’t go above two though to keep the pressure on). Also, most enemies will have more than one HP, but various weapons will still let you kill them with one hit. The details have yet to be worked out.
The core story idea is Theseus in the labyrinth who must find his way to the center to kill the Minotaur. I would like to implement a system where backtracking is impossible. In modern interpretations of the labyrinth, the surrounding area constantly changes. This seems like an interesting procedural generation problem and adds a layer of difficulty to the gameplay since you can’t just leave something laying around to go back for.
I want there to be a punishment for running instead of “solving the puzzle” and killing all the enemies, but I also want the game to be winnable if you do this a few times. This will be a delicate balance that may not get worked out in a week. One easy punishment is to have a basic leveling system.
If you don’t kill the enemies, you don’t get the experience to level up and get stronger. This means that maybe later you need to hit some enemy a few more times making the strategy more complicated. The labyrinth design will also help balance this by not allowing the player to skip something too hard until they are stronger to go back to it.
I also want there to be time pressure. The game would become too easy if you could indefinitely re-position until you get a line of enemies to take out one at a time. There will not be a “hunger clock,” but I won’t spoil how this will be done right now.
What I Hope to Get From 7DRL:
I made a 7DRL before (well, it wasn’t done during the 7DRL or over the course of 7 days, but it is similar in size and scope). I built all the algorithms, data management, procedural generation, game engine, and everything from scratch. I did this to learn how all these pieces worked and interacted together.
I’m proud of the end result, but it isn’t very pretty. I used standard ASCII characters for graphics and made lots of stuff way too slow and clunky. I used python and pygame to do it. This caused lots of distribution issues because of dependencies and python versions.
Because I’ve done the inner workings before, this time I want to focus on some other aspects. I have no problem relying on a pre-built engine (monogame plus the tutorial), pre-built algorithms (RogueSharp), and so on. I want to get graphics, animation, and sound into the game. These are all things that were wholly neglected last time.
Day 1: Get a level displayed, redraw some sprites and get those displayed. Best case scenario, I can move through the level and once I’ve cleared the enemies I trigger the win condition.
Day 2: Solve the labyrinth procedural generation problem (i.e. put in multiple “levels”).
Day 3: Items, armor, weapons.
Day 4: Put in the rest of the enemies and start tweaking movement patterns.
Day 5: Catch up on days 1-4. If there is time, make a start screen, win screen, lose screen. Play for balance issues.
Day 6: Sound + animation.
Day 7: Debug + balance.
Most days I’ll try to update progress on this blog. On Day 5, I’ll probably want other play testers if you are interested in giving feedback.