With the base-layout of my level complete and me being perfectly on time with my original weekly plan, I can now focus my time and energy into polishing up and tweaking what I already have to make it a more enjoyable experience, ready to write-up my final conclusion next week. To start off I removed a lot of unused assets from my game's content folder which were taking up unnecessary space, saving a fair few GBs of storage following good professional practises of optimising your game's speed and filesize (since the game is loading in various assets which aren't even being used). Next I played through my level in its entirety, starting from the right, moving to the middle section and ending with the left as I reached the floating garden at the end. This is the preferred route I'd like the player to go through in an ideal scenario to get the best experience from the game. However the level was still designed with freedom in mind, so to make sure it was well structured the game needed to be played through three separate times, with each playthrough starting in a different area (either going down the right, centre or left path).
This decision posed a problem for me though: because I'm the person who made the level it doesn't matter which order I play through it in, I know its layout like the back of my hand and am likely to learn very little about the game's mechanics. That where I came up with the idea to get three of my family members, who had no prior experience with the game but have all played games before, to each play the level. The catch is I'd instruct each of them to go down a different path first, and see how it impacts their experience. The results are below:
Person who went down the right path:
Found the level the easiest to playthrough compared to everyone else. It helps that you don't actually have to jump for this section, it just focuses on the player learning the game's movement options and bounce-pads. Because they didn't know you could even jump by the end of it they had trouble getting to the next area though.
Person who went down the middle path:
Struggled the most out of everyone. Combined with the area being dark, having the ghosts that kill you and the obscure bounce-pad, this experience set them up to always be on their toes for the rest of the level in fear of greater difficulty. Issue is, this part of the level was more of a twist, and differs greatly in mechanics and atmosphere to the rest of the stage.
Person who went down the left path:
Had a relatively good experience, they didn't want to leave the final garden for a long while though and were disappointed there was less of a reward for going down all the other paths since they enjoyed the nice atmosphere of it. Overall they didn't really struggle or find the game difficult from there, they did miss the moving platforms though and preferred them to the ghosts and bounce-pads as the main gimmicks of the other areas.
Overall though this feedback was very helpful, and there are a few changes which can be made because of it. A big issue that sprung up was because I'd put a bounce-pad in the middle path, it caused an issue with the person who went there first as they didn't understand the concept of it since it came out of nowhere. Fortunately the person who started at the left and then went to the middle picked up the idea very quickly, so it does depend on the person. To remedy this issue I tweaked the level slightly to make a small, empty room that looks like a dead-end, with the bounce-pad being the only thing placed in the middle of it, popped bang in the centre. This practically forces the player to use it, or at least want to walk on it, even if they have no prior knowledge of what it does. Plus, if they go down the centre path first, they'll already have an understanding of how it works for when they take the path on the right, which uses the bounce-pads as its main gimmick, slightly shifting them ahead of the competition.
I also removed the ? coins from the level entirely following feedback, which were previously used to mark secrets and hidden areas. These caused far too much confusion, and all three playtesters thought that you could pick up and collect them like a typical Mario or Sonic game. They caused more hassle than they were worth as they went against standard platforming conventions (as most platformers require you to collect floating, spinning coins, whereas here you can't). In the end removing these actual improved the game overall, as it means that the player now has to find the secrets themselves aiding the thrill of discovery and exploration of the level, without just mindlessly following a floating coin to the goal.
From here, I made a few other tweaks to the levels layout, since there were a couple of areas you could get stuck on, and an invisible wall that it was possible to land on top by mistake. It was also possible to get stuck in the body of water in the corner if somebody wanted to jump in, so I added a block inside so the player is able to jump on it to escape if they find themselves trapped. These last few changes have now brought the development of my level to its end, with the next and final week being dedicated to me writing up my conclusion and what I learned throughout the process!
Sunday, 27 March 2016
Sunday, 20 March 2016
PDP Week 9
This week I started doing my final implementation of a new gameplay mechanic (the camera system in a maze-like area), ready to start the tail-end of my game's level design. I'm a week late on my planned PDP, as I focused on added various changes following peer feedback last week. Originally I wrote how this week was going to be me initialising the final steps of production in my first planning blog post. However I feel that was actually too much of an over-estimate on my behalf in the past, as in actually my finishing up the level's final layout with a couple more weeks left for other adjustments, which is a much more realistic goal than the smaller time constraints I had given myself.
I began by researching the type of area this level should be, and as talked about by (Pete Ellis, 2016), I feel I should subvert the player's expectations in the maze area, and assets that aren't seen anywhere else (such as other dead player characters and ghosts). Subverting expectations is essentially mixing up a game's formula and adding a twist to it (so they could be a cute and cuddly game which turns quite grim and evil, for example). I've followed a similar practise in my level already, by adding twists to pre-established gameplay mechanics. However I want to take it one step further this week by adding a more grim and tense area compared to the more open and platform-based environments i've already established in my game.
I also added a maze into the level as the final feature left to implement, where the player must find their way to the end. As always it lets the player figure out how to even enter themselves without a tutorial, since the door is visibly wide open like it's inviting them inside. However when the player draws near the door the security camera positioned on top (an asset from the UE4 Marketplace), which automatically moves from side-to-side, will most likely catch them and slam the door shut until they're out of sight. This is another great example of me physically forcing the player to learn how a new mechanic works before they can proceed, as they must stealthily avoid the camera's sight and sneak in through the entrance, which is only really possible once they've analysed the situation and have a grasp of how it works.
Like all the other entrances the player will know they're supposed to enter due to the ? coin placed nearby, the level's path gradually navigating them towards the entrance, while also have the door clearly be visible, open and obviously enter-able when you get close enough. Once they do they'll pass through an incredibly long corridor (complete with an odd sensation with a few 'dead' player avatar characters), and from there it's up to them to find the way to the end! (With the final realisation for the player being that suicide is the only way out from the torment of the maze they've been through.)
I also got player death finally working after many weeks of frustration! Using the video tutorial below, I created a custom variable for death inside the main player's blueprint system, which disables the player's control inputs, plays an explosion particle and sound effect, turns the player's model invisible and after 2 seconds reloads the loaded level. This blueprint was then attached to a huge invisible shape floating below the stage which kills the player when they touch it. What this really means is there are no more needless invisible walls to restrict the gameplay, and I removed a lot of unnecessary ones because of this! Instead if a player falls off the stage by their own accord they'll naturally restart the level after death and have to play again from the beginning, which makes it really test their skills at the game than just be a 'pretty showcase'. I even added an 'enemy' in the form of a floating ghost, with a main purpose to inhabit the maze area, which also kills the player in the same way upon collision. It adds a new layer of strategy to my game as it's something extra for the player to avoid, and they're really effective when put into my dark corridor to build the atmosphere. I will still be keeping some invisible walls as a design choice though, such as for restricting a player from going out-of-bounds in areas they're not supposed to.
https://www.youtube.com/watch?v=qzFd-PfM5kc&index=3&list=PLZlv_N0_O1gbY4FN8pZuEPVC9PzQThNn1
References:
Pete Ellis, 2016. Subverting Player Expectation by Using Level Design [WWW Document]. URL http://80.lv/articles/subverting-player-expectation-by/ (accessed 3.20.16).
I began by researching the type of area this level should be, and as talked about by (Pete Ellis, 2016), I feel I should subvert the player's expectations in the maze area, and assets that aren't seen anywhere else (such as other dead player characters and ghosts). Subverting expectations is essentially mixing up a game's formula and adding a twist to it (so they could be a cute and cuddly game which turns quite grim and evil, for example). I've followed a similar practise in my level already, by adding twists to pre-established gameplay mechanics. However I want to take it one step further this week by adding a more grim and tense area compared to the more open and platform-based environments i've already established in my game.
I also added a maze into the level as the final feature left to implement, where the player must find their way to the end. As always it lets the player figure out how to even enter themselves without a tutorial, since the door is visibly wide open like it's inviting them inside. However when the player draws near the door the security camera positioned on top (an asset from the UE4 Marketplace), which automatically moves from side-to-side, will most likely catch them and slam the door shut until they're out of sight. This is another great example of me physically forcing the player to learn how a new mechanic works before they can proceed, as they must stealthily avoid the camera's sight and sneak in through the entrance, which is only really possible once they've analysed the situation and have a grasp of how it works.
Like all the other entrances the player will know they're supposed to enter due to the ? coin placed nearby, the level's path gradually navigating them towards the entrance, while also have the door clearly be visible, open and obviously enter-able when you get close enough. Once they do they'll pass through an incredibly long corridor (complete with an odd sensation with a few 'dead' player avatar characters), and from there it's up to them to find the way to the end! (With the final realisation for the player being that suicide is the only way out from the torment of the maze they've been through.)
 |
| The player sees the suspicious doors near the back of the map |
 |
| The player gets closer and must sneak past the security camera |
 |
| Or else the door slams shut when spotted |
 |
| Once inside they must navigate to the end, avoiding the ghosts and cameras along the way! |
I also got player death finally working after many weeks of frustration! Using the video tutorial below, I created a custom variable for death inside the main player's blueprint system, which disables the player's control inputs, plays an explosion particle and sound effect, turns the player's model invisible and after 2 seconds reloads the loaded level. This blueprint was then attached to a huge invisible shape floating below the stage which kills the player when they touch it. What this really means is there are no more needless invisible walls to restrict the gameplay, and I removed a lot of unnecessary ones because of this! Instead if a player falls off the stage by their own accord they'll naturally restart the level after death and have to play again from the beginning, which makes it really test their skills at the game than just be a 'pretty showcase'. I even added an 'enemy' in the form of a floating ghost, with a main purpose to inhabit the maze area, which also kills the player in the same way upon collision. It adds a new layer of strategy to my game as it's something extra for the player to avoid, and they're really effective when put into my dark corridor to build the atmosphere. I will still be keeping some invisible walls as a design choice though, such as for restricting a player from going out-of-bounds in areas they're not supposed to.
https://www.youtube.com/watch?v=qzFd-PfM5kc&index=3&list=PLZlv_N0_O1gbY4FN8pZuEPVC9PzQThNn1
References:
Pete Ellis, 2016. Subverting Player Expectation by Using Level Design [WWW Document]. URL http://80.lv/articles/subverting-player-expectation-by/ (accessed 3.20.16).
Sunday, 13 March 2016
PDP Week 8
This week I tasked some of my fellow university students to play my level so far and give me some feedback, in order to gage an idea on what I should improve on. This is the written feedback I received after they played through the entirety of the current level:
Ben Musgrave:
"adam's game
feedbak.
- invisible walls sometimes got in the way
- some bits could use invisible walls when the player is trying to get out of the way
- adam should move the second trampoline platform back (the one you have to turn around)
- adam's lifts need to go up then down as if the player falls off then can get stuck
- give the fence in adam's secret garden collision
- directions around the place is necessary, especially in the trampoline segment."
Ty:
"Very good work. Fix the moving platforms and invisible walls and you've done a good job so far."
This is all very useful information and constructive criticism from my peers, so this week I made it my mission to fix, or at least diagnose, every criticism listed above. Following this feedback I amended my moving lifts so the player doesn't have to restart the game when they fall off, and instead the elevators follow a set movement pattern. This required me to rewrite the code from scratch using blueprints and the marquee tool, and I used this tutorial (https://wiki.unrealengine.com/Blueprint_Lift_Tutorial) to do it. But in the end of this ordeal it really did wield positive results, as the player doesn't need to restart the game if they accidentally fall off a moving platform. Getting stuck and unable to progress is a terrible practise for a game to follow, so it's good that I made adjustments accordingly.
I also added various other quality of life changes as suggested in the feedback to balance the game, like giving the fences in the secret garden collision so you and movable furniture can't be kicked off the side so easily. I also moved the bounce-pad slightly back as requested, and added a couple of arrows pointing that the player needs to turn around. It was mentioned in the feedback that the invisible walls are bad, but unfortunately I must include them as a necessary evil due to not having a death system in place.
Some of the other criticisms made (like being able to skip the stairs in the bounce-pad section) was actually a design choice done on purpose. I made it specifically so that veteran players can speedrun the level if they know what they're doing, while most other people will instinctively go up the stairs... And if they don't, well they just found the secret bounce-pad as a reward for exploring!
I also tried to implement a death system this week follow professional standards set by platformer franchises like Donkey Kong and Sonic, where if the player falls off the stage they will hit a huge invisible collision box, restarting the level and reloading them at the start via blueprints. However, after following various tutorials (such as from here https://answers.unrealengine.com/questions/37113/player-death-or-level-reset.html with a Kill Z Volume and here https://www.youtube.com/watch?v=W1c7tsacXTg), I simply couldn't get it to function, possibly due to me using the latest version of Unreal, but other variables may be in place. To compromise I will carry on using the invisible walls I implemented before into this PDP task.
Because of this feedback and other changes that I worked towards and introduced this week I will implement my camera system next week, and place those inside a maze for the following week ready to start bugfixing and finalising my level.
Ben Musgrave:
"Feedback
Invisible walls = bad
Moving platforms don’t come back down
Can skip the stairs if you don’t feel like them
Invisible walls = bad"
Tom Fabry:
"adam's game
feedbak.
- invisible walls sometimes got in the way
- some bits could use invisible walls when the player is trying to get out of the way
- adam should move the second trampoline platform back (the one you have to turn around)
- adam's lifts need to go up then down as if the player falls off then can get stuck
- give the fence in adam's secret garden collision
- directions around the place is necessary, especially in the trampoline segment."
Ty:
"Very good work. Fix the moving platforms and invisible walls and you've done a good job so far."
This is all very useful information and constructive criticism from my peers, so this week I made it my mission to fix, or at least diagnose, every criticism listed above. Following this feedback I amended my moving lifts so the player doesn't have to restart the game when they fall off, and instead the elevators follow a set movement pattern. This required me to rewrite the code from scratch using blueprints and the marquee tool, and I used this tutorial (https://wiki.unrealengine.com/Blueprint_Lift_Tutorial) to do it. But in the end of this ordeal it really did wield positive results, as the player doesn't need to restart the game if they accidentally fall off a moving platform. Getting stuck and unable to progress is a terrible practise for a game to follow, so it's good that I made adjustments accordingly.
I also added various other quality of life changes as suggested in the feedback to balance the game, like giving the fences in the secret garden collision so you and movable furniture can't be kicked off the side so easily. I also moved the bounce-pad slightly back as requested, and added a couple of arrows pointing that the player needs to turn around. It was mentioned in the feedback that the invisible walls are bad, but unfortunately I must include them as a necessary evil due to not having a death system in place.
Some of the other criticisms made (like being able to skip the stairs in the bounce-pad section) was actually a design choice done on purpose. I made it specifically so that veteran players can speedrun the level if they know what they're doing, while most other people will instinctively go up the stairs... And if they don't, well they just found the secret bounce-pad as a reward for exploring!
I also tried to implement a death system this week follow professional standards set by platformer franchises like Donkey Kong and Sonic, where if the player falls off the stage they will hit a huge invisible collision box, restarting the level and reloading them at the start via blueprints. However, after following various tutorials (such as from here https://answers.unrealengine.com/questions/37113/player-death-or-level-reset.html with a Kill Z Volume and here https://www.youtube.com/watch?v=W1c7tsacXTg), I simply couldn't get it to function, possibly due to me using the latest version of Unreal, but other variables may be in place. To compromise I will carry on using the invisible walls I implemented before into this PDP task.
Because of this feedback and other changes that I worked towards and introduced this week I will implement my camera system next week, and place those inside a maze for the following week ready to start bugfixing and finalising my level.
Wednesday, 9 March 2016
PDP Week 7
This week I continued to research improvements I could make to my level and started to iron out some more bugs and glitches.
Firstly, as researched by (J MatthewZoss, 2016), a game and its level needs to have a certain amount of 'polish' to it. To sum it up in a quote from that source, "In a general sense, our group of developers defined a polished game as one that lacks issues that pull the player out of the gaming experience." This is a word or phrase that is difficult to define in gaming, as it's used in such a variety of contexts: from a game's core mechanics being really polished, a game being delayed so it can be polished up and have some bugs fixed, or even in my case polishing the level design. Essentially this term means that a polished game contains a quality standard and finished touch which really goes the extra mile to immerse the player into the gaming experience, while also adding an extra layer of finesse and attention to detail which really makes the game 'click'. It can also be related to how consistently your game performs, which is very much relatable to level design in the games industry sector I'm looking to improve in!
As discussed by (Paul Suddaby, 2013), a well designed level keeps that high level of polish and quality throughout the whole experience, without have say one really memorable and well planned out part of the area, only to be followed by a tacky and unplayable mess of a stage, creating a vast contract of quality. There are various other factors which add to the game's overall polish (as in, how much time and care was put into the level), from having a gradual, yet well-tested difficulty curve throughout the whole game which lends itself to the player's skill (something that's difficult to achieve in my own level due to the more open-ended nature of it, but is still completely possible in the smaller puzzle sections) to ensuring all of the collision is correctly done so the player can't glitch out of bounds outside of the map where the developers never intended you to go. It's the little details which really add up to make a great experience.
Using this research this week I will be working towards polishing my game to improve the existing experience over expanding on it's scope. This means I will retest all of my different areas so far and add anything that I feel is missing, while also redesigning parts of the level to make it more streamlined or interesting. So for example I might add some more different platforms to jump on throughout the level, as strangely enough the player doesn't actually need to jump that much to navigate around the stage, and they can accomplish most tasks just by walking! This is possible since the player automatically performs a short 'hop' whenever they walk off a ledge, which is a feature that was already programmed into the base Unreal 4 third-person platformer template. So to amend this I'll add and change various parts of the level and platform distances depending on the character's jump trajectory, so it's compulsory to reach the other side of a gap by pressing the spacebar to jump.
This week within my Unreal 4 level as talked about above I fixed various issues with my level. The first thing I did was change the player's spawn point as that there's more of the level to traverse, as right now they spawn in the centre of the room. I also added various pieces of decoration to my level, like birds and furniture, to make the area seem more alive and more interesting to explore. As in its current state with grey platforms everywhere the stage was quite uninteresting to look at. I still plan on keeping the monotone grey aesthetic, however the decoration and objects will be shaded with drastically different colours to stand out. This is a very interesting visual style that I've chosen to go for, and gives this demo a very original look and feel making the area interesting to play through.
I also added a few question mark coins scattered around my level, in the general area and proximity of a secret (as shown below), indicating something interesting is around there and the player should go and explore that area, while also not giving away the exact location or what it is. This preserves the sense of adventure of the player's mindset while also helping comfort them in know that they won't miss anything too important during their adventure.
Next week I will build another section of my level which is at the same level of polish I researched this week! The new mechanic will be a security system using a camera, which closes the door needed to proceed when the player is spotted.
References:
Firstly, as researched by (J MatthewZoss, 2016), a game and its level needs to have a certain amount of 'polish' to it. To sum it up in a quote from that source, "In a general sense, our group of developers defined a polished game as one that lacks issues that pull the player out of the gaming experience." This is a word or phrase that is difficult to define in gaming, as it's used in such a variety of contexts: from a game's core mechanics being really polished, a game being delayed so it can be polished up and have some bugs fixed, or even in my case polishing the level design. Essentially this term means that a polished game contains a quality standard and finished touch which really goes the extra mile to immerse the player into the gaming experience, while also adding an extra layer of finesse and attention to detail which really makes the game 'click'. It can also be related to how consistently your game performs, which is very much relatable to level design in the games industry sector I'm looking to improve in!
As discussed by (Paul Suddaby, 2013), a well designed level keeps that high level of polish and quality throughout the whole experience, without have say one really memorable and well planned out part of the area, only to be followed by a tacky and unplayable mess of a stage, creating a vast contract of quality. There are various other factors which add to the game's overall polish (as in, how much time and care was put into the level), from having a gradual, yet well-tested difficulty curve throughout the whole game which lends itself to the player's skill (something that's difficult to achieve in my own level due to the more open-ended nature of it, but is still completely possible in the smaller puzzle sections) to ensuring all of the collision is correctly done so the player can't glitch out of bounds outside of the map where the developers never intended you to go. It's the little details which really add up to make a great experience.
Using this research this week I will be working towards polishing my game to improve the existing experience over expanding on it's scope. This means I will retest all of my different areas so far and add anything that I feel is missing, while also redesigning parts of the level to make it more streamlined or interesting. So for example I might add some more different platforms to jump on throughout the level, as strangely enough the player doesn't actually need to jump that much to navigate around the stage, and they can accomplish most tasks just by walking! This is possible since the player automatically performs a short 'hop' whenever they walk off a ledge, which is a feature that was already programmed into the base Unreal 4 third-person platformer template. So to amend this I'll add and change various parts of the level and platform distances depending on the character's jump trajectory, so it's compulsory to reach the other side of a gap by pressing the spacebar to jump.
This week within my Unreal 4 level as talked about above I fixed various issues with my level. The first thing I did was change the player's spawn point as that there's more of the level to traverse, as right now they spawn in the centre of the room. I also added various pieces of decoration to my level, like birds and furniture, to make the area seem more alive and more interesting to explore. As in its current state with grey platforms everywhere the stage was quite uninteresting to look at. I still plan on keeping the monotone grey aesthetic, however the decoration and objects will be shaded with drastically different colours to stand out. This is a very interesting visual style that I've chosen to go for, and gives this demo a very original look and feel making the area interesting to play through.
 |
| The bird is a royalty free model from the Unreal 4 Marketplace. |
 |
| A floating ? coin, just out of reach to the typical player which encourages the user to explore. |
References:
J Matthew
Zoss, 2016. The Art Of Game Polish: Developers Speak [WWW Document]. Gamasutra.
URL
http://www.gamasutra.com/view/feature/132611/the_art_of_game_polish_developers_.php?print=1
(accessed 3.8.16).
Paul
Suddaby, 2013. 5 Important Ways to Add Polish to Your Game - Envato Tuts+ Game
Development Article [WWW Document]. URL
http://gamedevelopment.tutsplus.com/articles/5-important-ways-to-add-polish-to-your-game--gamedev-7642
(accessed 3.9.16).
Thursday, 3 March 2016
PDP Week 6
This week I researched some more level design techniques, and also designed a further extension of my level utilising this new moving platform element for my stage, which loops round and drops the player back off into the centre of the stage again once they've finished playing through it.
In a previous blog post I researched level design in the 3d Mario games and how they're structured, but what about the 2d Mario games? Since both types of platforms follow similar, yet seperate structures in game mechanics and design, it would be interesting to analyse both genres and see what I can learn from the 2d games which could then be applied into my own level. I researched and analysed a couple of videos from the Youtube channels and (linked below), who are both games industry veterans, on their takes of the fundamentals of 2d Mario games. Extra Credits tackles the original Super Mario Bros, whereas Game Maker's Toolkit focuses more on the newer games like New Super Mario Bros U and Super Mario Maker.
https://www.youtube.com/watch?v=ZH2wGpEZVgE
https://www.youtube.com/watch?v=e0c5Le1vGp4
After analysing those video a big point of interest rose up, many Mario levels only introduce one or two new elements at a time not to overwhelm the player. I've already being doing something similar to this in my own stage, to some degree. All of the different paths the player can go down will have their own unique elements attached to them (like the bounce-pads and elevators), and because the level will be larger in scope and size than your average run off the mill Mario course, this gives players time to learn and adapt to their new-found skills at their own gradual pace without ever getting overwhelmed with options.
These two videos also both enforced the 'teach by doing, not showing' message which I've constantly stuck by in my own level. And the Mario Maker video showed good techniques of applying a concept then taking it further, which I will do for my own stage. It also goes on to say that changing up the use of different level elements as much a possible is the best way to success, and constantly using one mechanic in the same way multiple times before moving on can still feel quite repetitive and tedious. This way the player always gets to experience something new and are never left waiting for more content to appear, and it means the develop shouldn't just regurgitate previously used content and enemies throughout the whole game.
This week I also continued to develop my level using the elevator platforms, and as usual I will list a step-by-step playthrough below explaining the logic behind it:
I progressed a lot this week, and while I continued to playtest my level, even sections I've already completed, for any bugs and glitches, following professional practises. Next week I will continue with my PDP's research and development!
References:
In a previous blog post I researched level design in the 3d Mario games and how they're structured, but what about the 2d Mario games? Since both types of platforms follow similar, yet seperate structures in game mechanics and design, it would be interesting to analyse both genres and see what I can learn from the 2d games which could then be applied into my own level. I researched and analysed a couple of videos from the Youtube channels and (linked below), who are both games industry veterans, on their takes of the fundamentals of 2d Mario games. Extra Credits tackles the original Super Mario Bros, whereas Game Maker's Toolkit focuses more on the newer games like New Super Mario Bros U and Super Mario Maker.
https://www.youtube.com/watch?v=ZH2wGpEZVgE
https://www.youtube.com/watch?v=e0c5Le1vGp4
After analysing those video a big point of interest rose up, many Mario levels only introduce one or two new elements at a time not to overwhelm the player. I've already being doing something similar to this in my own stage, to some degree. All of the different paths the player can go down will have their own unique elements attached to them (like the bounce-pads and elevators), and because the level will be larger in scope and size than your average run off the mill Mario course, this gives players time to learn and adapt to their new-found skills at their own gradual pace without ever getting overwhelmed with options.
These two videos also both enforced the 'teach by doing, not showing' message which I've constantly stuck by in my own level. And the Mario Maker video showed good techniques of applying a concept then taking it further, which I will do for my own stage. It also goes on to say that changing up the use of different level elements as much a possible is the best way to success, and constantly using one mechanic in the same way multiple times before moving on can still feel quite repetitive and tedious. This way the player always gets to experience something new and are never left waiting for more content to appear, and it means the develop shouldn't just regurgitate previously used content and enemies throughout the whole game.
This week I also continued to develop my level using the elevator platforms, and as usual I will list a step-by-step playthrough below explaining the logic behind it:
 |
| Going up the moving platform implemented last week, the player encounters a new set of stairs! |
 |
| The player then sees an elevator like they used just previously, so they naturally want to step on it. |
 |
| When it stops, the player is taken to another lift that they can move across. There are also invisible walls here to help prevent them from falling off. |
 |
| After this comes the twist in the mechanics, as they player now must jump across from life-to-lift as they move and try not to fall down back into the main section of the level below. |
 |
| It's all about mastery here as this section tests the mastery of the player's skill. |
 |
| Finally as a reward for their hard work the player is treated with a luscious garden to explore, and because the furniture are physics objects they're even able to be kicked around wherever the player likes if they really want to. |
References:
Extra
Credits, 2014. Design Club - Super Mario Bros: Level 1-1 - How Super Mario
Mastered Level Design - YouTube [WWW Document]. Youtube. URL
https://www.youtube.com/watch?v=ZH2wGpEZVgE (accessed 3.1.16).
Mark Brown, 2015. Game Maker’s Toolkit - Analysing Mario to Master
Super Mario Maker - YouTube [WWW Document]. URL https://www.youtube.com/watch?v=e0c5Le1vGp4
(accessed 3.1.16).
Subscribe to:
Comments (Atom)