7DRL 2022: Retrospective

7DRL is over. Most everyone has turned in their games. After several hours of last minute changes to improve balance, I submitted “You Are the Amulet” at the end of Day 6. This is the retrospective on the project; what went well, what went poorly, and what I will do differently next time.

The last map before the boss fight

What went well

  • Integration with Tiled. This was a last minute addition to the game engine, but I felt it was vital that I be able to play on nice looking levels. I didn’t finish Tiled integration, as it has some quirks, and the open source tile sets I was using had their own quirks. I would want to double down on Tiled for another project, and allow mixing tile sets in one map. Tiled supports this; my engine can’t handle it yet.
  • Trinket.io. I knew that having the game work in a browser would be important. I don’t think anyone has run my game from the command line, and I don’t know that anyone will. I hope the judges do. A lot of the decisions I made were entirely based on whether it would work in Trinket. They don’t seem to support sound or transparency. When I wrote my Layout Manager, I made sure I could switch between Trinket and Native layouts.
  • YAML. My decision to program the game in a YAML file that was executed by the Python game engine was a literal game changer. As it stands now, I could write an entirely different game just by rewriting the YAML. There’s some things I still need to put in the YAML, but that wouldn’t take long to do.
  • Level generation. I was planning to spend Saturday creating levels by hand, but I thought of a way to do procedural generation to generate Tiled maps and populate them with critters. The level generator just adds to the YAML file and added no new Python code, proving again how import YAML was to finishing this.
  • Pathfinding. I really like how pathfinding worked in the game. Advent of Code gave me the opportunity to really lean into it and make the proper choices of algorithm and stuff.
  • I thought the prologue screen went well. I think it tells you up front what the game is going to be like, and I think it looks graphically interesting. It was the first map I did for the actual game, and I think it clearly shows why moving to Tiled for map generation was the correct choice, compared to the maps I was generating before I integrated it. I haven’t even come close to unlocking all the cool things Tiled can do.
Prologue

What went poorly

  • Using Final Fantasy Tactics Advance and Chrono Trigger sprites. The use of these sprites means the game has gone as far as it can; any time spent continuing work with stolen assets is wasted, as there is no world in which I could release a game using them.
  • Using Python. I knew from the start that a successful game is a game that can be played in the browser. I elected to just stick with Python, as the engine I’d built to display isometric maps for Advent of Code was written in Python and I didn’t want to learn something new.
  • Memory management. The sprite sheets used for both the sprites themselves and the room tiles are duplicated in memory for each NPC and for each room. I think this is why Trinket.io crashes so often trying to load them. I was starting to implement a caching system, but it was not going well and decided to just remove half the levels and hope things got better.
  • Level loading. Every level is loaded at the start of the game. All the NPCs in all the rooms, everything. This was a huge mistake. Part of this is that I had no idea how I was going to create maps in the game until the Friday before the challenge started. I’d built in a lot of support for exits that would let the player move more conventionally from room to room, but I couldn’t integrate that with Tiled. The multi-map support it provides doesn’t seem to work with isometric maps.
Tutorial #2

What could be improved

  • Future projects will be in either JavaScript, ClojureScript or Unity. All produce games that can be played in the browser.
  • Trinket.io. The site just wasn’t set up for large projects. I could only seem to add images to the very first “Trinket”, there was no folder organization, the aforementioned tiny viewport (800×600) and lack of support for later Pygame versions was painful. It was there when I needed it after all the other options for running Python/Pygame games in the browser had failed, but I don’t think I’ll use it again.
  • Combat was one of the last things I added in the game. I’d toyed with maybe not having combat. Then, I thought I would just use D&D’s system. In the end, I just used a hit percentage chance for each weapon, and a damage, and a range.
  • Itemization. I’d started the game with the expectation that there would be loot all over the place that would give you a bunch of upgrade options. I cut all that content out of the design, so now the only item you can pick up is the Amulet. No armor, no curses, no unidentified items, none of that stuff. No traps, not much of anything. If I write another Roguelike engine, or continue with this one, I will put all that stuff in.
  • Isometric maps. My design goal was to write something like FFTA. I like the look, but getting everything positioned correctly and drawn in the correct order was a nightmare. I do think it makes the game look distinctive, in so much as anyone who looks at it and has ever played FFTA immediately identifies it. But, the free resources were lacking — there’s WAY more free sprites for orthogonal rendering than isometric. Heck, I’d have paid for a full set of fantasy-themed, animated sprites for PCs and monsters, but I couldn’t find anything like that.
  • It is possible to make the game unplayable through decisions made while playing the tutorial. One of the other devs mentioned this to me, and it is true. The second tutorial map, the last thing I added to the game, has severe flaws. If you don’t follow the Frog Knight’s instructions exactly, the Archer will expend all her arrows trying to kill you, and you won’t be able to use her to kill the Sprite, and then you can’t proceed. I should have added a switch to the room YAML that would turn off NPC attacks.
  • The game shouldn’t have tried to have a plot. I had a full plot designed, with lots of puzzle rooms, an evil Amulet trying to block your good Amulet, blahblahblah. The very first map should have introduced the central mechanic, and the entire game should have been centered on possessing NPCs to solve puzzles like some sort of weird Sudoku. OR, the game should have been a traditional roguelike, focused on items and combat. This hybrid I made isn’t the best.

There it is, for better or worse. The final game has been submitted. It has an itch.io page with all the details on playing it and getting the files for it, as well as some YouTube so you can just see me fail at finishing it (I have never finished it since adding the procedurally generated levels).