itch.io

Day 4 and Day 5 were spent revising the UI and the dungeon generation algorithm. Everything looks much better, though I don't like how long that took. The dungeons were far too linear, and now they aren't quite as bad. I've added several test rooms but it doesn't have enough game play yet that I think it's worth demoing. It's unfortunate, but I may only get 1 day of a demo. That said, tomorrow (Day 6) looks good for adding more rooms, items, and some monsters finally.

And, to Ekolis' question, it's a text adventure like Zork but with a bit more combat and the dungeon, rooms, puzzles, and items are procedurally generated. Combat was not a focus for me, so it probably won't be too interesting. I'm ok with that.

The puzzles won't be as elaborate as in some good text adventures (old or new) but at least they won't involve guessing the magic verb or phrase needed to solve them. It's more like you need to find one or more items and use them to get past a door, or pit, or a guard. Although the puzzles are generated safely (i.e., the item needed for a puzzle is never behind the puzzle's locked door) the interactivity of the game allows breaking them. So, if you're able to break a door, then it doesn't matter if it was locked or you never found the key. Breaking puzzles like that is not correct according to adventure games but it makes total sense for a roguelike.

I'd argue you can add procedural generation to the starting distribution of living cells. You could also vary the rules for living vs dead cells by a variable that changes depending on the 'level' you're at, or just randomize it's value each game. You could also add walls to the level that act like the boundary, and the layout of the walls would be procedurally generated. It would affect what patterns get created in potentially interesting ways but you'd need large rooms or spaces so that everything doesn't die off too soon.

For gameplay, I'd suggest the typical rogue goal of 'reach level X then leave'. So, the board could change in size or shape or number of living cells at the start based on depth, and the goal is to reach a certain depth. To change depth, have a cell that you need to reach which is the stairs down (and it's like a wall: it doesn't get created or destroyed, it just waits for the player to reach it). The player could attack other cells to kill them off, so that they can make their way safely to the stairs, but make sure that there is a rule regarding re-spawning living cells so that the player can't just clear the board and then leave. I'd also argue against the goal being to kill everything, since it might be trivial or impossible depending on the pattern created; having to avoid those enemies while

For last year's 7DRL I tried to write a text-based roguelike. I got hung up on the UI of all things and ran out of time due to life pressures, but spent some time over the summer trying to get the basic engine working.

This year I'm trying again. Using a modified version of the engine I wrote last year (i.e., actually making it a game) and a much simpler UI, I'm finally at a point where something resembling a game is there. It's the end of my Day 3, but honestly it's pretty good progress compared to other years. The game has a random dungeon of some sample rooms with lock/key puzzles scattered throughout. The generator is designed to pick random key/lock combinations depending on the room, so that will help with making thematically appropriate puzzles. The player has an inventory,  light sources matter for seeing the rooms, and can die from too much damage due to traps or wandering in the darkness. The game is winnable, in that if you can reach the exit room you're presented with a win message and a total score. Thus, it is 'complete' in a very simple sense.

Tomorrow the plan is to add more content (treasures, keys, locks, and rooms) and test that these things work correctly. There was code for wearing stuff, but I suspect it's broken. After that I plan to break the puzzle generator by adding loops to the otherwise perfect tree, alternate ways of getting past locks, and keys with multiple uses. Once all of that is in an working correctly, then I'll add combat. It's going to be simplistic, but varied item effects and ways of dealing with enemies should keep things sufficiently interesting.

Demo and screenshots are expected tomorrow evening, so that I have a few days available for feedback for those interested in playing it. 

End of Day 4. After fixing several bugs and adding some more content, progress is moving about one day slower than I'd like.

The goal is now to explore the dungeon, find as many treasures as you can, and then leave. A score is given for finding treasures, overcoming obstacles, and doing it quickly. A screenshot is below, though I'll pretty up the UI a bit more on Day 7. Although this is based on interactive fiction games, I'm not using console-style commands. Instead you click on the name of the object you want to look at, which gives a list of the things you can do with it. Clicking on an action will end your turn (I should probably indicate this with a different color).

Tomorrow (Day 5) is going to be adding more content, such as basic puzzles (lock/key) and traps. Then Day 6 is adding simple combat and attaching the generator. It'll be interesting to see how many weird grammatical issues will pop up with something so text heavy as this. I'm somewhat disappointed that combat won't be as detailed as I'd like, but I wanted exploration to be there too. I'm happy with how the UI works. It needs more polish in how it looks, but it works well enough.

End of Day 2 and not much to report. Work and getting sick took up most of my time, and I broke the UI while adding movement between rooms (because of course I would). There was progress though, and I know what's wrong with the UI but need sleep before I can fix it properly. Items can be picked up and monsters move between rooms (if appropriate), though interaction is still limited. Tomorrow I plan to fix up the UI problems and add a bit more interaction. That should result in something screenshot-worthy.

Thanks! Getting through the UI and basic engine are always the most difficult parts for me, so if I can pull that off soon then I should be good for the rest of the challenge.

Based on this discussion on reddit about the differences between text-based games (Interactive Fiction) and roguelikes, I decided to experiment with that topic in this year's 7DRL challenge. Also, my main RL engine that I was going to use broke last week when I tried to add better AI and I didn't want to waste time trying to fix it.

For the Mad Wizard's Maze, players explore a procedurally-generated dungeon with the goal of finding a set number of treasures and then leaving. The commands, UI, and interaction are all in the vein of Interactive Fiction (i.e., text-only descriptions of things, and an abstract space to explore). The procedural part is straight-forward, but I'm trying to make the game as content-driven as possible. This way there is greater opportunity for interaction between various elements to occur, and hopefully that will contribute to more of a roguelike feel. I plan to add other things that are usually not in interactive fiction but would give more roguelike-tactical opportunities, such as sensing nearby things (hearing enemies in adjacent rooms, or seeing light or fire to hint at the next room), different types of attacks, and a chance to evade enemies in a room for X turns so that avoiding combat to trigger a trap (or something) is viable. As I said, this is an experiment.

As my day 1 draws to a close I managed to get an ugly UI working and a basic structure for the game. Players can start a game, get a predefined location with certain items, and do some basic clicking on the UI to indicate what should happen. The next two days will involve making the basic actions and interactions work, which will hopefully result in a "complete" game (i.e., you can start playing, can pick up the only treasure, go to the exit room, and then win). Screenshots will come tomorrow, after the UI doesn't have a bunch of placeholder text everywhere.

I noticed the following bug. Go down to the next floor (falling or stairs can do this) such that an enemy has spawned beneath the player, then access your inventory as your first action. The game will crash as shown in the image below. I don't think it depends on your inventory, though I always have a full inventory at the time this happens. I'm assuming it's because there is an enemy beneath me, since it only happens sometimes when I start a new floor. I could also be mixing up the keys (as I often do in this game) and am actually pressing the wait key instead. Either way, I press a button that isn't movement and get the error.

Quick update

Thanks to the submission extension I was able to make an Itch.io page for this game and actually submit it to the contest! You can play it here.

Making the page was easy. However it took me a couple of hours to get my code to work properly online, due to problems with Node, the compilation process I was using, and poor resolution in the iFrame on the Itch.io game page. It works fine now, but there was extra time spent on getting those things working.

While adjusting the resolution of the game though I found the bug with the traps not working. It turns out that trips were not activating when they were hidden. Initially I created and tested traps that were visible (since it was easier to make sure they worked), then I added them being hidden. Sometime after making them hidden I must have changed the code that checked the conditions under which terrain or traps should be activated. This fix has been added to the game.

I still consider the game incomplete, for the reasons listed in my previous post, and I think it feels incomplete when played. Plus, saying the game is incomplete differentiates it from the others that were complete and submitted before the extension.

Day 7 (Sunday)

I am considering this a failed game. It is "complete" in the sense that you can go through the actions necessary to win (i.e., you can find the crown and bring it out). However, all of the intermediary pieces are not finished enough to my liking.

For example, I was only able to get the initial traps that I created working (spawning monkeys, rolling boulders, and falling floors). Yesterday when I changed the method for generating maps, those traps broke. I have been unable to fix them. So, the dungeon is generated with many inoperable traps.

That leaves combat. Melee combat works. The AI isn't particularly interesting, but what bothers me is that I never got around to adding ranged combat. In other words, you only wander around a mostly empty dungeon bumping into enemies that are blindly running towards you. I don't find that particularly interesting, and it's not especially innovative for a roguelike.

The parts that I wanted to experiment with I was unable to finish: the traps, and the item management. In particular, I wanted to see how the game could work with multiple characters going in and out of the dungeon, and needing to manage their food supply and such. Since that required a dungeon to explore, I thought I could use the traps to make it more interesting. The item management is complete, in that you can have multiple characters and switch between them to enter into the dungeon... the mostly empty dungeon.

As such, I'm bowing out. There is enough of a game here that I'm considering continuing it as a separate project (especially since I never figured out how to make a game page for it on itch.io anyway), but not enough that it feels like a complete game and certainly not innovative when it comes to roguelikes.

I thought this was a good run. In total, I spent about 48 hours on the game (definitely long enough for this contest) but by day 3 was really tired every day thereafter. I liked that the game was effectively complete halfway through and I was able to work on the intermediary content in the remaining days. I liked that I lost practically no time to fiddly administrative and management stuff, and testing JavaScript in the browser was really fast. This went far smoother than my attempts in C++ and even Java.

However, two things slowed me down. First, I wasted a lot of time on bugs related on the underlying structure. At least 6 hours were lost to just getting proper input, and I think around 7 to properly drawing to the screen, despite using a toolkit to draw and JavaScript for input (which is pretty simple as far as programming languages go). These were across multiple days (the input bug happened on 4 days!), so I could still progress, but in terms of the total time available it was far too costly. The prior code that I used as my starting point got me going quickly, but broke soon after I tried to extend it. I'll either turn this game into a library for me to use in other games, or look for another engine for next time.

The second thing was the main topic of the game. The part I wanted to experiment with for a roguelike required too much additional content. The scope was too big, but I couldn't think of any other way to do with. I had other ideas for a game at the start of the jam, but none of them seemed experimental enough or required a significantly smaller scope. Again, I wanted to experiment with something for this jam, so my ideas had to fit that desire. Unfortunately it didn't pan out, but there's always other years. Besides, there's already plenty of other entries to try out this year!

Day 6 (Saturday)

No itchio page yet since I spent my time adding some content and fixing bugs. The game is still stable, but I lost a good couple hours to one particular circumstance where the game would ignore user input and effectively freeze. Kinda annoying. It's fixed though. Two other major accomplishments for today. I got the resource management part mostly working, and it's good enough that I could leave it as is for the final project. The second accomplishment was adding a better level generator. It now uses pieces of pre-constructed layouts to arrange content. This makes it easier to create lots of variations of simple traps without the whole level feeling too samey. There may be some of that already though, so I may probably adjust it by shrinking the levels a little bit.

Tomorrow is some basic polish on the UI, add instructions, and whatever extra content I can fit in. It's not as complete as I would have liked, but I'm content with it. Below is a screenshot of the beginning, where you start off at a base camp with other explorers. My test explorer dies really easily and has no equipment to speak of, so I can make sure those parts of the game work properly.

The only thing I'm really disappointed in is how slow the game seems to run. I think that's just a problem with HTML5 games, and lack of using WebGL. It's not something I'm going to fix though (this is a turn-based game after all).

Day 4 / 5 (Thursday / Friday)

My workload was much higher than expected yesterday, so I used whatever free time I had that day to work on the game. Hence the combined update today.

Progress has been slower than I would like. The game is playable, can be won and lost, and some basic traps are involved: monkeys dropping from the ceiling to attack you, boulders flying out walls to crush you, and that's about it at the moment. The game is still very stable, and that's good, so it's just a matter of adding more content and making the room generation algorithm more interesting. The turn counter isn't working yet, so the hunger clock is missing. Although it's easy to add, I want to add more interesting things to the game first.

By tomorrow I expect to have a prototype playable on an itch.io page, so that I can spend Sunday (day 7) on polish and extra stuff. Overall, I have lost a fair amount of time to my usual suspects: refactoring, over-engineering of solutions, and having game ideas that are too abstract for a short game jam (i.e., the main mechanic I want to explore depends on too many other things already existing in the game). At least this game is more stable than my other completed 7DRLs, and the work flow went much better. We'll see how I feel on Sunday.

For now, I leave you with a current screen shot of me exploring a somewhat empty level, avoiding pressure plates that spawn monkeys.

Day 3 (Wednesday)

Got the item management system working, even if I'm only using some basic placeholder items at this point. This involves both items used by the player and items stored in an external base camp. The menus for accessing said items are there, though still very rough. Enemies are now walking around, and the UI was updated to display all of this. I'm content with the progress so far. Tomorrow is a day to add content, particularly traps, since the structure of the game is now present in its mostly complete form. Enemy AI is just random wandering, but I plan to reuse some basic AI I wrote for a previous game entry that chased and fled from the player. That'll be sufficient.

Whether the game will be finished successfully will largely depend on how day 4 and 5 go. At the moment, this could become a game that is complete but too shallow to be interesting. That's ok, since actually completing a 7DRL is a pretty big accomplishment given my past track record, but I'd still prefer an interesting game too if I can swing it.

Day 2 (Tuesday)

Didn't quite get the item management system working yet. To salvage what little time I had today, I focused instead on other parts of the game that needed work. The UI was changed slightly, and the whole game flow is now complete. The player can start a new game after losing or winning, the game can be won, and the levels are generated such that winning is always possible (for now at least).

There isn't much to show for this day though, which is rather unfortunate. My plan for tomorrow is to finish the item system, add some mobs so basic combat works (and the player character can die), and then show some stats for the victory/gameover screen (like how long it took and what was accomplished).

Day 1 (Monday)

I started the contest a little late, largely because I wasn't sure how much time I'd have again this year. Regardless of how things go, I thought I'd try my hand at another 7DRL. Although the timer said only 6 days left, I'm working from Monday the 5th until Sunday the 11th local time (EST; losing an hour to stupid daylight savings time). It seems to be within the contest time frame and is going to be 7 days for me anyway.

I'm writing this game in JavaScript, using the ROT.js engine. The beginning of this project involved reworking an earlier project I had started with ROT (attempting to merge some of its features with another JavaScript engine) so that it was simplified and streamlined for this much more simple game. My plan is to have a rather traditional dungeon crawler with more elaborate traps and some multi-person resource management. The basic ideas are laid out but I'm not sure how much fun they will be. We'll see in a couple of days.

By the end of the first day, I have completed a simple set-up. The player can move around a randomly generated dungeon, go up and down stairs, and open/close doors. This is actually a pretty good starting point, since doors and stairs are instances of a more generic method for objects that can be triggered by stepping on them or operating (e.g., pulling a lever). In other words, I have a framework for simple traps. Below is a basic screenshot, which I'll have to pretty up a bit by day 3.

Tomorrow I'll fiddle with inventory and basic items, and that will give me a complete prototype: player creates a character, character wanders around several floors of a dungeon, picks up McGuffin, wanders back through same levels, and returns to surface and wins. I'm happy with this plan because, unlike my previous attempts at a 7DRL, it means that the rest of the contest will come down to adding content and polishing the mechanics/UI. For day 3 I want to add the resource management part and the remaining parts of the UI. Somewhere in day 2 or 3 I'll add simple monsters, but I won't be focusing on them too much in this game.