Introduction

I usually try to do a jam or two every month.  Typically, I'll do it solely for practice, fun, and to know what it's like to finish something; however, this time around I was truly seeking competition--and there sure was. The games released during this jam have been so incredibly creative that I almost feel a bit bad for not putting a little more time into my game's premise. Nonetheless, I feel proud in what I have done this time around for my first 3D game jam submission.

In this devlog, I want to talk about my initial thought process at the beginning of the game jam, my process of making the game itself, and all of the cut content that I didn't have time to implement or develop. Then, lastly, I want to discuss what I did wrong and what I could've done differently.  For the longest 8 days of my life, this was a super educational experience.

Thought Process

So starting from the theme reveal, the moment I saw "Time is Power," my mind snapped to traditional time powers (i.e. slowing and speeding up gameplay, reverse, etc). But then I realized: wait a minute, time IS power. It doesn't just have to be a superpower. It can, instead, provide you with powers.

And then the image came to me, exciting me to my core. 

Speeding down and drifting down curves, flying off ramps, passing through obstacles with reckless abandon as fast-paced rave music hypes the player up in the background while they only have 10 seconds left to get to the finish line. If only I could draw out how cool it sounded. But, instead of pivoting to that idea, I considered two additional ideas: a potential fighting/shooter game, and a time-based casual similar to that mobile game, Tomb of the Mask.

Then I chose the first idea.

However, it wasn't just because the racing game was so interesting to me; I legitimately considered the benefits and drawbacks of the three ideas.

Though I'd say I've become somewhat decent at it, I've made so many action games that considering a different type of gameplay intensity that didn't explicitly involve killing people would be a breath of fresh air (of course I still love action games, but still.) However, I may consider developing an action game in 3D one day--just not for this jam.

Furthermore, making a time-based casual in that way, where I base the image of it solely on another property, may prove unoriginal and difficult to adapt to. I will admit, however, that this idea probably could have worked just as well if I thought deeper about how it could be differentiated.

Nevertheless, I had made my decision. I would have a high-speed racing game against the clock, where completing the track fast enough rewarded you with powerups, perks, and car costumes. And I would finish it all in 4 days, a strategy I figured would really help me out with time-management.

And so, I went hard at work the next day.

Design Process

Design Summary

As is with all game jams, unless one is in some kind of decade-long game jam or just has that much expertise, the image they have in their head initially will almost never be what they submit. Since the deadline is so tight, time and careful effort should be put into making the game as fun and beautiful as possible while incorporating the initial vision in a way that is nonintrusive to the project's development time. This is a lesson I have learned many times before, but not as so brutally.

I truly believed I had a low scope; four levels, a couple of powerups, some costumes, and a bare-bones perk system where the extent of its complexity was teleportation. How bad could it be? Well, I could only develop two levels, two powerups, no costumes, and no perks. At least I added a tutorial.

In the rest of this section, you'll see how much I was able to develop my initial idea, and how much I wasn't.

Art Design

This had the least amount of problems. I find Blockbench really easy to use, especially having used it for one or two years, so making the car was simple enough. A chassis, and some wheels.

I also made the goal rings in the tutorial by pasting in a builtin ring-shaped mesh and rotating it 90 degrees (probably my best work).

I made the powerup icons in paint.net. For the shield icon, I modified free clipart of a shield, while for the portal icon, I made it myself using two circles and the arrow tool. I also made the checkmark you see when you beat the level fast enough using the shape tool.

Game Design

Game design was really fun and challenging. I often posted my work-in-progress stuff to Discord, as those who were active during the jam may recall.

To be frank, I didn't have enough time to intricately develop the theme. The powerups were kind of shoehorned in, and I didn't really test the levels enough to know if I gave the player too much time or too little time in the two levels.

During the jam I solved a lot of problems by applying basic physics to the situation. We want to limit the player's maximum velocity. Instead of manually adjusting the velocity, just use Unity's builtin friction system.  We want the player to be able to brake (something I forgot to tell the player in the tutorial, whoops.) Multiply the friction by a number. (Yeah, friction really helped me out during the making of this game.) Failing to consider alternative options such as those that are already builtin to the engine can create a worse experience than if one were to just use the builtin version.

Other problems were solved using pure experience, i.e. using a capsule collider on the car as opposed to a box collider so that it can go up ramps and even skip (very) slightly elevated platforms at high enough speeds, using a coroutine for the tutorial, using transform.forward in addforce, etc.

But then, there were some problems where I genuinely needed to think, and those took up a lot of the time I spent during the jam. If you've played the game, you'd know that the car is always angled parallel to the surface it moves along. To save time, instead of describing the timeline of my methods, I'll just describe its final version.

I used raycasting to find the normal, the perpendicular vector to the surface below the player. Then I used atan2 on the Y coordinate of the normal and the magnitude of its XZ coordinates (the square root of the sum of x squared and z squared) to find the angle with which I had to replace the x-rotation of the player. I then converted it from radians to degrees and offset the angle by 90 degrees.

It's hard to explain, but I'll try to describe it graphically; the method is essentially taking the normal of the raycast as it bounces off the surface. Then, it finds the hypotenuse of the triangle formed by the X and Z axes. Then, it draws another hypotenuse with the XZ one and the y coordinate of the normal. Finally, it finds the angle of this second hypotenuse and adjusts it so that it can be used.

I felt really proud for coming up with this, so I wanted to finally put it down on paper.

Of course, it wasn't flawless; when the player rotates horizontally on an inclined plane, the code does not adjust for that and causes the player to look as though they're mounted to the angled surface as they drive along it. If one were to turn around on any ramp, they would notice this. However, I felt that putting so much effort into trying to fix that would take away even more from what I felt was the time-killer of this project.

Level Design

Designing the levels was fun. It was by no means easy. I made them completely in Unity using primitives and modifying materials. 

The City level took two to four days, though I'm not quite sure where all the time goes during these things. A lot of my time may have been lost to my real-life obligations and responsibilities. However, the time may also have gone into the planning I put into the level, or lack-there-of. Planning is obviously important, but sometimes it's cooler to improvise a level as one goes on. Obviously, however, it isn't the most efficient nor stable way of doing things. This was evident in the difference between how I operated in building the City level and how I operated in building the Tower level.

With the City level, the only "plan" I had was the theme of a city. I built a border and some kind of gateway, and then made some buildings for the city. I added in a statue, a beach, a street with spikes, and an island. Here I was kind of just jumping around from concept to concept until it became kind of detached from the city theme as a whole.

For the Tower level, I planned it out quite simplistically in my notebook. You start in the ocean, then get on a bridge. Then, you go through a "sewer-system" and then through the hallway stairs of the clocktower. Finally, you enter some portals and teleport to the final part of the level, which takes place within the clock tower's clock. Here, the theme was more obvious; it's a shoreside clocktower. Whichever one you prefer, it's pretty clear that planning has its place when it comes to developing a focused and coherent idea, whether applied to level design, story, or even gameplay.

I think the most difficult thing about designing the levels was having to replay the game over and over again. Don't get me wrong; I liked playing my game. I personally felt I had made it quite fun and engaging. However, every time I added a new obstacle, I had to replay the game to make sure it was reachable, didn't send the player flying across the map when they made a turn, and blended into the rest of the track. This took a surprising number of hours when you add all of those testing-sessions up.

UI Design

UI design would be much more difficult if I hadn't made a way to handle buttons and other UI elements that I have shared among my other projects. Using scripts I made such as SwitchScreensOnButton and NextSceneOnButton made it so that I didn't have to write code just to show the player the level select menu or go to a certain level; I just had to throw in the script and change a few variables.

One thing, though, is that sometimes Unity screws me over by making buttons do nothing when clicked, almost at random. It's pretty annoying and made it so that you have to restart the game after beating the second level if you want to play the rest of the game with all powerups unlocked.

Cut Content

Let's see...

• The easter egg is kind of unfinished (it just kinda instakills you (won't spoil it here lol))
• As stated before, limited the amount of powerups and removed the idea of a perk-system
• Two levels instead of four
• Taxis in the City Level
• Dining Room and Living Room areas in the Tower Level
• Citizens in the Tower Level (Tower Level was made during crunch time)

However, I don't hate myself for not including this stuff. I did as much as I could, and I think this cut content helped me realize the true limitations of my skills, something humbling that will definitely improve how I manage my time in the future.

Mistakes and Takeaways

The powerups were kind of shoehorned in at the last minute. I failed to put enough time and effort into effectively incorporating the theme of "Time is Power" with the exception of the time limit. 

I should have planned my levels more carefully and with less... stuff. Attempting to make even 10 minutes of gameplay in 8 days didn't sound as hard at the start as it did now; I thought I could get away with making the levels 2 minutes long. The tracks, if played perfectly, cap at 1:40 minutes.

I should have thought about gameplay from the perspective of the player. I tested the game hastily, not bothering to think "will someone see this on their first try?" or "will someone know where to go from here?" The latter question I especially neglected. This leads into my next takeaway.

I should have gotten an outside source to playtest my game. Playtesting your game yourself is obviously the quickest way to verify your game is functional, but getting a second opinion is crucial. If you can have your playtester go through the game without you having to say a word or guide them, you are pretty much good. However, if you have to point at things and say, "go there" or "do this", you may want to reconsider your gameplay flow.

I should have put more time into making the mechanics feel right. This connects to the previous takeaway, as personally I felt the mechanics were comfortable; however, having made it, I understand best how it works and how best to manipulate it. Getting someone who has never seen your game before to try and play it and give their thoughts on the feel of your controls can benefit you greatly.

Lastly, I should've planned ahead more.

Conclusion

In conclusion, though I made a thousand and one mistakes, I feel that this is the first step to learning how to make 3D games that are fun, well-thought-out, and interesting. Though I don't believe I completely failed, I did misstep in some regards, and I will take those mistakes to the next games I make in my game dev journey. This jam was a great incentive to learn how to make a 3D game, and I thank the host for giving me the opportunity to do so with a unique and challenging theme.

Astok