Devlog 2, basic systems
General Outcome:
In this devlog, most things touched on happened over the course of 2 weeks, as we had easter during this time, so production slightly slowed down, that said we managed to stay relatively on track. during this time, as a team, we realized how much we needed to get done for the upcoming playtest session, and we will be working over the next week to finish implementing these features and mechanics.
Jamie:
I added the ability for player 2, (tall player) to give "piggybacks" to player 1 (short player), this is so we can make the players dependent on each other during the game, and encourage interactivity between the players. this proved rather challenging, as currently, both players are running off the same prefab. firstly I had to be able to differentiate the players in code, so I made a script that allowed me to give the players a player ID in the playerDetails script.
This had quite a few hurdles to overcome, because the ID was coming from the inputManager, and I needed to get the variables into the playerDetails script, I had never done anything like this, so it was a challenge to find sources on the new input system that did what I wanted, in the end, I found a solution for another problem that was similar to mine, and changed/adapted the code so it would fit with my scripts.
all of this also allowed me to create objects in the scene that defined where players 1 and 2 would spawn, this would allow the level designers to create levels where the players would spawn in different locations
once I had the player IDs sorted I could go back to the main script and change the player's character based on their ID, so I made player 1 smaller, faster, and the color red, whilst player 2 was taller, slower, and blue
now finally after I got the ID system in, I could finally get the players to give each other a piggyback, I added an interact button and made some checks to see if both players were colliding with each other
then I made sure player one was set as a child of player 2, got rid of their rigid body, so they can't fall, and changed their position so they rest on top of the other player
finally when that was done I made another function that would give the player back their rigid body and kick them off the other player
The next task was getting the camera to follow both players at once, in theory, all I have to do is get the position of both players, then calculate the middle point, and set the camera to look at the middle point, then when the distance between the players get greater or smaller, I pan the camera back and forward.
simple in theory, but a few problems occurred, first was player position. at the start of the game, neither player is spawned in, meaning the camera has nothing to look at. so I created some variables that would be filled in once the players' are in the game
then I made a script that would do all the maths calculations, and change the cameras zoom and position based on the position of both players
Kim:
I took care of puzzle implementations/ ideas. The addition of all these features can be reused or combined at different levels. These are not the actual final levels. They’re visual representations of what I've written for easier understanding.
Level #1
I implemented the idea of timed puzzles. I think these are a must in platformer games. My idea is very simple and I came up with it when thinking about a minigame in another game. I took inspiration from the minigame Princess Quest in Five Nights at Freddy’s: Security Breach. The minigame uses mirroring to activate 6 lamps to proceed. I thought having a timed level where you have to collect a certain amount of something to open the door would be a good addition. I designed it to have some obstacles like P2 needs to activate a lever to allow P1 to continue gathering the collectable. The level won't be mirrored like in Princess Quest as that would cause problems. Princess Quest is single player in comparison to our game which is co-op.
Level #2
I decided to create a level that is on the easier side and would be good to implement near the start of the game. This level requires P2 to use their ice power and also introduces the idea of moving platforms. Once the hidden lever is activated the platform starts moving to allow the players to jump on it and proceed to the next level. This shows the player that things can be hidden behind ice walls, that platforms can now move and that lever can activate platforms. The moving platforms will have an addition behind them showing they can move. I got the idea for moving platforms from Ori and the will of the wisps.
Level #3
This level is also inspired by multiple platformers but Ori and the will of the wisps is the one that comes to mind. The addition of a toxic liquid to add some challenge. Once fallen in the toxic liquid, the player dies and respawns at the start of this level. To up the difficulty, the platforms could be moving and there could be crates to climb on the platforms. The player can now climb ladders (this needs to be fully checked if it can be implemented). This can be mixed with a time level to further increase the difficulty.
Level #4
This is a similar concept to the toxic liquid but there are spiked vines instead. If the player lands on the vines they will die and respawn at the start of the level. This level introduces falling platforms. The platforms have a 2 or 3-second window where it will fall. If the player fails the platforms will respawn. The falling platforms are represented by the chains holding them. The vines I think would be a great implementation in levels with biomes as it fits the theme of plants. These vines I took inspiration from Stick Fight. Some levels in stick fight have spikes that will kill you on impact.
Ben:
For this week I began designing the structure of the level for our game. The major puzzle aspects are going to be mainly a feature in the mid to late levels, so I was not as concerned with designing them. The levels I had decided to design are the first 3 levels. These levels should act as a way to teach the player the main mechanics. These levels lead up into a temple which will act as a sort of checkpoint. After this temple, new mechanics will begin to be shown and used. The first level was designed to teach the player the basics without showing them directly. I wanted to make the first section force the player playing as the older sibling to use the carry mechanic to carry the younger sibling down a fall as they are too scared to jump it themselves. Directly in your path is a movable box. It is placed in a way that you should not miss it and therefore you should not miss the prompt to push it. The box will be scratched with yellow markings. These markings will appear on every movable object. As the level design is not yet concrete, I also experimented with having the older sibling required to push the box close to the drop and then stand on top of it to catch the younger sibling, this would transition into the carry mechanic. In this way, it would demonstrate both mechanics together and would teach the player the basic controls without needing to be told directly. A problem I can see with teaching the players this way is that we did not teach the player how to move in the first place. This normally wouldn't be a problem but since this game is co-op, it is more important to teach the players how to move. I am thinking about the possibility of teaching the players how to move somehow through the starting screen. The level continues on where you use your newly learned mechanics to push a minecart, climb over a rooftop, and exit through a mineshaft. This level is the most concrete one idea-wise as it needed to be.
The second level is all about reinforcing what you have learned. This level visually will be much more uninhibited. You will drop out of the mineshaft using the same technique as the carry mechanic and will land in an underground habitat where grass and moss grow. In this area, you will need to use what you have learned in order to reach the next level
The third level will begin to test how well you have learned by increasing the difficulty and thinking of the player. The player will begin to find new objects with yellow markings. It is up to them if they will connect the dots between the yellow marks and the ability to push objects. The biome for this area is even greener. on the other side of the level is an entrance to the temple. In order. However, due to ceiling cracks falling, the bridge has snapped and fallen down. The players will be able to climb down the remnant of the bridge to reach the bottom. They will then have to navigate through tall grass. For this area, I had an idea of having the younger sibling be unable to see if they were in the grass as the grass is taller, but I feel that this will strip away more gameplay from the younger sibling. The idea of this level is to climb a tree in order to reach the temple. The growth of a large tree underground is unnatural and mystic. I want the growth of unnatural wildlife and foliage to tell the player that nature has adapted and evolved in order to grow there. If the player thinks about them, they may sooner realize that nature would only need to adapt if something happened to their previous habitat.
Files
Get In The Dark
In The Dark
Status | In development |
Author | Jamie.C |
Genre | Adventure |
More posts
- Devlog 1, getting startedApr 06, 2022
Leave a comment
Log in with itch.io to leave a comment.