I never considered myself naive when it came to the amount of planning that goes into a game, but there have always been certain things that I have taken for granted. A great game just works, and if the game is immersive enough, the player simply doesn't have room to question exactly how it all fits together. It's seamless. If the player can feel the seams (via bugs or bad design), the game won't make it very far.
This is why, in games ranging from Pokemon to Halo to Final Fantasy [whatever number] to WoW, the player doesn't scratch her head and ask why her character doesn't fall through the ground, or how gravity works, or how the game knows when to play a sound or to animate the character in a certain way. Good games don't allow these questions to come up, which is why most players don't really consider them.
But now that I'm on the other end of the screen, it's time to dig in and answer those questions in my own way. One of those seemingly simple things that we tend to take for granted is a game's dialog. Skybrawler is a story-based game with a huge number of NPCs (non-player characters), which means that I have to develop a system to track and manage all of the various dialog that will pop up during the game. And more importantly, the dialog that is displayed must match the portion of the game the player has reached.
Let's take Chief Engineer James Daniels as an example. He's in the game right from the start, and the player will have hundreds of opportunities to talk to him as the game progresses. Obviously, Daniels can't say the same thing over and over; that wouldn't make sense, and it would surely prevent the story from going anywhere. Instead, Daniels needs to say different things depending on where and when you talk to him. If he just helped you take on an army of Stonefangs, he should say something about it afterwards when you talk to him.
So each major character will have an entire library of phrases that must be conjured by the game, depending on when that character speaks. And if that's not a daunting enough task, I have to make sure that I assemble this library of dialog in such a way that it is flexible. That is, if I need to make a change as to how the dialogue is displayed, I don't want to go in and manually change every single stored chunk of text; I should be able to change one variable at the top end, and the lower-level functions should flex accordingly.
I think I have the basic system down, but I need to ensure that it is functional, efficient, and flexible before I go about actually implementing it. It would be a hell of a job to undo it once it's in place.
This is why, in games ranging from Pokemon to Halo to Final Fantasy [whatever number] to WoW, the player doesn't scratch her head and ask why her character doesn't fall through the ground, or how gravity works, or how the game knows when to play a sound or to animate the character in a certain way. Good games don't allow these questions to come up, which is why most players don't really consider them.
But now that I'm on the other end of the screen, it's time to dig in and answer those questions in my own way. One of those seemingly simple things that we tend to take for granted is a game's dialog. Skybrawler is a story-based game with a huge number of NPCs (non-player characters), which means that I have to develop a system to track and manage all of the various dialog that will pop up during the game. And more importantly, the dialog that is displayed must match the portion of the game the player has reached.
Let's take Chief Engineer James Daniels as an example. He's in the game right from the start, and the player will have hundreds of opportunities to talk to him as the game progresses. Obviously, Daniels can't say the same thing over and over; that wouldn't make sense, and it would surely prevent the story from going anywhere. Instead, Daniels needs to say different things depending on where and when you talk to him. If he just helped you take on an army of Stonefangs, he should say something about it afterwards when you talk to him.
So each major character will have an entire library of phrases that must be conjured by the game, depending on when that character speaks. And if that's not a daunting enough task, I have to make sure that I assemble this library of dialog in such a way that it is flexible. That is, if I need to make a change as to how the dialogue is displayed, I don't want to go in and manually change every single stored chunk of text; I should be able to change one variable at the top end, and the lower-level functions should flex accordingly.
I think I have the basic system down, but I need to ensure that it is functional, efficient, and flexible before I go about actually implementing it. It would be a hell of a job to undo it once it's in place.
No comments:
Post a Comment