Day 0: Makin’ a post, makin’ it real!

Hi all, super excited to finally kick this thing off! I found out about Devtober mid last month, and I thought it would be the perfect thing to get me out of my non-development rut. 

A bit about me: 
I work in the game industry, however I don’t do any actual development in my day job anymore. I’ve felt my dev skills slipping over this last year, and it’s bumming me out! Time to get back on track! My goal is to use Devtober as a way to get back into the habit of development and use the momentum to complete this project and ship by the start of next year. That feels like such a bold claim--but I’m hoping that by stating it publicly I’ll feel even more pressure to actually follow through. I think it’s fairly doable, given that my game is pretty simple. On that note…

About Don’t Suffer A Loan
Don’t Suffer A Loan is an orthographic voxel-based action game where you take on the role of a college graduate driven mad by their student debt.

After one too many phone calls from your student loan servicer suggesting you sell all of your belongings to make a loan payment (“It’s just stuff! Hey, do you live in a state where you can sell your blood?”), you finally snap. You make your way to your servicer’s corporate office to show them that their stuff is just stuff too. Smash your way through office equipment, posh furniture, and a whole lot of coffee mugs until your property damage value equates to your student debt. Just be sure to get your smashing in before security can get ahold of you!

Inspired by personal experience and reported tales by my comrades in debt, this game is designed to serve as an outlet for anyone who knows too well the frustrations that comes with living with student loans. 

Where I’ll start
I started this game back in 2017, and I managed to get the core gameplay loop prototyped before I put it on the backburner. I actually haven’t even pulled up the project files yet, but I unearthed my old Trello board and was pleased with how much I had knocked off the TODO. I’ll spend the first day or so getting oriented with the old project and updating it to Unity 2019 LTS, then do a proper evaluation of next steps.

Completed today:

• This post! No going back now!
• Brought project Trello back to the land of the living

Tomorrow TODO:

• Review Unity project, upgrade to 2019.4

Love it. Can't wait to see more. I'll be watching this thread. 

Day 1: Oh but those stats, though!

Day one is complete! And I even did the one thing on my TODO! I wanted to do more, but honestly I didn’t have much time today. I think there’s going to be a little bit of an adjustment period as I get back into the groove of developing in the evenings. But that right there friends is why you never over-promise anything! 

I had to go digging in an old hard drive, but I was able to recover the old Unity Project for Don’t Suffer A Loan (or as it was called at the time, Loan Game). It upgraded to Unity 2019.4 without any errors, which I think is as much of a testament to the simplicity of the project as it is to pure luck. 

Project Assessment Key Takeaways

Art! I’ve got it! Art! I need to make more!

So, one thing I did during the initial prototype stage was come up with the art style. As mentioned in the last post, DSAL is a voxel based game, and I wanted to lean hard into the hyper blocky aesthetic.

The entryway to your student loan servicer’s corporate office. The company’s name is Tenvina, and that’s definitely not an anagram!

A closeup of  your graduate self, with a cop ominously hanging out in the background. This is actually just a placeholder for development--in the final game you’ll be able to pick your gender, skin tone, hair style, and gown colors. Gotta make it personal!

I also wanted to keep the animations quite blocky, so instead of rigging the characters and animating keyframes, I instead decided to go stop-motion style, and create multiple models for each animation…

This is incredibly time consuming, but it accomplishes the exact look that I want, so I don’t mind the extra effort. There will also not be too terribly many unique meshes that I’ll need to animate, since much of the variety of the denizens of Tenvina corporate will come from texture swaps.

What really has me worried about this approach, however, is optimization. When I did the test animation above, I just switched the meshes on and off in the animation. Enabling and disabling meshes on the fly just seems like a recipe for disaster on a much larger scale, so I need to take some time to explore different optimization options (for example, I wonder if just disabling the renderer instead of the whole mesh would be better). This is definitely an area I want to explore more deeply before I start dedicating hours upon hours of animating everything else. 

Hallelujah I completed the stats UI functionality!

The core of DSAL is breaking stuff and keeping track of the value of the stuff you broke. There will be an on screen monetary UI tracker, but I also wanted the players to be able to go in and see a record of all of the unique items they destroyed on their adventure. Enter the Stats UI, which you’ll be able to access when you pause.

As you can see, there’s no nice UI design yet, but it’s all fully functional. The main part of the window rotates the selected object, but you can click on it and drag it around to look at it from any angle. Each item will have a little bit of info about it, the value, and the number of that item you’ve destroyed thus far. This design is heavily inspired by Katamari. I’m really excited that this is just ready to go, and I don’t have to think about it at all. Go past me!

The AI I wrote needs to go in the trash! 

The cop/security AI I wrote is really bad. The cops won’t chase the player, and get stuck at navigation points after a certain amount of time. So I’m just going to scrap the whole thing and start over--It would definitely be faster than trying to untangle the mess that’s there. I’d also like to try using Micosmo’s Sensor Toolkit, which I picked up during the last Unity Humble Bundle. It looked like a neat little asset and I haven’t had the chance to play with it much yet. This might be a great fit for it!

And that’s pretty much it for day 1! But tomorrow is Friday, and I expect to have a lot more time to put in more work! I’m still just so stoked about the stats! 

The player controller works fine!

...But I didn't expect it not to, so...yay!

Completed today:

• Unity Project Upgraded
• Patting my past self on the back for the stats window
• Patting my past self on the head for the crappy AI

Tomorrow TODO:

• Start working on the new cop AI

Shout out to MCGameFAP for replying to my thread! My first ever response to my first ever post, I felt so excited, yanno!

Day 2: Sensors!

Got a couple of good hours of work in today, although there’s not a ton of visual stuff to show off for my efforts quite yet! As planned, I started working on the cop’s new AI, and the first step in that process was to determine whether or not I wanted to work with Micosmo’s Sensor Toolkit, which I decided to move forward with. It’s a really straight forward system to work with, and it’s got some great FOV visualizers, which I’m a sucker for.

The toolkit also has some navigation functionality, although I wasn’t quite as impressed with that. I’m sure it’s probably user error on my side, but given how quick it is to work with Unity’s native navigation tools, I really don’t see much reason to use a different system. 

At the end of the day, all I ended up doing really just amounted to this:

Which of course looks incredibly basic, but that represents properly setting up sensors, colliders, figuring out physics layers, and so on. But now all the futzing around with a new system is over, so I can just focus on writing a state machine for our foe in blue. Here’s a flow chart I worked out for their behaviors:

I was also going through some old notes and was reminded of the fact that in addition to police, there’s also on site security present in the corporate office (which is why the flowchart is listed as both guard and police). At the start of the game you’ll only encounter security guards, who will be randomly distributed throughout the building. They’re much slower than police and have a smaller FOV, meaning it’s much easier to get around them during your destructive rampage. However, after a certain property damage value is hit, the cops are called in, and they’re serious business. They’ll be much faster (only running, versus security which also has a walk) and have a huge FOV (as seen above), so they’ll be harder to avoid. I’ll probably just extend the police class for security, but we’ll see how things go tomorrow when I have more time to work. 

I’ve set aside plenty of time tomorrow to really dig in, so I’m hoping that by the devlog check in I’ll have completed the cop’s AI. At the very least, I’ll be much further along the way!

Completed today:

• Evaluated Sensor Toolkit
• Integrated Sensor Toolkit into new cop AI script

Tomorrow TODO:

• Continuing work on the cop AI

Day 16: behavior Trees and I’m not dead yet (I’m getting better!)

I’m back! I’m bold! I’m--thinking that this is entirely too niche of a reference, so I’m moving on!

Oh boy, it has been a while. While I’ve utterly failed at devlogging every day, generally speaking I’ve been able to keep devving every day--Okay, with a couple of notable exceptions, but at one point my phone decided to kick the bucket and I had to go on a whole epic adventure to get a replacement. It was a thing. But I digress!

Most of the reason why I had avoided devlogging was out of shame, if I’m being honest. It turns out I’m way more out of practice programming than I realized, and I kept running into issues with my AI that I couldn’t code my way out of. The height (depth?) of the shame spiral was when I managed to get a stack overflow error in Unity, which was something that I had literally never managed to do before. I felt dumb, friends. 

The uptake of all of this is that I didn’t just give up. I tried two full iterations of my cop AI, first trying to run everything through a Switch statement, and then trying to iterate through different coroutines. I had varying degrees of success with each when it was just a matter of navigating through waypoints or chasing the player, but as soon as I tried to implement attacking behavior, it all just fell apart. After fighting with the scripts for a week I decided to change my approach and take a stab at creating a behavior tree.

I used some behavior tree assets in Unity in the past (most notably Rain by Rival Theory, if I want to really date myself here), and while I found the initial learning curve to be somewhat steep, I thought it might be worthwhile to attempt to bring them into DSAL. I can’t remember how I initially became aware of it, but I remembered a little BT system called Panda, and given that it had a free version, was well documented, and had multiple examples to study, I decided to give it a go. It was a decision I didn’t regret! I took a couple of days to get to know Panda, and then went about finally getting my cop AI where I wanted it to be. In the end, it was actually pretty simple to throw together. 

Panda was such a success that I was able to create the other patrolling AI within a few minutes of completing the Cop. So, DSAL now has a secondary fully functioning AI: Security!

(What do you mean they look alike?!)

Our Security friend here will actually be the first on the scene in the game--His team will be free roaming the office building from the moment our hero breaks in, though admittedly they don’t pose nearly as much of a threat as their police counterparts. Until Security spots the player, they’ll walk while they make their rounds throughout the building, and they’ll do it slowly. Once they see the player, they’ll start to run, but nobody in their division was on the track team--they run about half as quickly as the police, and their field of view is also reduced by half. In short, they’re really easy to avoid so long as their numbers don’t overwhelm the player.

Here’s the security guard and the police in action. You can see the cop is on the chase right away, while the guard feels like it’s out of his pay grade…

Eventually they both start beating on the grad. Rude.

So that’s it for now. Maybe it still doesn’t seem like much, but it really was a ton of work, and it represents getting past a major snag in production for me, so I’m rather pleased. Now that I’m comfortable with PandaBT, the remaining AI will be much faster to build. 

Completed today(over the last two weeks):

• Learned PandaBT
• Created Cop BT
• Created Security BT
• Created Security material swap
• Created Security walk cycle
• Put in soft hooks for game over scenario in game manager

Tomorrow TODO:

• Office worker BT!

Day 26: The Flight Patterns of the Common Office Worker

You know, it’s crazy how quickly this month has gone by. I’m both dreading and excited for it to be over. Admittedly there’s a certain event at the start of next month that’s been occasionally driving me to distraction! But, onto development news!

The first pass of the worker BT is complete. This is for the roaming worker--those that just can’t stay at their desks and walk around the work floor. I need to create the functionality for the workers who stay diligently at their workstations until the player comes along to wreak havoc, but the only difference there is in the first part of their tree, so that should be a quick adjustment tomorrow. As it stands, here’s what we’ve got:

Once the player enters their field of view, the workers immediately try to get away from them and once at a safe distance, beat a hasty retreat to the exit point. Every time they get within range of the player again, they recalculate a new position to run away to (which you can see best toward the end of the gif). 

I’m also toying with the idea of preventing the workers from freaking out until the first bit of damage has been done, and perhaps just regard the player with curiosity (in the form of a question mark above their heads) as they move past. This might cause some navigation issues though, so I might just shelve the idea for later.

As you’ve probably noticed, the workers themselves don’t have unique meshes for the moment. I was lucky previously with the guards and cops in that I had already created the meshes and the animations, but the workers never got beyond the concept phase. I’ll probably swap out the temporary mesh with the guard’s mesh just to make sure that the animations will run properly, but that will be it on the visuals for a bit. My new goal is to try and get all of the major programming done before the end of the month, and I’ve got a little bit to do for the UI functionality as well as the object destruction. Once those key pieces are handled, I think I’ll spend November focusing on the art side of things!

Completed:

• Wandering worker BT

Up Next:

• Stationary worker BT adjustment
• Animation test
• On Screen UI functionality
• Destroy all the objects!

Day 29(/30): It’s the same night so long as you report in before you go to bed, yeah?

The stationary worker is complete! I have also made a Really Ugly HUD! 

As you can see above, there’s a worker who stays put until they catch sight of the player, and then runs off into the sunset (actually, toward the nearest exit, which it decided was on the other side of the map). As I had planned on in the last post, I swapped the placeholder mesh with the guard mesh so I could test animation functionality--as you can see from the gif, all is good on that front. 

The Really Ugly HUD is also very simple. The user will be able to put in a goal debt (their own personal student loan debt, for example), and the bar will rise with the damage that they do until they meet their goal. There are actually four tiers of goals to meet after their own debt for players who like a challenge. The Really Ughly HUD is really ugly! I hate it! But it’s purely there for functionality’s sake for the moment as I honestly have no idea what the final design should be. 

So with those last two pieces, I really feel like it’s time to get back to the art side of things. I want to fine tune the object destruction, but to do that I really do need to have an attack animation for the player. 

Given how long it takes to create animation sets, I can’t imagine I’ll have time to post an update before the end of Devtober, so I figure now is the best time to give my final reflections and talk about next steps.

Obviously, I didn’t meet my goal of devlogging every day, and that is a bummer. Looking back though, I’m not sure how worthwhile it would have been to log every day. There were a lot of times where all I did was just fail at scripting something, and while I think it’s important and valuable for people to see that game development is a bumpy road with many setbacks, I’m not sure how entertaining a week’s worth of logs would be if they looked like this:

Day 1:

Tried to program an AI--Failed

Day 2:

How the heck do I keep failing with this AI?

Day 3:

I don’t remember what variables are anymore. What is a computer? I am a sheep herder.

Day 4:

Baaa

Day 5:

Oh god why was I so stupid? Got the AI working, here’s how I did it [functional logging]

Day 6:

JK Baaaaaa

Day 7:

Starting work on a dynamic level loader…

Or maybe it would be, I don’t know. 

Log failing aside, I think I’ve spent more time developing in Unity this month than I did in the previous nine. It feels good to be back in the saddle, and I do find myself remembering more and more as time goes by. In addition to DSAL, I was also involved with a weekend game jam and was given a small VR project to develop at work, so October me really has started to feel like a developer again. I want to keep this going, and I’m cautiously optimistic that I may still yet be able to reach my goal of an early 2021 release.

So what now?

I’m going to continue developing DSAL, and I think I’ll actually make a page for it here on itch and make a proper devlog going forward. There are a few pieces I want to put together first (a logo, primarily), but I think that’s going to be the biggest step in keeping me accountable. 

For DSAL itself, it’s art time. After I finish the animation sets for the player and fine tune the destruction, I’m going to work on the office worker meshes, animations, and texture variants. That’ll very likely get me through November! 

Once I get the page up for the game, I’ll post a link here in case anyone wants to follow along with the development. 

It’s been a fun ride, Devtober, I’ll see you next year!

Completed:

• Stationary worker BT
• Worker placeholder animations
• Property damage HUD

Up Next:

• Make an itch.io page for DSAL
• Animate the player
• Create and animate office workers