Spaces in Time - Part 2: Time Rifts Continued

Click here to see the last post in this series.

Earlier this year, I submitted my ice-themed time rift to the Steam Workshop, and I was rather surprised not only to see how many people have viewed and downloaded the map, but also left positive reviews.  At the time of writing, the map has a 5-star rating, with 944 players leaving reviews and 1,556 players being subscribed to it (plus, 18 favorites!).  This is rather surprising, considering how little pre-planning went into the map, and the fact that it was my first attempt at a mod for the game overall...

Application (Continued)

Looking at some of the notes and screenshots in my previous post, not much had really changed.  I did want to place more effort in creating something that resembled a difficulty curve, rather than just haphazardly placing obstacles in hopes that they would create something interesting.  Overall, I stuck to the use of the 4 main obstacles (rotating ice cubes, rotating pie-shaped platforms, slides, and grapple hook points), but the way they were presented to player was altered slightly.  Where the start of the rift had 3 rotating cubes originally, the later revision replaced them with 2 static platforms and a singular rotating cube, as a means of introduction to the obstacle.

This idea was also applied to the spinning gears, which would spin at a faster rate later on in the rift, and the pie-shaped platforms, which would be missing additional pieces as the player got closer to the end.

Difficulty curve aside, much more of the time and effort went into creating a course that offered fluid navigation, and placing aesthetic elements (lighting, particles, decals) to support the chosen theme.  Thankfully, the base set of assets featured in the tool set allowed me to create a setting that felt very much like a "grimy" industrial freezer.

I would very much like to update this map in the future with ice physics, if I manage to take the time to learn how to create customized volumes within the UDK.  As it stands, there are no means for modders to create flat slippery surfaces, unless they manage to code it themselves.  There is currently a volume that will force the player to slide down a slope that is too step to stand on, and it may potentially offer some solutions to simulating the feeling of walking on ice.

Until then though, I'm going to move forward with my level design studies into what are referred to as "Purple" Time Rifts.

Purple Rifts

Purple Rifts are sub-levels found within each chapter that are typically used to help tell stories about key characters or settings.  They are structured quite differently from Blue Time Rifts amd regular chapters in that they have their own sets of sub-levels and a unique collection system, more similar in style to the collect-a-thon games of the 90's.

Rift-Specific Collectables

Aside from from the green and red "pons" that the game utilizes for currency and health (respectively), Purple Time Rifts introduce "Rift Pons" and "Storybook Pages".  Rift Pons must be collected in order to proceed through each rift's sub-levels, and are spread out among a map, typically at points of interest or after particularly challenging action-paths.  Storybook Pages, on the other hand, are entirely optional collectibles that are well hidden in each sub-level.  Each page contains an illustration that is revealed once the level has been completed, offering additional details to the story that the level's environment may not have been able to reveal.

This collectable system is similar to the one that would be found in Banjo-Kazooie, albeit on a much smaller scale.  Rift Pons reflect Jiggies in their importance and difficulty to achieve, while Storybook Pages reflect Mumbo Tokens in their rarity and placement.  Players will often have to search every nook and cranny in order to find and collect all of these pages, while Rift Pons are usually a clear goal that the player is actively in pursuit of.

Example Storybook Page location, from imgur.com user soviam.

However, while the collection of Rift Pons are required to progress, it is worth noting that the number of Pons required to open the next Rift Gate is often less than the number of Pons available in each sub-level.  This allows some freedom of choice for the player, as they can "bank" some Pons to use in a future sub-level if there future are challenges they choose to avoid.  This was a common design choice in previous 3D-Platformers, as it encouraged back-tracking through previous levels, should players get stuck when trying to progress in levels later on in the game.  However, in the case of these Purple Rifts, progression is a one-way street, and the collectables are self-contained; Rift Pons and Storybook Pages have no impact on the game outside of the level.

Rift gate displaying number of "Rift Pons" required to open.  Clearly visible for the player to reference while exploring.

Environmental Story-telling

"Purple Time Rifts are created when a time piece crashes into a person, causing the rift to be themed around them. These rifts lead to a strange dimension where the world resembles the chapter they can be found in." - Hat in Time Wiki

The above quote, found in the game's wiki pages, provides a little more context for the purpose of these rifts and the reasoning for their appearance.  As previously mentioned, the Storybook Page collectibles found in these rifts are used to help further tell the story of key characters in the game.  However, unlike the "Blue Time Rifts" we explored in a previous post, Purple Time Rifts have much more variety in their setting, reflecting the environments of the chapters they are attached to.  This can be seen by each rifts use of familiar props and characters.

Next Time...

I had originally started my own Purple Time Rift way back in April, when I had attempted to participate in the modding contest hosted by the game's developer, Gears for Breakfast.  However, I far underestimated the effort that would be required to complete my vision for a new map, and far overestimated the amount of time I had to complete it.  At the time of writing, I have approximately 336 hours in the Hat in Time Editor, and I have given myself a deadline of December 21st to complete my project.  My next post will be a much lengthier dive into my development of the map, not only observing and applying the design philosophies of Purple Time Rifts but applying common level design practices as a whole.

Until then, I figure I could at least add a few in-progress screen shots from earlier in development.  I will be on vacation after the map is finished and released, so the follow-up blog post will not be written until early next year.  At that time, I'll probably also be posting some tidbits about my 2018 experience as a whole, and maybe discuss my plans for 2019. 

Until then,

J-West

Spaces in Time - Part 1: Time Rifts

Introduction

If you have read any of my previous work, you'll know that I have a... "thing" for the 3D Platformer Collect-a-thon genre that was popular in the 90's.  These are the games that I grew up playing.  Last year we saw a good number of releases, most of which were met with mixed reviews (see Yooka-Laylee, Snake Pass, Freeze-Me).  There is one, however, that would surprise everyone and made it's way to being the 2nd highest rated game on Steam in 2017: A Hat in Time (referred to as "AHiT" from here on out).

For being the first game for the studio Gears for Breakfast, and the first game ever created by Jonas Kaerlev, there is so much that AHiT did right.  "Hat Kid", much like Mario on the Nintendo 64, is an absolute joy to control, with movements that were easy to learn and a bit difficult to master.  Badges could be purchased that manipulated gameplay in fun and interesting ways, like granting the player the ability to sprint or freeze time.

What astounded me the most, however, was the level design.  AHiT offers so much variety in it's spaces that I never grew tired of playing.  One moment you're at ease, exploring the open and inviting world of Mafia Town, and the next moment you're sneaking around on the Owl Express, gathering clues to track down a murderer.

I haven't been able to get this game out of my mind.  AHiT is a huge step towards what the modern 3D Platformer could become.  And seeing as it comes with it's own set of modding tools, I figured its high time I tried my hand at actually creating my own spaces to play in, rather than sitting around and critiquing the worlds that others have laid out for me.

Why Write This?

There is a fantastic opportunity here for me to expand my own design experiences and learn something new.  What better way to do this as a hobbyist than by modding a game I enjoy?  A Hat in Time offers it's own tool set for creating new levels, hats, skins, and other assets, all based in the Unreal 3 Development Kit.  Not only do I get the chance to design levels for a 3D Platformer, but I get to learn a new engine while I'm at it.

As I will be learning many things as I go, I figured it was a better idea to keep track of my progress through individual blog posts rather than one large essay, like I did with Yooka-Laylee.  I'll do my best to research particular aspects of AHiT's worlds as I attempt create my own, learning what ideas could work in practice and which don't.

Now then...

Time Rift Overview

The modding community over at the AHiT Discord strongly suggested that anyone just starting out with modding should take a look at the Time Rift template that can be used when starting afresh.  The template level is quite simple to work with; a small obstacle course with a spawn point, check point, time piece, a revolving platform and a couple of stationary platforms.

I bolded the term obstacle course in that last sentence because, in essence, that is what the most basic of the Time Rift levels often turn out to be.  There aren't any new move sets or concepts introduced in Time Rifts, they are meant to test the player's mastery of what they have learned so far.  The first two time rifts the player would typically come across are within Mafia Town (Sewers and Bazaar), neither of which require the use of additional hats or badges to complete. 

** Note, for the purpose of this particular post, I am focusing on the more basic rifts.  Purple (or cave) rifts, while similar in nature, have more complexities to them (collecting, narrative, sub-levels), so I will be saving those for another time.

Rather, they utilize Hat Kid's movement-based mechanics in interesting ways (wall climbing, diving, and of course running and jumping).  These time rifts aren't available right away - they only appear as the player progresses.  Looking once more at Mafia Town, the first time rift, Sewers, doesn't become available until after the player earns the time piece for "Down with the Mafia", the 4th act of the chapter, which provides the player with ample time and opportunities to learn and master that basic set of mechanics.

Time Rift Design

At their very base, platforming levels could be considered as string of obstacles or micro-challenges for the player to overcome.  The "Blue" Time Rift stages are a prime example of this, as each rift re-uses similar assets in new ways to put the player to the test.  There is only one objective (time piece at the end of the course), and, for the most part, the way to get there is fairly linear.  The first two rifts, featured in Mafia Town, take the average player about 1 minute to complete, and require nothing more than a firm understanding of Hat-Kid's base mechanics: running, jumping, climbing, dashing, etc.

"Bazaar".  You can see the variety of assets used in this level, and how they are grouped together to create individual challenges.

As the player progresses, however, mechanics that are introduced in a world are placed into their corresponding time-rifts.  The next pair of blue rifts the player would be expected to come across are in Battle of the Birds, both of which are a bit more complex than their Mafia Town counter parts.  "The Owl Express" uses the pressure-plate switches found in the Acts "Murder on the Owl Express" and "Train Rush" to create exploratory puzzles, while "The Moon" utilizes the band-following mechanic from "The Big Parade" and designs a level that discourages the player from taking the same route twice.

"Owl Express". Still a linear path to the finish, with switches and more complex structures introduced.

Application

While creating a mod map doesn't necessarily require you to stick to the mechanics featured in particular Acts or Chapters, I've learned that simply focusing on a certain set of mechanics or a theme can often help with design direction, and give a more cohesive feeling to the level without throwing in too much.

When thinking of what sort of interactions I wanted in my own rift level, I was particularly fond of one set of actions: sliding, jumping, and ending on a grapple hook.  The idea of sliding made me think of ice, which in turn gave me a theme, "Mafia's Icebox".  I wanted to try to give the impression that the rift was taking place within an industrial refrigerator, without straying too far from the basic set of time rift blocks.  In the end I focused on the interaction with grapple hooks and slippery surfaces, doing what I could with Unreal Matinee and Kismet to create challenges around these concepts.  You could consider this both a bottom-up and a top-down approach to designing this level, as focusing on one set of interactions provided me with a theme to work with.

Ultimately, I wasn't looking to make a challenging level for the average player; I instead wanted to make a level that was more enjoyable and a little tricky to try to speed through.  In that mindset, the pathways ended up being extremely straight and linear, with only 4 hard turns until the goal was reached.

I do enjoy playing with the fog settings.

What has really become tricky is using materials and lighting to create the feel of ice and cold steel.  This is why there are individual jobs for lighting and environmental artists, neither positions of which I have much experience in...

The first iteration of this level re-used most assets at least twice:  

• 2 sets of 3 rotating "ice cubes"
• 2 sets of 3 rotating ice "pizza slices"
• 2 sets of 2 rotating gears
• 3 "slides"
• 3 grapple-hook lifts
• 1 static grapple hook point

While this helped to create the consistency I was looking for, it doesn't really have the right balance of variety to really keep the player on their toes as they progressed.  Simply increasing the speed that the gears would turn or changing the arrangement of platforms doesn't quite give the increasing sense of difficulty a linear level like this should.  I need to find a way to remix some of these obstacles to make the progression changes a bit more drastic...  Maybe add a few more static grapple hooks as a means of traversal.

Mid-Post Update

I had originally planned to complete this post and share it once the level was done.  However, during the process of designing this Rift and writing this post, Gears For Breakfast officially released the Modding Update for AHiT, and even started a $1000 mapping contest for the best Purple Rifts the community could offer.  This is an opportunity I am extremely excited about, and as much as I hate jumping ship in the middle of a project, I might have to make an exception for this one.  The contest goes until April 27, so after that point, I'll see about finishing this "Icebox Rift" and maybe write a reflection post about what I learned while creating my own Purple Rift.

See you in a month!
J-West

In Retrospect: Voodoo Cheval (Part 2)

Click here to see Part 1.

The previous post left off with the re-introduction of snakes in Wave 6 of level one, so we'll pick up from there.

Wave 6

The snakes are significantly faster than zombies, and paired with their capability to split in two should the player make a wrong move, they prove to be a significant challenge when tossed into the spawn wave mix.  

Up until this point, the player has been able to get by with just drawing circles of various sizes on the screen, fighting off larger and larger hordes of zombies.  With the addition of snakes, I wanted to keep a similar pace to what has been developed so far without having to place a large emphasis on a new enemy type, hence why two snakes were placed in this wave, along with 4 zombies.  

As snakes appear first on the screen, it gives the player a moment or two to process what they are seeing and try to recall where they had seen it before.  This was, in hindsight, the wrong way to go about it.  Snakes should have been a part of the mix from the beginning, considering we introduce them so early on in the experience.  This could have even further prevented the use of the exploit (discussed in the last post) from the beginning, keeping it from even being called an "exploit" in the first place.

Thankfully, if they fail to react and kill the snakes in time, we have placed a check point here to avoid the frustration of starting over at Wave 1.

Wave 7

A bit of a throwback to the lesson I was aiming to teach in Wave 2, with the single, large grouping of zombies.  This wave, an arrangement of 8 snakes that were split into 2 straight lines, were meant to suggest visually that the player could chain together multiple snake kills with a single drawn line.  Two lines of snakes were used instead of one to, again, avoid slowing down the pace too much when introducing a (possibly) new idea.

Waves 8-10

More practice in iteration, applying concepts I attempted to develop since Wave 1.  Overall, I'm pretty happy with the way these placements turned out, they strike an odd balance between symmetrical and random.  Enemies are, for the most part, consistently pouring in from every direction into the screen, without favoring a particular side.  This keeps the player actively analyzing the entire scene, making quick decisions as to which enemy to take out first.

Wave 11

The last enemy that gets introduced in Level 1, the "Demon".  The demon comprised of 3 possesed skulls, all chained together by magic.  The idea was that to defeat the skulls, you would have to trace the chain that connected them.  Sometimes, this suggestion would be a little more vague than others (see above screenshot). 

This was a bit of an odd one to work with, as his prefab asset was designed to randomly place him on the map, with the skulls placed in a somewhat random arrangement up to a certain distance from one another.  Originally, we had aimed to have 10 waves in total for Level 1, but somewhere during development of the other levels, it was decided that the demon should be introduced earlier in the game.  I don't recall if we even had discussions of offering the demon a tutorial like we did the zombie and the demon...  But I liked the idea of giving him his own wave, and letting the player figure out how to defeat him.  The chains, being connected in straight lines, should have (hopefully) suggested what action to take.

Waves 12-15

The last set of iterative levels.  Now that I have played through the whole game a few times, these last few felt anti-climactic... I'm unsure as to why this ended up being the case, but the only thing that I can recall was worrying about the integration of the random demon spawn with the rest of the enemy placements.  Placing that asset required thought and timing in relation to when the other enemies would appear on screen; I didn't want to run into the situation where the player was unfairly overwhelmed.

I am pleased to see that, for the most part, I remained consistent in applying the concepts from earlier parts of the level (varying sizes of zombie hordes, grouping of snake-lines), as it certainly added variety to my input actions.  The game never quite felt stagnant, the only change between waves that I could feel upon re-playing the game was a rise and fall in flow .

Conclusion

"Voodoo Cheval" has it's flaws, but as "my first shipped title", and my time working with a large team on one project, I enjoyed the experience and am rather proud of the final result.  Joining VGDA made me a few friends, but I also got the opportunity to learn a lot of development practices and concepts first hand.  These lessons may seem obvious to you as a seasoned developer; they're obvious to me now even with only a year or two of experience under my belt.  But these lessons were important nonetheless, and sometimes the only way you will learn them is the hard way:

• Play-test early, play-test often, play-test with everyone.
• It's obviously important to play test your game frequently and thoroughly, but it's also important to try to play with a mindset of someone who has never seen your game before.  This is the job of the average QA tester, someone who will dive into a game and try to break all of the rules; accounting for every possible thing that could go wrong or could be done differently than what the designer anticipates (see 'The Exploit' in part 1).  This could yield better results in the long run when you take your game to external play-testing.
• Play-testing the whole game (or level, in my case) sounds exhausting, and I'm pretty certain I had my aversions to the idea during development (even though my part of the game lasted only 5 or 7 minutes...).  But it's truly the only way to really gauge the difficulty curve of the experience as a whole.
• Look outward for inspiration.
• Something I realized looking back at this development process was that I never ventured outside of Voodoo's bubble to gather inspiration on how to approach the spawn-wave design.  I would often try to sketch waves on paper and try to determine the best way to use the pieces at hand, or simply drop assets into Unity and adjust their locations until I had a wave that simply "felt good".  Now that I have a few other projects under-way, I am constantly doing research and looking for inspiration to better the game-play experience overall.  I can't help but wonder how different this level could have been if I had put that into practice earlier.
• Open and constant communication.
• This wasn't a lesson so much learned as much as emphasized.  As a college student, working on a game part-time with a club, your priorities shift often.  Class work builds up, exams get brutal, and tasks that you either aren't payed for or graded on will get pushed aside.  Communication in this kind of situation is huge if a project is going to see completion by a deadline, as assigned tasks that you might not be able to complete can be handed off to someone else.  As VGDA did it's best to mimic an Agile environment, there were several techniques and tools that I had to become familiar with, like Trello or weekly Scrums, that assisted in keeping communication open and updates constant.

Overall, as small of a game as Voodoo Cheval is, my time developing it was worthwhile.  I've since continued working with VGDA on our next title, and I can't wait to see what challenges we overcome together.

In Retrospect: Voodoo Cheval (Part 1)

During a QA session with some of the recruiters at Blizzard, it was brought to my attention the importance of maintaining documentation for your design and development process.  While I reviewed the documents I had made for previous projects, I had the idea of making a collection of blog posts that review particular challenges or struggles that I encountered and what my solutions to them would be.  Looking back at my experience in this way, I hope, will help to shed some light on things that may have gone right, as well as things that I could have done differently.  Consider these posts to be bite-size post-mortems.

Voodoo Cheval is the first (and at the time of writing, the only) game that I have worked on that has been published onto a distribution platform.  If you are unfamiliar with the title, it is an action game intended for mobile devices, where the player is tasked with defending their beloved horse from an onslaught of zombies, snakes, and other monsters by drawing particular shapes on the screen to destroy them. 

I was brought onto the project rather early in development, signing up for a role that sat between design and programming, but leaning more towards the design end of things.  The team, like myself, were all full-time and part-time students of California State University, Long Beach, who had banded together to form the Video Game Development Association (or VGDA, as I will refer to it from now on).  What I found so brilliant about this opportunity was that very fact; we were all students.  We all had coursework to worry about, jobs to help pay for rent and tuition, very little free time, and a huge passion for video games.

The team was fairly large in scale, and with each of us only being able to contribute so much time each week to development, tasks were divided into smaller, more manageable pieces.  While I had the opportunity to work with other students designing systems, namely enemy behavior and player controls, the bulk of my work was in designing Level 1; an open setting where 3 types of enemies would appear on the screen in waves.  By the end of development, there were 15 waves in total, each with it's own purposeful design with the aim losing the player within "the magic circle".

Tutorial

Upon starting the game from the main menu, the player is met with a very brief and simplistic "scripted tutorial" scene, where the player is met 2 types of enemies that they will see throughout the remainder of the game.

Although this tutorial was not of my own design (will give credit when I find out who exactly built it), it had a large influence over how I built the rest of the introductory stages.  The goal was to make the tutorial completely interactive, without hindering the start of a play session too much.  As the enemies approach the horse on screen, the player will have the opportunity to defeat these enemies in the usual fashion, but if they do not know what to do, the snake and the zombie will pause, staying frozen in place before they can cause any harm.  When they freeze, the spell effect (usually visible on the screen when touch input is detected) is animated to suggest what action to take, almost in a "monkey-see monkey-do" kind of way.

No pop-up windows, no invasive companions to say "Hey! Check this out!".  Just a simple suggestive animation paired with a brief safety buffer before the game really begins.  For a new player, this brief encounter establishes the foothold that the following enemy spawn waves will build upon.

Wave 1

Looking back on it, I'm pretty sure I over-thought some of these enemy placements...  It was clarified before I started that enemy spawn would not be random, but placed.  With replay-ability being a concern, I felt it best to keep these placements a little on the unpredictable side.  Hence, this asymmetrical placement of the first two zombies.  An easy win, but it also should have served as an indicator that, from this point forward, there will never be just one of these guys on the screen at a time.

Wave 2

The idea behind this wave was to re-enforce an idea that might not have been obvious to every player: the fact that you can kill more than one enemy with the same attack.  Even if you attempted to draw a circle around a single zombie in this grouping, you are bound to rope in another one with how close together they are.  This was also meant to establish the idea that the size of the shapes you will draw can vary, which we will find out later can either help or harm you immensely.

Waves 3, 4, and 5

The third wave was intended to push the player to use the different sizes of circles that were demonstrated between waves 1 and 2.  The zombies on the left and right are the first to appear, and they are spaced relatively far apart.  It would be fairly easy to circle each one individually or circle them both together.  The grouping at the top of the screen comes shortly after, a little more tightly knit together, and finally there's the big grouping at the bottom, appearing slightly behind the grouping at the top.  

At this point, the player may start to feel a little frantic, drawing circles around zombies the second they pop onto the screen.  But if they are patient, they may be able to see that by allowing the zombies to draw in closer, they can draw one big circle to take them all out at once.

Unfortunately, we never implemented any sort of reward system for combo kills.  Something that would have made this design process a little more meaningful.

Wave 4, shown below, tries to make that idea of the risk and reward of patience a little more obvious, having the zombies enter the screen in the form of an actual circle.

In hindsight, it might have made more sense to swap Waves 3 and 4 to make this point, but I think it also works in regards to replay-ability.  Now that you are fully aware of how this kind of strategy could pay off, you might want to play through it again and see how many zombies you could kill with a single drawn circle.  An unexpected issue that this design may have contributed to, however, is the discovery of an exploit that many players would try to abuse,which I will discuss shortly.

Wave 5 was simply a zombie rush, with assets placed in various positions in an attempt to establish rhythm, but while avoiding predictability.  Designing waves like this one (there are many others in Level 1) was simply an iterative process, where I would place the zombies in various positions and re-position them until the wave felt like it could hold a "flow"; not too challenging, but not to boring either.

The Exploit

Something that become apparent to us rather quickly during play testing was the fact that the player could, in fact, draw circles big enough to wrap around the whole screen, if they were quick enough to make the  beginning and ending points of the line connect.  I don't quite recall at what point or which wave that play-testers would come to this realization, but I'm pretty sure it was around waves 3 or 4.

When a discovery like this one is made this early on, it makes the "strategic placement" of enemies essentially moot.  Even more unfortunate, the team never got around to properly addressing and fixing the issue.

A (rather poor) demonstration of the exploit being used in Wave 3.

Looking back, there are a few reasons I can think of as to why this wasn't fixed.  One is the deadline; as students, the goal was to make one small game over the course of a semester, all the way up to the week of final exams.  While we did do a fair amount of internal play-testing, this issue wasn't really brought to our attention until we had students from other colleges play the game at the Student Game Developers Alliance Summit in May, not long before our deadline.  At this point in time, we were no doubt scrambling to get bugs fixed and the final art assets in place, which ultimately still resulted in a cohesive experience we were all proud of by the end of development.

Another reason that comes to mind is how ineffective this strategy becomes after Wave 5, as snakes are re-introduced for the first time since the tutorial.

Something that might not have been made clear in the tutorial is this particular trait about snakes:  if you accidentally draw a circle around them, they "split", and form two smaller snakes that the player now has to deal with.  If the player were to simply sit there and spam large circles on the screen, without paying attention, they would be overrun within moments.

I recall at the time feeling that this enemy design would counteract the exploit so easily that it would be abandoned after Wave 6, which could also be how the rest of the team felt when the exploit was discovered.  In either case, it taught me to try to play-test my own work from a perspective of someone who doesn't know what to expect.  This seems so obvious to me now, after reading books and articles on bug testing or human centered design, but as this was one of my earliest projects, I'm willing to forgive myself and move on.

Continue to Part 2.

Essay: A Study of Spaces in Yooka-Laylee

I've written a small essay analyzing the spaces and level design of Yooka-Laylee.  I have anticipated this game since it's Kickstarter announcement, and felt that this is a good opportunity to practice writing about some concepts of design that I have been studying about lately.  I'm looking to grow in my wiritng ability, so as usual, feedback is encouraged.

Below is an excerpt from the opening paragraphs:

"Yooka-Laylee, and other games that fall under the Free-Range Platforming genre, appeal to gamers who like to explore, discover, and interact within an interesting 3D space.  While the game mechanics are important to the impression the player has over their experience, creating a space that places the player in a state of flow is just as important, if not more-so.  Everything down to the tactile interaction the player has with the objects placed around them assists in creating a memorable and enjoyable experience.  It is in the expansion of these virtual spaces that we often see a change between generations of gaming, as an increase in memory and processing power allows for bigger and more interactive worlds to explore.  To create a world that in non-linear, but also naturally guides and encourages the player to take specific actions is a challenge indeed, and I hope to get a firm grasp on how 3D level design should be done for my own work in the future."

Click here to read the rest.

"Free-Range" Platforming

Alternatively Titled: "Don't get caught up in terminology like I do."

While I was researching for my previous post, I found myself getting caught up in labels.  It turns out that the name "3D Platformer" can go a long way, and I was constantly finding myself reading too much into games that were not really similar to the type of experience I was searching for.  As an obvious example, Wikipedia gave me Crash Bandicoot when I wanted Donkey Kong 64.

This led me to searching for games that bore the other relevant title of "Collectathon".  However, it turns out that I would face a similar issue.  While games like Banjo-Kazooie and Super Mario 64 wear this label with pride (collecting being the goal of the game), there are others that also bear the title that are not quite in the same vein of gameplay.  Titles like Rayman Legends, while incredible games that highlight collecting as a motivation, are still linear experiences in comparison the the exploratory nature of the N64 Rare games.

I'm hereby proposing a name change for the games that followed the 3D Platforming Collectathon model of Super Mario 64:

"Free-Range Platformers"

The term "free range" refers to a style of husbandry that has livestock (usually associated with chickens) roaming freely in an enclosed area outdoors, rather than being cooped up all day.  I found myself relating to these games in this manner; typically, each game will have a hub world that the players will have to return to after spending some time exploring a stage.  Try to imagine those free-range chickens collecting all of those seeds and insects, only to exchange them for a more prime location in the chicken coop when they return at the end of the day.

Granted, this label may suggest that the player is some kind of a farm animal, but I stand by it.  In fact, I think I'll use this term in my future posts until at least ONE other person picks it up.

P.S. - More in-depth analysis on free-range platformers coming soon.

Essay: The Evolution of the 3D Collect-athon (and Where it Stands Today)

I've written my first major essay on game design, looking at the evolution of a genre that I've held very dear since my childhood in anticipation of Yooka-Laylee's release.  This is my first time writing something of this length on the subject, so feedback and constructive criticism is appreciated.

Below is an excerpt from the introductory paragraphs:

"Many reviews have praised the game as a proper "return to form", being a true spiritual-successor to Banjo-Kazooie.  Others have found the game to be far too dated, stating that the game carried issues back from the N64 era.  I have often considered Banjo-Kazooie to be one of my favorite games of all time; it is the game that got me into games in the first place.  So I had to ask myself: Is there really any room for the original 3D Platformer/Collect-athon style in this day and age?  Could a game like Yooka-Laylee offer more than just a nostalgia trip?"

Click here to read the rest.