Asylum – Dev Diary 7 : Dialogue System
The dialogue system I started yesterday has been proving to be tougher than I expected. To put it into some perspective the game is created from instances, those instances are made from objects and each object is assigned a sprite (or series of sprites). Now my initial dialogue code was based on instances so that I could tell the engine to move the camera over to an instance of my choice and then show the dialogue after that. However it would appear that I cannot access an instance by using it’s name set inside a variable (string). However, an object name in a variable is OK. This seems a bit odd to me but if that’s what happens then fair enough.
After talking it though with a couple of forum users I made the change to use the object name. The camera now gracefully moved over to the object in question and I could continue developing the dialogue system.
I’ve also made a point of making sure that the process I’m using to store the dialogue is done in such a way that it could be translated easily later if necessary. At present I’m only planning for English, but you never know.
I’ve also created it in such a way that I can extend it if I want to. At present the dialogue system will just go through a series of text strings and pan to objects where needed, however I could extend it to show a picture such as the face of someone you’re talking to without too much trouble.
For the moment I think it’s looking really good. The player triggers the sequence, the camera pans across to focus on the tannoy intercom and the dialogue is then typed into the box that appears. A small … is displayed once the full text is shown indicating that it is waiting for the player to click or press space to continue. The next line is then typed on to the screen and this continues until all the dialogue is complete at which point the camera pans back to the player and the game continues.
Tannoy sprite is a placeholder for the time being.
Overhead Elements
One thing that I’m toying with is to have out of focus elements over head from the player, such as support beams, cables, pipes, etc. These could be used to guide the player but I don’t want them to look like they will block the player. This might be the case with the overhead support beams (below) but they are blurred quite heavily so it might be all right. We’ll see.