itch.io

Aaaaaaaaaaaaaaaand done!

https://everythingisbacon.itch.io/the-fortune-teller

Well. Okay. "Done." I managed to submit by the skin of my teeth, goodness gracious. I cut it way too close. I snuck in under the wire with a PC build, but then decided to see if WebGL even worked. It actually does pretty nicely, sans fog. So I have both versions available now. I'm going to work on this for one more day (there's a day left in February after all), and try to really pretty up the WebGL build.

...Also, I have 22 more card descriptions I need to write up. Whoops! I wasn't kidding when I said before that I understood why people charged money for books on tarot descriptions. It's so much work! 

At some point this week I'm going to try and write up a postmortem about the project. There was a lot of stuff that I learned/relearned about Unity game production that I'd like to document. 

But anyway, now I rest.

Despite the lack of posting the last few days, I’ve made a good bit of progress. All of the fortune teller’s animations are complete and set up in sequence:

The only last bit to animate is the card itself moving to a more visible location for the player as the fortune teller describes what it represents, but in order to create that animation, I need to know where the dialogue box is going to sit.

And the dialogue system is what I’m working on right now. I’m using the (conveniently named) Dialogue System from the Unity asset store. I’ve got the script already set up and now I’m just trying to design an attractive looking UI, which is admittedly a weak point for me. I do have the text scrolling with a sound effect already set up, so that’s pretty cool! The Dialogue System can do an amazing amount of stuff, which means it's a little bit of a challenge to onboard with. I’m slowly getting the hang of it, though. I’ll post here once I have the dialogue box designed, but I’m going to refrain from showing the dialogue itself. After all, seeing that is half the fun! :)

Behold even more!

So the core code functionality is done for the tarot draw. It was…way easier than I actually expected it to be. I know the gif is fairly low quality, so I’ll drop a screenshot of the game manager here in a second, I just want to point out that when the cards on the table are updated every time a new draw is made. Now obviously this isn’t how it’ll function in game, I just wanted to make it clear that the link is there.

Hookay so, this is the manager:

We have a list that stores all of the Tarot card scriptable objects, three SO variables to hold the selected cards for the spread, and then the actual card meshes in the scene. 

How it works:

Currently this all runs off of the Draw Cards button in the Game Manager. 

• When the button is pressed, a method is run to select three random numbers between 0 and 78 (the number of cards in a Tarot deck). 
• I then test those three numbers against each other to make sure that there isn’t a duplicate among them. This is done with a do while loop. 
• I then shuffle the Tarot card list using the Fischer Yates Shuffle algorithm, and if you haven’t heard of that before don’t worry, I was in the same boat. But Googling is a mandatory skill and luckily someone on Unity answers actually had a code snippet ready to go: https://answers.unity.com/questions/486626/how-can-i-shuffle-alist.html
• Cards now properly shuffled, I assign each of the SO variables one of the cards from the list using the random numbers I generated as the list index.
• Cards now selected, I assign the SO’s image to the material assigned to the card meshes.

All in 73 lines of code! Obviously there will be more once I hook this functionality up into a final system, but I was really surprised by how little it took to draw those cards out.

So tomorrow, I’m going back to some animation work. I need to get those finished so I can finalize the flow. The fortune teller needs a shuffle animation, as well as a deck holding idle. Once that’s done, there are a few more loose threads here and there, but the main thing will be the dialogue boxes!

I will refrain from making estimations on timelines, as that’s bad luck. But I will say that I’m feeling very good about the progress on this project. And oh it felt so nice to program again.

Behold!

ALL of the Tarot scriptable objects are complete. Most of them have placeholder text, but at least now I can write the core card draw functionality. Which is precisely what I’m going to do tomorrow!

The card Scriptable Objects so far. This represents 907 words, which doesn’t seem like much now, but it takes a lot to read up on all these card meanings and translate them into useful blurbs for the game. In order to get everything running with the time I have left though, I’m going to have to make all of the SOs ahead of time and just put in filler text for now. That way I can make sure that the card draw is working properly and get the dialogue boxes working at the very least. Then I’ll just sneak in writing the full blurbs here and there when I can.

…I’m starting to appreciate why there are books published for card interpretations, geez.

Well, better than last week! Saturday evenings are generally dedicated to DnD, which is precisely what’s happening tonight. However I managed to sneak some time in and create the Scriptable Object for the Tarot card data. I use Odin, so they’re also quite pretty:

Writing the card blurbs is an interesting challenge. Since I’ll have no way of knowing what the user will be asking the fortune teller, I have to make the language as generalized as possible. It wouldn’t make sense for ‘you’ to be referenced if the user asked a question about a friend. 

I’m going to try and make the time to write them all out tomorrow. But we’ll see!

Clearly I forgot what a normal Friday is like, because I had way less time than I thought I would when I was making plans last night.

Either way, with my tiny bit of time, I made the card dealing animation.

I also made her antlers lighter since they were getting lost in the background. 

More tomorrow (should I make promises like this on a weekend?)!

Yep, I'm Bacon#5826 on Discord! :D 

Hey Thimras, you still interested in doing some music for this jam? I could really use some help in that department, as I have zero musical skills. Link to my game's thread, for convenience: https://itch.io/jam/arcade-arcanum-tarot-jam/topic/1904457/fortune-teller-game 

Particle effects, volumetric lights, and the first appearance of the tarot cards, oh my!

We also have a refined fortune teller. I added a few more details (and gave her antlers!), so now I’m happy with her. 

Hnnnggg that feel when art starts to come together…

Tomorrow will either be programming or animating, depending on what mood strikes me. If I’m feeling extra spicy, maybe a little of both.

New fog, who dis? 

Guess who got Aura 2 in a Humble Bundle once upon a time and forgot about it until tonight?!

I’ve never played around with it before, but just a bit of poking at buttons got me to something very close to what my original vision was, so I’m pretty happy. I’ll probably fiddle with it a little bit more, but I really need to finalize the ground before I say “Style Set!”

Also, we have a fortune teller!

I’m still not fully set on her outfit (it feels a little plain) which is why I only did a quick idle for tonight. I was able to get the key components of the outfit that I was envisioning, however. I knew from the beginning I wanted her to have braids popping out of her hood, and I wanted her eyes to glow. I added a mask in homage to not the terrible world we live in today, but to the merchants in Resident Evil 4---What’re ya buyin? What’re ya sellin? 

I’ve got the eye blinks running independently on a random timer, so she’ll sometimes blink at you a lot, and other times she’ll just…stare.

It’s hard to capture in the gif since I had to reduce the quality to upload it here, but I’m using a fun little hack with animation style mixing. The fortune teller’s idle animation is made by creating alternately configured versions of her mesh in MagicaVoxel--in other words, each frame is a unique mesh. The animation is just a matter of enabling and disabling the meshes in sequences. It’s not at all a time efficient way to animate, but it allows me to basically perfectly recreate pixel animation in voxel form, which is the aesthetic that I tend to stick to in my voxel work. The eye animation however…is linear! The reason for this is because I find selectively injecting smooth animations among stepped animations gives a fun otherworldly effect. The viewer might not immediately pick up on what’s going on, but they’ll get a sense that something is just slightly off, and this too is an aesthetic I like going for. 

You might also be sucking air through your teeth at the idea of animating via enabling and disabling meshes, but actually, it’s not as much of a processing overhead as you might think, especially in such a small project as this. Voxel meshes in this style by their nature are extremely low poly, and to get that pixel art look, you end up working with very few frames. I’ve had scenes full of 30+ fully animating characters in this way and haven’t experienced any frame loss at all. 

Ooh, what if she had antlers?

Questions for tomorrow. :)

Blaah. Just didn’t really feel the art tonight. Created some fog, not super happy with it at the moment, but it’s a starting point at least. I think it’s definitely time to move on to the fortune teller and revisit the environment at a later time. 

It’s a little hard to see, but here’s a gif of the fog:

And here’s a screen grab:

Aside from the normal background fog, I’ve added some symbols in the particle system. The concept is there but the execution isn’t quite yet. I’ll revisit it later on.

Here’s to better use of time tomorrow…

Here’s a fun fact about your dear pal Bacon: I don’t actually like weekends very much.

Well--I like the concept, I enjoy looking forward to them, but without the structure of the work week I become a sloth. I will live on the couch and binge TV shows and I’ll eat pastry and oh boy is that some wine? 

It’d be okay if it was just one day, but nope, my sloth just…sloths all over the full 48 hours. 

So I’m back at it again on a Monday, and let’s just pretend I never said I was going to update on Saturday, shall we?

Here’s another fun fact, and maybe you already know it (because I certainly do, but that doesn’t keep me from forgetting when it matters): In asset import settings, you’ve gotta tick the Generate Lightmap UVs box if you want things with emissive materials to glow. 

I spent far too much time fiddling around trying to get my imported meshes to emit and receive light. It was annoying. But it’s also fixed now:

No proper lighting pass yet, just got those assets a-glowing. 

I’m also still working on my vision for the exterior world. I think I really just need to get the fog in to finalize the direction. But here’s where I’m sitting now:

I created the sprite sheet for the fog particles. I have an interesting concept I want to play with tomorrow. 

Ah--Also, I’ve switched render pipelines. Maybe it wouldn’t have been a big deal in the end since half of the issue was forgetting about generating light maps, but hey, choose your battles, right?

Boo! I was tempted into the black hole of lighting/post processing tonight and ended up wasting a whole bunch of time. I was thinking “Oh, if I just block out some lights, it’d be really cool…”

I’ve basically done zero lighting or post processing work in URP, which is the render pipeline I saw fit to use for this project. Things are…different. I’m having serious thoughts about jumping ship and swimming back to the good island Built In Render Pipeline. Do I feel guilty about this consideration? Slightly. But the goal of this project is to get something out within the specified timeframe and to generally dev without stress, so… Yeah. I might go that route before I add too many more assets.

Speaking of assets, I did manage to make a few before I was pulled in by the illuminated Siren’s call. The tent interior has some more décor.

 I feel like I still need some stuff on the sides, but this is a tent, so it’s not like she’s going to be able to hang shelves. All the stuff hanging from the top of the tent will be glowing (thus my desire to test some stuff out), which will help break up the dark purple. 

I think these are all the accessories for now, though. I need to have a better sense of how much space the fortune teller will be taking up, especially with her animations.

..Plus there’s a different render pipeline to switch to..

I’m going out of town tomorrow, so there’ll be no updates until Saturday!

Alrighty, we’re officially in Unity! Tonight I made a couple more assets, then dumped everything into the engine so I could start blocking things out and see what other scene assets I need. I think I am going to make another tree or two for more variety, since the shot I set for the start menu is a bit wider than I had originally expected. I’m also going to make a few foliage pieces to help define a pathway that I’ve decided to add. Here’s a quick screenshot of how I envision the starting menu, complete with really ugly notes. :) 

I need to make several more assets for the tent interior, but I did make a pretty cool skull that you can see in the back. I still haven’t gotten to the fortune teller, so I ugly sketched her positioning. Any likeness to Among Us is entirely accidental I swear.

I haven’t decided on a color pallet for the fortune teller yet, but I want her to really pop, so it might end up being red? We’ll see. 

I’ll definitely be adding more stuff to the table. Right now I’m thinking of some candles for sure, maybe a small cauldron? I want more opportunities for glowing effects, as the tent itself will be much darker than the exterior environment. 

And that’s it for tonight!

Back at it for night two! Had a bit less time this evening but still managed to knock out a few assets. I feel like I have a vision for the scene now and I’m eager to get into Unity to try and make some cool ambient particle effects. Pixelated fog? Yes please! 

In the meantime, here’s what tonight produced:

The fortune telling table and chair for the player to sit on. This will be just inside of the tent.

I decided that there will be a glowing skull parameter around the tent, à la Baba Yaga. This isn’t  the first time I added bone fences to my artistic endeavors, and it won't be the last! 

Spooky tree! The player is going to find themselves in the middle of a strange forest, when aha! Suddenly the tent appears out of the fog. I might do a variant of the tree, but the scene is going to be pretty tightly focused and I think I can get away with just careful positioning. We’ll see once the scene is composed in Unity.

More assets tomorrow, and maaaaaybe the fortune teller herself. She’s going to be a bigger design deal so I might reserve her for an entire working session the night after next, but we’ll see.

Hey all,

First jam of 2022 for me after doing nothing at all in 2021. Going to try to do a few this year, but let’s start with this cool theme! Last month I was just thinking that the mechanics of Tarot would be a fun little programming challenge and then I came across this jam! Good timing. :)

Thanks to work I’ll probably only have an hour or so each night to put towards this, so I’m going to keep my project small. It’s going to be a fortune teller app with a voxel art style. I’ll be using Unity. I have a large-scale project that I’m working on that’s voxel based, so this is also a chance for me to explore some more artistic aspects of voxels that I haven’t been able to do in my other project. :) 

Tonight I came up with my concept, downloaded the tarot cards, and created the fortune teller tent asset. It’ll eventually be full of cool mysterious stuff! I’ve also sketched out the fortune teller, I might try to model her tomorrow if I don’t spend too much time on accessories.  

Last but not least, I researched a Tarot spread for the fortune teller to do readings with. If I suddenly end up with more time I might program a few different spreads, but for right now she’ll just be doing a simple three card “Answers from the Universe” deal. 

That’s it for now!

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

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 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 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 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 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

Thanks! :D

Definitely--I had sooo many ideas to add in, but I think my biggest accomplishment in this jam was resisting feature creep and actually submitting something that was at least had some complete gameplay loops rather than a heap of half made features! :D I really do want to go back and finish it, haha!

Oh yay someone noticed that!! 

I really enjoyed this one! 

UFO UFO UFO UFO 

I really like the rise of the animals in the beam! I only hinted at that in my game, but I think the full beam up is a very nice effect!

Thanks so much for the feedback! I definitely want to go back and bugfix this weekend :3