itch.io

Total lines of code: 3261

Of course it's now 2025 and still no demo release. Not to fear! Work continues on the game, which is technically tech-demo functional.

NEW STUFF:

- HP/Mana/Armor bar reworks: A lot of work went into creating animations for these bars in previous months. I was using Godot's built-in ProgressBar nodes which worked great until Syro (our graphic designer) and I started to work on replacing placeholder textures with new ones. Once I realized there were certain things I couldn't do with the built-in ProgressBars, I set off on a new, dumb crusade: to rebuild ProgressBars from scratch, both as a coding exercise as well as a design one. Spoiler alert: it's been like 4 weeks now.

Although the object itself runs on some pretty basic algebra (fill the bar up to remaining_HP / total_HP * bar.size.x - i.e., using basic ratios), creating the framework for it to run correctly, calculate correctly and graft it into the current code has taken a lot of time. This is one of the hazards of coding as a hobby, in that I probably waste a lot of time revising and catching up to previous days' worth of work. The object is also theoretically designed for different sizes, which can be set in the Inspector (THEORETICALLY, so that textures of different sizes can be used without altering the final, visible output). 

Included in this is my obsession for the "white overlay animation" bar, which is a white bar that goes on top of the progress bar to visually show how much of the quantity has been lost. I want it to be dynamic and exciting, plus a good way to tell the player where the damage is going. This also proved to be quite the trouble, as the original design was more complex than necessary (without providing great functionality) and required several reworks and downsizing before it started falling into place.

As far as coding and design practice goes, this was a keeper!

MAJOR BUG FIXES:

- Hard to count, at this point. I don't count bug fixes to currently-being-implemented code, as that's just part of the creation process.

PLANNED ADDITIONS:

This is the exciting part.

- Placeholder replacements: Working with Syro, the graphic designer who did most of the UI elements in BB-Breakout, to create the UI textures which will replace the current fugly placeholder art. Other exciting prospects include a more consistent visual style, creating a workflow for creating new graphics which mesh with the future style, and reducing the amount of future work by improving on design processes.

- The Savior Trainer tech demo.... coming soon?

Total lines of code: 2845

More polishing for the concept demo release. The end of the year has been busy for me, as I'm sure it has been for everyone else, but work continues to steadily happen. I've spent a lot of time with debugging which has been an eye-opening experience - I'm sure I've mentioned this before elsewhere, but it's incredible to think of how much time and effort can be saved through mindful, effective design; however, being able to design skillfully requires skill in the first place, which is what this endeavor and each one before it is all about. Practice makes perfect and, without further ado, here's a list of changes.

NEW STUFF:

• Cooked up some instructional screenshots in lieu of an actual tutorial.
  Feedback improvements: cooked up an insufficient Mana warning icon that is overlayed on player actions which require mana and for which the player may not have enough mana to cast. Since players recover mana through Downstating, and Downstating can happen if clothing is damaged in battle, the player is technically allowed to queue up actions which they may not have enough mana for at the start of the turn. But if they either queue up a Downstate or once they are hit and they go through a Forced Downstate, they will then have enough mana so I want players to have the chance to queue up whatever they want, but to be aware that their attack may not cast.
• Feedback: created and added banners to announce when it's the Planning Phase (picking your attacks), once player is Out of Actions (all action circles used) and during Execution Phase (attacks being carried out).
• Feedback: improvements to text feedback during combat to improve clarity regarding who hit who with what and for how much.
• Auto-Resolve Turn When Out of Actions: after many days of bugfixing the combat_processor mana / action_circle deduction logic, I realized I added a check to determine when the player has used up all their available actions. So a light went off in my head: what else can I use that check for? Opening the Options screen now includes a toggle for Auto-Resolving a turn when all actions are used, which can speed up battles for players who don't feel the need to review their actions (and is just a cool feature to add anyway, hadn't even thought of it until I had this new tool in my hand).

MAJOR BUG FIXES:

• Environmental processor: Huge fixes to processing / loading logic, which were previously incorrectly allowing players to skip certain locked locations without having the appropriate world_flag.
• Buff / debuff effects, which are temporary increases to player or enemy stats, were being calculated correctly (after the infinite buff exploit was fixed) but were being reverted within the turn on certain circumstances. Since they are meant to last for a full turn, redesigned their logic so that they correctly store and modify stats as necessary and only release at the end of the turn. Also, fixed them using the incorrect target when calculating stats (oops).
• Save / load data now correctly works on export versions.
• Mana calculation fixes: definitely a design mistake which took its toll on the amount of hours it took to fix. Long story short: by the time I wanted to add the Insufficient Mana warning icon, I realized that mana calculations were being made in up to 4 separate instances: when running an effect, when releasing an effect, and in two separate calculation scripts at the entity level (check_for_bundle_costs and individual_costs). I consolidated all mana reductions within a single function which runs in the combat_processor and eliminated all other instances. Previously, enemy mana was actually being "invisibly" spent during the Planning Phase because that was the system I used for enemies to choose their next action, based on available mana after using the previous attack. Now, calculations are made separate from the spending which is cleaner, clearer and less prone to fuckups (like enemies ending up with -19 mana because of canceling -> requeueing stuff). Enemies and players also now calculate mana using a unified, planned method instead of haphazardly like I was doing before.
• Effect tweaks: revised code including undoing any extension of effects upon effects (ie, Strong Attack no longer extends Normal Attack) so that cost calculations are clear. Effects now load their costs upon creation instead of upon being added to the tree, which squashes a ton of bugs around invalid properties on 'nil' objects. This, in turn, fixed bugs which were happening when using effects with action_circle_cost > 1.
• Lots of fixes to collision_shape sizes and node positions which, although not critical, caused unexpected behavior with the tooltip code. Most importantly, the fixes are made at the script level which mmeans that all future additions in these cases should align correctly instead of requiring individual tweaking.
• Redundant code: removed a shitton of redundant code including aforementioned mana deduction calls.
• Simple but effective changes to turn logic, especially re: stopping players from processing a turn when the turn hasn't fully started yet.

PLANNED ADDITIONS (AFTER RELEASING CONCEPT):

• An actual tutorial. :P
• Character creator: a separate module which can attach to the DungeonCrawl code and exchange information with it. I plan to have a point-based system which will allow players to allocate them to stats, equipment and skills. It's meant to be the demo / initial phase of a larger game system upon which the DungeonCrawl will function.

Here's a fun fact! While going through my notebook to see what I've been working on since the last devblog, I read the following phrase: "I really want to put the demo out there. Maybe it's time to stop pushing it off and just do it. Can keep working on it in the future."

It's still true and it's still pending, but here's hoping for a December release!

Total lines of code: 2648

Working through November has certainly been challenging. A lot of fine-tuning, fixing bugs, revisiting half-finished ideas and getting the demo to a playable state. If you've ever developed a game, I'm sure you're familiar with the concept of fixing something only to find two more things that require your attention, and that's certainly how this has felt (reminds me of that episode of Malcolm where Hal goes to fix the kitchen lightbulb only to find the light switch is malfunctioning, then going to fix that and seeing that a cupboard door is squeaky, then going to fix that and... you get it).

The "end of October" release date for the tech demo has now been moved to "end of November". Feature creep is unavoidable but putting a milestone at this stage of development feels like a necessity to begin working on other aspects of play. Once the demo is out and people (hopefully) play it and produce feedback, I look forward to many more rounds of feature creep / reworks to come.

NEW STUFF:

• Game now recognizes the player dying and there's a game over screen with a restart button available.
• A gallery has been added that stores pictures which didn't make it into the actual game but that have potential to be useful for something. At this time, this accounts for ~60 something images. The gallery is dynamically generated, so future images can just be dumped into the gallery folder without me having to do any more work to display them. This is light-years away from my previous gallery attempt in BB-Breakout, where every single button for every single image and every single script was hand-made which was extremely time-consuming. The gallery is also pre-loaded with the game, as the first iteration had a minor-but-avoidable ~2 second load while all the images were loaded for the first time (based on one of my first tutorials which showed how to preload particle effects to avoid hiccups in game, like in BB-Breakout's ball particles).
• Added and reworked combat feedback to be able to show color and sound. So, suffering damage is now associated with a certain animation (eg, the player portrait flashes red) and the code calls an appropriate sound to match the attack. Every entity (player/enemy) now has an enum_type which designates it as a Player, Monster, etc, and I have added sounds to be picked from randomly when they're hit. The sounds were sourced from Freesound and, like everything else, are a WIP.
• Options popup, currently includes a volume slider that manages the volume for the Master bus (my first working version of one!).

MAJOR BUG FIXES:

• The infinite buff bug is now actually fixed with a solution which, in my head, was going to take 5 mins and ended up taking up a whole morning.
• Previously, exporting the game caused it to lose track of pathing for custom resources and images. The code has been fixed so that pathing doesn't break on exporting any more. As a sidenote, I run into this problem every time that I want to export a new project and, while I understand that appending .import and .remap to stuff is important in some weird way, this seems to be one of the most ubiquitous and nonsensical problems for Godot to have. Anyway.
• Player can no longer interact with environment items during battle (don't access the endgame stuff before killing the boss, cheaters) ((jk, I haven't added the endgame screen yet)).

PLANNED ADDITIONS:

• Save/load data needs to access user:// instead of res://.
• Planned actions should warn player that they do not have enough mana to perform this action, but still allow players to queue it in case they have also queued a downstate or are about to receive an attack which will force them to downstate. Idea: downstates from enemy attacks only recover 50-75% of mana.
• Saving my future ideas in a centralized location instead of scattering little post-its everywhere between .txts, my notebooks and these blogs.
• Some kind of tutorial in the form of in-game images or screenshots showing how to play / what the buttons do.
• Some kind of endgame scene to let you know that the demo is, in fact, over and that killing the Succubus means you saved the world.

Hey, thanks for the comments!

Paddle speed could certainly be changed but I think it was part of what I considered to be the "difficulty" of playing the game, which is hard to balance when the modifiable variables are pretty much 1) brick placement, 2) ball speed and 3) paddle speed. I'm not saying I did it right, just giving you an idea of why I did it the way I did it.

I agree that there's a lot of features missing which I would've loved to add, but wasn't yet good enough at coding to implement. I remember thinking of power-ups dropping from destroyed bricks but not even knowing where to start putting it into the game.

I guess the best way to explain it is that, because of the way I coded the game, changing one thing means that I have to change a lot of other things because a lot of it is String-matched or hand-placed, and a lot of scripts reference each other in spaghetti-ish ways. On a more positive note, I learned a lot during the development of BB-Breakout that I would improve on in later projects.

Thanks again for trying out the game and also for the feedback! I'm happy to hear you enjoyed the art! These past months I've been practicing and working on a bunch of other projects, one of which I'm preparing to release a demo of soon, so I hope you keep an eye out and try that one too!

BB-DungeonCrawl is coded from scratch in Godot.

As of 11/3: ~2200 lines of code (it's certainly growing!)

So this is another bit of a lengthy post that I'm going to try and keep short, but there's only so much I can do while trying to summarize what I did during October! For this post, I'm going to write down some thoughts on general game design, my growing pains with building the game and things like that. Further down, you can find a more organized structure for key changes, bug fixes and what I plan on working on next.

October was tough in the sense that a lot of the systems were in place, at least in a very primitive manner. So equipment for the player, including stat bonuses (boni?), is available - however, there's no pictures to go with the armor, there's no damage to it or ArmorPoints, and no interactivity. Effects are in (see the previous devblog where I talk about Commands)  - however, you can attack, double damage attack and heal, which seems limited for a game with 1-on-1 high-stakes combat. Environments were in and it's possible to navigate the "map" - but there's no way for me to lock a connection, or any coding for something like a traproom, and 90% of my "map" content is empty rooms.

So, even though I promised myself I was going to focus on content with the goal of releasing the functional tech demo at the end of October, I ended up not working as much on content as I did on improving old systems.

Environment Processor

The environment processor was a big undertaking and a massive leap forward in terms of functionality. Data is now added to the environment custom resources such as the sound the player hears when they enter this room, whether this room has been explored or not, and what other environment_resources are linked to this room (ie, exits, where does this room lead to). The environment_processor keeps a copy of all the rooms and is able to reference the data while the movement buttons are being generated, and therefore can change an exit name to ????? if the room hasn't been explored yet. Defining exits at the individual resource level also allows me to fine-tune how different rooms link together. Here's an example from the game:

First of all, remember this is a "virtual" map; there's no physicality to the rooms themselves or to the exits, only an arrangement defined by me; what I mean by this is that, if I wanted to, I could connect the basement to the moon because there's no actual distance between the two. Behind House is a room in the outside of the house. This room can be accessed from the Pathway to the House (aka the starting room), as well as from the second floor Balcony, and also from the Living Room. These are all meant to be plausible exits by the way, so I want them to make sense. Conceptually, you would have Pathway -> Behind House which is just walking (cue gravel sound and call it a day). You would also have Balcony -> Behind House, and this one's trickier because you can't climb from the yard to the second floor, but you can certainly jump from the second floor to the garden (now there's an HP cost to traversing this way). Finally, if you're inside, you should be able to open the living room door and simply walk to the garden - but if you were in the garden and trying to walk inside the house, you might find the living room door locked from the inside.

Each of these situations requires a different approach. The code needs to be simple enough to allow me to connect rooms easily and without having to define all these little variables if I don't need them. But, when I do need them, I need to be able to tell the game that jumping down from the Balcony costs 5 HP and, by the way, if the player can't afford it, make sure to stop them. A door might be locked, but is it locked from every direction that you enter it from? The Living Room is locked if you're coming in from the garden, but it wouldn't make sense for the Living Room to also be locked if you're entering from the Kitchen.

That level of granularity made the environment_processor into a significant challenge but also elevated the navigation to a new level, where the map itself can be a part of the survival aspect (rather than just speed-clicking the rooms in a straight line to the exit, which you could do before). There's additional functionality to change sounds depending on the particular exit (so, gravel sound if walking from pathway to garden, but falling sound and THUMP if going from Balcony to garden). To signal the player about these environmental challlenges, the env__processor also displays a "locked" icon if an entrance is unavailable, or a "danger" icon if there's an HP cost to the player. And, as I mentioned before, simply leaving all the details blank tells the script not to worry about it and leaves all the defaults on. For me, it's a huge win.

Effects

In case you missed the previous post, Effects are my version of entity-agnostic, modular objects which can be attached to the player or the enemy to cause something like damage, or healing, or buffing/debuffing, etc. They essentially started as a proof of concept kind of thing ("would it be possible to use the same damage object for both the player and the enemy to save me work?") and evolved to be an integral part of how combat is currently managed, what with being able to queue up actions, cancel them, process them, etc.

From one point of view, it was all about growth for effects. Started out with DamageEffect and expanded into Heal, StrongDamage, ArmorPierce, Buff/Debuff, and so on. Having different tactical options for different situations seemed like a natural fit for my kind of game, where combat is meant to be deadly and unforgiving and ignoring the enemy's defense on a critical round may be the difference between walking away with low HP or none at all.

However, there were other changes to the Effects system which ended up needing reworks at the combat_processor, which is the node that handles all combat logic. One of these changes is the action_circle_cost, aka how many actions does an Effect require to be queued. I had already added action_circles (ie, actions within a turn, depending on your speed) to the game and did a lot of coding around that early version - for instance, when using the cancel action button, your last queued action is removed and you are given a single action_circle back so you can queue up something else. But now, with different effects having different action_circle_costs, the code has to be rewritten in a way that identifies how many action_circles to return to the player. Before, enemy actions were deleted 1-to-1 with the player's, but now the code has to behave differently because player and enemy actions are not necessarily matched 1-to-1. All of these little things require constant revision and rework (and it would all be much better if I just designed everything perfectly from the beginning), but the "final" version is always satisfying to see in motion.

Armor Points

Before yesterday last week, Armor Points didn't even exist. This is meant to be an HP system for armors/clothing which absorbs damage for the player and, when damaged enough, come apart to become more powerful, less defensive and more interesting to look at :). Conceptually, all armor has 4 "states" of damage (think undamaged, low damage, high damage, broken) and every state has its own Armor Points to absorb damage with. So, for example, if the Psychic Robe has 3 AP, it has 3 AP for every of the 4 total states, which means 12 AP total. Every time you cross one of the 3 AP thresholds, a little bit of the robe comes off.

Compared to prior to this rework, where all damage goes directly to HP, a lot of the logic has to change! The player's take_damage formula hahd to be rewritten so that AP is damaged before HP is, which means keeping track of the current state of each specific armor and its AP. And what happens if an enemy hits for 5 damage, but there's only 3 AP left? Should the rest of the damage just fizzle out? No, I want that excess damage to hit the player's HP instead. Oh, and don't forget to call the function to break the armor when that happens! 

In the future, I plan to add bonuses to the armors depending on their state. So, for the Psychic Robe, "undamaged" state might provide +1 ATK, and "broken" might give you the ability to use the DoubleDamage attack, but leave you open to attacks because you have no AP left. I think it can add an interesting nuance to combat and how resources are managed, which should be challenging, which is the direction I see the game going.

NEW STUFF:

• Armor Points added, armor will now absorb damage and break.
• New effects added including buff/debuff stats and Armor Piercing damage.
• Attacks can now use mana as a resource, or cost more than one action per turn, or both.
• File structure reorganization, matters only to me.
• 3 armors with pictures added (Psychic Robe, Shirt + Skirt, Domina).
• Basic, if tardy functionality, such as an Escape Battle button.
• Enemies can now drop items if defeated in battle and the player doesn't have the item.
• Placeholder game over screen that allows player to restart the game instead of having to reopen the game.
• Max mana is now determined based on the armor being worn, making decisions around armor more significant.

MAJOR BUG FIXES:

• Buff stats can be used to buff stats infinitely (unfixed, but found :P)
• Armor states not being tracked separately by armor (ie, damage to one armor was affecting all armor).
• Custom resource data not being saved along with character save data.
• Text window / combat log overflowing, there should be no occurrences of lines being hidden unless I screw up again and add a newline where I'm not supposed to.
• release_effect (code used to delete an effect and return all affected stats to normal, such as in the case of buffing) now differentiates between effects being used vs canceled so, for example, mana is returned when queueing an attack and canceling it.

PLANNED ADDITIONS:

• Encounter bar rework. Once a threshold is reached (x amount of encounters? x amount of levelups? x amount of rooms explored?), enemies receive bonuses.
• Finish Armor rework to provide bonuses per state.
• Make all equipment significant, the way armor currently is: each armor has stats for how much mana you can have, how much AP it provides, stat boni, etc, which means that choosing one armor over another should be something to think about. I'd like for weapons and accessories to be similarly important: for example, weapons might give you a specific skill that's unique to that weapon. Or they might have customizable slots which the player can add different boni to (kinda like a Materia system).
• UI improvements so that shit isn't in the wrong place, the wrong size, or unaligned (ugh!).
• Rebalancing enemies to account for the new Armor system.

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!