PDP Week 11

I have now come to the last week of my personal development plan, and finished off with a comprehensive level which exhibits the knowledge I've collected over the previous 10 weeks. So this final week is dedicated to me documenting my conclusion to summarise my own personal growth throughout this learning process. A huge thing I learned right off the bat was the Unreal Engine 4 software, with me spending so much time with it for this project I really learned how to navigate the software much more efficiently, along with figuring out how to choose the right tool or technique for the job. I began this PDP with basic knowledge on UE4 since I'd used it previously for the programming module, but before this process I didn't even know there was an asset list showing all of the objects in the current scene! Something like that is critically useful for professional organisation in the games industry, as you can hide and show certain assets in your engine if you just want to work on something in particular (such as a corridor with all of the ghosts and lights removed without physically removing them, since they made get in the way during the creation process). So looking back at my previous self-development plan and research, I’ve really improved my level design skills compared to what I’d said previously inside them. Especially since I’ve only had limited experience with level design in general before this PDP.

One of the main level design techniques I learned from this process, which I tried to enforce into my own work, was the method of teaching players by showing, not telling. Letting players figure things out on their own with just having subtle hints for them to follow really leads to the thrill of exploration when they figure something out, and the three main areas of my level help highlight this since they all teach this concept in their own ways, but go about it in a completely different process to each other. The bounce-pad section (and first one I did) probably spends the most time teaching the player its mechanics with the most gradual learning curve, whereas the last area (the tunnel) threw the player into it at a much faster pace. Its good variety I feel and helps the different sections feel more unique, since the player will remember all three areas without having one specific place feel generic or uninteresting.

The level I created visually may not look fantastic graphically, however the blocked-colour visual style is quite fitting which creates quite an abstract style for the game which suits the level design. The focus on this PDP was to improve my level design though, so the graphics were never the main priority. It still feels very abstract, with the level being suspended in the air over a flooded city, it adds some more tension to the platforming sections of the level design since when the player looks down as they're jumping over high gaps, it has a very large sense of scale to it. Some of the extra touches like the buildings in the background, the seagulls and butterflies I do also like though. It helps make the level feel a bit more alive, and the grand cityscape of this game isn't populated almost entirely by unmoving static meshes this way.

I also did a video walkthrough of the level to demonstrate a playthrough in its entirety, viewable on Youtube here:

https://www.youtube.com/watch?v=1oSeX5q8lOs&feature=youtu.be

A few things that surprised me throughout the development of my level was how fiddly Unreal 4 could be at times. As I thought in theory level design was just dragging and dropping assets from the library, however there’s a lot more to it than that. You have to structure it in the correct way and place, rotate and resize various objects individually by hand, likewise Unreal 4 can be very buggy at times. Like when it hangs for long periods of time or freezes completely, which is why I made a point to save as often as I could: to damage control the software and potentially not lose lots of work if something went wrong.

I feel that I managed my time well throughout the project’s development, however I did finish my 11 weeks earlier than expected. Because I completed a PDP entry once a week for 11 weeks, I finished earlier than timetabled (as I was filling them out by actual weeks and not the timetabled ones, so for example I would fill out 2-3 entries in the Easter break before we even came back to uni). Because of this did I have time to go back and check my previous entries to improve them, however I could have given myself more time to work on some of these entries during the whole timeframe.

I really enjoyed watching people’s reactions as they played through my level, and also taking their constructive feedback to make it better and appeal to a variety of people. I really didn’t enjoy some of the bugs in Unreal 4 though, which really hampered the development process (especially the aforementioned freezing bugs when I saved the project which sometimes made development a chore). Likewise I found programming some of the elements both fun and frustrating, fun to experiment with it and see your creation finally work, but also frustrating when something goes wrong and you can’t find the source of the problem. I feel I could have spent more time programming to improve my skills with it, even though I didn’t enjoy parts of the creation process. However the focus of my PDP was level design so I feel I spent a good amount of time working on it.

I received peer feedback throughout the development of my level, and I feel the views of others really helped me to improve my level in areas where I’d overlooked them. For example, when I couldn’t get death working in the level originally and used invisible walls to block the player instead. This came back to bite me however when I received some peer feedback, as a few people claimed the invisible walls to be annoying and something that broke the immersion of the game. This encouraged me to give death another chance and find another way to incorporate it.

To conclude though this PDP has very much helped me improve as a person, and Unreal 4 especially still has a lot of untapped potential I didn't even touch upon (like the landscaping tool) that I can continue to research and investigate in my spare time. If I were to do this task again I’d definitely try to include more skills and techniques, to teach myself a larger variety of mechanics inside Unreal 4, as in a way I played it a bit ‘safe’ and should strike to leave my comfort zone more often. Also if I were to migrate into the games industry specialising in level design, I feel I'd be more confident in my abilities of creating a fun level for a professional retail game due to the practise I did with my PDP. It helped create an environment where I could just test different theories and concepts to see what did and didn't work (like me not implementing a death system into the project and using invisible walls everywhere instead), while also realising my mistakes and improving upon them as knowledge to take into the future (such as me understanding why invisible walls can be a bad idea as they break the player's immersion, so I worked towards implementing death into my game instead so I could safely remove them all and create a much more fun experience). But overall I enjoyed the time I spent creating my level for my PDP, and I’d like to give level design another go in the future.

PDP Week 10

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!

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.)

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).

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:

"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.

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.

The bird is a royalty free model from the Unreal 4 Marketplace.

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.

A floating ? coin, just out of reach to the typical player which encourages the user to explore.

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:

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).

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:

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.

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:

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).

PDP Week 5

This week I focused my time on researching some more mechanics to implement, as well as fixing any bugs/ making adjustments to things that I already have in my level (like adding some more invisible walls to step the player from glitching out of bounds with research from (Bobic, 2000) with an article on advanced collision detection). The purpose of this week is to add a bit more variety into my level, while continuing to expand on its scope and size.


Upon testing my current level (a critical process in the development of any game) I encountered various areas where it's possible to go out of bounds to unintended areas (like falling off the stage into the sea below). To remedy this I added various blocking volumes (invisible walls) around the current level in places where the player will instinctively know where they're not supposed to go, and will fully-expect an invisible wall anyway. So for example in the tricky platforming sections with the bounce-pads they will hit an invisible wall if they try to bounce away purposely in the wrong direction, but in this instance they are also used as guides to help navigate the player along without actually telling them, which is me building upon the theories I've established din previous weeks further. All of this is an example of me conducting professional level design practises, as the player starts to learn how the environment is structured and what the common conventions for various objects in your game mean, they'll also begin to get a grip on the level designer's style too.

I also started making a branching path today at the start of the level, something I originally planned but should still be wary of. Because when the player instantly loads the game they have freedom to go wherever they please, a concept introduced in one specific place (like the bounce-pads) may not make sense when used in context somewhere else. This is why I will strive to introduce different concepts in different places, so that the player can go anywhere first and still gradually learn and understand how to play through the level.

The new mechanic I created this week was an elevator platform, using a tutorial by (Tesla, 2014) linked below. Essentially it acts as a completely static platform until the player stands on it (that's when a collision is detected) and from there it will move upwards in a fixed direction at a fixed speed until it reaches the stopping point using an animation timeline inside the Unreal 4 editor. From there the player can carry on and play through the level once the elevator stops, and there is a lot of potential for this new mechanic in my game to navigate around different platforms and pieces of terrain.

https://www.youtube.com/watch?v=09-Owqumeo0

With this new platform created I started applying it within my game world, in a semi-hidden area when the player begins the game, as explained below:

The player starts the game and sees a curved platform with a staircase veering off to the left, enticing them to follow it.

They then encounter a platform they can jump across to. This may also be the player's first time jumping, so it's easy for them to walk around and try again if they miss, as they continue to get the hang of the mechanics using the earlier theory I researched.

When they jump across and look down into a place that at first looked like a deadly drop, they see a strange white platform that's a strongly different colour to all of the other platforms in the scene. With the long trail that led them here it gives a strong compulsion for the player to jump on it...

And when they do the white platform will fly straight up and take them to a secret part of the stage! It offers a very fulfilling feeling to the player, as they found this secret area with no tutoring at all creating a very rewarding experience.

Next week I will continue to flesh out my level using this new mechanic, and continue my research into level design techniques too.


References: 

Bobic, N. (2000). Advanced Collision Detection Techniques. [online] Gamasutra. Available at: http://www.gamasutra.com/view/feature/131598/advanced_collision_detection_.php [Accessed 24 Feb. 2016].

Tesla Dev, 2014. Unreal Engine 4 Tutorial - Basic Elevator/Lift - YouTube [WWW Document]. URL https://www.youtube.com/watch?v=09-Owqumeo0 (accessed 2.24.16).

 

PDP Week 4

This week I started building upon the fundamentals of my level design using the bounce pads from last week, while also conducing some research onto a good method to go about doing this. In the last blog post I created an area which is only accessible via a bounce-pad, so I decided to design an area which uses that mechanic with confidence in that the player will know how they work and will be able to reach the end.

According to a video below by (Brown, M. 2015), someone who has a lot of previous professional experience working in the games industry, there is a very efficient four-step method to constructing a game's level, as used in example games like Super Mario 3d World which expands upon the initial concept of 'showing not telling' that I researched. It basically involves ensuring your game has lots of variety while introducing a unique concept in every level, to make each one feel memorable to the player while also keeping the end-user engaged with the game without them getting bored, since there will always be something to look forward to in the next stage. This source underlines a good base guideline to set out each level: first, you introduce the new mechanic in a safe space, somewhere so that the player can experiment and toy with the new gameplay element in relative safety without fear of dying due to trial and error over bad game design.

The next step is to actually use the new game mechanic in the context it was designed in and take it another step forward. So far example with moving platforms (something I will implement into my level at a later date) the player will already understand their basic workings, so the next encounter with them could be over a pit or using them to climb up a wall, as the level's difficulty gradually scales. The next step is to take this new mechanic in a different direction, and apply a 'twist' to it as you throw the player off. For example, as a twist there could be moving platforms as you navigate over them, but there could also be bounce-pads as well to test the player's mastery of two different gameplay mechanics at once! This adds yet another layer of depth to your level as it gets harder at the same pace as the player, without ever having them way out of their comfort zone with no idea what to do.

For the last and final step, add one last tough challenge to truly test the player all of the skills that they've acquired in the level. Once they've reached the end of this final test and bypassed the whole stage, gracefully bow down to the mechanic for that level and discard it just before it gets tiring and wears out its welcome/ loses its appeal, as the player continues to proceed onto the next level, with yet another new gimmick lying in wait for them to master!


https://www.youtube.com/watch?v=dBmIkEvEBtA

This is a process I will implement into my own game, in fact, it's something I've already started doing when incorporating my bounce-pads and introducing them to the player! Such as when I first introduce the bounce-pad in a safe space, the player is free to experiment with it until they have a good understanding of the mechanics behind it. So I could take it a step further from here, and this is the progress I made:

When the player walks up the stair they will encounter a bounce-pad, and know exactly what they do.

Upon collision they will be bounced up to another platform. Initiating the 2nd step in the 4 step process with a challenge of jumping up onto platforms with these bounce-pads.

After a while I introduce the twist to the bounce-pad mechanic, which is the 3rd step of the process. There's another bounce-pad placed here, but this time it's on the wall! Another platform is clearly visible across the large gap, so using the player's previous knowledge and presumptions based on the evidence I've left for them, it's only logical to jump into the bounce-pad on the wall to see what happens...

The player will find themselves rocketing across the gap! This modified bounce-pad object was simply done, as I edited the strength value for that specific instance to be much stronger horizontally across the X axis than upwards on the Y axis.

The player will now come to the end with one last puzzle, following the guidelines for step 4. It's the final challenge for the player before they wave goodbye to the bounce-pad mechanic before it gets tiring.

All the player essentially has to do is bounce off the last jump-pad, and position themselves to land safely back at the start of the level without falling off into the water! It's the last hurdle to face until they go somewhere else and explore another part of my level, while also just being a really fun and exhilarating way to travel back to the start of the map as they tumble down from a great height!

Next week I will conduct some more research for different level design techniques to apply in another section of my level!


Reference:

Mark Brown, 2015. Game Maker’s Toolkit - Super Mario 3D World’s 4 Step Level Design [WWW Document]. URL https://www.youtube.com/watch?v=dBmIkEvEBtA (accessed 2.17.16).