Interactables and You

This entry is part 12 of 15 in the series Game Development

Previously On IT Ninja . . .

Last time I was busy working on the questing system. I did some stuff that was needed, but I still wasn’t happy with the way it all worked. Because of that I have spent time away from developing the game and just spent it thinking about how things should work. So, to replace my idea of a quest giver and an NPC and other stuff like that, I am going to create a catch-all Interactable. Quests, dialogue, interactions of all sorts will all be built on one system.

The reason this is important to do now is because if I make major changes later I will have to go back and fix all kinds of broken things. If there’s nothing in the game to break, there won’t be anything to fix! But it takes a lot of thinking and planning to figure out how this will all work.

And Now On IT Ninja . . .

Changes Everywhere

One of the big changes will be adding a “turn-in” for quests. This means when a quest is completed, the player must take an action to receive the reward. This will allow me to chain things together to help force the player to do what I want. So I’ll be rolling the quest giver, dialogue, and NPCs all up into one thing.

Proper Planning Is Paramount

I need to go back through and re-think how all of this works. Plan the behavior of this system from start to finish. Figure out all aspects of it, the procedural as well as the observable. So far I like what I have, but I’ll need to add a visual indicator if the interactable is important for some reason. So we’re changing that from a quest indicator to a “Hey, come talk to me for something important” thing. . . Could be a quest is available, or you can turn in a quest, or something else.

Or should I have each individual aspect have its own indicator? That would mean having to figure out logic behind deciding which indicator to show. With just one indicator for everything, I can turn that on or off as needed. Okay, so that’s decided.

Then I have the initial interaction. That will open the UI stuff I’ve already built. There will be a picture of whatever you’re interacting with, the title will be the name of that thing, and the big text area could contain . . . information about what you’re interacting with? I like where this is going. . . I could actually go back later at some point and change that, but for now it’ll be a descriptor or something.

From there you have buttons to choose your type of interaction, Talk, Gift, quest. Oh wait, if it’s a quest turn in, that will happen first when you interact. Then you get your choices. Buttons active if the option applies, hidden if not. Then when you click the button something happens appropriate to the button.

Putting It All Together

So this is where I actually go and make the changes in the existing game/code. As I think more about this, I feel like I need to create a new class just for interactions. This class will contain all the things I want, including the quest, the text stuff, whatever. Then I can just pass this one thing over to the UI manager which then deals with all of it.

Holy crap! I didn’t realize I never finished this post. I did (mostly) finish the work though. It took a lot of effort and a TON of changes to get things working the way I wanted. Let me walk you through what I’ve done. I have now completely replaced the original QuestGiver with the new Interactable. I modified the UI to fit this new idea and fought with the code for a long time to make it all work.

I’m going to walk you through the logic now, which was a bit complex. First, the interactable checks to see if it has a quest to give the player or if the player has a quest to turn in to it. If it does, it enables an indicator. When the player walks up to the interactable and interacts with it, the interaction starts. The interactable then puts together some data into a new class I created and sends that over to the UIManager to do the interacting.

The UIManager then looks at that data and determines what to do. If there’s a quest to turn in it does that and then the interaction ends. When there’s no quest to turn in it will enable buttons depending on what the interactable can do. If it has a quest, there’s a button for that, if the interactable can talk there’s a button for that, etc. . . Then the UI opens and you can do all kinds of stuff from there.

Challenges

I ran into a lot of issues as I put it together, mostly because of my confusing code and stepping away from the work for a while. It felt like every step had something broken that I had to work through. First it was the UI not opening properly, then it was parts of the UI not appearing, Once I felt everything was right I found issues with the quest turn in. I had to make a lot of modifications to the Quest Class, build a whole new Interaction class, and try to remember how my QuestTracker worked.

Next Time On IT Ninja . . .

There we have it, ripped out the old quest stuff and replaced it with something bigger and better. No more QuestGivers and NPCs, instead we just have one system for Interactables. Now that I’ve completely redone a major system within my game’s framework it’s time to implement another system that is extremely important. I’ve actually already started working on it, but we’ll go into that another time . . .

Series Navigation<< Questing ImprovedSound It Out >>

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.