Okay, yikes, that title sounds ominous, so I should clarify. (Though it also sounds a bit self-contradictory… how can you have Week One of a day?) The Last Day to Live is the title of a game. Or… will be the title of a game. It’s the game I’m creating for my personal project in the Unity Create With Code Live course.
I say “Week One”, but the course is actually currently on Week Five. In retrospect, I wish I’d thought to start this blog earlier and documented my progress through the course from the beginning. Though the first three weeks were devoted to preset projects that might not have been so interesting to write (or read) about anyway, so maybe it’s for the best that I didn’t start that early. Regardless, Week Four was the first week devoted to the personal project, so I guess that’s not a terrible place to start. So this post will be about what I did in my personal project last week. (As for what I did this week… well, read on.)
So, the point of the personal project was that, having learned the basics of the Unity editor, participants in the course were now to come up with ideas for their own original games they wanted to make. There were five main steps delineated in the process:
- Project Design Document—fill out a document describing what the project is going to be, and what specific features it’s going to include. (A template document was provided, with fields to fill in.)
- New Project With Primitives—block out your project in the Unity editor, using primitive shapes—cubes, spheres, etc.—instead of final graphics.
- Player Control—enable the control scheme for the player to move around the gameworld
- Basic Gameplay—implement enemies, powerups, and other game elements, and get the fundamental gameplay working
- Swap Out Your Assets—substitute final models for your original primitive shapes. (This step was listed as optional.)
Where am I in this the process? Well, as of the end of last week, I finished step 3. If you want to see my project design document, you can view it online, but here’s a summary: Last Day to Live is (well, will be) an action RPG, with the twist that the hero is doomed to die in one day’s time due to a terrible curse. (This does not mean a real-world day, of course. Time will pass faster in the gameworld than the real world. Exactly how much faster, I haven’t decided yet.) However, the hero has powerful allies who can bring him back to life if he dies by any means other than the curse—and if this happens, the clock on the curse is reset. This means sometimes it will actually be to the player’s advantage to die, and I have a number of ideas for puzzles that rely on this mechanic.
Not that I’m going to be able to implement a lot of those puzzles during the duration of the Create With Code Live course, of course. (The course ends with a “Graduation Play-a-thon” on September 9.) But I hope to at least have a minimum viable product that showcases how the game is supposed to work.
I put my (very) rough concept sketch at the top of this post (and it’s also in my project design document), but here it is again, just because:
So that’s the project design document. What about the actual project? Well, as I said, I’ve completed up to step 3; I’ve implemented the player movement… and that turned out to be a nontrivial task, because I’m going beyond the movement methods that were actually covered in the Create with Code class. Movement is largely handled by something called a NavMesh that facilitates pathfinding, making it (relatively) easy to allow the player to click on a location on the gameworld and have the character find a way there.
The thing is, I didn’t want that to be the only way to get around in the game. NavMesh navigation would avoid obstacles and find the best way to get to a location, but what if you didn’t want to avoid obstacles? I wanted to allow the player to make the character walk off a cliff and die if they wanted to, because given the premise of the game sometimes it might actually be useful to do that! So, in addition to clicking on a location to get there by pathfinding, I also wanted to give the player a way to guide the player’s movement more directly. In the design document, I said that shift-right clicking or middle clicking would make the character move straight toward the cursor; this was such a stupid idea that I completely forgot I’d written that until I looked back at my design document just now, and implemented a double-click to move straight toward the cursor instead. But then as I was testing the game I realized that this wasn’t the best way to do it either, and that it would work better to have the player click and hold the mouse button to move straight toward the cursor. So I changed the implementation to that instead, and after some tweaking of velocity and acceleration values I was happy with the result.
But then there was one more method of movement I wanted to implement. Although it’s not mentioned in the design document, I decided I also wanted the player to be able to use the space bar to jump. This turned out to be trickier than I thought, because as it turns out the NavMesh navigation method overrides the character’s position and doesn’t allow the character to leave the surface. (This also would have been an issue with jumping off cliffs with the click-and-hold movement method, of course, but I didn’t realize this till I tried to implement the jump.) I eventually solved the issue by just deactivating the NavMesh when the character jumped (well, technically deactivating not the NavMesh itself but that NavMeshAgent on the player character that made it follow the NavMesh), and then turning it back on when the player hit the ground. (Well, that and a bit of futzing around with velocities to make sure that the character jumped in the direction he’d been moving before the jump rather than just jumping straight up.)
At this point, here’s what the game looked like. Again, it’s not pretty; it’s just blocked out with primitive shapes rather than final models; but the navigation worked—though you can’t tell from this still image, so you’re just going to have to take my word for it.
Oh, hey, wait, come to think of it, you don’t have to take my word for it. I can put a WebGL version of the game online so you can play it! So I did, and here it is. I mean, I don’t recommend playing it, because nothing is really implemented so far except the player movement so there’s nothing to actually do in it (and I haven’t even made the camera follow the player yet, so if you do move around much you’ll quickly go out of view), but you can play it if you want to.
But there was still one problem. Well, two problems, technically, I guess. I didn’t turn off the NavMeshAgent when the player used the click-and-hold movement method, which means the player couldn’t actually walk off cliffs when using the click-and-hold method. But that’s an easy fix, and the reason I didn’t fix it right away was because of the other problem.
The code was a mess. It worked, but it was a mess. And as I added more features, it was just going to get messier. Eventually, the player was going to have to be able to attack enemies, and talk to NPCs, and that would mean more different cases to handle, and more branches and conditionals in the code, and there was a danger it was going to get seriously unwieldy.
But there was a way I could avoid this! I remembered seeing a Beginner Programming course on Unity Learn that included a section on Finite State Machines, which from what I skimmed of it looked like exactly the kind of thing I would need to keep the code simpler and better organized. So I figured that rather than forge ahead and keep implementing game features and end up with an impenetrable tangle of code, I ought to go through that course, learn more about Finite State Machines, and rewrite my code to use them before things got too out of hand. So… that’s where I am right now. I haven’t gone past implementing the player control yet because I want to clean up the code first, while it’s still in its early stages. But by the end of this weekend I hope to get through the Beginner Programming course, tighten up my code, and then move on to Step 4 and start implementing basic gameplay.
