Communicator up and running

posted in KrisWolfe
Published August 24, 2019
Advertisement

Hey all,

I just got my communicator working. It's not glamorous art, but it's good placeholder for now. I have 4 counselor robots for the 4 pillars of the game: Build, Navigation, Research, and Military.

CommunicatorUpdate.gif.70e462881af4ef68bf85bf486a3221b2.gif

The communicator blinks a button when we queue up a dialogue. The screen will then fade to the dialogue screen, where we display the character portrait, and run through the dialogue.

image.png.899938453fa3e0da6c6d7c6f82a2bb11.png

Lots of placeholder art. We run through the dialogue, we have lots of choices in the bottom portion of the screen when we get to options, and when it's done, we go back to the last screen we are on.

The DialogueDB keeps a dictionary of all the dialogue in the game, and we send it an enum to pop out the dialogue. The dialogue is queued with the respective counselor button, so if we get 3 messages at once, we will run through the dialogue when the player wants to deal with the messages based on which one came first. If there's more dialogue, the communicator will pop back up and the player can choose to run through the next dialogue.

So the next part is something I've spent all week trying to figure out how to handle. How does the game know when there is dialogue? I've thought alot about the observer pattern, but how do I hook up the observer pattern all throughout my code? I want dialogue to trigger when certain events happen. I want dialogue to trigger when you max out your resource stores and lose material. I want dialogue to trigger for ANYTHING. So how do I have my code listen in throughout without using monobehaviors and also not violating SOLID principles or the state of objects or anything that could possibly go wrong?

I came up with an idea to have a DialogueTrigger class. This is something I think I'm willing to sacrifice some SRP by having these triggers inside the classes of my Colony Map, or map tiles. For instance, if we max out our storage, and we are now not being inefficient, we will call the dialogue trigger class. Inside the trigger, it can count down, or if it's just an event, it will trigger the event. This will send a message to our dialogue database to trigger a dialogue, and then my dialogue system handles it from there.

So I can have these "portals" with dialogue triggers. The code doesn't know what the trigger is, it just sees a trigger and calls it. The class itself decides when to send the dialogue.

I really can't think of anymore elegant solution, so this is what I will be going with for now. Visual Studio is actually pretty good about keeping tabs on when these dialogue triggers are called from, so if I need to remove them, I'll have an easy reference back to them.

So the first step to game flow is to get these dialogue triggers working, which honestly shouldn't be hard, and then start polishing the game flow from start to finish...what do I want the player to see or do? This will be the next step to getting a playable prototype to start running it by some gamedev forums.

Previous Entry Combat System in place
Next Entry Refactor and Polish
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement