#riverhollow

Redesigns

So to keep up my motivation and interest, I've been working on redesigning characters. Some of the changes are a little older than this past week of work, but I've just finished redesigning the last of the classes.

New designs are on the top row, old designs are on the bottom. They look a lot better with the extra depth now, don't they? I'm pretty damn happy with how they've turned out.

Combat

I've been working on complicating the combat system somewhat and I'm very pleased with the results so far. Monsters are now properly moving up to player characters to attack them and, for the most part, they're not tripping over themselves to do so either. I have noticed a small error that I need to resolve, but otherwise it's looking good.

Still plugging away at the Monster "AI" although I've been sick so haven't been able to spend too much time on it.

The pathfinding itself isn't a problem, I'm using Dijsktra's Algorithm for pathfinding in general and have been for, what at least a year now, and it works great. The problem however is determining where to set the end goal nodes right>

For example, we need to find the full path to the player so that we can path properly in the event thatthere is an obstacle beyond the max range the monster can move. If we do that, though, then we could have a path longer than the max range. If we just lop off everything longer than the max range and go for it though, we could wind up with a last tile that is occupied by an ally. Tiles occupied by allies are ok to talk through, but NOT to land on, so what do we do?

After a little late night bickering with my husband as I explained the problem and why certain strategies do and don't work, we determined the best plan is to lop off everything past the max range, and then look at the last tile to see if we can stand there. If not, set that tile as being temporarily invalid to walk through and recalculate the shortest patht ot he target node.

Now, of course, this all assumes we can properly determine what the target node should be. For simple skills like melee range skills, we just need to look at the tiles surrounding the party members, find the closest oone we can reach and hit it. But what if it's a spell? Now we need to calculate the whole path, backtrack based off the range of the spell to determine how close we have to get before we're in range.

Now what is that spell has an area of effect. We need to figure out where the target spell tile is based off of how many of the party we can reach with it. The plan to tackle this one is to have a method to store the max number of targets hit based off skill shape, since I have different shaped skills in mind, lines, rings, "circles" etc. and then each pattern needs it's own calculation based off of where the party members are in relation to each other.

Annoyances abound, and I am not looking forward to it, although at the same time, once this is done and working to a certain extent, I'll have an actual working combat engine that I'll be able to expand on.

So this week I started working on trying to implement larger monsters. In order to facilitate this, I played around a bit with slimes. No real reason, just amorphous so I can play with the dimensions.

This did, however, require me to play with the lighting and figure out how to make it look properly curved. I like the first and last ones, although the first one is more of a gelatinous cylinder XD

I also threw a cat into the warmup becauser why not. Thought I'd play around with it a bit... The side doesn't quite look right though but it's good enough for now.

Combat Pathing

Oh lord, so I needed to work on the monster AI a bit which, honestly, can fuck right off. Starting slow with just having the Monster pick a skill, then move to the closest enemy and use it.

It soudns simple, but edge cases are a nightmare, especially when I have the above larger than normal monsters complicating things. I'm needing to figure out simple ways to have the pathing recalculate if there is an obstruction like another monster in the way.

New plan going forward is to make weekly updateso n either Saturday or Sunday with everything I've done that week, not just things I think are important.

So I've been working on some new sprites for my adventurers. I realized that I was making the characters more 2-D and flat than they should be after I made Isabelle, so I made these guys to give it a try at making better ones.

While I was developing and adding in some new features, I noticed that two of my Managers seemed to be doing very similar things conceptually. I had a GameContentManager, that was supposed to manage the direct raw Content from the game files, and I had an ObjectManager which was supposed to handle the Game Object implementation of things. As time went on though, the two kind of got closer together until they were almost indistinguishable. Have compressed them into a single DataManager class for now.

I've done a complete rework in terms of how sprite animations are being loaded and played. Originally, all sprite animations were played by just requesting the hardcoded string for what to play, for example, "WalkDown". This is tedious though and can introduce errors. I have created a set of enums for verbs, such as Walk, Idle, Attack, etc, and now PlayAnimation can take in a verb which it then translates to a string. Whenever a single verb is passed like that, it knows to also apply the Direction of the WorldActor automatically.

Another enum for non-directional animations was added, similar logic occurs when we pass that enum into PlayAnimation, except it leaves out the Direction.

I'm working now on allowing characters to occupy more than one tile in combat, this will allow me to make larger creatures, as well as give new options in combat.

Regarding combat, combat will only happen on specific combat maps where enemies dwell. I'm trying to determine, though, whether the major maps should be broken up into smaller maps or not in order to facilitate this, or if I just need to make all combat maps be occluded when they would otherwise be visible on the main map.