Warning: this is a lengthy post since it pretty much summarizes the first month and a half of work. It's actually a shorter, edited version of the original .txt!
BB-DungeonCrawl is coded from scratch in Godot.
As of 9/29: ~1500 lines of code (subpar way of tracking game progress because there's constant refactoring / rewriting, but it's something!)
BB-DungeonCrawl, aka Blobber Prototype, aka Main Window Project, is an attempt to design a "blobber" (first-person, party-based dungeon crawler RPG) in the vein of old-school games such as Eye of the Beholder, Might & Magic, Wizardry, Ishar, early Shin Megami Tensei releases, Rance, etc. It's missing a lot of familiar concepts which may seem integral to the blobber experience (party system, minimap, directional navigation), but it also brings together a lot of ideas which I had never attempted before. At the time of writing this journal post, I have worked on the game for ~1.5 months and it seemed like a good time to look back at the original concept and how it has grown since.
Similarly to previous, unreleased prototypes (such as BattleBodyguard, the overworld party-based TRPG project), the premise for BB-DungeonCrawl began with the design of a simple interface and later attempts to include further functionality and cool ideas. This is also why there's so much placeholder art; I didn't want to spend tons of time making UI graphics while there wasn't a game to play. This has helped me spend more time writing sub-par code and less time making sub-par art.
The titular MainWindow was meant to provide as much information at once as possible and looked very similar in its original form to the current version. Player and enemy portraits dominate a large section of the screen but other permanent fixtures include a text output window, sections for player/enemy stats, a permanent tooltip for hovered UI elements, a view of the environment (aka, the room you're in), and movement / action button sections.
Because a lot of early work went into designing and organizing the MainWindow, I didn't really delve into systems design until much later. Therefore, the early code included a lot of fluff which wouldn't make it into later stages (eg, a more complex and abstract 4-stat system compared to the current ATK/DEF/SPD iteration). Similarly, a lot of the custom resources that I created to manage my systems go through similar phases of creation, realizing I should've done it differently, reworking, and repeat.
A weak initial design phase coupled with lots of time spent in rework sounds like a waste of time in retrospect, but I also think it's simply a part of my learning experience with coding. Looking back at when I started coding in January 2024, there's virtually countless improvements in coding habits (omg comments), architecture, connectivity, etc. The previous project which I mentioned earlier, BattleBodyguard, had four different Autoload scripts (aka singletons) which I was using to store / retrieve info, resulting in an extremely disorganized structure and so much redundant code. Meanwhile, one of the coding goals for DungeonCrawl was to maximize direct connectivity between nodes to avoid having "intermediaries" to communicate between them; one other such goal was to minimize the use of string matching to reference anything which could be directly referenced as an Object, which went a long way towards reducing bloat and minimizing avoidable errors (oops, misspelled "lagartija", now the whole game doesn't work). It also enabled me to improve on my debugging process, as it's much easier to find exactly where in the code there is an issue (BattleBodyguard is now essentially dead in the water because, somehow in the transition from Godot 4.2 to 4.3, one script was corrupted and I can't figure out how to salvage one part of the project without it).
Other coding learnings include developing dynamically-created objects and the logic to populate them with minimal supervision. As an example, I had a great time designing and implementing the tooltip system, which only requires nodes to be a part of a certain group and to have a custom_tooltip String written for them. Meanwhile, the code detects where the object is, determines its size, creates an Area2D and a CollisionShape to match the object so the player can hover over it, and manages the custom_tooltip automatically. Compared to my only released project, BB-Breakout (the result of ~2 months' worth of following Godot tutorials) which had every single object manually placed and scripted, this saves hours upon hours of work!
Making objects modular (or more independent, at least) and scalable has also critically improved code readability, which in turn has allowed me to significantly refactorize chunks of code without going crazy or breaking the project (or both). In fact, DungeonCrawl is the first project in which I've been able to rewrite critical game functions without breaking the whole thing, and this has been so important because of all the rewrites / redesigns I have implemented as the project becomes defined over time.
Some of these rewrites include the combat system, which evolved from an extremely simple first version. Initially, I only had an Attack button and pressing it would cause the enemy to lose x damage and the player to lose x damage (essentially, a Godot version of going on your calculator, starting from 10 and substracting 1 until you hit 0). Eventually, I would settle on a mix of ideas which are the current combat system: queuing multiple actions per turn, being able to see what the enemy plans to do and canceling actions according to the challenge. The whole thing is a coding Feat of Strength, if you ask me. Implementing it required my first working attempt at a Commands system (as tutorial'd by SelinaDev here and referenced here), Objects which could function independent of the owner nodes and which can be called upon from various sources in interesting ways (eg, the Command that currently processes trap damage from entering a trapped room is actually the same as taking damage from an enemy, with a flag to ignore Defence). The new combat system then required scripting which would form the logic for starting a turn, checking player and enemy intentions, processing the correct Commands, allowing the player to see what Commands were queued, canceling Commands if desired, and eventually processing the whole turn in order (all of this without breaking the game, which I did a bunch of times). A lot of rewrite work involved figuring out how to store and access the data, as well as where to place and how to display both parties' turns. If you can theorize on how you would implement a turn-based system with multiple actions per turn, I'm willing to bet that your version of it would be quite different from mine; however, mine works and major bugs have been squashed, and this alone makes the whole endeavor worth it and super satisfying.
Effects, aka my Commands system, would also grow quite a bit in scope and functionality. While I originally started with just a DamageEffect, the system now encompasses more tactical decisions such as healing, dealing double damage or armor-piercing damage, buffing or debuffing stats for yourself or the opposing party, and even undressing (for gameplay benefits, of course ;) ).
Another redesign highlight includes the equipment system, which currently includes the ability to change equipment (which in turn changes your stats and, in the case of armor, your portrait pictures), finding equipment either as an item in the room or as a drop from enemies, among other things. Also a coding milestone, my first inventory/equipment system runs on minimal String matching and on my own custom resources for equipment slots, equipment items and custom interactable buttons to allow the whole thing to work.
To bring this post to a close, I wanted to expand slightly on design paradigms, which is what I would call the essential rules by which I am trying to design the game. One of the first paradigms which I wrote down on my notes was, "the game should strive to be as responsive and fast as the player is able to interact with it". I personally dislike games which hide critical functions beneath layers and layers of menus, especially if it also involves watching fluff animations. Ideally, I'd like as many functions and information to be readily available from the main screen such as stats, equipment, etc, and this is currently how the MainWindow is designed. I also plan to include hotkeys to be able to quickly queue up actions or interact with the gameworld, allowing the game to be played with KBM and offloading a lot of the point-and-clicking, if desired, to keyboard shortcuts. This also led to the implementation of an animation speed toggle (instant vs. not), where combat anims are speeded up to be almost instant but can also be slowed down to see what's happening in more detail. This all changes relatively automatically and can be adjusted centrally so that I don't have to go through every. single. animation. to adjust their timings individually.
Finally, the other paradigm that I'm currently trying to live by is that "gameplay should come first". While it's fun to play an adult game for its artwork or story content, I enjoy such games a lot more when there is a fun gameplay loop attached to it. Some of my favorite eroges include Kichikuou Rance, Sengoku Rance, and even Big Bang Age, which have meaty gameplay systems which elevate the whole game to something more than just porn. Unfortunately, I not only have limited coding experience but also game design experience, which makes the whole idea kind of hard to pursue. But, as the game grows and systems start to fall in place, I think that there is a good chance that the project as a whole will find its footing or, in the worst case scenario, give me a better idea of what kind of game I want to create and how to achieve it. I think this is probably the worst way to go about it, kind of like building a house by nailing wooden planks together and seeing if they resemble a wall, but I also think it's the only way to go about it when you're just starting out, which I am.
Thanks for reading!