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.
0 Comments
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.
This week was a doozy, where last week we were conceptualising new ideas, this week we were implementing these ideas by making the assets and getting them into the engine as soon as possible. By pushing out a finished mechanic within a week was a lot easier than it seemed as we still needed to add basic jumping mechanics to make the movement feel better. From last week, what we had needed to finish off was the eel turret. As all the textures had been finished, all we needed to do was to animate it as Conrad had rigged it whilst he was modelling it. From there, Scott went and started to animate the turret. We wanted to try out some new techniques for animation and we really wanted to test if doing a squash and stretch animations work. From help from another team, we were able to find an animation modifier that would allow us to do it. The other animations that he did were just the standard idle and fidget animations. This first mechanic that was needed to be done immediately was the propeller. Conrad had textured the propeller while Scott modelled, rigged and animated the propeller. We were quite happy how the propeller turned out, it did have its fair set of issues when it came to imputing it into engine. The problem was that the scale of the bones was 0, so if you are scaling bones in animation, make sure that the scaling is .001. The second main mechanic was the glider. Corne was the main person on the project, conceptualising the shape and the style of the glider. After he had made the glider, we had a short discussion about extending the style of the model by making it more DIY looking. Juane had gone through and edited to fit this kind of style, whilst Conrad went in to texture the glider wings to make them look like newspaper articles with wanted signs of the main character. To get the newspaper to look like it had wind going through it, Juane had made a shader that would apply an effect to the mesh that would look like it simulated wind. The animations of the character with glider was kind of tricky but we were able to centre the character to the glider. While we were steaming ahead with our progress, we used this momentum to think of more mechanics that may challenge the player but didn’t want to use any more buttons that we already had. One of the ideas was to create more environmental mechanics for the player to navigate around and to slowly improve their skills. One of the environmental mechanics that Corne focused on was the fan which was used to practice the texturing styles.
Heading into the Alpha build of our project we have focused our asset production on the main mechanical parts of the character and the levels themselves. Things like the Robotic arm used for grappling and as a propellor/glide, as well as environmental mechanics such as enemy turrets and the level select overworld. Part of our overall level design philosophy is to mechanically build solid levels and character mechanics first and foremost. A new mechanic and level section is the hang glider. Unlike the propellor which is used to slow the players decent and give a longer descent arc, the hang glider is used as a Spyro like mechanic to cross long distances while managing speed and height. In line with our art direction, we want the glider to look like it’s made from newspaper and PVC piping as if Klepto haphazardly built it himself. Corne worked on the initial concept, modeled the Glider parts and UVed the sections for Conrad to texture in Sprint 2. In tandem with the Hand Glider we concepted and started working on an enemy/environmental obstacle that can make the hand gliding sections challenging but more interesting than just flying around. The idea of a turret that shoots at the player was formulated. In keeping with some of the humour of our game design Conrad concepted a turret that has an electric eel as the turret operator, and also as the power source. With Conrads concepts we have a really solid base to work from in terms of art direction. This is a nice change from previous pipelines where we kinda made stuff on an Ad Hoc basis. Juane spent alot of time during the first sprint (week1) of our Alpha working on the character rig. And integrating the Obirope plugin to function as Kleptos robotic arm. The ObiRope arm is much more stable than the previous animation and physics based arm rigs we attempted earlier in prototyping and vertical slice. Scott was tasked with rigging and animating the propellor arm for Klepto. This propellor pops out of Kleptos arm and is used to slow his descent. Scott went through a few iterations of this rig in order to get the best out of his animations. The animations themselves were also tweaked throughout the week to best suit the situation and timing of Kleptos jump height and arc.
Klepto’s alpha phase concluded this week with a build that featured a level select and three levels to traverse. Mechanics concerning Klepto’s mechanical arm were further improved this week. The arm no longer jitters when riding on moving platforms and grappling on turbines feels smooth after switching to a physics-based rotation. Improvements were also made to the grapples disconnect logic to improve stability and make the game fairer. Additionally, the new model for the grapple point has been added and integrated into the Level Building kit. The level I contributed to the Alpha build made use of the newly improved turbine movement, floor fans and a variety of other objects found in our Level Building kit. Initially, the floor fans were not an interesting mechanic because the player was simply forced up when walking onto it, very similar to what the jump pad already did. However, their true value was realized when they were placed in sequence above an abyss and the player had to use their propeller to glide between them. The fans were also fun as a mechanism to push players off moving platforms if they weren’t careful. With our Level Building kit almost completely fleshed out, this level took only a couple hours to build. In preparation for the NZGDC, I spend extra time polishing a demo build of the game which featured just one level. I added a tutorial system to give instructional text popups when the player walks to a block with a “?”. I also added a scene at the end in which players can give feedback using the Stomt plugin. This will be helpful for when the demo is shown because we can get insightful information without always supervising our game. Additional fixes and visual tweaks were made to the level for the demo and the ability to make Klepto walk when gently pressing LS was implemented.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
September 2017
Categories |