So, on the last post we built the basic structure and flow of Dragon Quest’s Battle system. On this next one we’ll work on getting the visuals closer to the real one, adjusting the windows properly and finalizing the bottom log window so it scrolls the text.
Adjusting the Design
First let's extract the window from the screenshot I had. With that we are able to create the border and make the image I needed. Below you can see the screenshot and the extracted window image.
Unity already knows how to slice the image for you all you have to do is to set where you want it to. This is a must do if you want your game to hit multiple screen targets. Though this is not something I’m aiming for here it makes life easier if I want to later on create a brand new window for example.
Next I had used a screenshot from the game in order to position the windows in the same perfect spot. One thing to note is that on the left and top window the titles have a black background that sort of covers the white window border. In order to make it look like that I simply added a black background to each of my title text fields. Also note that on the left on the size is fixed so even if you added a larger name it would expand. I kept that in as well.
Next I had used a screenshot from the game in order to position the windows in the same perfect spot. One thing to note is that on the left and top window the titles have a black background that sort of covers the white window border. In order to make it look like that I simply added a black background to each of my title text fields. Also note that on the left on the size is fixed so even if you added a larger name it would expand. I kept that in as well.
Bottom Screen Smooth Text Display and Scroll Up
The bottom screen serves as a log of events to what’s happening in the battle. On the last version I simply cleared the text and added new one as I see fit, but on the original Dragon Quest the text showed by bits and the window scrolled up when full.
The basic workflow of the log window is:
Let’s look at some code now, shall we?
The basic workflow of the log window is:
- Receive text to be display and store it
- Every X seconds display a new letter on screen
- If the window is full scroll up
- If there’s still text to display go to Step 2
- No more text to display, wait
Let’s look at some code now, shall we?
This is the main section of our WindowBattleLog class. The textField is the variable that actually holds the text being displayed on screen. The textToAdd one is responsible for holding the text that is queued up to be shown next. This way I can “push” a lot of text in and the window will handle its display.
The textSpeed is responsible for how fast the letters will show one after the other and the scrollSpeed is actually a delay before I actually do scroll the text up. More on that later on.
The TOTAL_LINES and CHARS_PER_LINE tell me how many lines I want the window to have and the number of chars a line can have at most.
The textSpeed is responsible for how fast the letters will show one after the other and the scrollSpeed is actually a delay before I actually do scroll the text up. More on that later on.
The TOTAL_LINES and CHARS_PER_LINE tell me how many lines I want the window to have and the number of chars a line can have at most.
The AddText function is the entry point. That’s what I call everytime an action happens and I want to display it. It adds the new text to a variable. I also added a handy breakline option since DQ used quite a bit.
After that I do an invoke to the function that will really consume the text and show it by bits on the display. Note that I check if the invoke is already running at the beginning because if I'm just adding more text but the invoke is already consuming something, then there's no need for me to start it since it will loop by itself.
After that I do an invoke to the function that will really consume the text and show it by bits on the display. Note that I check if the invoke is already running at the beginning because if I'm just adding more text but the invoke is already consuming something, then there's no need for me to start it since it will loop by itself.
The add to display simply consumes the first char of the textToAdd string and adds it to the text field. If the length of the textToAdd is one then I just added the last letter so I can just cleat variable. If not then we advance the textToAdd one index.
Basically what we are doing is, say we did and AddText(”Command?”). The firs time, the AddToDisplay will consume the first letter “C” and show it on the screen. Then the variable will change from “Command?” to “ommand?” so on the next loop well consume the “o” instead. This way we always consume the first letter not matter the size of the textToAdd.
Note that before doing the invoke again I check if the window is full. Let’s take a look at that function.
Basically what we are doing is, say we did and AddText(”Command?”). The firs time, the AddToDisplay will consume the first letter “C” and show it on the screen. Then the variable will change from “Command?” to “ommand?” so on the next loop well consume the “o” instead. This way we always consume the first letter not matter the size of the textToAdd.
Note that before doing the invoke again I check if the window is full. Let’s take a look at that function.
The window will be full when I have more lines than the TOTAL_LINES amount. In order to count how many lines I have right now I loop through each char and check if it’s a “\n” (breakline) charactr. If it is then we increase the line amount.
Now, there is another case where “\n” won’t show up. Since unity will truncate the textField as the content is added we won’t get a new “\n” there. So if we add a very long text at once it will automatically breakline but a "\n" won't be found.
So, the way I solved that is since I know the number of chars a line has I just count them. If it reaches the quota them I can consider that a new line.
Now, there is another case where “\n” won’t show up. Since unity will truncate the textField as the content is added we won’t get a new “\n” there. So if we add a very long text at once it will automatically breakline but a "\n" won't be found.
So, the way I solved that is since I know the number of chars a line has I just count them. If it reaches the quota them I can consider that a new line.
If the window is full then we will scroll the text up. A quick hack I’m doing here is simply erasing the first line then moving the rest of the text to its position. Since it all happens quickly you get the impression the text actually moved up when it didn’t really.
So, first we find the index of second line via checking for a “\n” but as mentioned before there might be lines without a “\n” between them. So if the secondLine index is bigger the CHARS_PER_LINE we are sure that is the second case I mentioned so we can surely consider the index as CHARS_PER_LINE + 1.
With that done we get the substring starting from the second line index we just found until the end string. Meaning the length minus the second line index value.
Next we simply set the text displayed as the substring. The result can be seen ahead:
So, first we find the index of second line via checking for a “\n” but as mentioned before there might be lines without a “\n” between them. So if the secondLine index is bigger the CHARS_PER_LINE we are sure that is the second case I mentioned so we can surely consider the index as CHARS_PER_LINE + 1.
With that done we get the substring starting from the second line index we just found until the end string. Meaning the length minus the second line index value.
Next we simply set the text displayed as the substring. The result can be seen ahead:
Improving Text Display Calls and Organization
Now let’s take a look at how the calls to the WindowBattleLog are:
It’s looking ok right? But a bit messy. Before moving ahead to other things let’s organize this a bit. First let’s create another class to help us out.
Vocab is just a static class to hold some data for us. In this case it relates to the text we’ll be displaying. This is another nice hack you can use to quickly organize data. This makes it easy to use and and maintain but definitely not the right approach for a larger scale project. Then again, we need to use the right solutions and this one fits with our problem.
With the class set up let’s use it now:
With the class set up let’s use it now:
The major advantage of having the Vocab class is that if you want to change the text being displayed you don’t need to touch the class that handles the logic. It separates possible future problems.
Here's the final result:
Here's the final result:
That's it for part II! Please feel free to look through the code and question it. If you missed the first post you can find it here.
On the next part we'll be going through the player window and command window. We'll be able to choose the command and the target. Please look forward to it!
On the next part we'll be going through the player window and command window. We'll be able to choose the command and the target. Please look forward to it!
RSS Feed
