Right now, Items and Tile Types are hard-coded. I would like to instead store this data in JSON files, which will be placed in a “/data” directory in the root of the project. This will make it easy to edit/add new items and Tile Types, and easy for myself and others to contribute to the project. There is a JSON plugin for Rollup that loads JSON files as ES6 modules. That would be a great tool to use for this issue.

Right now, if the game needs to temporarily change an actor's glyph, there have been two ways to deal with this. One, the change and reverting of the change are hardcoded (i.e. sentinels waking up). Two, creating a temporary private variable (_varname), store the current value in there, and change the current value (i.e. the old stun code). When its time to revert, change the current value to the value in the temporary private variable, and delete the temporary variable. The first method only works if the what the glyph is and what it changes to are constant. The second method is tedious to code and bug-prone. Furthermore, both methods would fail if I wanted to implement stacking multiple status effects (which I do). Therefore, the game code needs to support a new method. My idea is to implement a stack data structure to represent an actor's glyph. The top glyph in the stack is what is drawn to the screen. The game can push and pop glyphs from the stack to display status effects.

At the time of this writing, there is only one item: a wind rune that knocks enemies back two spaces. There are three more elemental runes to design/implement.
Here are my ideas so far:

• Ice Rune: freezes an enemy for X number of turns
• Earth Rune: creates floor tiles
• Fire Rune: (?) - maybe sets an enemy on fire, causing them to move randomly for X number of turns

When the player reaches the level exit, they only get a message saying “Multiple levels not implemented yet.” When the prototype for a single level is finished, the first thing that needs to get done is properly implementing multiple levels in the game. Since the player can’t backtrack to previous levels (assuming it hasn’t completely collapsed by that point), the game just needs to generate a new level when the player reaches the exit.

Diving in just coding and experimenting with whatever came into my head worked great at the start when I was just trying to make my game ideas into something tangible. The development of this project will be kept “””lean””” in order to be able to change and add new features rapidly. However, if I am not going to be the only person working on this project, there should be a reference for the Setting/Lore/Design Ethos/etc. to keep everything consistent (unless amalgamation of various genres/ideas/tones/ IS the aesthetic). This is especially true in the possible event in the distant future that I step away from the project.

Same applies for a coding style guide.

There is a lot of repeated/redundant code in collapser.js. It makes changing anything in regards to the Collapser involve a lot of bugs and/or a lot of using Find/Replace. Collapser needs to be refactored to make future maintenance and design changes much easier.

Hi! I was looking over your project and noticed here that you're using the argument passed from rAF as dT. I just wanted to let you know that what rAF is passed is actually a DOMHighResTimeStamp, essentially performance.now(). It's the number of ms since the document was loaded. I generally keep track of the last timestamp and calculate the delta myself. Just thought that might be helpful! Reference