| Devlog #1 | Devlog #2 | Devlog #3 | Devlog #4 |
The previous #UntitledDrivingGame devlog ended on kind of a cliffhanger: I wasn’t sure about the future of the game and if I was going to keep actively developing it. While I ended up starting to explore some other project ideas, even releasing a new racing game prototype (Pickup Truck WTF) on itch.io, I decided that I wanted to continue building #UntitledDrivingGame. In this devlog I’ll talk about some of the factors that went into the decision, what’s changed in the game, & my plans for development over the coming months.
Watch the video version of this devlog on my YouTube channel!
It's been a while since the last devlog, sorry about that!
You can get an early pre-alpha preview build of #UntitledDrivingGame here on itch.io!
Follow me on Twitter for more regular updates on #UntitledDrivingGame and all my other projects!
Subscribe to my YouTube channel for video versions of these devlogs and more related content!
Been a little quiet recently but back working on #UntitledDrivingGame!— Tristan Cole (@elocnat) March 3, 2021
Doing some code cleanup & trying to make the vehicle feel better. Not sure if it's clear in the video but added some traction control & a button that breaks it (for now).#indiegame #indiedev #gamedev #UE4 pic.twitter.com/XuWWFNHTy9
The initial reason I wanted to put aside #UntitledDrivingGame was that I didn’t think (and still don’t, to be clear) it would be a commercial success and I thought it would take a lot of effort to get it to a place where I’d even be comfortable charging people for it. Since putting the game on the back burner and focusing on other things for a month or so, I’ve gained some fresh perspective on the project. Before I was focusing a little bit too much on the hypothetical end product and my inefficiencies instead of actively developing the game and learning as I go. This led to a lot of days where I barely got anything done because I felt like I was wasting time not building this magical end product that my skills and resources don’t currently allow for.
Additionally what I realized was that not only do I need temper my expectations for the end product but I need to legitimately release a finished game or else I’ll continue this cycle of making “prototypes” that end up as abandoned projects with 100 views on itch. Making new projects is exciting: I’ve learned it’s arguably the easiest part of development and the most addictive. You’re rapidly iterating while exploring fresh ideas and don’t have to worry about anything but the core gameplay experience you’re presenting. There’s not much like seeing a game idea in your head come together in playable form for the first time, but then comes the hard (and often boring) parts of making it into an actual product; fleshing out story lines/lore, fixing bugs and refactoring code, overhauling/contracting out final art, marketing/community building, adding polish, etc. It’s a lot easier to throw up a basic project page, call it a prototype, post about it once on Twitter and forget about it.
Here's a trailer for my short side adventure: Pickup Truck WTF
Overhauling acceleration curve & testing new engine sound
I’m now focused on finishing the game by setting more reasonable goals for my current skill level. I want to keep iterating on the current design and scope the project a little better in order to keep a clear and reachable end state. I’m still planning on keeping all the major features I’ve mentioned like multiplayer modes and character tricks, but I’m going to hone in on a few basic areas: keeping the gameplay tight, ensuring the art style is basic but attractive, making good level design choices that promote flow, and concentrating on replayability.
After the initial alpha release there was a small post-release update that fixed a few small issues such as persisting settings and fixing reverse direction. Since then I’ve made a handful of changes based on the feedback I’ve gotten mainly focused around improving the vehicle feel. In the currently available build the vehicle is very floaty and feels like it’s gliding around on ice all the time. I wanted that feeling for drifting but the vehicle needed some traction control to make it feel more like a real vehicle when driving regularly. Currently drifting is tied to the left controller face button and allows the player to use the mechanic as a combo extender (similar to a manual in THPS). One tradeoff of adding more traction has been that directional control feels a little less precise because the turning radius is noticeably larger. There’s still some tweaking to do, but overall the new traction feels like a welcome addition.
Another change to make the pawn feel more like a real vehicle was extending the acceleration/deceleration times. Before, the vehicle took off almost instantly from a stop to full speed; there was a small curve but it wasn’t very noticeable partly due to the instant camera lag. The player could also reverse almost instantaneously. I’ve made changes to the acceleration curve and slowed the camera lag a little so that the vehicle appears to take a second or two to get fully up to speed. It’s a subtle change but it feels better and makes the player give a little more thought before switching directions. I’m working on some updated engine sounds and fake gear switches to add to the effect.
Experimenting with a wheeled vehicle controller
First test with vertical wheel movement
I did spend a couple days experimenting with a new vehicle controller using UE4’s built-in simple wheeled vehicle component. Currently I’m using a static mesh setup and just lerping positions for moving parts like the wheels but I wanted to attempt using a skeletal mesh since the vehicle physical animations are built in already. I rigged the current truck model I’ve been using in Blender and imported it into UE4, added the wheeled vehicle component, changed some traction settings & added some flipping force and gave it a try. While it was nice to have the built in animations & the basic easy traction control to make it feel vehicle like, it just didn’t feel right going over jumps and flipping around. The wheels and friction made the speed fall too quickly on landing and it couldn’t maintain the same sense of speed the current vehicle does. I’m sure I could have made it work after a few weeks of tweaking but I didn’t think it was worth it to continue down that route. I can fake the vehicle animations on the static mesh for now and even switch to a skeletal mesh system in the future if necessary.
Speaking of visuals, I made a small change so that the vehicle wheels now fall (independently) when they are off the ground. It’s a nice addition that you notice when grinding or flipping around in the air even if it’s a little exaggerated currently. An even bigger visual change I made is adding a new vehicle. I love how it looks in game, but even better is the fact that it has separate body parts including all four doors, the trunk, and the hood! This model allowed me to start prototyping new trick modifiers the player can use to get more points. I’m still not sure of the final form of the trick list, but right now the player will be able to open all the main vehicle body parts at will in the air to add combo modifiers to the current tricks. I’ll expand on this next time after I’ve had some more time to implement and improve the mechanic!
Previously I was managing my tasks via an Asana Kanban board similar to how I’ve worked in the past. While this is a great model for a team environment, the longer I used it for this project the more I started to dislike it. I’d create tickets for things I needed to do and tasks that just kept piling up; it felt like it was removing my focus from the core of what I needed to do. While working on Pickup Truck WTF, I decided to just use a blank document and make various TODO lists that I split up in sections (usually weekly). I’ve done this for side projects in the past and often do it when I’m working on a separate board just to keep myself on track, but moving to this way of working really helped me narrow down and focus on specific tasks for my own projects. I choose one thing from the list to work on at a time, not skipping around weeks (occasionally I move things), and keep all the specific details of it in my head. I’m able to focus on the big picture task this way and micromanage the details of it in my head which so far works great for me. It will be a nightmare if anybody else joins the team, but it’s also not a huge change from the Kanban style so it will be easy to swap between them for solo and team projects/jobs.
Gameplay with the new traction control settings
Testing out the new vehicle trick modifiers
I’ve already mentioned that I want to focus on level design, tight gameplay, a basic but solid art style, and replayability, but those are more overall points of focus than specifics. Recently I applied for some funding to take the project to a polished vertical slice and laid out my ~6 month plan to achieve that. Depending on the amount of content at that point, I’ll make the decision to either release the game (early access), pitch it around to publishers (less likely), or maybe even try crowdfunding. The plan to get there includes:
Right now I’m focused on the vehicle section and nailing down the core gameplay and trick set. That’s what I’ll be working on until the next devlog; it’s the most important part of the game and needs to be really solid and fun to achieve the amount of replayability I’m pushing for. Adding characters and animating tricks is going to take a large chunk of time as I need to develop a workflow and get comfortable with the whole process. I’ll also have to start thinking about architecting the vehicle for multiplayer and doing some initial testing and code rework to make that possible.
Thanks for reading and following the development of #UntitledDrivingGame!
I’ll try to keep a max month between devlogs from here on out while I’m actively working on the game. Let me know what you think, give the pre-alpha build a try if you haven’t, and follow me on Twitter to get more regular updates on development!