Tara Saltine's : Counter Chaos Development Log
Movement System - 26/04
I've spent the first day (or two) working on the core movement system - even though it was always meant to be simple, I haven't actually worked on a rigidbody-based movement system before that isn't super restricted. The top photo showcases the first evenings system attempt - I had a core system working fine using a vector3 to determine movement direction, but when it came to having my system work in tandem with the orbiting camera I encountered like a LOT of issues. I attempted to solve this by complicating the system further & further (ironically, with the goal of keeping it a one-line system with direction setting and character movement), at one point attempting to use a function I'd never used to try and convert a world vector to a local vector to make the movement direction match with player rotation - looking back at this now that would NOT work lol. The main issue I was encountering with this system, was that I had set it up so that the camera rotation defined the players facing direction - which is really not what I had envisioned and I don't quite know why I did it... I started from scratch after a while of rewriting the simplest system over and over - the bottom example is what I produced at about 2 in the morning - and in a rare moment of clarity I looked in horror at what I'd made and decided to call it a night. JK, I'm too stubborn for that - I refused to sleep until I had the base function working. I was using a small portion of a tutorial to explain orbiting camera setup - and allowed myself a small glimpse of how they tied their movement system into the camera... It was essentially the first thing I wrote - almost exactly, with a slight change in formatting. My refusal to use resources makes things so much more fun - I love creating stuff from scratch - but it does waste time.
This was the final system when it came to setting angles - declaring the movement direction in the same way but using a player head in tandem with the camera direction to give the player a local movement direction instead of moving in relation to the world. That line at the bottom was what made the system function - unfortunately I cannot take credit for discovering this function on my own, as I didn't even know about Quaternion.AngleAxis before it was mentioned in the camera tutorial I was looking at. I'd say this was my movement done & tied into my camera - but I still have jumping & custom gravity to do. Honestly I thought rigidbody movement would be easier, but the lack of customisability and need to tie it into Unity's physics behaviour is annoying - setting speed & selecting the right force type was just trial & error. That's it for now - I probably won't discuss the next few bits I intend to work on (jump, ingredient pickups, etc) on here as they're likely to be boring. Ciao.
Dish Selection - 01/05
I've spent the past few days working on the dish selection menus pre-game - and frankly its made me realise how much I like working on UI or background logic-heavy stuff. I'm gonna keep the logs briefer from this point onwards - I love to ramble but the style in the previous post wasn't what I'm looking for in terms of a log. Basically everything here is done with IDs - each dish button has a corresponding ID - that ID is put into 2 dimensional array. I did not know they were a thing to be honest - I just knew I needed an array of arrays basically - to allow each dishID to contain all the associated mini-game IDs within using 1 variable. I used a slot system for the buttons so I could parent them to said slots and affix them to the backing element to allow scrolling. The filter buttons just set an ID as the filtered one, and check each slot of the second part in the array of the ID of the button that's about to be spawned. Fun system to work on, frankly as bad as it sounds I could go without programming any mechanics with ease - love a good system.
Playthrough / Manager System 03/05
Super enjoyed working on all the background stuff to make everything work. I opted to do this before programming any actual mechanics - in a previous project I experienced the pain of having my mechanics all done then trying to build a system to call everything around them. Changing up my approach again for this log by the way. Essentially the system switches between break and game states - wiping game elements and totting up the score at the start of each break. It goes through minigame IDs passed through, and decoded, from the dish selection screen discussed last post until completion. The system itself is quite short, the time consuming elements were just figuring out how it interacts with a timing management script and everything else in the game. I can't really showcase this system with a GIF, as it only visibly swaps a timer between 2 states with a screen effect on a delay - but trust me its working and its cool.
Dish Preparation 04/05
Thought I'd whack out my unique mechanic before working on any minigames, so I set to work on dish preparation today. To be honest, the base system is super simple - for once I tried to apply some visuals, specifically programming based visuals e.g camera transitions and moving UI elements so they'd still be grade-able elements. Pointing out first that there are 2 elements of dish preparation that don't match my plans and its killing me - but its the custom ingredients for each dish (system is set up to do this via the main id decoding into prep ingredient ids), and ingredient scaling based on individual minigames. I couldn't apply my implementation of the former because it's a visual change (requiring lots of annoying setup ergo time), and couldn't apply the latter because I'd need to read the in-button ID's of the former to determine which game score to grab. Apart from those issues though, the system works great - had a slight annoyance in the fact I decided, as a challenge, the prep controller wasn't gonna be in the scene upon start (even though prep is done in every dish?) but sorted it all out with many GameObject.Finds. I also chose to make the buttons subtractive (max count there on start, deletes the unnecessary ones) and change IDs - as a fun (though slightly less loading optimised) contrast to the additive spawning button prefabs I used on my main menu. In short, press a button, click twice to set axes like a claw machine, ingredient drops (scale based on score, for a cheeky hint at performance), boom - repeat that or click submit for a beautiful camera pan & score reveal. Just to clarify, the videos laggy because its a GIF, actual performance is smooth.
Veg Minigame 05/05
Finally onto my minigames - for my first 3 I wanted to hit the ones with unique movement modes, so opted for the veg themed one, I know it looks like cheese & peas but thats just the placeholder visuals I went for ok. Frankly, working on the vehicle controller was hell - its base functions were super duper easy scriptwise, which I dont enjoy. All the work came in the prefab - proper weight centers, wheel width, & mass all for it to still flip over. I spent a long while perfecting the prefab to get the base stability. I hate rigidbody movement. The current version flips very rarely, an aspect I want to go back and fix (particularly because a perfected stability system would allow a more engaging arena design) but at the minute I still have 8 minigames, 2 menus, and a system I want to get done and I can just about manage it if I rush a smidge - I'll likely return and make any polish changes after I've done EVERYTHING else for my project. I'm honestly partly trying to just cram in as much programming as I can because I'm not entirely sure whether I get judged on how nice the game plays to feel so much as the programming techniques I've displayed. I've been taking a modular approach to my ingredient behaviour - housing all the pickup behaviours (as theyre much simpler) in the normal base script, and any funky behaviours in external scripts I tack onto the prefab. These have a move script, that allows straight movement in a direction - down, up, forward, or backward, and with an added segment that allows them to either stop on terrain or pass through it. There is actually a new function in the ingredient movement script to decay speed over time, but that's spoilers for tomorrow's post.
Cheese Minigame 07/05
I chose to hit my cheese minigame next to showcase another movement mode. My original plan was to follow a tutorial for this - as much as I don't like it, I somewhat have to demonstrate proper usage of resources - but I ended up feeling a disconnect between their system and my games vibe so I wrote my own. This allowed me to keep the flight system rigidbody based - smoother and with some natural acceleration and deceleration (also fitting the convention of my other scripts). I used a modified version of the ingredient falling script I created for the veg minigame, with a speed decay function to create the lingering ingredients. Attached to the ingredients & hazards is a tack-on script that detects the player in a radius, the ingredients subtly path out of the players way to make them harder to collect - and the hazards do the opposite. I intentionally designed ingredient movement to only stop on tagged terrain so I'd be able to have them originate from the moon centres without getting stuck. I introduced a new dual spawning function in my ingredient spawner (along with one to spawn the ingredients in the moon centres with random rotations) to allow spawning of 2 ingredient/hazard types with different spawn weights. I far prefer this mini-game to my veg one - it just feels better to play even thought it's simpler. I like how the ingredients turned out with the moon space, even though they have set speed values and decay rates they don't form hollow spheres as I was concerned about. To hark back to the veg game for a second - I absolutely couldn't bring myself to leave the flipping issue unsolved, so made a quick system to respawn the player if they don't detect ground underneath them for 4 seconds.
Wheat Minigame 08/05
I chose wheat as my final of the core 3 mini-games - partially because I like it, partially because it shows off some interesting design differences to other videogames. I used a movement system (for the UFO) similar to one I used in a project last year with an alien theme - sort of as a reference. I had to alter some stuff to make it take camera rotation into account, but that was easy enough. I went for a tiled approach for the wheatfield - even though every rod of wheat carries its own rotation, because I have central tiles grouping them and controlling them in sets there's 25x less individual scripts and collision detections running. The central tiles detect the wind collliders, set the wheat as facing it, tilts it back, and scales it down - this happens for each wheat rod in the prefab. Because of these central tiles and the floating movement, I was able to keep the wheat rods super simple (being literally just a mesh-rendered cuboid) for optimisation reasons. The wind beam caused a few issues with the collider deletion not triggering the wheat tiles ontriggerexit - but I remedied this by teleporting it before deletion. I also worked on a pause system today - but its identical to any other pause system par the usage of one of my menu icon loops to instantiate tutorial images & text based on the current game or next game if in a break.
Fruit Minigame 08/05
Fruit was the leading game in terms of interest score on my survey - so I developed it next. The batting mechanic went quite interestingly - considering I had a parry reflection mechanics in my last project, I though I'd end up using similar functions but the end product was wildly different. I couldn't do distance checks for optimisation reasons given the number of projectile, couldn't use a trigger collider for detection since the projectiles are trigger, and couldn't use a rigidbody either because the origin position would disrupt player movement. I ended up using the sphere overlap function for detection - and after a few tests that ended up with me tilting the entire counter and players gravity, got it working easily. For reorientation, I used a raycast to detect hidden trigger colliders around the ingredient clumps to make aiming easier given the 3rd person camera, and for non hits just projected a position from the facing direction of the player - for both of these I used transform.LookAt to reorient the projectiles towards the position of an empty that would be moved to either the centre of whatever the cast hit (the ingredient clump) or the other point inline with player facing. The clumps just use the same logic the ingredients use to detect the player - but requiring a negative value (hazards) and a variable that only gets set true after deflection. The hazards have a light homing using slerp. I quite like the end result - definitely a good choice.
Sugar Minigame 09/05
Next up in terms of interest score was my sugar mini-game, the implementation for this one was quite simple. My original plan for the hovering ingredients involved using 2 colliders that swap the transform.movetoward target of the ingredient to each other on collision - I decided to go for a simpler system similar to my dish preparation placement (just moving forward, and flipping 180 on a set delay). I'm trying to cut down on using tags - so my bouncer & climber colliders were equipped with their own scripts, over the player detecting the collider tag in the player script. The bouncers use the players current falling gravity (increasing the longer they're in the air) as the basis for their bounce height - meaning the height of bounce is tied to fall height. I reset the gravity to base after bounce for a more natural feel. The pillar script is super simple - literally just when the player is in the trigger and holding space, add upwards force. There's a pound ability on the shift binding that multiples fall gravity for higher bounces - but that's literally the simplest thing, it full on just times the gravity by its set multiplier. I've no strong opinions on this mini-game - I think cheese remains my favourite still.
Squid Minigame 09/05
Finally for my secondary set, and this one wasn't decided by interest score, (in fact it had the lowest, but it was my fave concept and I wanted a protein ingredient anyway) was my squid minigame. The base ingredients constantly rotate towards the player and cast backwards, then take the renderer material of whatever they hit to apply it to themselves - its an imperfect camouflage because it doesn't take camera rotation fully into account, which is what I intended. The materials of the backing object have a light emission applied to them - just enough so the ingredient spheres don't really have rendered shading and they blend in a bit better with the backing elements. Instead of ingredients spawning throughout the game, I chose to spawn these all at base and have a scavenger hunt vibe - explorative movement was always meant to be the focus for this game, and I felt this captured it. The ink rain uses the previous ingredient movement script with an added function to the stop on terrain segment that allows it to detonate into a prefab on terrain - the ink spheres are just persistent hazards with a custom pickup effect that increases an ink value on the player. As this value increases, more ink canvases spawn and block the screen to reduce the players ability to subvert the camouflage with clever camera angling. I'm really happy with how this turned out - it's probably my favourite mini-game besides cheese to play, and I think the screen blocking's the right intensity without being annoying.
'Juice' Minigame 11/05
Instead of working on my settings or Tara hud elements, I reprioritised and decided to focus on mini-game development first (because there isn't really anything I need to put in settings, and the tara hud is technically a visual element). Working off the order from my survey, I went for juice next. I altered the ingredient spawning to simplify it slightly - instead of having the ingredients split off into hallucinations I realised I could just use the dual spawning system and a new ingredient behaviour. The ingredient behaviour checks the players hallucination value (determining fov and hallucinated vividity) on spawn to determine how opaque the hazard is. I decided just to alter what I could with the cinemachine camera (hence the FOV change over the planned, more severe, warping) both because getting involved in post processing kind of crosses the line into visuals and this was enough to demonstrate my concept, and two because given the time I have left I don't know if I'll be able to implement settings - and adding nauseating screen effects is something I'd never do with an accessibility toggle. I went for the sinking plates over the spinning plates (hence why I don't stop moving in the GIF) because, as I predicted, a custom system would be necessary to have them actually spin the player. The sinking plates are super simple, they just have a trigger equipped with a script - when the player enters the trigger it sets a variable to true that makes the plates move down to a set position, and when the player exits it sets it to false and makes the plate move up to a set position. While I do know vaguely what I'd do for the spinning plates, it'd be a BIG time sink for one mini-game and I'd rather just crack on since I had a back-up plan anyway. The hallucination value is increase by the floor hazard and hallucination ingredients - it's very much a game where one bad move can spiral into disaster, I suppose that brings in the alcohol themes in a strange way relating to substance abuse.
Oil Minigame 11/05
Next in line was my oil mini-game - and this one has some difference in overall format to the others. The slimes and ingredients need to switch between passive & hazardous states - to keep them in line I'd need a central script managing them. The controller's job is to do that, but with the previous format requiring the end delay I couldn't quite do that. I altered the general manager behaviour to also disable the elements this game enables, so I could axe that end delay in place of an IEnumerator to swap everything between the states. I used a navmesh agent for the slimes since I wanted the behaviour to be simple, they randomly path to invisible spots on the arena when passive, and set the navmesh target to the player when hazardous. I've been trying to cut down on tags, but without creating new script found I needed to introduce new ones for the slimes and chase modules attached to ingredients (enabled during heat state). I was originally getting the child of the ingredients, but this was a tad inconsistent with whether the visual or chase module ended up first in the index. I used the same overlap function as the fruit game for the whisking. Overall, I quite like this minigame - I was debating cutting the whisk because I couldn't represent a cooldown or overheat via the bar, but after revisiting my sketches I realised I could think of it more as a manual whisk and have it be spam click based so kept it in.
Chicken Minigame 11/05
And finally, last and least - by survey metric, and my overall impression - is the chicken minigame. The reason why I particularly like it the least is because it's the only mini-game that doesn't hinge on collecting ingredient pickups. I never set the collectibles in stone for any of my designs - it just happened that all of them follow that convention par this one. Had I developed other games with alternate ingredient gaining methods in mind, I don't think this would stand out to me in the slightly negative way that it does. Anyway onto the game, I used the player rigidbody magnitude and velocity to calculate a speed - and recorded this twice, once every movement frame for a current speed, and another with a couple frame delay for a previous speed. I smushed these together to form a speed difference float, and when the different is high into the positives a crash is detected - because the current speed is drastically lower than the last recorded one. That's about it for function really, the squares you see are rings that either impulse the player upwards or set a variable to true that causes the player to move consistently forward with the speed compounding with their normal movement - lowering control, and putting the speed above the threshold needed for crash detection.