Week 7 has been a dramatic increase in positivity for me. Developing the new level, Sunset Showdown, has been both entertaining and hugely productive. As of Friday (after 3 days work) the level is complete functionally, and can be played from start to finish. It is the hardest level (as it is the final one of our beta build) and other than collectible floppy disks, is ready for players to experience. I have had a few non-team members play through it, and have had a positive response.
This week I also rebalanced and finished the second level, ‘Falling Down’ to make sure it was ready for the artists to attack with their wonderful art brushes. The level was tweaked to make it much easier, as well as adding in both checkpoints and floppy disks throughout. I am pretty happy with how Falling Down functions, and am positive about its position within our overarching structure. I fixed some small issues with this level, as well as adding in the energy fence, which is now fully usable. The energy fence blocks the players’ way until it is deactivated, and usually will require players to use a crate on a pressure plate in order to proceed. There are both button-activated and plate-activated options within the game, to make sure that players understand how both of these concepts work. Making this level complete also energised my desire to complete the final level as well. In the meantime, we also created a bunch of new assets for the game. On my suggestion, Conrad and Scott between them created a wagon and a horse, as well as textures and other props. The massive prop injection into the scenes has made the game look a lot better already. Sunset Showdown, the final level, is something that came together in the first few days of week 7, which was hugely inspiring. The final level uses all of the mechanics present in the other levels, and presents quite a challenge. I am happy both with the level of challenge and the level of entertainment presented to the player. Some platforming and grappling parts in particular are more challenging than any of the other levels, and the requirement for player skill is somewhat higher. I still have to go through the level and add in new content (like the water towers) as well as tidy up some elements, but I am hugely positive about the result that I have reached with Sunset Showdown, as well as the bounce back from last week’s mediocrity. This week I have also tidied up my documentation, and am starting to log everything properly. The documentation in the group log that I created I have not been using as much as I should, so I have gone back and added in the tasks that I completed over the past week. The last few days that we have to work on the game will be productive and result in a title that we can be proud of, fortunately.
0 Comments
I spent Week 6 entirely working on different concepts for new levels. On Monday, I decided that I would work towards a much larger level, with the goal of creating a much larger and open space for players to move around.
Initially I had a lot of problems with this, as I was unable to come up with a way of creating a level of such size that also felt like it was focused. I went through three different prototypes over the week, trying out different puzzles that never really seemed to fit. On Friday, I re-evaluated the focus that I had on making a much larger level, and decided that my approaches were largely a waste of time. The little progress that I had made had resulted in very little entertaining, playable content being produced. I was unhappy with my week 6, mostly because the work that I created was not entertaining or interesting at all, and felt largely like a waste of time. I am optimistic about the next week, as I have a plan in place to make sure that I am more productive and create something entertaining. For the opening of the beta section of the project, we outlined new milestones and goals that we wanted to achieve. In terms of the art of the project, the milestones were:
Whilst working on the main milestones, we also achieved a lot of little in-between things as well over this first week. During week 5, we added in textured floppy disk pickups. We gave them large areas of reflectivity and strong grey/white/red colour scheme to help them catch the player eye in a potentially busy scene. This week, we textured the Rotisserie Engine that will be powering Klepto’s Space-Faring Van. This is an environmental prop that adds a bit of flair to the inside of Klepto’s van, and it’s this engine that powers the vans ability to be smaller on the inside, as well as the vans space travelling abilities and the warp room. Finally, we began planning out the props for the Wild West Environment. We looked at cliché’ cowboy and western imagery as out inspiration. Klepto, in his quest to become the greatest Thief in the galaxy, wants to replicate the various places on earth that he wants to rob, so everything in Klepto’s simulation is hand made my him. To this end, we’ve decided that everything should be made of cardboard, tape and other rough materials that would be easy to find. All of the mountains and scenery are huge hand-painted cardboard facades, and most of the props are as well. We did a page of concepts, and then made a few props to see how they’d feel in-game. The final thing we got in-game this week was the 'Zap-fence'. This is a simple barrier that if the player passes through, they get electrocuted and lose all momentum. This week we created some more animations for our character which will be implemented into the game as random events. We also modeled a few assets which include a mouse on a wheel which powers an electric fence. The collectible that Klepto will pick up was decided to be a floppy disk implying that he needs to get data from each level to complete the mini game on the arcade machine. We also tried a new technique to modelling the interior of the van which turned out to take a little longer than anticipated, so we decided to change to what we were using before. The holo room we created is influenced by the cerebro room in X-men with rotating mesh and colours which complement the design. Our shader was a conversion of an existing shader which was shown in one image using another shader program and recreated in amplify, with some adjustments. The glider also now has some feedback when the player collides with walls or floors.
This week’s work was continuing on the creation of the environmental assets for the game, whilst completing the models needed for the mini games that include the cop chase game and the gliding game. The glider animations were finally finished off so we were able to move onto the next mini game which would be the cop car chase. The cop car chase mini game needed to have actual cop cars that chased the van around in circles. Scott went on to create concepts and started modelling the cop car. Conrad went on to finishing the model as well as texture it. Corne went on to replacing the make shift wind turbines that Josh had created. The wind turbines were a really cool aspect to the games environmental puzzles as this was a more creative way to get elevation in the levels. One of the most important mechanics of our game was the grapple and the model for the points where you are able to grapple weren’t looking that great. Juane went on to model a grapple point where Conrad went on to texture it. Corne also made a logo that would be used as an easter egg for the texture. Another important feature for our game was the completion for the texture and shader of the platforms. Juane had purchased the Amplify shader plugin for Unity, and went to create the main platform for the levels.
This week a large focus has been placed upon the level select room currently within the game. This room is designed to act as the information hub for the player to track each levels progress, choose levels to play and view rewards within the van. Building off the previous weeks saving and loading functionality, this week, new canvases have been added to each level platform within the level select. On loading of this level these canvases now populate with the level information saved on the external JSON file to show the player stats such as completion times, completion percentages, secret tokens collected and medals earned. Each level platform now correctly displays the stats relating to that particular level in the currently selected world. These information panels have been set up to display only when the player is within a certain range of each level platform. To restrict players from accessing levels which are not yet unlocked, we have designed the level room in a way which requires bridges to be built to each platform when the level is unlocked. In order to keep track of which bridges have been built and which have not, the external file has now also been set up to track whether each level platforms bridge has been built yet or not. A cinematic shot has also been set up to show the first bridge of each world being built to help guide the player where to go. Apart from this when completing a new level and returning to the level select room, a check is done to see whether or not the next levels bridge is still required to build or not. If this is the case, then another cinematic shot has been set up to show the bridge being built before saving this data to the external file for future reference. Each level which has their bridge registered as built on the file also automatically appear when the scene is loaded.
On a whole the games entire progress can now be saved successfully and loaded again for the player to continue where they left off. All level stats appear to load and display correctly, and the level select now appears to function as it was intended to. On Thursday this week, we had a playtest session in which people tried out the level I am currently working on. The goal was to observe people playing the game to discover pain points in the level design and the game mechanics. From this playtest, I received 8 detailed responses. The most apparent issue was that I had made the level too difficult; the distances between the grapple points were far too large. As a result, the level became much longer to complete than anticipated. The problem was that I had designed the level's difficulty around my own skill level, not around the skill level of the average player of our game. Additionally, the level’s difficulty ramped up too quickly and did not give players enough time to acclimatize to the grappling mechanic. Subtle issues with the design arose too. A few players were unable to figure out the crate on pressure pad mechanic. This was due to me applying my own affordances about crates being placed on buttons that I had developed from playing many other games. Not everyone that plays our game will make that connection. The image on the pressure pad is footprints which perhaps does not clearly communicate that the crates could be placed on the pressure pads too. Mechanically, the biggest problem is the grappling hook. This is because player’s easily lost control of where they were aiming the grapple swing, causing them to spin out of control. This causes death, frustration and makes the levels last longer than they should do. I sat down with Uncharted 4 over the weekend to analyze how this game handles its swinging mechanic without letting players spin out of control. The 3 core observations I made were:
Currently while grappling in our game, a player can hold LS forward and the forward force will not reduce over time. After a time, the player will settle in place, appearing to hover in front of the grapple point. To fix this, I had to ensure that a forward force would only be applied when the player is behind the grapple point and a backward force would only be applied when in front of the grapple point (relative to the camera). Initially, I used the player’s velocity as the normal vector (with y as 0) of a plane and used dot product to determine whether the grapple was in front or behind the grapple. However, this gave undesirable and inconsistent results. I then decided to use the cameras forward vector (with y as 0) as the plane normal and this gave much better results (assuming that the player is swinging towards and away from the camera). That swinging change worked nicely but the bigger issue still persisted; it was still too easy to spin out of control of the grapple. I tried slowing the player down by adding drag until the player’s movement direction was close enough to the input direction taken from the controller. This felt horrible. I experimented with modifying the configurable joint of the grapple to lock angular movement about the grapple to one axis. I then set the axis of rotation as the camera’s right vector (with y as 0). This gave a smooth and stable swing in which the swing direction is controlled by the camera. The changes are definitely an improvement. I let someone play the game who had major trouble with the grappling before and now they can finish the level much easier. Whether or not the grappling will continue to use the mouse to aim is not finalized, however, and will need to be determined through more testing.
Week 1 of the beta for me was spent developing two new levels. With the decision made to focus on the Wild West world, I developed an initial level (as a tutorial) that introduces jumping, movement, and button presses. This level will take maximum 30s - 1 minute for an experienced player, and is intended to serve as a very small introduction before players jump into the rest of the game. The second level I created was a mostly falling-platform level, entitled ‘Falling Down’. This level serves mostly as an introduction to the concept of falling platforms, and includes several different arrangements of these, including objects where the player is pushed off, when they have to jump from platform to platform, and where players have to move around the outside of a building, to climb to the top. I see this level as a natural escalation of the challenge of the game, so it is not intended to be approached after the previously mentioned tutorial level. With ‘Falling Down’, I wanted to experiment more with creating interesting platforming environments, and understanding the limits of the character. A secondary goal was to make a level a bit bigger than the previous levels, as I had not yet made a level that was actually large. The level took about 3 days total to create, - including drawing, implementation, and testing. In terms of components, it includes falling platforms, pushing blocks, a small vertical platforming section, repeated timed jumps, circular platforming, and a small amount of navigation in a larger area, that forces the player to jump between pillar-oriented platforms. The team’s response to the level was pretty positive again, but with a number of required changes to make as well. In the previous level that I created for the demo, the pushing blocks often infuriated players because of the timing. Mistiming the blocks meant that the level’s flow was much worse. I retooled how the pushing blocks worked, to allow them to chain off each other. I also created a trigger area to make sure that the blocks only start moving when the player gets close. This means that if the player wants to sprint through the level, it is facilitated by the design. Enabling fast runs means that I am able to make sure that everything can flow properly and feel really smooth to play. The level design sections I have experimented with thus far in other levels have been put in here (pushing blocks, jumping around a tower, etc.) and there are no grappling hooks. Next week I will go back and test the level, to make sure that things like jump spacing or timing are accurate. This level will most likely be the third or fourth level, and include mechanics and objectives for the player that will not be possible without first getting used to the grappling and jumping. I am happy with the current focus of the level, however it will require some tuning before I move on to the next level, as well as mechanical implementation (it requires buttons, as well as doors and switches) before the level can be completed aesthetically.
Saving and loading is a very important underlying mechanic which allows for players to maintain their progress within a game. Up until this week there was no way for the player to continue where they left off as not too much consideration had been placed into this feature. It is however one of our design goals which is why a large emphasis was placed onto it during the week. A framework has now been set up and connected into the game which will allow the serialization and saving of game data to an external file using JSON. This data can also be read from the file at any point and used to populate in-game information.
Currently the saving and loading feature has the capability of saving data including each levels completion status, time completed, pickup completion percentage, medal earned, as well as whether or not the secret token had been collected or not. This data will allow us to determine which levels and worlds can be accessed from within the level select room as well as which mini games can be played within the van. It will also allow the player to keep track of their times and completion status for every level and gives them the opportunity to replay the levels to achieve better scores. Currently we have implemented up to three save slots in which new games can be created from the main menu. There is also the option to select a save slot to load from the main menu. This basic set up will now allow the player to track their progress. We have also added a new form of collectable for the player to run around the levels and find, the floppy disk! Klepto must collect these disks in order for him to increase his computer memory to run his simulations. These collectables within each level are used to determine the levels completion percentage based upon how many were picked up. The world of Klepto’s thievery-based simulation got a fresh coat of paint this week; transforming it from a poor man’s Tron to something more resembling our little alien’s idea of the Wild West. If you want to survive in the Wild West, you need reliable tools and Klepto’s most important tool is his grapple arm. To this end, we made various improvements to this gadget which reduces the ways in which the grapple can become unintentionally disconnected. This included increasing the radius of the grapple point when Klepto connects and decreasing it again when disconnecting to prevent Klepto from being forcefully disconnected by leaving the collider. Additionally, instead of getting immediately disconnected when grounded, Klepto will pull himself up towards the grapple point again and continue swinging. Previously, if Klepto connected to the grapple point when he was too close, he couldn’t do anything until he lengthened his arm by disconnecting, falling, then reconnecting. This was not intuitive so this was changed to a method that pushes Klepto away from the grapple until he is at an appropriate distance to connect. Additionally, the grapple-in-range-line was adjusted so that when Klepto is nearly in range but not quite, it turns red instead of green. Obviously, a thief training simulation is not much help without a measure of how well our trainee is progressing. A time score system has been implemented which awards Klepto with a gold, silver, or bronze medal (or no medal) depending on how fast he has completed the level. The aim of this is to improve the speed running prospects of the game.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
September 2017
Categories |