Mistakes made within the whole scope of creation of Luminaire

Scope
Initially started with a scope too big. The game chosen to emulate had a very large scope for an old game, although it seemed doable, being a single person coding the project, what seems small can be a huge undertaking.

I had a fear of reducing the scope mid-project due to the possibility of causing confusion on what I was working on. When I finally did reduce the scope near the end of the project, this was not the case at all, in actuality, it was the opposite.

Visuals & Graphics
Doing graphics, adding TIMELY effects, and aligning visual elements accounted for almost 50% (or even more) of development time. Although I tried to save the majority of the visual work for the last half of the project, I still spent a considerable amount of time tweaking it and chasing bugs.

When doing the initial write-up and scoping, take graphics/effects and alignment into consideration ASAP. Try to plan out coordinates, centers, x/y values and resolution values as early in the project as possible.

Mechanics
Even though I had a well-written mechanics guide for my inspiration game, doing the mechanics for the game was a huge challenge. There was other games of this genre I was able to find a mechanics guide for, I decided to emulate the more in-depth game. Even though it was hard, having this guide was invaluable. To keep in mind though, it had the forumlas the game used, but no actual code.. so of course I had to do it (mostly) from scratch.

These are smaller, more exacting issues and thoughts about particular mistakes and oversights I made.

Make a separate room just for story usage.
Room sizes should match closely to the amount of tiled "usable" space in the room, except when completely necessary.
Simplify any selector variables/objects as much as possible.
Use more functions - especially a room exit/enter function.
Use less objects and more sprites.
Identify all parts of an 'event' and code in anticipation of their implementation.
Use booleans whenever possible.
Set more flags and only do computational checking in as few lines as possible.
Keep variables as local as possible.
Sprites and objects share the same global 'depth' numbers
Setup debug room asap to test in, so half of testing time isnt getting to or "playing to" where you need to test.
Not changing the code for npcs/items in each different type of room, and using a few rooms instead of making a new room for each actual room.
Not using a single room as the fight room and just stacking whatever layer is appropriate.