Tag: role playing game

RPG Game Dev Weekly #2

Well, so far not so great for getting weekly posts on this! It’s probably better for me to aim to do these periodically and summarize the last week or so of work. Fewer commitments that way and it’s a bit more realistic for me to achieve. With that said, let’s dive into it!

Entity Filtering in an RPG

Our RPG has had some notion of entity filtering for a long time, but to understand the current state of filtering, it’s important to understand the two major sets of entities and components we have:

  • Game Objects + Behaviors: Everything in our RPG game world is represented as a “game object” and the properties/capabilities are captured by components called “behaviors”
  • Definitions + Generator Components: The content for our game is represented by “definitions” and the “generator components” are how we transform this information into “game objects” and “behaviors”

Because I heavily focused on our loot generation system early on, the focus for filtering was really around being able to select loot from “drop tables” (which have item definitions on them and associated with enchantment definitions). Early on it was a goal to ensure that loot generation and other game systems could have extremely complex situations handled, so we needed to be able to do things like generate loot given arbitrary game state. Additionally, this system needed to be fully extensible to support any game state we wanted to add in the future.

In what might seem to be an extremely contrived example, assume we want to generate item X when:

  • The player is level 50+
  • The current weather on the map is raining
  • The current time of day in the game world is night
  • The player has completed quest A, B, and C
  • The player is holding item Y
  • We are generating loot for killing enemy N

These conditions represent a filter that we need to execute, but I never realized until recently that the implementation of this is actually something I’ve started calling “bidirectional filtering”. This means that we’re running a query with a filter over a set of drop tables, but we provide along some state and the drop tables are filtering backwards on this state. Sound complicated? It was, especially before explicitly thinking of it as bidirectional filtering!

It can be more easily digested when thinking of it this way:

Provided Game State:

  • Current weather
  • Current time of day
  • Player (level and equipment in this example)
  • Quest status

Required Filter from Game:

  • Drop table ID matching enemy N

Using the above information, we select all drop tables matching the required filter from the game. Essentially, any drop table ID for enemy N. For each of the drop tables that match this specific ID, we then run THEIR filters the opposite direction on the game state! If a drop table had no specific filters on it, it would match right away. However, if it had a weather filter on it, it would need to match the provided game state weather.

Okay so that’s bidirectional filtering in our RPG, but this is what ALREADY existed! So what did we need? We actually just needed single direction filtering. Literally just standard querying of game objects. Half the battle of what was already in place!

If you’ve played games like Path of Exile or even Last Epoch, you’ll see indicators in the game that there are tags associated with different things (like skills, items, enchantments). If in our game we want to be able to query all items in a player’s inventory that are of type “axe” or all skills associated with “fire”, we need some way to filter our entities. And in this case, there’s no need for the entities to filter backwards like in bidirectional filtering!

We expanded our filtering system to support this now, which unlocks:

  • Skills that require certain item types
  • Skill prerequisites that aren’t just a skill ID
  • Advanced skill targeting
  • Enchantments that boost skill stats (damage, levels, etc…) that match a particular filter
  • Crafting / Alchemy (i.e. filtering on ingredients)
  • Item socket patterns (this was already in game, but we can do this declaratively instead of writing custom-coded plugins)
  • Restricting applying poisons or consumables to certain item types
  • … this list goes on and on!

RPG Movement Overhaul

This block of work is what chewed up most of my RPG development time the past few days. I was frustrated with my initial and seemingly failed implementation of A* for path finding. For anyone that’s gone through popular computer science algorithms, A* is a pretty straight forward algorithm for finding shortest possible paths. It’s really popular in games because it’s extremely efficient! But my take on it just wasn’t cutting it for our RPG, and it would often report that no paths were possible (which just wasn’t true)!

Our RPG has an explore mode and a combat mode, sort of like Pokemon. However, the combat is tactical, so it’s sort of like Final Fantasy Tactics with respect to that. Being a 2D tile-based game, having tile-restricted movement makes a lot of sense. However, early on I felt that having free-form movement in the explore mode felt really fluid and fun. There was no great reason our explore mode needed to be tile restricted. However, making this movement system decision complicated all of our tile-based movement by trying to re-use the same code.

So I did a thing that I find feels counter-intuitive as a programmer normally… I duplicated a bunch of code, one for supporting tile-based movement and the other for freeform. No more “common code” for this. From here, I found I could actually start correcting each movement system and tailoring it to do the right thing. I was hitting this blockage before because these really were two fully separate implementations of class that can support movement.

From there, I worked through my path-finding issues. I built out some visuals that can determine where the player can move, and used this to validate what I believed I was seeing in my unit tests. 2D stuff is easier to understand visually! The following is an example that shows a snag that I hit where our logic to check “can we move to this position” was incorrectly calculating the distance to that point. If the player has only 3 moves to make, why does it think it can get to the tile labeled 4?

The answer? It was doing birds-eye distance checks back to where the player was standing. Not going to work for our RPG! Instead, I was able to re-use part of the A* algorithm to calculate the distance as the algorithm progresses through neighboring nodes. I also needed to update A* to report the total distance in addition to the positions on the path. The result was consistent calculations between our valid walk points and the actual pathfinding algorithm. The next snapshot shows a small update to the visuals:

And at this point, it was really just about showing/hiding/updating the valid walk highlighting at the right times! So I figured I’d whip up a little video to show progress on that:

What’s Next In Our RPG?

We’ve been making some awesome progress on our RPG. We’re starting to look into random dungeon generation, and I’ll probably try to find something more architectural to tackle. I find I burn out fast when I spend too long on things that feel strictly visual or like I’m polishing things. In this case, the movement part of combat is critical so it needed to get done. But reflecting on all of the changes there was nothing fundamentally changed in our game to accomplish this.

Additionally, I’m going to start doing a better job of adding more content. I’ll be adding in item affixes for item generation, prefixes/suffixes item name creation, and ideas for items that can drop. I don’t think we fully have the components required to define all the items I’d like to make, so I’ll start just by recording my thoughts in a consistent format.

Overall, we’re moving in the right direction! But there’s no denying making an RPG is a ton of work!


RPG Game Dev Weekly #1

As I’ve been trying to get more YouTube content put together more steadily, one of the themes I’m interested in is doing some behind-the-scenes of the role playing game (RPG) I’m making with some friends in Unity3D. I’ve found that being able to work on an RPG outside of my regular day job is a really awesome way for me to keep up on my technical skills. I love coding, and the further along I move in my career as an engineering manager, the less time I actually spend writing code myself. I pride myself in being a technical engineering manager, so for me working on this RPG is a great outlet for creativity and practice. I mentioned this in my LinkedIn post here:

Persisting Game Objects Across Maps

In this video, I focus on one of the challenges the game was facing due to how objects are materialized onto the playable map. The map that we load from disk to be shown and interacted with in the playable RPG commonly has “templates” and “spawners”. Both of these are responsible for creating objects at runtime given some criteria. As a result, uniquely placed game objects appear on the playable map for the player to interact with.

Sounds good then, right? Well the two challenges I focused on addressing were:

  1. If we leave the map and go to another one, there’s no way to persist the player across maps! That means you get a brand new character every time you transition maps. In an RPG, this is definitely not going to work out.
  2. If we return to an existing map, we expect it to be in the same state as when we were last on it. This means that the objects generated from templates or spawners must remain and NOT be respawned (which would effectively make completely new game objects).

Check out the video below:

RPG Dev Log 1 – Persist Game Objects Across Maps

Persisting Map Game Objects in a Cache

Next up was actually implementing some of the changes being discussed previously. In order to make this work in our RPG, my goal was to:

  1. Allow maps to save a lookup of the unique IDs for game objects that were generated
  2. Save the list of game objects generated into a “cache”
  3. Upon revisiting a map, tap into the “cache” to reload the existing game objects

One of my mental hurdles with this was acknowledging that we don’t yet have a solid serialization foundation for our game. I was thinking I’d want to serialize the game data to something persistent to make this work, but I was also worried writing things to disk would be overkill (and how does this mix with save game concepts?). Instead, I opted for the lightweight approach was “get something working” and I can revisit this later to extend it to persist things to disk if necessary.

Check out the video below:

RPG Dev Log 2 – Persisting Map Game Objects in a Cache

Which Domain Does This Belong To?

We’ve been trying to practice Domain Driven Design (DDD) concepts in our game. One pattern I’ve taken to an extreme is over-separating domains into very granular pieces and the result is that we have HUNDREDS of C# projects. It’s overkill, for sure. However, I feel that it’s offered some flexibility in having boundaries we can collapse later. My experience so far has told me it’s easier to collapse boundaries than it is to split.

This is all and well until we have situations where I need a class that has knowledge of two domains. That’s what this next video was about. I talk through acknowledging that I don’t know what to do and that I’ll move ahead with something best effort. I think the answer to my dilemma is that I need to translate things into a new domain for usage, but it feels like overkill. If you have thoughts on this leave a comment on this post or on the video!

Check out the video below:

RPG Dev Log 3 – Which Domain Does This Belong To?

Death Animations For All!

Finally, this last update was about something hopefully less boring… Death animations! I worked through how:

  1. I can extend our reusable sprite animation factory to create a death animation to be reused by ALL our actor sprites
  2. I can build a system that checks actor life and changes the animation as necessary to death

Unfortunately I had some hiccups the first time through recording this, but I wanted to code the whole thing live. After a Blue Screen of Death interrupted my first attempt, my second attempt I think worked pretty well! Without much code at all we could get this system fired up and it worked the first time! Well, close. I didn’t realize that our animation system already supports an animation that has an “infinite” duration final frame (in this case, the body laying on the tile). This is handled by a null value instead of a set length in seconds. I fixed it right after recording! Overall, I was incredibly happy with the result.

Check out the video below:

RPG Dev Log 4 – Death Animations For All!

Video Stream – RPG Systems with Loot Generation

I asked on LinkedIn about whether or not people would be interested in a video stream that focused on programming, and I had some positive feedback. In order to test the waters, I decided I’d start with some system-design stuff given that I’m going through a bunch of practice with distributed systems. This is a bit of a change up from distributed systems in that this is interactions between co-located systems in a game framework I’m creating.

Here’s the video!

In the video stream, what I’m trying to accomplish is finding a way to share information from particular domains to be used in other domain. I mean, that’s the gist of it 🙂 The complicated parts are:

  • How do I keep domain information from leaking into other domains
  • How do I control access to the information without globally exposing it (i.e. avoiding something like a static global variable)
  • How do I make sure I have the right state when I want to go use it? (i.e. the systems run on a game loop, but some interactions that get triggered are from user events outside of the game loop)

My white-boarding skills in MS Paint are pretty rough, but I feel like it went okay! I’ll follow up with my findings, and hopefully get some programming videos put together to better explain some programming concepts.

Let me know what you think!


RPG Development Progress Pulse – Entry 1

Progress Pulse

Progress Pulse – Entry 1

For the first entry in the progress pulse series I’ll touch on some things from the past week or so. There’s been a lot of smaller things being churned in the code base, some of them interesting, and others less interesting so I want to highlight a few. As a side note, it’s really cool to see that the layout and architecture is allowing for features to be added pretty easily, so I’ll dive a bit deeper on that. Overall, I’m pretty happy with how things are going.

Unity3D – Don’t Fight It!

I heard from a colleague before that Unity3D does some things you might not like, but don’t try to fight it, just go with it. To me, that’s a challenge. If I’m going to be spending time coding in something I want it to be with an API that I enjoy. I don’t want to spend time fighting it. An example of this is how I played with the stitching pattern to make my Autofac life easier with Unity3D behaviours.

However, I met my match recently. At work, we were doing an internal hackathon where we could work on projects of our choosing over a 24 hour period, and they didn’t have to be related to work at all. It’s a great way to collaborate with your peers and learn new things. I worked on Macerus and ProjectXyz. I was reaching a point where I had enough small seemingly corner-case bugs switching scenes and resetting things that I decided it was dragging my productivity down. It wasn’t exciting work, but I had to do something about it.

After debugging some console logs (I still have to figure out how to get visual studio properly attached for debugging… Maybe I’ll write an article on that when I figure it out?) I noticed I had a scenario that could only happen if one of my objects was running some work at the same time… as itself? Which shouldn’t happen. Basically, I had caught a scenario where my asynchronous code was running two instances of worker threads and it was a scenario in my game that should never occur.

I tried putting in task cancellation and waiting into my unity game. I managed to hang the main thread on scene switching and application close. No dice. I spent a few hours trying to play around with a paradigm here where I could make my ProjectXyz game engine object run asynchronously within Unity and not be a huge headache.

I needed to stop fighting it though. There was an easier solution.

I could make a synchronous and asynchronous API to my game engine. If you have a game where you want the engine on a thread, call it Async(). Unity3D already has its own game engine loop. Why re-invent it? So in Unity3D, I can simply just call the synchronous version of the game engine’s API. With this little switch, suddenly I fixed about 3 or 4 bugs. I had to stop fighting the synchronous pattern with my asynchronous code.

The lesson? Sometimes you can just come up with a simple solution that’s an alternative instead of hammering away trying to fix a problem you created yourself.

DevOps – Build & Copy Dependencies

This one for me has been one of my biggest nightmares so far.

The structure of my current game setup is as follows:

  • ProjectXyz.sln: The solution that contains all of my back-end shared game framework code. This is the really generic stuff I’m trying to build up so that I can build other games with generic pieces if I wanted to.
  • Macerus.sln: The game-specific business logic for my RPG built using ProjectXyz as a dependency. Strictly business logic though.
  • Macerus Unity: The project that Unity3D creates. This contains presentation layer code built on Macerus.sln outputs and ProjectXyz.sln outputs.

I currently don’t have my builds set up to create nuget packages. This would probably be an awesome route to go, but I also think it might result in a ton of churn right now too as the different pieces are constantly seeing churn. It’s probably something I’ll revisit as things harden, but for now it seems like too much effort given the trade off.

So what have I been doing?

  • I build ProjectXyz.sln.
    • The outputs go into this solution’s bin folder
  • I build Macerus.sln
    • There’s a prebuild step that copies ProjectXyz dependencies over
    • The outputs go into this solutions bin folder
  • I use a custom in-editor menu to copy dependencies into my Unity project
    • This resets my current “dependencies” asset folder
    • The build outputs form the other solutions are copied over
  • I can run the project with new code!

This is a little tedious, sure. But it hasn’t been awful. The problem? Visual studio can only seem to clean what it has knowledge about.

I’ve been refactoring and renaming assemblies to better fit the structure I want. A side note worth mentioning is that MUCH of my code is pluggable… The framework is very light and most things are injected via Autofac from enumerating plugin modules. One of the side effects is that downstream dependencies of ProjectXyz.sln (i.e. Macerus.sln) have build outputs that include some of the old DLLs prior to the rename. And now… Visual Studio doesn’t seem to want to clean then up on build. So what happens?

Unity3D starts automatically referencing these orphaned dlls and the auto-plugin loading is having some crazy behaviour. I’ve been seeing APIs show up that haven’t existed for weeks because some stale DLL is now showing up after an update to the dependencies. This kind of thing was chewing up HOURS of my debugging time. Not going to fly.

I decided to expand my menu a bit more. I now call MSBuild.exe on my dependency solutions prior to copying over dependencies. This removes two completely manual steps from the process I also purged my local bin directories. Now when I encounter this problem of orphaned DLLs, my single click to update all my content can let me churn iterations faster, and shorten my debugging time. Unfortunately still not an ultimate solution to the orphaned dependencies lingering around, but it’s better.

The lesson learned here was that sometimes you don’t need THE solution to your problem, but if you can make temporarily fixing it or troubleshooting it easier then it might be good enough to move forward for now.


  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress