Just a programmer tracking progress for their game: a minimalistic combat-focused dungeon crawler at the heat death of the universe
Regular dying vs ANGERY dying
I added a flag to my enemy objects call “shake” and characterised the shaking with a few variables. Movement displacement is modified by magnitude and how rapidly a change can occur. Explosion generation is modified by a minimum time since the last explosion spawn and the chance to spawn an explosion once that minimum time has elapsed. At the top is a more normal set of parameters while the bottom is setting the parameters to somewhat excessive values.
The movement/explosion code can be used for other things too, like status effects, shaking when taking damage, and so on. All I have to do is couple setting the shake flag to the death flag, and it’ll be good to go!
Getting close to finishing this death stuff off - today I made it so that enemies won’t take damage or be afflicted with status effects after being defeated (you can see as the white slash doesn’t do anything to the left guy). I also added a little popup that tells you how much xp, data, and scrap you got. I made some icons in the font I’m using, but because win10 won’t update the newly built font until I’ve restarted my computer, I’ve just used letters for now.
So regarding those dropped resources, I also added them to the stat matrix that every battle entity has. There’s a “current value” column, but there’s also columns with additive and percentage bonuses. I’ve made it so that these base values can (and will) be modified depending on various moves/status effects.
Next up is adding those small exposions and shaking effects, and I’ll be close to done!
Enemies are getting more well behaved upon defeat. Now, they won’t teleport around (or activate any other of their status effects), and they also won’t use any attacks they had lined up too. They still take damage, which is fine, I will need to know that for recruitment purposes, but they player doesn’t need to see damage number on them at this point, it’s better for them to know that the enemy is in its death throes. So, I have to disable the damage numbers, probably tomorrow.
I’ll probably also have a little label pop up with the xp gained from the enemy, but I’m still deciding what/how many types of resources I want enemies to drop. I tend to go overboard with these things, but I was thinking experience (for levelling up), data (for researching new things), and scrap (which would act as money). Typing that out, that seems fine for now.
Speaking of communication with the player, the bottom gif shows some small explosions I was working on. They started off as sparks emanating from a central point but those looked really really bad so instead I opted for some small explosions. I’ll add in some sparks, but they’ll be scattered around. Once I have a few small explosions and sparks I like, I’ll spawn them randomly on the enemy, in addition to making them shake, making it clear which enemies have been defeated that turn.
So here’s something that I’ve had on my to-do list for AGES, and that’s implementing enemy death. There’s a lot that still needs to be done here but I’ll try to run you guys through it quickly.
So death doesn’t work like most other RPGs where enemies are defeated on the spot. The reason for this is that the primary method of recruiting enemies is through hitting them with certain elements, and of course, you can’t recruit enemies if they’re dead! I wanted to avoid a pokemon-like scenario where you’re trying to chip away at an enemy’s health while not outright killing them, because that’s not a very realistic scenario.
So, instead, enemies are removed from battle at the end of the round, after they check for whether they’re going to join your party or not. However, if an enemy reaches 0 hp during the turn, obviously all their moves and status effects are deactivated, and they just kind of hang around until the end of the round. Think of it as a final desperation sort of thing, where they are clinging to life for just a bit longer.
I have the trigger, timing, and fadeout animations sorted, in addition to removing them from my enemy list and enemy grid data structures. What I still need to do is, well, a lot, but I have to ensure that all further moves and status effects are rendered ineffective, and I need to create data structures which will hold end of battle XP and loot. Obviously, I also need to program the part of the battle where the robot joins you too!
I did some more work regarding skipping over characters. This was done in preparation for when I get my next-character-determining script working with status effects that cause you to skip your turn. At the moment what I’ve done is set it so that the script always returns a -1 (aka, can’t find a next character). This, in effect, means that the whole player’s turn is skipped and the enemy takes its turn. I’ve left some messages in the log to denote this.
I’ve also got it working for when no enemies are able to act (i.e. if all of their moves are on cooldown). You can see that every second turn, enemies can’t act either because they have no valid moves!
Finally, what’s probably most eye-catching here is my little grid refreshing animation!
Of course, showiness during game development always seems to be inversely correlated to how critical a function it serves. I just set it so that there’s a slight delay on the icons appearing, and the grid refreshing animation plays during this time. Every time the animation plays, it signals the start of a new turn.
Well, after all that nonsense surrounding April 1st, my first order of business was to convert everything back to normal. It was a pretty simple job since I tagged all my changed code, although I really should have added an april boolean instead. All in all, I changed 2 shaders, the skills and enemy database, and some text that gets output to the log.
During testing the other day, I realised that my beginning of turn effects - incrementing effects, lowering move cooldowns, and reducing status effect durations - were only affecting player characters. So, today’s job was a fairly simple one of extending the list of objects to check to include enemies too.
The only hiccup was that I realised on the first turn, it’d get to the pre-turn effects before loading the enemy stats, so I added a check to ensure the battle doesn’t proceed from pre-battle (spawning enemies) to pre-turn unless all enemies had their stats loaded! The gif shows AP regeneration for 2 allies and 1 enemies (although I don’t think enemies will have AP costs for their moves).
So, I did a bunch of focus testing over the last few months (thanks to all those involved!) and the overwhelming response has been that robots simply aren’t cool anymore. Plus, that sad and depressing dying universe? Pretty lame, honestly. I don’t even want to get started on how outdated that green colour scheme looked.
But you know what IS cool? School idols. So, from hereon out, I’m shifting focus and making a game about recruiting cute idols and forming the universe’s best idol group! Travel all across the galaxy to different high schools and recruit as many idols as your heart desires!
All the various game systems will be totally reworked too - parts will become outfits, elements will be song genres, your ship is now a caravan with a mobile stage, and crafting/gathering will let you produce new props for different shows!
Oh, but when you first encounter the idols? They can be pretty tough, so watch out!
Today, I decided to address some technical debt that had been accruing. You’ll notice that the group panel is looking pretty bare - I removed some of the characters in order to do some bugfixing regarding what happens when you target an empty character panel (and how to skip back and forth between characters).
This is because I knew my code was sloppy, and didn’t always check whether a character existed in a slot before going ahead and referencing that character. Doing so without a character there would throw an error, which needed to be addressed!
Also, when starting a turn, I would make active_character = 1 -
that doesn’t work because the first slot is empty. Wwhen advancing turns,I was doing a simple active_character += 1, and in this scenario, you’d have to skip 2 spaces if you were advancing from the first to the second character. Now I iterate through the matrix from the current active character and find the next actually available character by checking if someone’s in that slot (and whether they have a turn skipping status effect).
I also took the time to add in a small feature - you might have noticed that the HP icons are different for each character. Well, the main character’s flesh and blood, so he has a little blood droplet for his HP icon. But everyone else is a robot, so they have a metal plate icon for their HP! I really love messing with the UI so that it reflect’s the game’s universe, but it’s a really bad habit of mine and makes programming some stuff unnecessarily complex, so I’ve really tried to limit myself here until I become a better/more experienced programmer!
Yesterday I didn’t have much time so I wrote a script that flips things around. It either toggles or specifies an absolute flip on the x and/or y axes. Even though you can flip a sprite with one line of code, because I always have my origin at the top left of the sprite, things flip around the origin and require an x or y shift to compensate, hence the need for the script.
So anyway, I used that script today to flip the up arrows and make them down arrows! And I did some more work on the advantage system I’ve had cooking up. Basically, you probably know that you need to light up 3 elements in a row, column or diagonal. Now the grid reflects when that’s the case, and shows you how many lines you have! Of course, the enemy uses the same grid and can also get lines, so it shows their lines too!
I wrote a simple thing that turns all colours randomly to red or blue, so usually the grid won’t be this busy all at once! Nevertheless I was worried that this grid would be hard to read but from what I can see, it seems pretty easy to tell which elements/lines are yours or the enemies, and how many are lit up. I might change some of those light blues to dark blues -probably the element icons themselves in order to make the boxes and lines more clear.
Phew, today was supposed to be an easy day, but it was in fact, not easy at all! All I really wanted to do was to add some effects but I ended up going on a bug hunting spree.
The main task today was to do some cute little arrows for my advantage grid, when the element is activated in your favour. So in this case, the enemy is hitting the players with 3 different elements, all of which the players are strong to. This in turns causes the respective elements in the grid to light up in their favor. If they were weak to the elements, you’d see some red down arrows and a red icon instead.
I also got the affinity indicators (the labels saying overcharge in this case) to appear with the damage numbers instead of at the beginning of the attack, which is quite a bit more intuitive. That was pretty easy, just moving things around from one bit of code to another. But it looks a lot nicer now in my opinion!
The main bug that was annoying me, and took up a lot of time, was that sometimes the move grid (where I store everyone’s moves before they act) was disappearing on me, and after lots and lots of inspection, the bug was twofold - the first was that I used the same variable name for both the grid that stores ALL the moves a character can do, and for the temporary grid that is populated each turn. So I fixed that, but it didn’t solve the problem at all. Partway through my debugging, I found that calling a random function checking if the grid existed fixed my problem. That was my immediate sign to restart Gamemaker (as the cache can get out of date or corrupted or… something) and the problem went away even after commenting out the random function. Yay!
