Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

1401005 Posts in 67843 Topics- by 61374 Members - Latest Member: blakeadam

May 23, 2022, 10:30:37 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsXeen inspired, top-down, experimental RPG
Pages: 1 [2]
Author Topic: Xeen inspired, top-down, experimental RPG  (Read 3547 times)
Level 0

View Profile
« Reply #20 on: July 21, 2021, 10:59:24 PM »

What's next?

I had a short break from working on the game so I can recuperate a bit, do some paid work, work on some technology testing and do some hands-off thinking.

What I did up to now can be called the first sprint, if you allow me some agile PM lingo. Its goal was to make the proof of concept, and that's what I did. The goal for the second sprint could be to produce something playable, not too deep, but something you can start, have progress, and finish. I introduced the multilayered map, some programmer art, enemies, and basic combat. The goal is now to improve on these components by adding some gameplay.

What do we need? At least some opponents and a quest. How to get it? Well...

Improving graphics

I'm testing the idea of baking sprites and animating them from 3d models. This should allow me to buy 3d assets which are abundant instead of doing 2d art which is hard to get.

For the environment though, I have a different idea. Look at what this guy is doing for tabletop maps (https://twitter.com/_MoonlightMaps):

I would love to have such graphics for the environment in the game. This shouldn't be too difficult to achieve for the proper artist. Once I have the gameplay prototype, I'll go search for the artist. At least I know what I want. (If you're that artist, PM me, I'm hiring Smiley )


Or quest, whatever. I'll test the game logic with a simple scenario: there is a goblin encampment nearby, destroy it and get some loot. The scenario is simple but a lot of elements need to work together for it to be playable:
  • Encampment - some object on the map that can be destroyed, but it's usually guarded by its inhabitants
  • Enemy - I already implemented the basics, meaning they exist and you can kill them
  • Enemies - they need to work as a group. What I want to happen is that as you approach their camp, you'll find them scattered around but as you draw closer they'll group and defend the area.
  • Loot - when you destroy the camp, you get something from it and keep it in your inventory

Opponent AI

I spent most of the time thinking about the AI in the game. For Battle Bolts, I implemented the Utility system, but the game was small with a limited set of moves so I took shortcuts. Now I re-read and re-watched a lot of materials, and I learned some new concepts. The result is that I know how to implement Utility system, GOAP and even Monte Carlo. I'm ignoring FSMs here because I know they are easy to implement at first but later it gets messy as you add exceptions and you get stuck. Been there.

MC is off in this case because I don't need a reinforced learning system but it's good to know it, RL is exciting.

That leaves me with GOAP and Utility. I switched between them, one day GOAP seems to be the better choice, the other day it's Utility all the way. Finally, I settled on Utility because the implementation is simpler and it better fits my model. GOAP uses path-finding to connect possible actions, which can create a really smart multistep behavior, but as I'm already scripting such behaviors (weapon change, melee focus), I won't use the main advantage of GOAP. Utility system works on a higher level, so it should allow me to program different scripts (behaviors) and let it choose the best script based on considerations.

Some resources:
Great GOAP Udemy course: https://www.udemy.com/course/ai_with_goap/
GOAP GDC talk:

Utility System GDC talk: http://www.gdcvault.com/play/1021848/Building-a-Better-Centaur-AI


Level 0

View Profile
« Reply #21 on: July 28, 2021, 10:52:40 PM »

Graphics improvement

I have to step up a bit in the graphics department, but as usual, let's see what I can get with minimum effort.

I want the game to be 2d, but it's near impossible to get the assets for a top-down, 2d game, without having the artist on the team. But I had this idea from the start: what if I take 3d assets that are abundant and render them to 2d. All beautiful old isometric games did that, look at Caesar 3 or Age of Empires. Except that they did their own 3d models, but let's see what can be done with some cheap assets.

I bought some monster models, a Toon shader, and Animation Baking Studio which can export 2d spritesheets from the 3d animated model. Let see how this works. (This guy here on forums is doing something similar)

Starting with some Goblin model I spent some time playing will all those new packages, but in the end, I got something. I exported walk and melee attack animations, plugged them in the existing system and I got some results:

From model to spritesheet:

Into the game:

I'm not overjoyed with this, I expected better output. I limited the individual sprite to ~128px and set 10 frames for animations. Animation is somewhere in the middle, not too blocky, but not too crisp. I definitely expected better edge detection for the outline from the shader, not just the silhouette. I'll have to spend some more time with tools to get the proper pipeline, or even touch the exported sprites a bit. But, progress is there. We're making content now!

Level 0

View Profile
« Reply #22 on: August 01, 2021, 10:29:52 PM »

Reorganizing tiles

Since I wanted to have the party that moves together, that's also how I modeled the tiles and enemies. They will form parties and move together, like the player. And now that I want to add multiple opponents, this approach starts to break down. For example, if there are some ranged opponents AI should organize it so that melee fighters are near the player and archers stay behind. But if I put them in parties of four, they are locked to their party formation so this would look weird. There is no reason for enemies to move in groups of four.

So I had to do some changes under the hood. I split every tile into four pieces. Graphics tiles will stay the same size, but the virtual tiles I use to calculate movement and distance will be in higher resolution. I can use this to draw fog of war too, which will make it a lot less blocky. The movement will stay almost the same, except that logically everybody will move two tiles instead of one, visually it'll look the same. The change is for the better, but it took some time to implement.

I had to rip out and rearrange some systems that were party-based, but still keep some of them because the player's party does move together. Blending this was difficult, but it's done now. While I was refactoring, I also added some improvements which I couldn't do before.

Improved ranged attack a bit. Now, when you execute the attack, they'll shoot at the closest enemy, searching for target in all directions instead of just in the direction the party is facing:

Melee stance and attack also looks better. All characters will automatically face the opponent, even the back-row characters. Attacks are now possible in diagonal too:

After that, It's time to make some enemy AI.

Level 0

View Profile
« Reply #23 on: August 09, 2021, 03:51:51 AM »

Enemy AI

Finally, I'm at the point where I have all the ingredients to implement a basic mission with some enemy AI. Since I don't have the manpower to produce a lot of content, I'll rely on declarative programming to enable me to vary the content by just changing the settings. For example, let's put a goblin village on the map. I'll designate a spot for the village and decide how many goblins will live there. For example, 10 goblins, 2 goblin captains. Once we have more monsters, we can mix and match.

Goblins will have multiple behaviors, which they'll pick depending on their state, using the Utility AI approach.
  • Patrol - goblin will circle around its village at some random distance and in random direction
  • Attack - goblin will engage the enemy (player's party)
  • Retreat - goblin will return near the village and defend it there

What makes the Utility AI approach so nice is that I don't have to define a big FSM that will switch between these behaviors. Instead, I'll define a set of considerations for each behavior. Each consideration results in a value between 0...1, when multiplied we get the utility of the each behavior. Behavior with the highest value is picked.

Some considerations I'll use are current health, distance from the village, is enemy visible and threat level. The most complex is the threat level, which will be calculated as a ratio of enemy strength and the strength of the own group. The strength of the individual is calculated as its attack power, defense and health. The numbers is not precise, more like a guess.

The resulting behavior I want to see is following:
  • A goblin patrols around the village
  • When an enemy approaches the village, those on patrol will spot it
  • If they are strong enough, they'll attack. If not, they'll retreat
  • Other goblins may join the battle or retreat, therefore grouping themself and defending the village

For the player, that means that they can encounter a goblin on patrol. If the goblin attack, they'll be some challenge, otherwise they would retreat. If the goblin retreats, they can follow them and fight the village or ignore them and continue on their way.

Here's how I combined considerations for behaviors. If prefixed with '!', the considerations negatively affect the utility of the behavior:
  • Patrol = !threat (patrol if there isn't any danger)
  • Attack = enemy * !threat * health * !distance (attack if enemy is near, we are strong enough, and we are healthy, if the village is close we are more prone to attack)
  • Retreat = enemy * threat * !health * !distance (retreat is enemy is near and they are stronger then us or we have low health, but not if we are already close to the village)

And that's it, goblins should defend their village. And it really works. But... It's terrible for the gameplay. You can't win, enemies will wait until they are strong enough and kill you with a few shots. I made a good system, but not for this game. The game has limited movement and a small set of possible actions, so I need enemies to be less smart.

Simpler implementation
I made enemies less smart: enemies will attack the player when they see them and fight to the death, that's all. Retreating is out for now. Sometimes, simple is better. I removed the fog-of-war so you can see what's happening in this gif:


Level 0

View Profile
« Reply #24 on: August 12, 2021, 09:55:08 PM »

When things go wrong

What to do when a party member falls in battle? In the first-person view of Might and Magic that wasn't a problem, portrait just displayed an unconscious or RIP image. But I can't do this because the player can see the whole party on the map, I can't have the dead character moving around.

Instead, let's just leave the body on the ground where it fell. The rest of the party can move around and finish the battle. If they return to the tile, they can heal the fallen member and they will return to the party. Out of combat, they can just visit the tile and the fallen character will wake up with minimum health.

Party members in general won't die. They'll just fall down, unconscious until healed. Returning to the temple to resurrect one character was never fun for me. Of course, if they all fall, that's TPK.


Level 0

View Profile
« Reply #25 on: August 16, 2021, 10:12:09 AM »

The quest system.

Now, this is huge. Quests can make or break an RPG. I remember trying some indie RPGs to support them and see what indies are up to, see what can they do that AAA cannot and get some inspiration in the process. But after collecting herbs, bringing soups, and killing wolves, I quit. Unimaginative and repetitive is no fun. I expected a lot more. On the other side, I played Pillars of Eternity. So. Much. Talking. Which means reading. And all this text is not improving the game much, it just makes it longer and harder to finish. When I want to read a good story, I take a paperback or Kindle and enjoy it in the armchair or outside. Staring at the screen is not my favorite position for reading. Show, don't tell should be the guideline for games too.

So I want something in the middle. Powerful quests and story, without too much text. I want to see if it's possible to just give some hints of the story to the player and let their imagination do the rest.

I need an easy way to write quests. I'll just use a plain text file with some keywords which I can then feed to the game engine to convert it to game objects. Let's write a simple quest first. I'll avoid having such quests in the game, but I have to start with something easy and iterate.

The quest.

There's a woman on the farm, goblins took her son. Everybody thinks he's dead but she's sure he's still alive. He had an amulet when he was taken. If you go to the goblin camp, fight goblins and enter the camp, you'll find an amulet there. Return to the farm and now the woman will understand her son is dead and mourn. But who knows, maybe you'll meet him on further adventures.

Here's the template I'll use to define quests:


grieving_mother: "Goblins took my son. Everybody thinks he's dead but I know he's alive. You'll recognize him by his amulet with E.K. engraved."
talked_to_grieving_mother = true
!gave_amulet_to_grieving_mother, talked_to_grieving_mother, !has_engraved_amulet
grieving_mother: "Please, find him."
!gave_amulet_to_grieving_mother,talked_to_grieving_mother, has_engraved_amulet
grieving_mother: "Oh no, my son, my only son... Thank you... for recovering the amulet. At least I can hold it when I pray for him."
xp += 100
grieving_mother: "Thank you for the amulet!"

This is a barebone quest. It says that there is an NPC at grieving_mothers_house (grieving_mothers_house is the name of an object I place on the map). Then, there is the engraved_amulet item, at the goblin_village (also a place on the map). You get it if you loot the village (after you remove the defenders). And then the dialog. If you talk to the mother, she'll give you the quest. If you go to the goblin village and manage to loot it, you'll get the amulet. If you have the amulet, she'll thank you and you get some experience. You can get the amulet first. In that case, she'll state her plea and immediately thank you.

I threw together some simple UI to display messages and dialogs. I'll add some pictures of the NPCs you are talking to but for now just the silhouette.

Visiting the farmhouse where you get the quest:

Fight the goblins, loot the village and get the item:

Return to the farmhouse and you get a thank you:

Of course, we can build a multistep quest like this. Let's say that the son is alive, taken into slavery somewhere far away. You can meet him and the quest continues. It's a matter of setting conditions and effects.

Future work

The above is just the quest mechanics. Quest design is a different story, and I'm getting there.

That was the fetch quest example. There are also kill/capture quests or destroy quests. They usually boil down to this, but int the way we tell the quest story and combine different storylines lays the great quest system. For example, there's that lich in the dungeon. You could go and just kill it, but it's too strong. By solving a related quest, you get his motivation. Another quest shows you his weakness. Finally, you can find a special weapon or defense that helps you kill it. All this spread around and weaved through other stories should make some good gameplay.

In addition, I want to give options with different consequences to the player. Multiple parties interested in the same item. Opposing factions where you help one but become the enemy of the other.


Pages: 1 [2]
Jump to:  

Theme orange-lt created by panic