So, it turns out that my recovery time for doing a gamejam over a weekend is a bit longer than I thought! That sort of threw me for a loop, and I was running especially low-energy by the latter half of the week. Add to that, there was some sort of less-glamorous-but-necessary tasks at my dayjob and I was pretty exhausted.
I realized I'm still not back up to full energy to write more assembly code. But I worked on something new... that's potentially for an old project! I've started working towards implementing a battle system mockup, that I could use for "nrpg", my NES RPG described earlier on in my posts here.
I had originally wanted to maybe do a turn-based RPG that's fast to navigate and has quick rounds. But about two weeks ago, I had a different idea for a completely different kind of battle system, with realtime elements.
I was thinking about a possible design for a "shmup RPG", with the following:
- real-time action resolution, like an action game (shmup, sidescroller, etc).
- simultaneously command multiple units with an always-visible menu bar at the bottom that has 4 secitions:
- party actions
- (??) autobattle
- (??) special team actions
- run away
- actions for party member A, B, C
- basic attack
- items - shared inventory. consumables, infinite use relics.
- (??) actions can be interrupted up to their execution, and possibly during the execution of held actions.
- each unit has a high-level state related to command progress:
- awaiting command
- moving into position (either a position relative to target, or an absolute position)
- charging (if applicable)
- recovery (if applicable)
- each unit also has the low-level physical entity with its own state management. These states are things like:
- moving to target
- basic attacks
- different phases of magic / special moves being performed
- hurt reactions
- entities move around in real-time according to these commands.
- positioning matters (although movement is automatically controlled by simple AI)
- simple pathing, no collisions/walls in the middle of battle arenas, so no need for A* or something -- simply move in a direct path to the target.
- attacks have designated ranges + targetting logic
- animations could have attack/hitbox and vulnerability/hurtboxes that affect the collision
- projectiles are spawned and move in real-time
- evasion stats that could apply upon either incoming attack proximity, or as a last-minute reaction roll to a projectile collision.
- timed reactions that can be selected from the menu as an enemy
- would probably need a streamlined menu interface to really make this work, potentially limited slotted skills, like SaGa, Pokemon or some SMT games.
- (??) waves of enemies continue to pass by - defeating them could yield bonus pickups that can be immediately gathered and used by party members. Like a shmup, they pass by and you can avoid their attack rather than fighting.
- (??) barriers and protective fields that can placed on the map, to resist or negate certain attacks.
I decided to shelve the actual shmup aspect with ships and whatnot, but trying to see if I can implement the action elements onto a fantasy RPG, in particular my NES RPG. Reducing the scope of the above idea to make it easier to get started, and going to gradually see what is necessary.
I'm currently implementing a system to manage combatants, and an entity system that spawns/updates various things within the battle. Entities will be the building block for several kinds of things the move around and have sprites. They could have extra metadata associated with them depending on if they're combatants, projectiles, traps, barriers, particles, damage numbers, etc. For now, I'm using placeholder art from some older projects, and trying to make stubs/placeholders for turn order, actions, etc. Going from there to block things in.
I want to see if I can mockup an action battle system using this. Failing that, I can reduce the scope to a turn based system later, and some of the same elements may still be useful. In any case, I want flexibility to handle different actions that could comprise of multiple states, and move and spawn sprites for VFXs. So even if the battle wasn't real-time, the turn actions would have many elements that need to be spawned, updated and animated.
I'm using my simplistic C engine, vg, so that managing things in terms of 2D background layers + sprites is pretty straightfoward, and all the input handling and windowing stuff is already taken care of. Everything is written to avoid runtime allocations + loading, and instead uses statically-allocated global arrays, so that it will be easier to port the various subsystems to asm later. I could have used something like Love2D or Godot, but I just reached for a tool I knew would take not too long to get setup. And plus this engine follows some similar limitations I'd need to follow if writing a game on an 8-bit console, so it gets me planning for this ahead.
Going to keep working away at it if the motivation sticks!
Also something I hadn't mentioned on here: I'm non-binary and my pronouns are "they/them". For a long time, I just didn't list anything so people could decide as they want, and I would only fill in people who were closer to me. But I realized I don't really associate anymore with my assigned-at-birth + assumed-online "he/him", and I wanted to do something small to update that.
I decided to list and update my pronouns on my Twitter a couple weeks ago. Before, my pronouns were never listed in my bio. For at least a couple recent years, I have considered myself non-binary but not openly. Without explicit pronouns, and because of my display name "Egg Boy Color" and my IRL name, gender assumptions were formed. And since I wasn't yet open about this, I'd usually go along with the pronouns people used.
As for my choice of display name, Egg Boy Color was meant as a lazy augmentation of Game Boy Color but with "egg" instead of "game". It was a console I was fond of and making projects for, combined with a breakfast item I liked eating. "egg" wasn't used in the queer-coded slang sense, but I guess it could have applied in my case.
I didn't think too much about the "boy" aspect, and still don't. At companies like Nintendo and Sony, there was probably an antiquated marketing decision somewhere around the gendering used in Game Boy and Walkman, but the products themselves are inanimate objects with no gender, and went on to be enjoyed by people of all genders. So I dunno, I guess I figure it didn't mean anything significant but is nonetheless part of the name. Even if my thoughts around my own gender might have changed since I chose my handle, I'm okay with leaving it as-is. At present, I still don't mind my older nicks Overkill or Bananattack either. They're legacy names, but simply retired them for sake of online searchability, and I liked eggboycolor better.
More recently, I mentioned my pronouns at my work, and in a couple other online communities. For me in particular, I don't mind the occasional mistake, but I still would appreciate people's cooperation in trying to remember my pronouns. In any case, I don't currently have any plans to change my online handles or IRL name, or to change my appearance too much, but I can't speak for the future. I have some opinions formulated and others still being figured out, and I'll choose what/if I want to share. But probably not going into much more detail here, as I want this place to continue to focus on my projects!
I'm still new to being more open about gender identity stuff. Anyway, that's a lot of words. It's probably enough to know my new pronouns, and leave it at that! they/them.
Alright, that's all for this week. Hope everyone has a good one, and see you again soon!