Building River Hollow

Down the Rabbit Hole

Spent a larger portion of the week than intended chasing a rabbit hole of programming refactoring. I want to say I should be surprised by now, but I'm not. Designing and building systems are whatI love the most about programming, so when I find or see an opportunity to improve something I just can't help myself.

It all started when I went to ensure that the resident Bard, Damien, was able to join the party. I found out that at some point I must have broken the code that handles the parsing for the selection box because not only was "Join Party" not an option, the word "Friend" was there, and that was just wrong.

To explain, before I went down the rabbit hole, I denoted selection text and options using special characters. A sample selection box text is as follows: "Hello, how can I help you? {{Talk-Talk|%Friendship-50%Join Party-Party|Nevermind-Cancel}}"

{{ and }} were used to note where selection options began. Each option was composed of a first part, the text to be shown, then a - before the next part which was the action to take place. The % was used to denote a special condition that would be used to determine if the action should be removed, and it was this that had broken.

I decided to clean my code up and make it easier to follow and parse because, in addition to that, the handling would pass the selected action to the class of the talking npc, going up the chain of overridden classes until it found something to handle the specific action.

Using the TextEntry logic of adding tags to text values, I completely removed the special character handling. Instead, every text entry that opens a selection menu now has a tag denoting it's Selection type. Some selection menus that ask for confirmation have a Trigger associated, and all options that can be selected have a verb attached.

When the code goes to display a bit of text, it checks the tags to see if it has a Selection tag. If so, it knows to make it a TextSelectionWindow and programatically constructs the selection menu based on the type of selection in the tag. When a piece of text is selected, it checks the current text's tags to see if there's an associated Trigger and checks the chosen action for a verb. It uses those two together to choose a course of action.

This rabbit hole took a bit of work, but it's much cleaner and easier to follow. It does have a problem in that everything needs to be programatically added instead of being a bit looser in terms of what menus there are, but I think the benefits far outway the cons :D

NPC Travel

Following up with last week's goals, the NPCs who do not start off living in the village now show up at the Inn at set periods. Currently, everyone stays for a single day before moving on. By doing this, it allows the players to meet the NPCs and get to know them, as well as determining what buildings they need tom ove in, while still forcing the player to build up the town to get them to stay.

The actual patterns they follow are perhaps a bit clunky, but for now at least this will work. I'm considering removing the Inn rooms as actual map locations and just having the NPCs spawn in the main Inn, but we'll have to see how that goes.

Crafting

Playtesting the "early game" a little bit made me definitely feel that having crafting take any real amount of time is tedious at best. Some games that I've seen do this, but it's not exactly something that I find endearing. For now, have made all crafting instant speed, take a set amount of stamina and play a sound effect.

It's still not satisfying though, I think I'm going to need some kind of payer animation, or maybe a heavier sound? Crafting isn't exactly an engaing past-time, but there should still be some good feedback from doing it.

Building Upgrades

I've started improving the manner in which Buildings get upgraded now. Have implemented the ability for upgrading Buildings to spawn new machines which allow you more crafting options, which is a good start. Currently the Level 2 Potion Hut spawns a Millstone to allow you to make powders.

Gremlin

The Shipping Gremlin has been fixed and now sits at the proper position ont he map and sells items for you. He's a special case as far as the NPCs goes so I needed to do some special handling for him, which I hate having to do.

Some new art

Wanted to work on spicing up my machines, made a new massive Cauldron and Millstone. I'm particularly happy with the millstone, minus the side of the damn table it's on. Unsure how to fix that...

Weekly Goals

Following up with my plans from last week, implementing all of the buildings with their own machines and one or two more advanced machines to upgrade to is the next step. Give the Forge a Kiln, Weaver's Cottage needs a Loom, etc.

After that, back to playing the beginning of the game, tweaking the "tech tree" as it were to force the player to upgrade the town to be able to make new items to upgrade their current buildings/build required buildings.

Watch Your Genre

So a little while ago, I was watching my husband play a game called Littlewood when I realized, that the source of my problems and confusion with River Hollow ist hat I'd been trying to force it into the wrong genre. River Hollow, as I had envisioned it, was not meant to be a Farm Simulator game that was reskinned for more combat. I wanted it to be a town builder.

Believe me when I say that was a huge relied but also a massive pain. I've been working and struggling with this game for how long, and the thought never once occurred to me to re-evaluate the genre I was building it in? Yikes.

That being said, though, once I made that change, many of the conceptual problems I'd been facing in terms of developign the game have been resolved. Leaving me with more immediate concerns instead of structural.

Buildings!

To go with the chanegs to River Hollow being a world builder, a lot of hanges needed to be done in terms of how Buildings are built as well as which ones can be built. I won't detail all the changes because it's been an ongoing process but will note changes made this week.

I found the Buildings to be very depressing and lacking a certainoomph when building or moving them, so I've added some soft thuds both on placement and pickup. It's funny how minor changes can carry such weight as the experience is much more pleasant now.

Additionally, there was a problem with the building moving to center itself ont he mouse when it was picked up. Have changed it to move relative to where it was picked up instead. tT's a lot less jarring now.

Made the Arhcitect's Shop start built, and made all building blueprints purchaseable from the start.

There was also a little problem in terms of canceling out of building mode when attempting to build, or move a building and it was "being held." This has been fixed now and works as intended.

Dialogue

As part of a large change I made in the structure of how text code is being handled, I broke my ability to edit the Cutscene Dialog in my Database Editor. This has now been fixed, and I can both add new cutscenes and edit their dialogue. It used to be that all cutscene dialogue was stored in a single text file, but this has now been chanegd to one file per cutscene for the sake of easier code maintenance. A bit more unwieldy in terms of number of files that exist, but it's not an inherent problem.

Weekly Goals

I'm going to end every Dev Log with a plan on how I'm going to move forward. I hope that this well help motivate me, as well as keep my mind fixated on the next steps to take.

The main focus I've been trying to keep my mind on is the starting point of the game and how the the start of the game effects how the game will flow.

The player will want to unlock the buildings of the town and such will need money. So I need to to put in more items that can be crafted as well as more items to use in crafting. Additionally, The Shipping Gremlin, who currently acts as the shipping bin, needs to be fixed. Currently, he only spawns at position 0,0 on the map.

To help with the flow of combat, I think I'm going to allow Damian, the bard, to start the game available to be a party member. This will at least allow the player a bit more of a saftey net as well as avoiding having the player be required to be alone in combat.

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.

So about that spirit yesterday, lol. I originally made this one, but he was slightly too big for the 16 x 16 box I had designed for spirits. So instead, I made theo ne I posted yesterday.

Don't get my wrong, that one is cute, but I just felt that it didn't look quite right so I said to Hell with it and just made this spirit slightly bigger than the majority of the others.

He's an important spirit, it makes perfect sense.

So, I had a bit of a revelation the other day. The reason my sprites looked kind of fucked up was because I wasn't actually making them properly.

You see, when you draw buildings in the 3/4ths view, you need to draw the tops of them, because that just makes sense. But I wasn't applying that logic to the NPC villagers I was making, or at least, not consistently.

So, as I worked on my new sprite here, I tried to take that into account. I made sure that we could see the top of her head, and addes extra light around her shoulders and the bottom of her dress where it flared out.

Is she perfect? Lord no, but I'm still pretty happy with her.

I spent all night working on this and I AM SO HAPPY.

I made a thing and I don't hate it, Whee :D This is a Muck Dweller. A low-level enemy that lives in the swamp.

OK, I swear I have been working! there have been some false starts, more tendonitis, a bunch of sickness and just time vanishing, but I've been plodding along.

I've also been wanting to not post anything until things are completed which, I admit, not a good idea to show constant development.

Anyway, here are the gemstone nodes that you mine for the ten types of gemstones :D

Diamond, Emerald, Ruby, Sapphire, Opal, Jet, Amber, Jade, Amethyst and Topaz.