We started day two bright and early in order to get the most out of the day. We also tried our best to keep to our priority list, although at times we had to deviate slightly in order to figure out the more basic mechanics of the game. Our main goal for the day was to get as much of the first level done as possible so that we could polish it the next day and perhaps work on any of the “extra content” we’d come up with.
Since none of us had done game jams before or built an entire game from scratch, there was quite a massive learning curve. In my personal opinion, it was also difficult working with such a variety of people with multiple skill sets, each at their own level of ability. This made me feel a little sub-par. I think it was also an overall difficult endeavour since it was taking place at our house, which meant there was no real downtime in between the game development. Sometimes people were staying up all night working on something, while others tried to sleep, which meant not everyone was involved in the activity at all times and there was some catching up. I think, in a professional or school environment, this might be a lot easier.
We actually began with the player and movements. I won’t go into every detail of the script, but there were certain things that tripped us up; the first was the colliders not working correctly with the crates. What I have found out is that, sometimes the more knowledge you have is actually detrimental to figuring out the simpler solutions. We had to look into a way to store the direction the player was moving as North, East, South, and West, then compare the player’s coordinates to the whether something was occupying the space the player was attempting to move to on the grid.
It took many hours to figure out a way to do this, but eventually we we stored the player’s future coordinates (tempCoords) to compare them to the crates in a StaticContainer game object parent. If the coordinates ended up being the same, then the player wouldn’t be allowed to move into that space. If the coordinates were different, then the player was allowed to move to the tempCoords.
One thing we took great care in doing was annotating as best as we could, for future reference. It’s something I’ve not done extremely often in the scripts I’ve made before, but it is something I need to get in the habit of. This was especially true when we had three people writing a variety of scripts and putting them together for different uses.
I think one of the main reasons we had to do this sort of addition to the player’s movements was because we were working on a grid-based movement system rather than just letting the player freely move. The objects and player didn’t necessarily fill the same amount of each grid square, but they would share the same centre coordinates and thus a fix like this worked.
The player script we ended up with was the fifth variation, since we had to make additions to coincide with other issues that cropped up throughout the day. However, it was actually the Guard script that was the most challenging thing I’ve tackled in programming to date…
Alison had come across waypoints in a Unity tutorial she’d done in the past, so we decided that this would be a good way to set up the lab assistants’ paths throughout the levels. Afterwards, I came up with the suggestion of actually using empty game objects with a certain naming pattern, place at the coordinates you want the guard to pass through, and this way it would be easier to adjust the paths or create new ones throughout future levels. Unfortunately, we didn’t get around to doing this and went with just scripting the waypoints in. I would like to futher explore my idea, though, but I didn’t want to argue the fact in the middle of the jam. The way it currently is scripted, each level would need its own LevelStats script made. As we learned in class, you don’t want to replicate script when you don’t need to.
In any case, the main components of the guard script are how the lab assistant will move through the waypoints, but more importantly I got to utilise raycasting to check for the player! The idea is really quite clever: the lab assistant will generate three rays that check the left point, mid point, and right point in a conical shape, which then verifies whether the player can be seen or not. This is set through bools and checks whether the line to the player is blocked by an object (such as a crate) or is free so the assistant can see the animal.
I think this script is perfect for this kind of game and something to keep in mind for any future sneak-like games I might consider making in the future!
By the end of the day, we’d managed to get the player moving a mouse and the lab assistant walking around hunting for any animals on the loose. Marc and Dean had managed to create a bulk of the assets and Dean designed a few level options/layouts for us to start building the first level of the game.