WHAT THE CORE MECHANICS ARE
Once we had got an animation team, we needed to tell them what game we wanted to make for sure. We had shown them both of our prototypes, and they liked both of them a lot. They were most excited about the time-changing game, and so were we. So we decided that would be the game that we would be working on with them for the rest of the project. The 2 main mechanics, other than standard platformer mechanics, i.e. running, jumping, pushing blocks would be using the scroll to travel through time, a total of 3 periods (past, present and future). As well as this the player would be equipped with a tool that would allow them to freeze objects in time (i.e. a “Freeze Gun”). This would allow the player to take objects through time/ keep them in their current state in time. The player would be able to freeze a maximum of 2 objects (left click and right click). To unfreeze objects, the player must left click with the mouse over that object again. This would hopefully add a catch that objects could block the player so they cannot unfreeze an object that needs to be unfrozen.
To help us design puzzles, we thought it was best to get a really good understanding of how the mechanics worked, so we could build levels from a solid foundation, with explicit rules in place. That would help to give us the most creative freedom: as there would be the least amount of ambiguity of how these puzzles would be played out, so we could design the levels with intention for how the player could (and would) play them. The time changing mechanic had already been prototyped earlier, to show the animators what we wanted to create, so the other mechanic (aside for player movement, enemies, etc.) was freezing objects in time. Before this was prototyped, it was conceptualized how this could be executed. The plan was similar to the diagram below.
Player fires ray → ray hits object → player clicks left or right when ray is over object → object hit by ray is stored in static data that it is frozen → When time changes, the objects frozen in static data ignore changes until unfrozen.
Line goes from player to mouse position → when line hits object it has a green outline → when object is selected as ‘frozen’ it gas a blue/yellow outline. The object will also show up in the UI somewhere.
To draw lines from the player to the mouse position seemed easy initially. The plan was to use the line renderer with 2 points, one at the players position, and one at the mouse position. I placed the line renderer component on the player, and added a script that would update the line positions 0 & 1 every frame. This didn’t work initially because of 2 things: the line renderer used local space, and the player was not static. To overcome this, i created an empty game object that stored only a line renderer component, and switched it to use global space instead. I tried nesting this within the player, but for some reason affected the transform of the player, and instead of working out why we just kept it totally seperate. After this I was able to draw a line to the mouse position, and then cut it off when the line passed into an object, using a raycast.
The second challenge came about when I wanted to draw lines around frozen objects. The first idea was not to use a line renderer at all, but to use different sprites for when the object was frozen and when it was not. The reason behind this is because we could not work how to draw a shape around a sprite. This was soon dismissed, as it would mean that for every sprite created, 2 other “frozen state” sprites would have to be created, which would triple the animation team’s workload.
After a day or so of deliberation, we remembered that a polygon collider will automatically draw a collider around a sprite of any shape, and a polygon collider uses an array of Vectors just like a line renderer, so we could use the same values to draw the line.
After a few hours of work, we ended up with a script that would find the polygon collider, and use its values to draw around the object with a line renderer. Again, the line renderer was not attached to the object, as it was affecting it’s transform. Instead a container prefab was created, that contained both an empty object with just a line renderer, and the object itself which contained a poly collider, and the script that would find the points and send them to the line renderer.
This works well, as for any sprite of any shape, the line would be drawn dynamically, so we would never have to handle creating bespoke outlines, the system would do it for us.
As for now, the objects frozen was stored in Static data, but this changed nothing. It would still be affected by time changes. We decided that this was not a big challenge to overcome, but was not yet necessary to do, so we left it until later.
Overall, this prototype proved a point to us, that a few extra hours of work at the start of the project could save countless hours down the line, and it will be something we consider when creating all of our mechanics for this game, and any other projects in the future.