I have one month to make an MMO: Day 15
Finally got around to linking up the dialogue system, its parser, and the client dialogue display. I feel redeemed.
Sleep still not right though, it’s 7am as I write this…
Redoing the collision
So a few days ago when I was putting together a collision system for the first time in this project, I decided to use a method that deviates slightly from the standard way of doing things in order to reduce the number of collision checks.
Turns out there was a reason people didn’t do it in that way: it causes the characters to come to a dead stop rather than slide along vertical or horizontal surfaces. This makes the game’s controls feel bad when you’re near object collisions. So I’ve switched back to a more standard way of doing things
The code looks like this now, which is a more standard way of doing it.
Dialogue System
I’m using FriendlyCosmonaut’s dialogue system here. It’s an excellent dialogue system which I’ve used in a couple of previous projects. It has quite extensive feature, but can be installed and used quickly.
I do have a few gripes about how it can’t purely be data-driven, and requires some objects be made, but those can be worked around easily. Go check it out, and if you’re a GameMaker user and aren’t already aware of who FriendlyCosmonaut is, check out her Youtube and Twitter
There are two ways the dialogue system is integrated currently:
Environmental objects
Items in the environment, like signposts, and other dialogue triggers that have no interaction and are for displaying information only, have their texts “baked” into the map data as properties of the object.
Here is the signpost object in Tiled. It consists of a signpost on one of the tile layers; and then an extra obj_signpost object placed on top of it. The player will be able to see the tile, while the obj_signpost object will be invisible but will act as the trigger for showing the dialogue box. The text of the dialogue is kept as the text variable in the Custom Properties of the object.
These are loaded along with the chunk, and are handled purely on the client side. When the player interacts with the object, a dialogue is generated using data already loaded in from the chunk.
This is what it looks like when the player interacts with the above signpost.
Entity dialogues
Entity dialogues are a totally different beast. As previously discussed, entities in Tiled have a dialogue variable that points to their dialogue that’s created in Twine.
The below NPC, Old Man Mes, has in his custom properties the ID of his dialogue in Twine:
When you look at that dialogue on twine, you’ll see:
In the client, when the player interacts with the NPC, it sends a dialogue RPC to the server, which fetches the dialogue for this NPC out of Redis, parses it into the format that the dialogue box needs, and sends it over to the client for display.
So, unlike Environmental objects, NPCs actually has the dialogue served up from the server, which processes any Harlowe code that’s part of the dialogue (for example checking variables, or inventory). In the below example, it may not look like much, but this dialogue is actually being pulled out of the database, and is fully scriptable using Harlowe.
Unfortunately I don’t yet have the text choice selection hooked up, that’ll come later
Aside from the dialogue, you may have noticed a slight adjustment in the graphics, I’ve removed all the chunk debug displays, and added a different font. This suddenly makes the game look a bit better than it did before.
Day 15 Task summary
It feels good to finally get the whole NPC dialogue system hooked up. It’s by no means complete, I have a few loose ends to wrap up tomorrow, getting the multiple-choice selection added, and it’ll be an ongoing task to add whatever parsing features are needed by the scripting.
Tomorrow, the last day of this sprint will be dedicated to typing up loose ends, and fixing the ability for players to enter indoor locations.
