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.
0 Comments
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.
This week has been the final week of our alpha phase of the game in which the team finalised a playable alpha version of the game. This alpha build consisted of a level select hub in which three levels could be selected and played. With the majority of our major mechanics now implemented within the game, this week a heavier focus was placed on playability, making each of the mechanics feel as good as possible as well as debugging. One of the things that previous playtests had suggested was to increase the feedback received when crashing the glider. To tackle this challenge Juan and I worked on making the glider model able to break into many pieces when crashing. By using some explosive forces and the new glider model which is split up into smaller fragments, we were able to create a crash which gives more feedback to the player and gives them a clear indication that they crashed the glider. A big emphasis was also placed on the “holo room” which will act as the level select within our game. The new model was placed into the game and the rings within the sphere were set up to spin. The teleporters were also placed in the scene to allow the player to choose which level to play. The three levels within the build were constructed using our level toolkit and each incorporated 2 – 4 main mechanics to focus on. The level that I created utilised the mechanics of turrets, grappling, jump pads as well a glider course as the final section. Other than this a large amount of time was spent on optimising code as well as debugging some serious issues within the game. Some of the challenges tackled included camera improvements when grappling and platforming near walls, glider usability and feel, as well as fixing a serious issue related to the new “rope arm” which caused the game to crash when loading a checkpoint for the player. The majority of the major bugs that we are aware of are now resolved with a few small optimisations and fixes still required.
In the week to come one of the things that we will be focusing on is improving the use of our JSON saving and loading system as well as planning and setting up the structure for our game save files and data to be saved as a whole. During week 4, I built yet another level. After spending so much time on the third level, I once again revisited what I should put as the main focus for the level - which came back to platforming. The enemy turrets in the level that I created, for example, were merely annoying rather than challenging. I think this was because I added them as an afterthought, rather than as a focal mechanic. So this week I started designing the level on paper first.
The above image is the final design of the level, after several different iterations. I went through several basic ideas, while also building on the mechanics that I had tested in the second level I had built. With this level, I wanted to test platforming and grappling proficiency above all else, as well as offer the player an opportunity to play around with the mechanics in a fairly open area. Extra mechanics (like making grappling hooks descend on button press) or moving blocks were introduced and added in order to vary up the different types of challenges. The level was changed back to a much more linear structure, with small sections of variance in moving left/right and up/down in order to progress (like button presses). I felt like a more linear structure would help my design skills improve faster, as I did not have to worry about players moving around unpredictably, and could offer a more responsive and interesting level. I put a lot of thought into designing this level, concepting several different stages until I felt they were appropriate. I am continuing to learn as much about level design as I can as fast as I can, and I feel like the result was a lot better than last week’s level. The initial response to it was very positive, and I continued building on it, adding some puzzles (though not as many as the previous level) and more platforming challenges. Using platforming alongside the grappling hooks proved to be a very entertaining component of the game, and required most of the team to attempt some sections in the level multiple times. Some of these issues were due to my inaccurate placement of grappling points and platforms, resulting in hard-to-complete jumps or movements that were impossible without getting used to mechanical quirks. The entire level layout and development took a few days, and then testing was required in order to get the level ‘feeling’ good. In preparation for the submission, however, we needed some extra, smaller levels. Both Dylan and Josh created smaller levels that showed off the other mechanics that we have in the game that I did not put into the levels. In week 5, I will again alter my approach somewhat as we enter beta phase. Rather than focusing on solely mechanics, there will also be a ‘theme’ to each level that connects to the world. The team discussion on Monday will involve deciding what the theme of the first world will be, and then the five levels that make up that world. From this point onward, level design will be more directed, with clear visions laid out for each level that is backed up in their design. Because we have the level select framework and the holo room complete, (mostly) implementing world-switching is the last main system to address. Week three has been a busy week for the team as we have now started finalising the mechanics within the game and been preparing them for use within multiple levels in the future. One of the major focuses this week was the improvement and finalising of the new glider mechanic within the game. With the main movement system implemented from last week, this week was more about making the glider look and feel as good as possible. This included a lot of playtesting and tweaking of values for both the glider and follow camera to get them feeling as satisfying as possible. The new glider animations were also implemented this week which now cause the glider model to bend its wings according to the direction of travel. To give more feedback to the player we also made the glider react differently according to the speed that it was travelling at. For example, when travelling faster the gliders newspaper and frame wobble more and wobble less whilst travelling slower. The glider can now also collide with objects which cause it to crash and respawn the player at the last checkpoint. We also attempted to make the camera shake when travelling faster however this ended up looking more like a mistake rather than an intentional mechanic and as a result we have taken it out for the time being. Other than this, some more effort was also placed into the cop chase mini game during the week. The main aspects of the mini game are now set up and allow the player to drive the van around whilst trying to avoid the police cars. The police cars successfully track and seek the player’s car and attempt to apprehend them by driving into them. The player can be caught if hit by one of the police cars. The mini game is designed to be funny yet entertaining at the same time and this is aided by the unrealistic car crashes which occur when the police cars crash into one another. To give the player the incentive to drive around the map we have also incorporated a fuel system into the mini game which causes the players car to use fuel as they drive around. The player can refill their fuel tank by finding fuel barrels which spawn at different locations around the map. Some more playtests were also conducted during the week to try and receive feedback on how the glider mechanic feels and reacts to player input after improving it during the week. To do this a simple race track styled course was created for players to steer through checkpoints along the way. Overall the feedback was fairly good as players found the glider fun and interesting to use. There were also no responses which said that the glider was hard to use. However, there was some feedback given which stated that the up and down movement of the glider felt slightly awkward to get used to. All participants were also happy with the speed of the glider and felt that it did not need to increase or decrease. One response also stated that the wind updrafts which cause the glider to lift upwards could be improved by increasing the feedback to show the glider is actually being lifted upwards. This is something that will need to be addressed in the future in order to improve player enjoyment of the glider.
Week 3 During Week 3 I learnt a lot about level design. Over the 5 days, I completely redid the second level, focusing on a different type of approach. The original version of the first level was much more linear. It followed a straight path, requiring players to complete the puzzles in a linear fashion. I have changed my approach to level design for this type of level; mostly because of the way the grappling hook works. How the Grappling Hook influences level design philosophy The grappling hook is a movement ability. This means that the player will want to move around as much as possible, because the hook is an alternative to normal movement. Because grappling movement allows the player to move in a large circle, spaces have to be much larger. This meant that the original level that I designed felt underwhelming compared to the ultimate ‘grapple fantasy’ that the player could experience. Only progressing along a linear path means that the mechanic becomes severely underutilised. I have altered the approach in this level, to cater to the idea of moving around freely. Where the previous iteration started the player and forced them through a linear ‘gauntlet’, this approach is more open. The green cubes above indicate the presence of a goal, and the red colours are hazards. This colouration was added as part of making the area more open, as it indicates to players what the object on top of the platform is. The pattern will also likely be changed or altered to compensate for players who are unable to distinguish that particular colour. The block-red boxes indicate the presence of switches, and the player will need to hit these to progress. Originally ordered, the buttons have had required ordering removed as part of assisting the flow of play. Requiring players to hit buttons in a particular order is an interesting but ultimately tedious mechanic if done repeatedly.
Each of the puzzles has a particular focus; one introduces the player to the mechanics by requiring the player to move out of cover to hit the buttons before the turret shoots them. The second puzzle requires the player to swing between platforms hitting the buttons while a pair of turrets shoots at them. The third puzzle (and the final on the first stage of this level) is a platforming challenge that requires players to make accurate jumps to progress, and buttons ordered from bottom-to-top. There are two platforms on the second level; one introduces laser walls and the other requires players to grapple around a central object. Because this level will eventually become the first level of a world, multiple mechanics are introduced in this level that will be expanded in later levels. In particular, I have an idea for further development of a level focused around the ‘central object to swing around’ idea, with multiple mechanics used in tandem to make it even more interesting. Changing the design of the entire first level will come later on, but the iteration on top of the second level has been successful thus far. The level feels more open and entertaining to play now, rather than a linear trudge. While the level can be completed extremely quickly, there will likely be additional puzzles added to flesh out the content further. Like last week, this week for me was about mechanical refinement and improving the feel of the game. Grappling was reworked significantly, with the goal of making it easier to control and removing some quirks from the mechanic. Now, the connection from the grapple target to the player is not created until the player’s claw has reached the grapple target. This means if the player jumps and tries to connect to a grapple point, they can still be falling for a time. If the player has not timed their jump well, they can still fall. Last week a challenge emerged when balancing between propelling and hitting buttons as the player cannot do both and this change to grappling is a similar challenge. The grapple now also moves the player around differently and is (hopefully) easier to control. The character collider also changed from a capsule to something more resembling a cylinder. The reason for this was with the capsule collider, players could easily slide off crates and platforms. This was very frustrating. A cylinder collider means that if you land on a platform, you aren’t likely to slide off. However, a problem emerged in that if the ground was not perfectly flat, the player could not move. So a customer collider was created which has a slight bevel on the bottom. The was a happy medium between not sliding and being able to walk over uneven surfaces. A lot of time was also spent on the magnet mechanic but it was extremely difficult making this look and feel good. So we put grapple points on the blades of the turbines and tested flying between grapple points on turbines. It was immediately more fun. So we made the decision to scrap the magnet and let the grapple do its job.
Environmental mechanics also got new models. The turbine, floor fan and pressure pad all have new models and textures. The pressure pad now depresses when the player steps on it. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
September 2017
Categories |