#entropy-game

I’ve had my eye on this for a while, but today I had a go at implementing the fantastic BktGlitch (from blokatt). It’s a shader (code that runs on your graphics card instead of cpu) that creates some really really cool glitch-like effects. As you play this game in first person through a visualiser, I thought it only fair to add some glitching effects. These won’t be on all the time, obviously, but only during certain events (taking damage, getting afflicted with a status, and so on).

It was fairly easy to get up and running, what took a bit of time was finding nice parameters that gave off distinctive effects. I think a lot of these are too harsh, so they’ll be tuned down for sure, with increasing intensity based on how damaged/worse off you are!

As I am a merciful game developer, I have now made it so that not every available square is filled with enemies! Essentially, I can now determine a number of squares that should remain free even after enemy appearance, and the enemy placement algorithm with work within this value. The other thing you might have noticed in the top gif are enemy names popping up - this is exciting because the enemies now know what attacks they can perform, and marks the start of work on the enemy AI!!

Enemies will have varying behaviour patterns (broadly classed as attacker or support with some subtypes), and in order to determine which move each enemy will use, I’ve drafted up some pseudo code which goes through how I think that will work. Essentially, I loop through each enemy, each move, and each target to determine a total score for that attack. The score will be weighted by enemy behaviour, skill utility, what other, faster enemies are doing, and then affected by any status effects the enemy might have.

AI can now add moves to the move queue! No more free wins for the players! You can see in the gif some pop up windows. This is the possible move list for enemy 1 -> enemy 1 adding their choice to the movelist, and then the same for enemy 2 (which has the same move list but adds a different move).

Once all possible moves for any one enemy are sorted by their score (total damage), we can then move on to the move choice stage. What happens here is that a single move and target is selected from the list based on some certain criteria. What I’ve got in the bottom picture is a very very rudimentary AI system that chooses a move based on the position in the list. irandom_range chooses an integer between the two specified values, and weightindex is the total number of moves in the list.

You can see that the very efficient AI will choose the highest scoring move without fail. An efficient AI will choose from the top 20% of scored moves. Pure random chooses a move at random, and so on. Inefficient is supposed to choose a move from the bottom 20% but I’ve accidentally typed weightindex*0.2 instead of weightindex*0.8, whoops!

Ok, today I got my data structure sorted that will hold all the moves and move related accessories that the program will need upon confirmation of that turn’s moves. It looks like a bunch of numbers (and, well, you’re not wrong), but lemme walk you through what they mean (from left to right):

ID of the owner of the move - obviously important when I need to do stuff like damage calculation, since I’ll need the owner’s attack stats + others. This is the ID of the object where those variables are stored

BattleID - most likely just for my reference, it’s the slot that character is in (0-4 for players, 5-14 for enemies/npcs)

Character speed - the speed statistic, which I’ll need for sorting the data structure to determine who moves in what order

Attack type - an enum corresponding to the type of move (aka, whether it’s an attack, defense, item, or escape attempt).

Everything below is needed only for attack and item type moves:

Attack/item ID - the unique ID in the respective database, needed to look up basically everything about what the attack does, including the associated script reference, animation, etc

Ally/enemy - whether the ability is targeting an ally or enemy, just as a quick binary value so I don’t need check if target id is less than 5 for allies or 5+ for enemies

Targets - This is a 2D array containing the object ids of all targets selected by the AOE, and the number of times they were selected. As attacks will be doing more damage if you have more of the enemy covered by the AOE, it’s important to know this! It won’t be double damage if you have 2 cells compared to one, but it’ll be something extra as a bonus for good positioning!

X value - the x position on the enemy grid

Y value - the y position on the enemy grid

P value - the player index

Just a note for the last 3, I’ve captured the coordinates of the attack separately from the targets, as I’ll need to know these if an enemy dies mid-turn. If everyone shoots at the same robot and your first character defeats it, it’d be quite annoying to have the rest of your characters shoot into space and not hit anything. Therefore, if an enemy dies and it’s a single target attack, your attacks will automatically be directed at an enemy of the same type (if available and within the attack’s potential radius). If it’s an AOE, it’ll just hit empty space!

Put my animations into the game! Yay!

Didn’t take a whole lot of time, since I still need to add the dynamic text in (which will be the attack statistics and the chance to escape). However, this puts me in the perfect position to work on the targeting system (reading in attacks and selecting from rows/columns, aoes, etc) which I’ve been aiming to do for like, 3 weeks now?

I swear these graphics take me forever to do! These will all appear in the viewport as you select the relevant option (and are designed to resemble the little icon in the menu, which I’ve uploaded again for your reference).

Had to round off the UI for my battle menu by doing the graphics for the defend menu (top), escape menu (middle), and the inspect function (bottom). I had first drawn a symmetrical shield for the defend menu, but after seeing how nice the asymmetry of the retreat menu played with the selector (the highlighted side showing the action), I decided to re-do my shield, and make the “cancel” side more attack-focused to signify, well, you’re cancelling your defense choice so you’ll probably attack.

Similarly, the retreat option either highlights you running away (the arrow) or the hoard of robots you’ll be facing (the X’s). The circle is supposed to indicate the display is like, housed inside a radar of some sort, but even if that doesn’t come across, it still unifies the otherwise scattered graphic.

I’m happy with my progress today! First off, in the bottom left corner, you can see I was able to add more attack information to the panel. Now you can see an attack’s power, number of hits, and elemental affinity(s)!

Secondly, I have added code that properly represents an attack’s AOE in the target selector. When you select an attack that affects, a column, row, or all the enemies, the cursor changes appropriately!

What I don’t really like is that the cursor is not that visible against the enemies, so I’ll be thinking of how I can make that more visible. You can also see that going back into the menu takes you to the top item, and I’d like the menu to land on the previously selected item, so I’ll be doing that tomorrow. I also haven’t properly implemented player selection with this new code, so that’s still to come too. Nevertheless, progress!

Okay so today I didn’t get a whooole lot done because I’m really lame and there was a moth in my bedroom (where my computer is) and I can’t stand flying insects so I kinda just left until it was gone (see second picture for an accurate representation of events that transpired).

ANYWAY when I did go back into my room I got in place the basic menu state (entering, exiting the menu while ensuring all other keyboard inputs and stuff are ignored). Then I was able to set up an array that points to the location on screen where the selector should appear for each of the 5 menu options. Pretty easy stuff all things considered, the hardest thing to get working was a 1 frame flicker when transitioning between states, but that’s because I had the object visible code for the menu and the viewport in different locations, causing the viewport to disappear one frame earlier than the menu appears.