More implementation on assets this week as we start fixing up the first levels a little bit. This meant making the leaf blower a little easier and more readable. We remodelled it and gave it animations to put into the level with. Also got the fire animations in that was just two mesh floating in a circle around each other. A pretty easy fix for a fire particle but really effective with it came to our game. Also went on to animate the talking sign that would help the player through the start of the level to make tutorials a little more obvious. Another thing that I worked on was animating a grab animation that would be masked so that his right arm would pick up the box instead of the box magnetising the player’s hand.
0 Comments
This week I junked an entire level concept.
The revolving platform idea that I came up with last week didn’t seem to be particularly interesting or allow me to do interesting things, so I decided to dump it. This was after spending the first two days of the week continuing with the concept, which I then decided was neither intuitive or fun and dumped it. This process was rather unusual - it represented a decent amount of work, and I had to come up with a replacement level that offered the same type of interesting mechanic. My plan over the next three days was a level that was built around rotating platforms, with different types planned. This will be used alongside pressure plates, gates, and the other mechanics that we already have present ingame. I’m pretty happy with this process to be honest, because it’s a case where I have been happy replacing content I have worked on with new content, if it doesn’t feel like it is up to the same level (or above) as the reset of the content in our game. Although the change took time, I wasn’t happy with how the level slotted in among the rest of our levels. In addition to this, I also altered the second level in the first world, removing some platforms that moved in-out and replacing them with static platforms. Some other platforms and walls have been added to force players to finish puzzles, as there were exploits that allowed players to move past the gate in the second half of the level. I fixed some other bugs in platform systems, like making sure that crates moved along platforms (an issue that is interfered with the first level in the jungle). Next week should be hugely productive, as I have the blueprint for the level (as well as the basic blockout) ready for puzzles to be dropped in and tested. Next week should be all of the time needed to develop the rest of the level, and then by week 5 the first two levels on my side should be done. With the addition of the new Aztec world into the game, the functionality of the level select needed to be modified in order to accommodate for the changing between worlds. This has now been set up in the van where the player has access to a lever which allows them to cycle through worlds. A camera shot has been set up to show the player standing at the lever as well as the door with the worlds name above it when interacting with the lever. When changing worlds the van doors are closed and the theming of the level select is changed to represent the new world that has been selected. For now, all of the Wild West props are disabled with a single call and all the Aztec props are enabled. This creates a delightful experience for the player when they walk out of the van and the new theme is revealed to them.
The save and load manager also needed to be tweaked to ensure that each time the world was changed the stats of each level were also appropriately loaded from the save file and changed. This also meant ensuring that the correct bridges had been built and the available levels teleporters had been activated. We also needed to ensure that each world was only accessible once the previous worlds 5 levels had been completed. This accessibility is now checked by the save load manager before changing the worlds. The teleporters in the level select have also been updated to hold an array of level names to load. In this way the save and load manager can now decide which level to load for each teleporter depending on the currently selected world. With the functionality of the level select now completed, the addition of new worlds will be quick and easy as all aspects of world selecting, new world additions and new level additions have been made completely modular to work with the existing core aspects. A new glider level is also currently being designed and built for the new Aztec world. The beginning of this level has now been built and resembles a gauntlet styled puzzle for the player to solve. It features four different paths for the player to traverse through, each with a unique and different challenge/puzzle to face. The player is required to grab a cube from each of these paths so that they are able to unlock the glider, which is visible to the player through an electric fence. At the beginning of the week (Monday/Tuesday) I went back and corrected some issues with the first level - namely, the pipe puzzle that I had created initially was not entertaining at all, so I removed it and replaced it with a smaller, concise platforming puzzle. I also adjusted timing values and platform placement to fix one of the puzzles in the later area, which was far too time consuming for the reward that the player received at the end. I’m generally happy with the result of this level, but I will probably revisit it in the third week and correct some issues that It has regarding how mediocre it feels currently.
Part of the issue that I have developing levels currently is the grappling hook. While the hook is fun to use and traverse the environment with, it limits level design somewhat in terms of how the environments have to be created. If the grappling points are present in the level, they generally change how the level is set out. Because the points allow players to traverse distances quickly, the distances are usually quite large. This means that larger levels have to be created, which leads to larger, emptier areas that are devoid of content ( somewhat more than I would like, in a lot of cases). In some levels, the grappling points are used quite well (such as the descent in level 3) but on the whole those areas should be rare, and make the player feel like they are set pieces to be enjoyed at particular stages. It is worth remembering that while it is our core mechanic, it should not be overused (for fear of all levels feeling the same) and instead should be used sparingly (such as the first part in the current level that I am building) to allow the player to traverse gaps or move around before going back to platforming. After that, the rest of the week was more about developing my level design skills than anything else. After the first week’s level, I was ready to improve the techniques that I was using to make sure the level did not feel similar to many of the Wild West ones. The result by Friday was something that I was very happy with - a revolving platform centre that leads the player further and further up the tower, requiring them to repeatedly walk across the centre section. This section took a while to get right, and I tried multiple different combinations - a multiple stage climbing structure that required the player to rotate it was not only too complex but also felt very samey, with the player looking at floor tiles for the majority of the time as they climbed up. I have plans for the rest of the level, which will include more creative and interesting platform applications, and a bit less of the grappling hook mechanics. In addition to this, I also fixed the Application.quit() bug that we have had for a long time, which prevented us from closing the application properly. The fix involved contact with the developers of obirope, who provided us with a patched version of their dll files that fixed the bug. After returning from our break, we decided to rescope the work that we had planned as we move into the gold build. The goal initially was to create three worlds, each with 5 levels present. We decided to cull the scope down to only two worlds, to make sure we can complete all of the content in the time we have left.
The remaining 8 weeks include two key appearances for us - appearing at both Armageddon and PAX Australia; we will be making sure to get feedback and opinion from as many people as possible while we are out in the public eye. The entire team is looking forward to this information, as we will use all of these new perspectives to make the game even greater. For this week, I worked on the newest level - our first jungle level. This level introduces the ‘megapad’, a pressure plate that is twice the size of a normal pressure plate - and requires twice as many crates. The megaplate will always require only two crates, and allows us to create puzzles where the player understands their objective immediately - that they require two crates to proceed. The two-plate puzzles will remain, and we will be able to use these independently to create solutions to puzzles where the plates are in completely different locations. This level has four side areas, which forces players to move around the level, solving the different puzzles. The plan for the second week is to create another level - and this time to change the approach to design - the first level is linear, with a group of different side puzzles hanging off the main corridor. The level in the second week may contain a linear approach, but avoid so many of the side areas in favour of creating a more concentrated experience. This week I designed and built a new level. Because I love the grappling mechanic so much, I wanted to explore this more, with a new twist. I implemented two small expansions to grappling; moving grapple points and grapple pulleys. Moving grapple points test player’s reactions, as they are required to jump between multiple moving grapple points and avoid electric fences. When connected to a grapple pulley, the grapple pulley will be pulled down and the objects attached to the grapple pulley will be pulled up. For example, an electric barrier might be lifted up by the pulley to allow the player to pass under it. These new twists on existing mechanics allowed me to create an interesting level. In world 2, guards exist to chase the player after being absent in world 1. A few small changes to the guards were made to ready them for the current version of the game as they had not been used since vertical slice.
Improvements have been made to the game’s feel and player feedback. Crates and buttons now have input icons appearing above them, just like the grapple points. The camera now rotates downwards automatically when the player is falling. The grapple points now have an offscreen indicator when the player is close to a grapple point, but not quite in range and the smoothness of player movement while grappling has been improved. This week Klepto underwent a slew of minor changes to improve the game’s quality of life. Improvements this week include:
The camera autorotation was challenging to get right but arguably yielded the biggest improvement to the game’s quality. The need for auto rotation arose from observing the people playing with controller during playtests. Unlike while using the mouse, many players found it hard to move the camera while performing actions such as jumping. I had some code from when I attempted autorotation before but I improved it to make it smoother. I revisited Jak 3, Ratchet and Clank 2 & Sly 2 to analyse the nuances of their camera systems. They all behaved similarly, the auto rotation was almost always occurring but it was slow to give the player enough time to counter its effects on the movement direction. Additionally, if the player ran directly towards the camera, the camera would not autorotate. This prevents the player from running in circles as the camera attempts to move behind the player. I replicated these features into my camera system. The autorotation while grappling required more thought. The closest example was Ratchet and Clank but that game does not have grappling sequences as expansive as ours. Additionally, there is only one way you need to go while grappling, there's no need to choose your swing direction. The auto camera rotation in those games appears to work by pointing the camera towards the next grapple point when you connect to a grapple point. I implemented a system whereby a child transform of the grapple point can be aimed at the next grapple in the sequence. When the player attaches to the first grapple, their camera will automatically be rotated towards the next grapple point. Of course, if the player moves the camera manually, autorotation will temporarily be ignored. In certain sections of our levels, the player needs to chose where they want to grapple to. To accommodate for this, that child transform described before can simply be set inactive and auto rotation for that particular grapple will be disabled. After a short break, we have now entered the gold phase of Klepto in which we plan on refining and tweaking our existing mechanics that currently exist in the game. The purpose of the next eight weeks will be to achieve the highest level of polish possible for the game without the addition of any new major mechanics or features.
After recently attending the NZGDC conference and joining a workshop on using Cinemachine in Unity, we decided to attempt the incorporation of the cinematic cameras from Cinemachine into the game. Currently there is a variety of camera shots and cuts, which are used within the level, select which are hard-coded to move the main camera to create cinematic shots. Cinemachine would make these cinematic shots much smoother and more controlled than the current implementation. A fair amount of time was spent on implementing this into the game during the last week, however we were unable to utilise it because it appears that we would have to replace our current custom-made free look camera with a virtual one from Cinemachine. This would interfere with the rest of the gameplay currently set up and as a result, we have decided to drop the idea for the time being. The level select functionality has also been slightly modified and some minor bugs have been resolved with regards to levels being accessible before previous levels had been completed. The glider movement has also been tweaked due to an unexpected movement behaviour, which was discovered whilst playing. Because of the multiple types of banking and rotations of the glider there was an issue causing gimbal lock to occur when banking downwards and to either side. This would result in the glider actually banking in the opposite direction, which made downwards movement feel unrealistic and hard to control. The rotations have now been changed in a way that allows rotations related to visual feedback to occur separately from the rotations that actually cause the glider to bank and turn. The electrocution animations and sound effects for the barriers have now also been implemented into the game when the player touches the electric fields. The player is also forced back from the fence after a few seconds of being shocked. The last week has been really productive. More Wild West mine props and set dressing has been done. Other props are coming along great. A recent addition is the JunkBots that Klepto has assembled to help him build his simulations. These bots are made out of cardboard and junk, much like everything else Klepto has built so far!
This week we worked filling the new Aztec jungle with assets and we needed to pump them out fast. I personally started on making two variants of the jungle trees in the game that would work to be able to make at least four variants. After this, I went to make a rig for the second computer, which had a huge mace on the bottom of it. I went on to animate the same rig and place that into the game. Porting these animations was a first for me as I usually ask one of the programmers to put it in or ask Juane about it. I really enjoyed learning how to import these animations into unity and working on animation blending.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
November 2017
Categories
All
|