Hello! This is gonna be an update on the exploration journaling game, Take a Walk. It'll be mostly focused on how I implemented the core gameplay features seeing as those are mostly done and locked in. Here goes it...
Some info on the tools I'm using- I'm using Unity 5.3.2f1 for the main engine and programming scripts in C# using Microsoft Visual Studio. I haven't really found an advantage to using Visual Studio yet over MonoDevelop, but I guess it's something to hold over the Mac users in class... I'm using Trello for backlogging tasks and then I use Twine to outline the dialogue so I can see it all in front of me. For version control I'm using a combination of Smart SVN(the trial version) connected to a free Assembla server. Somewhere along the line I messed up or something so now Unity thinks my project is called "trunk." I tried to fix it but it broke a bunch of things so I decided to just go with it. That's pretty much it in terms of stuff I used for creating the gameplay, but I'll include more applications I as shift to the audiovisual portions of the game.
When I started off, I broke up my work into three main sections: the walking, the dialogue, and the writing. These sections stayed pretty true throughout the project without any major additions. The one thing that I would say expanded a lot more than I anticipated was the connection of everything through different scenes. The solution I have for that isn't really clean, but it works, so I'm not touching it (this is a pretty common theme). I'm just going to go through each section and talk about how I implemented each one.
So first one is the walking. At the most basic level, the player clicks somewhere on the screen and the character moves to that point. At the time of the gameplay prototype, the way that worked was by converting the mouse position to world position, storing that and using it as both a direction and a determining factor in the speed of the player, the idea being that the player slows down as they get closer to the point.
With that out of the way, I began working to get a pathway of colliders working because it's not a game unless I can place invisible walls in front of you. This was simple enough and went as expected if you're at all familiar with Unity. What I did have to figure out was the way I wanted the camera to follow the player. In a classic novice move, I made the camera just a child of the player so that they would always move together. Bad move. It turns out that that's really disorienting. So my first solution was basically just to delay the movement of the camera by less than a second and then have it just follow at the player's velocity. This worked pretty well, but it wasn't perfect. There were ways to get the camera misaligned since it was essentially moving the same way as the player but starting late and ending at the same time the player stopped. I learned about a little thing called lerping and now I just have the camera move half the distance between it's position and the player position every frame. I've had no problems with that.
Finally, I had to deal with scene switching. I messed around with the SceneManager utility in Unity because it kept telling me that Appplication.LoadLevel was deprecated, but every time I searched for help online for my problems, people just kept saying to use Application.LoadLevel. So I ignored my issues with that yellow line under my code and moved forward. The way Application.LoadLevel works means that I have to pick and choose which gameObjects to save between scenes. At this time, I save the player, the camera, and the character that's been selected for dialogue (more on this later). Then I also have some variables exposed so that when the player and camera pop into the next scene they can be put in the right position. This creates a weird popping effect from a frame or two that I plan on fixing in polish. All this adds up so that the player can hit a collider with the sceneLink script attached and be transported to the next scene. That's pretty much it for the moving around. Next up: dialogue.
For the dialogue, I had less of a clear idea of how to do it. So I researched on how to do it. Basically what I found was a bunch of these dialogue modules you could download from the Unity asset store, all of which I would've probably had to modify further for it to work the way I wanted. I'll keep my fifteen bucks, thank you very much. Some of my classmates were also implementing dialogue so I took a peak at what they were up to. Most of their systems were a little bit more involved than I needed because their emphasis was conveying plot points through dialogue. I just needed a simple system where the player an character could exchange one line at a time for a short conversation.
Basically I just settled on brute forcing it. I got a sprite, attached a canvas in world space to it, and gave it a trigger so that it would only appear when the player was colliding with it. The player can leave anytime they choose. In actually creating dialogue, I made two prefabs: one button for the player's options and a text box for the response. At any time in a conversation, the player will only have two options. Once an option is clicked it hides the buttons and presents the response using Unity's EventSystem. Next, I made a a script that basically handles moving from a character response to presenting the next two options since there isn't an easy way to tie it in to the EventSystem that I know of. This whole construction means that I have to write the text into Unity UI objects (which sucks) and also have to manually link options to responses and responses to options (which also sucks), but once again this works the way I want it to and I'm not writing dialogue on too big of a scale where it's going to take up a lot of my time.
The one big bug I had to deal with was one where when the player clicked on an option he would move towards that option and the canvas would disappear as he moved out of the trigger. I solved this by giving the dialogue character an additional two triggers over the buttons that become active when the canvas is active. Then when the player clicks while in dialogue, I check to see if I've hit the colliers with a raycast. If the player has clicked the button, they will not move. That was pretty much it for dialogue.
Finally, we arrive at the journaling aspect of the game. I thought that this was going to take the longest since I had absolutely no clue on how to write to an external file, but it turned out to be a breeze.
Basically, I just have a canvas attached to the camera in screen space that is set active whenever the player presses left ctrl. In this space there is a large text entry box, a word counter, a prompt, and directions on how to save the writing once players have written enough. Here's a screen shot.
This is a screenshot from where the game is as of the publishing of this update so you'll notice the visuals are quite a bit more progressed than if I had been thinking ahead and actually taken screenshots when this was all ugly default/programming art. But there really isn't a better way to describe it than to show it. I was able to find an old build of the game that I forgot I had kept so here's a screenshot from the original gameplay prototype. Learned my lesson on creating and saving builds as well so there ya go. Now back to your regularly scheduled devlog.
The last part of this puzzle is writing the text to an external file. I use StreamWriter which is a nifty little tool included in the System.IO library of the C# library.
That pretty much does it for going through the gameplay. This log took a lot longer to complete than I originally thought because of life, general busy-ness, and common laziness, but it is done! I just turned in an audiovisual prototype last week and in four (short and terrifying) weeks the polished product in all its glory will be waiting for all to download and play. So thanks for reading and hopefully I'll have a log explaining the early audiovisual work up before those four weeks are up.
P. S. Here's the massive list of everything I got done with this prototype: