Ball Box - Week 1
- Jason Warrick
- Jun 9, 2022
- 4 min read
Updated: Jul 17, 2022
Following the development of a physics-based dexterity and puzzle game.
So let's start with the concept:
The idea for the game is a 2D puzzle game (Developed in 3D) where a player has to move a ball through a box containing different kinds of obstacles by rotating and moving the box. I want to work with a dialogue system, so the story framework for the game is that you're playing it on a friend's couch as they chat to you about what you're doing, and you can choose responses to direct the conversation.
I started by making a very, VERY simple test "level" to get the physics working and test the movement. At this point it's pretty much just a group of cubes with a rigidbody sphere, but the next task was to implement movement.
Before that I wanted to set up the GitHub repo for the project, that way I can track all of the versions of the game, rather than uploading it when it's finished which is sometimes what I end up doing if I'm being lazy (I know, I know!).
Using the new input system in Unity, I set up controller and keyboard input, which worked at first which was nice! I did start to run into some pretty tricky errors, being that VS Code stopped recognizing the input system package, which meant my scripts couldn't use it (which renders it pretty useless). I tried a variety of things to fix this, like restarting VS Code, Unity, and my computer, as well as reinstalling the package, updating both Unity and the package, as well as reverting versions of either to try and fix it, but that all just ended up making it more complicated, so I decided to check out Rewired.
And thank god I did! After about 10 minutes of setup (which vastly outperformed the hour and a half that the input system took to unsuccessfully debug), I had working, accessible, tweakable inputs from the keyboard and a controller! I definitely could've solved the input system problem, but Rewired was just so much easier and more pleasant to use that I don't regret it, even in the slightest.
As you could probably tell in the previous video, the collision was pretty terrible at first. So, I read through the CCD (continuous collision detection) documents on the Unity website, as well as some additional forum posts, and got a marginally better physics collision system! This mostly just involved adding more rigid bodies and changing the detection mode to either continuous, or continuous speculative, which immediately made the collisions more accurate, although they still had a ways to go. With this project, I really wanted to focus on accurate collisions, so this was a subject I wanted to dive into more.
Upon even more forum post scouring and documentation examining I figured out that decreasing the physics timestep can improve the responsiveness of collisions, at the cost of performance of course. Since the scale of the game is so small, I feel like I can get away with exploiting this, so I did! it didn't fix all of the issues (corners are still pretty funky), but it's plenty good enough to build the rest of the game around, and I wouldn't feel to terrible about shipping it out in its current state if it comes to it!
Another change I made after that was to transition over to moving the rigid body of the box, rather than altering the transform, as that can prevent the object from clipping into walls as much. The difference between this and the above iteration are more of a change in feeling than appearance, so I'll spare you another near identical testing clip.
This was the point in the project where I was really starting to feel the lack of organization that was looming over my head, so I made a trello board (seen above) and made a bunch of categories and tasks that will guide me towards a mostly finished game. I'm hoping that this will also help limit scope creep, as I will always be acutely aware of what I should be doing, which is usually working on new, unnecessary features or content.
For not only testing purposes but also my own enjoyment, I expanded the testing level a bit, that way I can see how it feels to actually navigate around something within the box. As well as the additional terrain, I also made a prefab game object that spawns a ball in its OnAwake method, and can also be triggered by other game objects, as its public.
While I was trying to make a win area prefab, I ran into an issue with the RigidBody.move functionality. Since that method targets the rigid body specifically, the children of the game object don't move with it, at least if they're empty game objects (which they are in this case). You can see this demonstrated here, with the scene view on the left showing the stationary win point that would ideally be moving with the box.
The solution to this issue took a while to reach, but is ultimately very simple: I just made both the win and spawn points cubes with rigid bodies, and then set their colliders to be triggers. This accomplishes two things, the first being that the points now move with the box, and the ball doesn't collide with the newly formed 3D objects. You may say, "Jason, couldn't you have just added a box collider and rigid body to the original empty game object," to which I would say "I tried that but the objects still wouldn't move." As an added testing and fun element at this point, I made the winning and spawning an infinite loop. This most certainly isn't going to be in the final game and is just for testing, I just wanted to explain the strange mechanic while I have the chance!
So, that is week one of Ball Box development! I'm slowly learning all of the wonderful, strange, and terrible features and quirks of Unity, and am growing to appreciate them all! Next week is looking like a pretty heavy week for mechanics development, which should make for a fun devlog, so see you then!
Comments