I’ve talked about the design of the chopstick controls, and the abandoned idea of a custom controller for them: but now it’s time to delve into the nitty gritty, the thing that all designers resent: thinking practically and making your idea actually function.
Ideas are a dime a dozen. Anyone can THINK of a jetpack, but making one that actually works is something only a few have made progress in. We aren’t make a jetpack, but as a group of three students without much knowledge in either Unity or C# (the programming language used by UNity)… it sure hasn’t been easy.
Before figuring out the actual chopsticks, Edward implemented a simple ‘pick-up object’ and ‘drop object’ mechanic that allowed us to mess with objects interacting with each other in Unity. From that, all seemed right with the world… Unity detected object A was being held and hit into object B, then object B got moved. Object B’s movement even depending on WHERE object A hit it. Just a little teaser: things get trickier when you’re trying to move object B with, are not being ‘held’, they ARE the controls and aren’t supposed to move unless a button is pressed.
The actual chopstick controls were something that the team couldn’t figure out where to start with. I personally knew someone who could help us: funnily enough, he was my father. Although he did not have Unity experience, he had a lot of experience with programming and was able to create the starting point of the controls for us, giving the basic functions that we wanted.
From there, I tried implementing the controls into the scene we had been using for tests, without any changes to it: just to see what the immediately obvious “next steps” were.
- Firstly, at the time the direction the chopsticks faced were purely based on the WASD keys, but these were reserved for player character movement: so I’d need to figure out how to make the direction faced be controlled by the mouse (as was the original plan)
- Secondly the chopsticks needed to move when the player did, staying in the same position relative to the camera when the player moves in –or looks towards– any given direction.
- Thirdly, the chopsticks moving further away from the player (with the R key) or towards the player (with the F key) didn’t work as intended. It would move the chopsticks in a specific direction without regard to where the player or the chopsticks themselves were facing.
So how did things go for dealing with all of these?
- It was not too difficult to make it so that the mouse controlled things, all I had to do was get the X and Y axis movement of the mouse, and make it so that when those change WHILST the middle-mouse button (or incase one is using a mousepad on a laptop, the P key), the chopsticks face towards that direction. (Exactly as desired!).
- The second issue was also relatively simple to solve, but I took an embarrassing amount of time to realise that the solution was an option: I just made the chopsticks a ‘child’ of the 1st person camera in Unity. They stay in the exact position they should be, relative to the camera.
- This issue was a bit more awkward to solve. The initial problem was that the code first made, used the global XYZ axis; not the local (ie. object’s own) XYZ axis. So when it was going ‘forward’ it was going forward relative to the world, not forward in the direction the chopsticks’ faced towards. This was as simple as changing one part of the script that initially used ‘Vector3.forward’ and have it instead be ‘transform.forward’
- A fourth bug I noticed later in development was that ‘pinching’ the chopsticks together would not actually pinch all the way on some devices the game was playtested on. This was related to how it checked for mouse input every frame and used a variable to try to determine how ‘pinched’ it was, and stop moving once that variable reached a certain point.
- Depending on a PC capable of higher frame rates would actually have this variable reach its maximum sooner in the pinch process, because more updates occurred for it. I worked around this issue by making it check for mouse input on a ‘fixed update’, this made it so that it updated a fixed amount of frames, and made the pinching movement consistent with when the physics engine updates: so it was both a bug fix and allowed for increased consistency with how the chopsticks interact with physics-impacted objects.
So now the chopsticks controls actually *moved* the chopsticks in all the ways they should. But how did the chopsticks interact with other objects? I started by just adding a collider to the chopsticks, but as with all things in Unity: it’s never that simple. Objects would very often not react in any way to colliding with the chopsticks… but sometimes did.
I tried seeing if adding a rigidbody would help with this at all… doing that alone resulted in the chopsticks flying off when they hit a table. I worked around that by simply making the chopsticks ‘kinematic’ so that no force, collision, etc actually influence the chopsticks. This DID improve things, but it was still very buggy, with chopsticks and any touched object clipping through each other at times: especially if the chopsticks moved too quickly.
Additionally, if an object was being held by the chopsticks, and the player moved the chopsticks forward, the object would not move forward with them (as it would in reality). These issues took a long time to make substantial progress on, and even that progress has not fully fixed the problems: just made them (significantly) less frequent, with some of its own problems too.
So what DID I do to make progress on these issues? I’m sad you asked. In short, I created a script that made it so that when the chopsticks are touching another object that has the ‘interactable’ tag (stuff like a cup, NOT a table), that object becomes a ‘child’ of the chopsticks, and so they’ll move with them. But when they’re not touching the chopsticks, they stop being a child of them and thus will no longer move with them. Sounds simple enough right? Nope, due to all the mess of even giving an object a better collider than ‘box’ or ‘sphere’ that covers multiple angles, it was quite difficult to actually make work: because colliders would actually separate themselves from the object they were a part of, and it took many different attempted solutions to prevent this.
As I write this blog, there’s still other solutions being tested in an attempt to make the chopsticks work as intended relatively consistently. I honestly do not mind the idea that it sometimes bugs out: occasional bugs can be funny, but like any joke: the humour wears off the more times you tell it. Right now we have a member of staff at our university helping us out, and hopefully in a future blog post I will be able to end on a happier note.