Thursday, March 10, 2016

Collectibles: coins, star coins and PowerUps

The game will be focused first of all on platforming, but it will also feature a lot of exploration. Exploring will reward the player in 3 ways:
  • By finding secret exits to hidden levels.
  • By discovering secret areas with immediate rewards (star coins or 1Ups).
  • By finding hidden PowerUps that make the level easier.
Coins are a must to have in the game: they can be used to guide the player without having to use text or non-elegant solutions like arrows. Star coins add depth and replayability to the levels and can also be used to set up challenges for the most advanced players, by forcing to get through challenges through the hard way to get the star coin. 1Ups can be used like star coins, but they´ll respawn every time the player revisits the level unlike star coins (this means there´ll be a fixed finite number of star coins in the game).
For these collectibles to be attractive to the player they must give a worthy reward: some players will be enticed to go after them just for completion´s shake, but other´s will just disregard them completely and pay no attention to them. Forcing to get them (especially star coins) can rise the difficulty of the level too much for novice players so that solution is not optimal.

1-Ups

Having 1-Ups in the game implies having a life system, but is this desireable? Lifes can be used in one situation: when the player runs out of lives he will start the level from the beginning instead of from the last checkpoint. However, this may not be a good decission as it can frustrate the player: he may find a part difficult and failing repeteadly at it will have another additional penalty. Besides, in a game where the player gets to freely replay levels he can easily accumulate lives, so that after a short while they become meaningless.
There is another approach we can take: isolate the life system from the overworld. The player can start each level with 5 lives, getting to a checkpoint will reset the number of lifes to 5. Losing all lives can send the player back to the overworld or send him back to the previous checkpoint and reset lives. This adds challenge, but is a nice help for the player that will surely be appreciated. This allows us to hide 1-Ups in the stage. We can also make it so that inside a level, the player can accumulate more than 5 lives if he finds them.

Coins

Coins are a must as they can accomplish the critical function of soft-guiding the player. However it would be good to have them fulfill another purpose, as this can give them more importance and make their usage in some situations (like bonus games) more meaningful. There are 2 ways we can implement coins:
  • Resetting them after the stage ends: This way the player can´t "cheat" by replaying a level with a lot of coins and pumping up his numbers. However, this adds a big restiction: coins can only be used in the level in which they´ve been collected.
  • Adding them to a total count: This allows to open other more general usages for coins, but also opens the door for "cheating" replayed levels. We can however bypass this by setting a limit of 100 or 200 coins per level run. This way we can use them in bonus zones in big quantities and even if the player finds a good spot for grinding, he will have to complete the level each time, which will discourage this approach. Another option is to add no limit and just add an even bigger limit to the coin limit per level, but once this limit is surpassed the coins in that level will disappear.
We can do a mixed approach: coins will respawn as long as the player doesn´t hit the cap limit per level, he can only take 100-200 coins in a level in each run (we´ll have to make sure that in each level this limit is not breakable by design) and there will be 2 coin counters: a main one which will keep track of all coins collected during the game and a level one, which will reset every time the player enters a level.
This solution allows to use coins inside and outside levels:
  • Inside: Some PowerUp Blocks will show a required number of coins and can only be activated if the player has gained enough coins during the level, similarly to the guys who ate star pieces in Super Mario Galaxy. Apart from PowerUp blocks, this can also be used for other elements, like deactivating a barrier or lowering a bridge. This makes the coins more important for the player and also allows to create levels where the player must search for coins to open the way forward.
  • Outside: Coins can be used to make a ranking in shared levels. In story mode, they can be used to unlock additional content (image and music galleries) and to unlock challenges (which in turn could give a star coin when completed). Challenges will be alternate versions of the levels with some restrictions, like lowering the time limit, pacifist runs, forcing from start to end the use of a PowerUp...Unlocking challenges will use coins, so the cost can be tied up to the coin limit of every stage. For example, if we have a level with only one secret exit and 200 coins max, the challenge can cost 100 or 200 coins. But if the level has 2 exits (meaning the player will have to play it twice to get all exits) we can put the challenge at 200 or 300 coins. This forces us to put one challenge in each level. A level´s challenge will only be available after completing the level at least once and finding all star coins in the level. The challenge will reward the player by unlocking gallery items, a upload slot for the level editor or a star coin. It will be also necessary to find a way to tell the player from the overworld map if a level has hit the final coin cap or not. Once a level has hit the coin cap, all coins will turn into ghost coins, so they can still be collected and used in puzzles but don´t add to the coin count. Apart from the gallery, coins could also be used to expand the level editor, for example by unlocking skins or new music.

Star coins

Star coins are optional and the player is not forced to get them. The original objective will be to make each level have 3 star coins, but during design we will decide if having a varying amount depending on the level would be better. Star coins can be used to gradually unlock more upload slots for the editor. Also, getting a star coin will add developer notes to the story mode level where it was found when opened in the level editor (this notes will appear greyed out in the editor to show the player they are there and with a message telling that a star coin is required). Though, it is very important that we take notes of the level design decissions while making them, so they can later be included in these tips.
In the game, star coins can be used to unlock some secret levels in the overworld. They are not lost when doing this (like in Super Mario 64 or Galaxy). Star coins will emit a sound when you´re near them. This sound will get louder the more star coins you have, making it easier to find the last ones. This will be done on a level run basis: on the first run the star coins will make no sound at all. After that run, the star coins will make a sound and project a halo around them. The volume of the sound and the size of the halo will be proportional to the total number of star coins you´ve found through the game: volume = maxVolume*foundStars/totalStars. This way, hunting for star coins in the end game will be easier.

Conclusion

With this system we provide great value to both coins and star coins and also tie them to the editor.

Nintendo tricks for 2D platformers: The game feel

Nintendo is often praised for the excellent gameplay in their titles. One critical aspect of this is how well the controls usually feel and how responsive the characters in the screen are to your inputs. During development of Mario 64, Shigeru Myamoto used a "secret garden", a place where there was no fancy terrain or hazards and you could just walk around with Mario. The idea was to use this place to adjust Mario´s movement until it felt right. Like Myamoto said, it should be fun to just walk around. To achieve this, Nintendo uses some "tricks".

Update 25/08/2016: Included Automatic horizontal momentum cancellation and Double jump hold up. Check http://www.juicybeast.com for a more detailed explanation.


Index

  • Size matters: Block based world
  • Collisions
  • Collision threshold
  • Runnign over gaps
  • Minimum walking speed
  • Skidding and turning around
  • Jump height
  • Preservation of momentum
  • Jump vertical anatomy
  • Horizontal movement in the air
  • Safety jump extension
  • Sprinting
  • Conclusion
  • Bonus 1: Automatic horizontal momentum cancellation
  • Bonus 2: Double jump hold up

Size matters: Block based world

All the units in the Mario games are relative to blocks. Maximum jump distance and height, distance to reach the maximum horizontal speed, distance to skid...Even Mario´s, the enemy´s, obstacles´ and objects´ sizes can all be expressed in blocks: * Mario is 1 block wide and 1 block high, while Super Mario is 1 block wide and 2 blocks high. * A Goomba, Mushroom, Boo, Muncher, spike, Spiketop, Spring...are all 1 block wide and 1 block high.
This makes it really easy to design challenges as well as is an invaluable tool to communicate the game´s metrics to the player. The players will be able to read the game´s distances without any previous information and have the answers to the challenges the level will present beforehand (Can you reach this platform? Can you jump over this pit?).

Collisions

Even though Mario´s sprite can be expressed in block units, his collison bounding box is in fact smaller. If Mario walks against a wall he can enter it for 3 or 4 pixels (just his moustache, a part of the cap and the hand on the back). Conversely, when he jumps up he can enter a block for 3 or 4 frames before triggering a collison. Also, when running off a block, Mario will start falling before all his sprite leaves the block (again, 3 or 4 pixels earlier).
Having a smaller collision mask like this helps movement feel better as well as allows for some behaviours that make movement feel "right": * It´s easier to jump up between 2 blocks. * It´s easier to fall between 2 blocks. * It allows falling between 2 blocks while walking. * Collisions feel better as it seems that things are colliding with Mario´s body, instead of with the tip of his moustache. In general, it´s always a good idea to have a collision mask smaller than the player sprite. This allows for close savings and is extensively used in shoot´em ups for example.

Collision threshold

When jumping up against a block, Mario games will check what distance into the block the player is. If the player is right below the block, Mario will jump straight up and hit it. However, if Mario is near the edge of the block, the game allows for some threshold: if Mario is inside this threshold (3-4 pixels from the edge) he will instead be pushed out to the side of the block and allowed to jump up without hitting it. This will only happen when there´s a free space to be moved to.

Running over gaps

A cool little trick in all Mario games is that you can run over one block gaps without falling. I have no idea how Mario games do this, but I´ve implemented a method that seems to work perfectly: * When the player runs off a block, get the x-position of the block he fell from. * Check if there´s another block at the same height and at a distance 2*Block from the block Mario fell off. * If so, don´t allow the player to fall.
In my game, the id of the block where the MC is standing is always stored. In this case, I store the id of the original block and update it to the block at the other side of the gap once the MC has passed the medium point between both.

Minimum walking speed

The character should feel like it has weight. In action games, like the Megaman series, you pushed a direction and Megaman started walking in that direction at full speed. In Mario games however, Mario will start moving immediately but take some time to reach the maximum speed. This acceleration provides a feeling of weight to the character. But there is more: instead of applying a constant acceleration from 0, what Mario does is that he instantly achieves a minimum walk speed as soon as you press a direction (we´ll call this spWalkMin). Then, in the next frame he will start accelerating until he reaches the "normal" walking speed (spWalkMax).
The same happens when you are moving and let go of the direction: Mario will gradually come to a stop. In fact what happens is that the speed will deccelerate from spWalkMax to spWalkMin and once it reaches spWalkMin, instantly become 0.
These modifications allow for the character to resemble a realistic movement, while at the same time gives it a boost in responsiveness so it feels better to control. If we got rid of spWalkMin and worked from 0 all accelerations and stops would take more time and make the character feel slower and less responsive.

Skidding and turning around

If we make Mario run and suddenly press the opposite direction he will start skidding, loosing speed over distance until he starts running in the newly pressed direction. If the game followed a realistic physics engine, Mario would skid until his speed passed 0 and then start accelerating in the opposite direction. However what really happens is that the speed will only drop to a set value (spSkidTurn) and then instantly start running in the opposite direction with a reversed speed (-spSkidTurn). Again, this way the games mimics real life movement to a point, while keeping the character responsive.
I may need to check this, but I think that in Mario games usually spSkidTurn = spWalkMin, which helps in keeping a consistent behaviour.

Jump height

In Mario games, the horizontal speed is treated in ranges:
  • sp <= spWalkMin (Stop). This will only apply when we´re totally stopped or in the very first frame after we started walking.
  • spWalkMin < sp < spWalkMax (Slow Walk)
  • spWalkMax < sp < spRun (Normal Walk)
  • spRun < sp < spRunMax (Run)
  • sp = spRunMax (Sprint)
This ties directly with jump height: the faster Mario goes, the higher he´ll be able to jump. In SMW, this assignment is also done in ranges:
  • Stop => jumpHeight = 4 blocks
  • Walk => jumpHeight = 5 blocks
  • Run => jumpHeight = 5 blocks
  • Sprint => jumpHeight = 6 blocks
Note that the jumpHeight for Walk and Run is the same, probably because Nintendo wanted to make all levels beatable without running. The sprint´s jumpHeight is really never required in SMW, although it may be needed for some secret.
This relation of horizontal and jumpHeight has an immediate effect on gameplay: the faster Mario goes, the higher he´ll be able to jump (and consecuentially, the longer horizontal distance the jump will cover). It effects how you take every jump in the game, always making sure to run a few steps before achieving any jump, like you would do in real life. Again, the standarization in ranges makes the movement more cohesive and easier to understand by the player (horizontal jumping distance is also defined in blocks).

Preservation of momentum

When jumping Mario will preserve his horizontal speed if the player releases the direction button. This means that, in order to stop, the player must push in the opposite direction. This behaviour is also applied when Mario walks or runs off a block: his horizontal speed will be maintained, which will make him fall a distance off the block that he ran off.
I haven´t checked this, but I suspect that when running and then crouching, Mario will deccelerate at a slower pace than if the player just let the direction key go. This allows for a technique where you can run, crouch and slide under enemies or hazards, without affecting the normal movement.

Jump vertical anatomy

The jump in super Mario games is really something. It describes a nice arc, is responsive and fast and feels great. Instead of applying an initial vertical speed and letting gravity do the work of bringing Mario down, Nintendo used a different approach:
  1. Pressing the button gives the player an initial vertical speed (iniJumpSpeed) and starts 2 counters (we´ll can them cntA and cntB). As long as the button is pressed, this speed is mantained and cntA increases. cntB will increase regardless.
  2. Once cntA reaches a certain amount or if the player releases the jump button, the player will no longer have control of the jump´s height. cntA will stop counting, but cntB will continue. During this time, Mario will continue rising with the initial speed.
  3. One cntB reaches a set value, the second phase of the jump will start. Gravity will kick in, slowly making the speed turn around.
  4. Once the speed reaches -iniJumpSpeed, it will be capped at this value and Mario will continue falling until he reaches the ground.
Playing with the values of iniJumpSpeed, cntA, cntB and gravity will give out different types of jumps. For example, iniJumpSpeed depends on the horizontal speed before jumping, so it can be set to a higher value if Mario is runing instead of walking, allowing him to jump higher. If the target values of cntA and cntB are set to be equal, the second phase of the jump will start as soon as the player releases the jump button, giving a more angular jump (like in Super Meat Boy). This control is more responsive, but is more demanding of the player and makes it much harder to do things like jumping on top of small moving targets (like a Goomba). Setting cntB to a higher value than cntA will give a higher jump with a nicer arc. The value of gravity also affects the shape of the arc: a smaller value will make the jump floatier and the peak of the jump will be smoother, but if you set it too small the jump will become too floaty.

Horizontal movement in the air

When moving in the air two neat tricks are used, depending on whether you are pressing the same direction you´re facing or if you press the opposite:
  • Same direction: Mario will accelerate towards the maximum speed of his current speed range. That is, if he already started the jump with sp = spWalkMax he won´t accelerate at all. However, if he started the jump before reaching the maximum speed (spWalkMin < sp < spWalkMax) he will be able to accelerate to spWalkMax, but not beyond. Accelerating mid-air is not a realistic behaviour, but it makes the character more responsive to player input, is integral to platform games and is a way to keep the speeds in the designed limit values, providing a more cohesive movement.
  • Opposite direction: Mario will deccelerate with a higher than usual acceleration (this allows for nice air movement). Note that in this case the Skid Turn trick is not used, so we can have more control in the air to, for example, kill all horizontal speed and land at the center of a platform.

Safety jump extension

When Mario falls from a platform there are a small number of frames where a press of the Jump button will still trigger a jump. This way there will be no frustration over missing simple jumps. A special note is necessary here: to avoid pixel-perfect jumps in a level you should design the jump distance of any obstacle without having the Safety jump extension in mind.
This is a really intelligent trick Nintendo designed and is surely one of the things that made the original Super Mario Bros. thrive in arcades everywhere.

Sprinting

Sprinting in SMW works like a hidden P-Meter of SMB3: Mario must run for a fixed distance at max speed (spRun) to be able to enter the last and fastest speed range. Once he´s started running at spRun the P-Meter will start to fill and every frame that he´s not running it will quickly decrease (even in the air). This finally comes out as something like "Mario must run for at least 10 blocks to sprint". This way it´s really easy to take this into consideration when designing your levels, having direct control over when the player will be able to sprint or not.

Conclusion

All these tricks are really intelligent modifications that can be applied to any platformer game and that will only make it better, so there´s really no reason why you shouldn´t implement them in your game to achieve a great feeling.


Bonus 1: Automatic horizontal momentum cancellation

When moving horizontally and releasing the directional button, or pressing in the opposite direction, the player will progressively come to a halt. However this is hard to account for and can easily make the character feel uncontrollable, with the player constantly having to make small corrections to every movement.
We should check that the player isn´t going to run on an enemy or obstacle and if so, kill momentum immediately. Also, it may be a good idea to kill momentum if the player is about to fall through an edge in this same situation.

This should help a lot with precise movements, like when trying to climb a series f blocks stacked on top of each other.


Bonus 2: Double jump hold up

Sometimes when the player is falling down he may press the jump button just before touching the ground, which will trigger the double jump if available. The player may not have wanted this, so if he was counting on using the double jump after this one he´s screwed.

A nice way to solve this is by checking the distance the player has to the floor before triggering a double jump. If this distance is very small and the floor is safe (ie: no spikes or lava or whatever) we´ll hold the double jump until after we land (1-5 frames, needs testing). If the player was going to fall on an enemy, we can hold the jump until it touches the enemy and trigger a bounce as if the player was helding down the jump button to bounce high. If the floor is indeed hazardous, we´ll trigger the double jump immediately, as that must clearly be the player´s intention.

Macro/micro level design and pacing

I originally posted this on the Super Mario Maker subreddit: https://www.reddit.com/r/MarioMaker/comments/3rcme0/macromicro_design_and_pacing/

I´ve seen many guides on how to design a level following the basic Nintendo layout regarding challenges and mechanic development, but I´ve found nothing about the considerations you should make to create a full Nintendo-like level, how to fill the gaps between those challenges or how they relate to each other in terms of difficulty and complexity. So I´ll try to give some tips I think can help and would also like to get feedback from others, because this topic is being overlooked and I find a lot of levels are not considering it.
For clarity, I´ll divide this writeup into 3 sections: micro design, macro design and pacing.

Micro design

Micro design reffers to the details of every challenge you put into your level. As has been stated countless times, you should choose 1 or 2 main mechanics and 2 or 3 secondary mechanics and evolve those main mechanics through the level progressively. The first challenge should provide a safe environment where the main mechanic is presented in a clear way, while further challenges will manipulate it by modifying basic parameters (distance or height between platforms, platform width, number or placement of enemies, penalty for failing...). Also, if you use a secondary mechanic it is often a good idea to make a small challenge where it´s presented on it´s own before attaching it to the main mechanic. If you´re using 2 main mechanics, it may be advisable to make a simple challenge for mechanic #1, then another one for mechanic #2 and then a third one mixing both on what will be the standard mechanic of the level.
Try to develop your mechanics in interesting ways: instead of just adding new or more of a certain element, play with positioning, speed, trajectories and those kind of parameters that can make a challenge feel very different from the one before it, while maintaining a common core. If your only way of evolving a mechanic is adding one more Paratroopa in each iteration, the player will start loosing interest after the 2nd or 3rd repetition.

Macro design

Macro design reffers to the way the challenges are positioned in the level and how they join up to create the level layout. It makes no sense to put your hardest challenge at the start of the level and the simplest one, where the main mechanic is introduced, at the end for example. You should try to mimic physical progression on the level with mechanical progression, so as the player advances through the level he´s presented with more complex challenges as he gets closer to the goal. Note that a complex challenge is not the same as a difficult one, in fact they are independent characteristics of a challenge. A complex challenge will test the knowledge of the player on the mechanics it´s built upon and if the player has understood and learnt how to use them correctly he should have no problem beating it. A difficult challenge however, will relate to the set of skills of the player and can make it so that even if the player has mastered the knowledged of the mechanics, he will still fail the challenge if his skills aren´t up to the task. This is a very important distinction as is what ultimately defines a fair challenge. If the player understands what he has to do, but fails at doing so he will blame himself and his lack of skill and most likely will try again. But if he takes on a challenge where it´s not clear what´s he supposed to do and fails, he will blame the game. Even if he beats the challenge he won´t probably have fun as he doesn´t understand what happenned, there has been no true gain or sense of accomplishment from the experience.
For macro design, Nintendo itself uses a 4-step approach in both 2D and 3D recent Mario games:
  1. The main mechanic is first introduced
  2. Then it´s developed and the player´s knowledge of it is tested
  3. Then an unexpected twist is introduced
  4. Finally a challenge is used as a conclusion
Usually the most difficult challenges are at the end of steps 2 and 3, while the easiest are at steps 1 and 4. Steps 1 and 4 are comprised of a small number of challenges, usually just 1, while in 3 and 4 more than one challenge is used. There is an awesome video by Game maker´s Toolkit that explains how this is used in SM3DWorld, I encourage everyone to check it out:
!https://www.youtube.com/watch?v=dBmIkEvEBtA
Using this template to design your level is a very good idea!

Pacing

Pacing is a characteristic of a level that relates directly to both macro design (how the challenges are positioned in relation to each other) and micro design (what the challenges themselves are). If you follow the 4-step design you´ll end up with a nice level, but it´ll feel like it´s missing something and is too straightforward or simple, to the point that the whole experience might end up as bland. This is why pacing is important.
Pacing sets the rythm of the level and can alter the state of mind of the player greatly impacting his impression of the level, so it´s no small thing. Instead of just laying out challenge after challenge in a progressive way, add something in between to make the player focus in other things, like a minipuzzle in a secondary room if your level is too intense, or a frantic game of killing as many Dry Bones as possible if your level is slowly paced. Disrupt the flow of the level and create memorable situations for the player, or let him take a breath after a demanding challenge and just have fun picking up coins in a bonus room.
You should consider where to place your hardest challenges as this impacts pacing heavily: if the player fails, he will have to replay through your level (or part of it if you use checkpoints) to attempt it again. Sometimes it´s good to put the hardest challenge at the end, but other times it´s better to put an easier challenge after it, as this provides a good feeling of mastery and closure. Also, putting an easy challenge before a hard one has an effect on making the hard challenge look or feel even harder than it is and creates a nice spike in the level´s pace. The main point here is that you should avoid your pace being a flat line or a constant ramp, as the player will get accustomed to it or know what to expect: always try to surprise him to keep him interested. Use this with care, as too many ruptures in the pace will make your level feel directionless and chaotic, so it´s better to start with a flat/ramped paced level and then add disruptions in some points. The 4-step design provides a good layout for places where you can put these disrupting events: you can separate each step with a disrupting moment, but remember you aren´t limited only to that.
If your level features a final boss fight you can add a section afterwards where the player just has to walk while coins fall on him and nice SFX play. If your level is slow because you´ve had to carefully evade Twomps all the way, you can add a final rush with a star through a corridor killing lots of Thwomps until you reach the goal. Both of these situations provide a great feeling of closure and will help leaving a lasting impression on the player, even though they are totally opposite of each other. The key is what´s been building towards them, so before deciding on the last challenge of your level take a look at it as a whole and decide what better suits it.
Hope you find this useful and I´d love to hear any opinions on the matter!

Kishotenketsu: The Nintendo formula for level design

Kishotenketsu is a narrative structure used in Asian literature and prominent in four panel japanese comics. This structure is defined as follows (src: Wikipedia):
  • Introduction (ki): Topic toss or introduction, what characters appear, era, and other important information for understanding the setting of the story.
  • Development (shō): Receives or follows on from the introduction and leads to the twist in the story. Major changes do not occur.
  • Twist (ten): Turn or twist to another, new or unknown topic. This is the crux of the story, which is also referred to as the yama (ヤマ?) or climax. It has the biggest twist in the story.
  • Conclusion (ketsu): Resultant, also referred to as the ochi (落ち?) or ending, it wraps up the story by bringing it to its conclusion.
Nintendo has been using this structure to design the levels of some of their best games by decades now. It seems this concept was introduced in the company by almighty videogame god Shigeru Myamoto and has been polished through the years.
The levels in Mario games usually focus on a main mechanic and develop it through the level, making the player understand it and gain knowledge about it until they usually master it by the end of the level. This mechanic can be an ability of the player like the spin jump in SMW, a powerUp like the feather, an obstacle, or even combinations of simple elements. It is also important to note that usually there is a mechanical progression in Mario games as well: the player may be introduced to some simple mechanics in World 1 and later those mechanics can return in a later part of the world to serve as the foundation or part of a new main mechanic. This is one of the reasons why Mario games flow so well, because all the necessary concepts are gradually introduced and have their time to shine before more tricky concepts appear.
Applied to level design, Kishotenketsu results in something like this:
  • Introduction (ki): Presentation of the level´s main mechanic. The player is provided a safe place to use it and understand it with no risk of suffering any penalty.
  • Development (shō): The main mechanic is developed and presented in different ways, making the player learn and understand different concepts around it and develop the skills relared to this mechanic.
  • Twist (ten): The mechanic is used in an unexpected way, thanks to the addition of other elements or by any modifications that turn it upside out. The player must use his knowledge of the mechanic to find a new solution to the proposed challenge.
  • Conclusion (ketsu): The conclusion of the level will usually present a hard-ish challenge requiring mastery of the main mechanic to beat it. In later Mario games like 3D Land and 3D World these challenges are usually optional, have no penalty and are placed right before the goal. They are used to reach the top of the goal, but if you fail/skip them you can still beat the level and receive no penalty like harm or death. Another way to look at it is as subversion: the player may need to look at the mechanic in a totally different way, maybe trying not to use it to get through that last challenge, thus showing he´s totally understood how the mechanic works.
This is a nice formula to set the main structure of a level before designing the detailed parts and will be used in Kitsune extensively.

Sprite design

Concept sprite



Color test



Final 32x64 Idle sprite (small ears, no animation):


Collision mask adjustment

One necessary thing to do is to better adjust the sprite size. As it is now the sprite´s too big and even though the mask is independent and causes no problems in-game, the visuals are a bit off. the player can walk too much into walls, the point for walking off cliffs is not clear...This problem doesn´t happen in any Mario game, so let´s see how they do it.

Mario´s personal space

In SMW, Mario´s sprite is 16x32 px can push 2 or 3 pixels into a wall. This amounts to a bit of his moustache and the hand behind him. However, his belly and feet are perfectly aligned with the wall. This makes sense visually and functionally. When walking over a cliff, Mario will start falling when still 3px of the sprite are overlapping the last block he was standing on. Both distances match, which indicates that the mask is centered.
When standing on the ground, Mario is perfectly aligned with the floor. However when jumping upwards and hitting a block, his head can go some distance into the block. We need to measure this distance, for now we´ll call it Y.
So in conclusion, Mario´s sprite is 16x32 px, while his mask is something like 10xY px.

Kitsune´s personal space

Kitsune´s sprite needs to be even bigger than Mario´s, exactly double: 32x64 px. We can use´s Mario´s relation between sprite and mask size to estimate Kitsune´s: 

MarioKitsune
Sprite width1632
Mask width10X = 20
Sprite height3264
Mask heightY (probably around 28~30)2*Y

It becomes evident that Kitsune´s mask will also be double than Mario´s.
In conclusion: * We must make Kitsune´s sprite 32x64. * We must make Kitsune´s mask 20x2Y. * The mask will be centered on X, and bottom aligned. * Kitsune´s belly and front hand must match the mask width to provide nice feedback when walking against walls. * Kitsune´s feet must match the mask width. * Only the tail and ears, as they provide no positional information, can be outside the sprite limits.