Some weeks ago inspiration hit to see if a game like Darkest Dungeon could be a viable option for a solo dev, in an actual “hack & slash” situation (with tons of loot, modular characters, procedural generation, etc.). It was both an exploratory exercise, as well as some distraction from the ongoing (monotone) work (for a much larger project).
At first it was thought to try to stick to 2D, maybe use some trickery to make it 2.5D with paralax (or by adding depth to not restrict movement to 2 axis, thus making it look more like a platformer of some sorts, but with fixed camera), but that was quickly passed as the project shifted into more of an isometric view. At that point it was not clear if this could work well enough to be able to make a combat heavy game. Considering things like player rotation and how (“real” (3D) bone) animations* would pan out (opposed to having to stretch the model and make it "appear" as if underwater).
*The animations are 4-5x slower normal speed (animated at 60fps), to test how debuff effects (such as slowness) would affect the experience (not solely relying on reducing speed with less frames in-between). Also, restricted to using only 2 “axis” for each character (opposed to the common 6, 8 or 12, which could become cumbersome for every asset for the game if not pre-rendered and handmade).
It does not look like much, but it was surprisingly challenging to design, animate and (sort) of make it all work. A lot of iteration went into changing, reducing/scaling down the art (“flat shaded”) and animation (with the scalable jump mechanic for both motion states), as well as coming up with pipelines (fixing them) to streamline the process of asset creation: All in the name of being able to complete a design-to-final-product in a week or two (for a character per se). Furthermore, the goal was to make a more action oriented combat: Hence, the ability to walk and run with shield front or attack (the prior affects damage taken), or to be able to jump (the idea was to jump over traps).
Although, there is no UI (due to time constraints), it was envisioned not to have one or at least have one that has minimal clutter (hence the health indicator is the cursor for the player): More of an arcade-esk game, where interactions kept short (an example here would be to quickly equip items via the numpad). This could need some tweaking, as for one it is (still) difficult to see where the player is facing and the damage indicator is not visible enough; just to name a few mistakes.
That being said, the project was cut short due to recognizing how much more preparation would have been needed (by the end of it) in order to make such a project work, even for a tiny demo as this one, as implementing the AI and combat came to be. Hence the bugs of mis-registering hits, issues with turn directions, AI behaviors, (fast) collision detection, etc. All of which began to need more and more time to test, fix and implement (with workarounds, etc.); it all started to creep in scale, take up more and more time and precious mental state (speaking of the potential of months of full time work, with creating everything from scratch).
Bit hesitant to come to any conclusions, but probably, with a solid, scalable architecture (of which this tried to be, by relying more on data tables and modularity for example), the initial idea of populating the scene with assets (for gameplay and world) could work. Albeit, would need a lot more pre-production than once thought (even after having some experience with scalability with previous projects). The uniqueness of this 2D/3D mix gave it some extra spice to taste and be a formidable foe of some sorts.