Documentation + User Guide


Differences from concept:

There are many similarities to what the concept contained compared to what has now been implemented with the area with the least alignment being the AI which was stated to be more complex to make it easier for the player.  I did not get to do many of the extra things I would have liked to do with the game but I managed to remove most bugs to get a solid working game instead.

  • “Custom Art and Design”
    • Much work went into creating art for the characters and the background.  The only graphics that were not designed by me were the text.  I did not create more than one character like how I had in the concept art because I was running out of time and it just wasn't necessary enough.
  • “Animations”
    • The animations did not take as long as expected probably due to my experience doing an animation project in college.  There are a couple animations that could have been added to the game that were a death animation for the kaiju and idle animations for all the characters.
  • “AI”
    • The AI is not as complex as it is described in the concept.  The enemies will attempt to approach the player and punch from the right or left side once in range.  Characters will not have variations in their attacks or avoid attacking the player all at once.  However, I believe there is still some difficulty achieved because the player must manage the amount of enemies on the screen and if they run away they can get overwhelmed at be at the risk of damage.
  • “Hitboxes”
    • Hit boxes work exactly the way they are to be expected.  The hurt and hit boxes do not collide with each other and make sense in there positioning.
  • “Camera Effects”
    • What I thought would be a difficult feature to add turned out to be rather simple and got added early in development.  The screen shake was added using a 6D noise cinemachine camera that would be turned on and off when the kaiju would be in the cooldown animation for the stomp.
  • "UI"
    • The final game did not include the high scoreboard simply because I was not ready to get access to remote storage but it had a start menu and a game over screen.

Feedback:  

Feedback was received at a point where the game was not fully implemented yet.  The player initially had no real goal or score to achieve and no game over state.  Instead the testing focused on the quality of the animations and how the players would consider the potential difficulty without those things.  Later worded questions for feedback would ask the tester what new features they would like to see in the game so I could get an idea on what to work on apart from the obvious things.

Form questions referenced can be found here: https://drfuff.itch.io/super-stompy-kaiju-revenge/devlog/254781/testing-form

Q1 - “do you play many beat’em’up arcade games” turned out to hold no weight in the feedback considering that there was no way to link the answers with the rest of the feedback.  Otherwise, the majority had played a beat’em’up game before with only a fourth reporting they had not.

Q2 - this information was very easy to interpret with 66% saying the walking speeds were fine and the other 33% being evenly split between the characters being too fast or too slow.  No changes needed to be made here.

Q3 - Over half of the testers said that there should have been more variation in the attacks to make them harder.  There was a sort of some difficulty but I could understand that the game may have been more fun with other enemies types.  I could easily change the colour of one and give it a faster speed at least.

Q4 – Over 90% of the testers agreed that there was enough detail in the characters to understand what they were doing.  I was a bit worried about this and raised the dimensions of the kaiju because of it so I wanted to make sure it was right.  Turned out I didn't need to worry about it now.

Q5 – 75% strongly agreed that stomping enemies was satisfying.  Being the main purpose of the player in the game, this was a requirement for a successful product.  Adding the screen shake animation was part of this.

Q6 – 50% of the testers strongly agreed that "the attacks were at the speeds that they should be" with another 33% reporting that they agreed.  No changes were made to the animations but they could have been changed if the players believed the length of the attacks were too long or if the kaiju's walking animations were too different for the speed it was going.

Q7 – Question 7 was harder to interpret with most testers reporting that they had trouble avoiding the attacks of the enemies.  I wanted to make it difficult but being an experienced player of 2D beat’em’ups, I was unsure if the speeds of the attacks would be too fast.  After a while I decided, considering that the weighting was more on 2 and 3 with 1 being undoable and 5 being extremely easy, that this was ok to leave as it was.

Q8 – 50% of testers agreed that the animation of the kaiju getting hit was enough to tell that they had been hit with an attack with another 25% in the middle.  However, none and put down that as a “strongly agree” and I felt it was important that the indication was obvious, so I added a new effect to when the Kaiju got hit.  Now the kaiju will flash to show that he is temporally invulnerable after taking a hit and his hit animation is slowed down.

Q9 – 9 out of 12 gave a response to this question.  In summary, testers wanted to have more enemy variants and attack types or sounds.  I didn't add sounds because that seemed like too much to add at that point and I didn't have much of an idea on how to make sounds or include sounds in Unity.  As for the enemy Variations I considered making a yellow tinted enemy that would move slightly faster than the other characters so that the player would have to deal with it immediately.  I also planned a third blue enemy that would attack from a distance with a longer start up then throw a punch that brought him part way across the screen but getting this right was difficult as that one could catch the player off guard and attack if his startup was done from outside the screen boarders.

Q10 – 8 out of 12 responded.  This was more of a bug report to inspect if anyone else found bugs.  There was 2 found; when the kaiju was not moving the enemies could not attack (which was fixed), and the screen shake.  I had attempted to find a simple solution for the screen shake but I ended up not finding anything.

Q11 – In this worded question I asked if there was anything that I could add to the animations.  This wasn’t a very well thought out question to be honest but the feedback that it got was nice.  One person had an idea for throw animations but in my own opinion that seemed out of place for a game like this.

Assets:

Graphics:

Sprites and animations:

  • Health bar (used in UI)
    • Contains boarder, backplate and fill.  Used to show the health of the kaiju on the UI
  • Kaiju (Player Character)
    • Includes walking animation, Stomp animation, hurt animation and a standing sprite, all with a flipped duplicate.
  • Enemy
    • Includes walking animation, attack animation and a standing sprite all flipped and a non-flipped death sprite.
  • Background (used in Game Scene and Start Menu)
    • Includes a repeatable image of both a street and a basic city backdrop.
  • Little Kaiju
    • Made a idle animation but current just used as a icon in the game scene UI next to the health bar.

Font (external resource):

Manteka by Edu Araya

Edu Araya. 2012. Manteka.[Font] available at: https://www.behance.net/gallery/2846011/Manteka. [Accessed 30 May 2021].

Code:

Many scripts are originally based off ones found in tutorial work.  Modified ones include:

  • Spawner from practical 10
    • The spawner was used to spawn the enemies that arrive from both sides of the road.  It was altered so that it would not spawn any more enemies if there was already a certain amount of enemies existing in the game already.  "Squished" enemies wouldn't count.
  • PlayerMovement from practical 6
    • This script was used to handle all the movement and animations that involved the character.  This was altered alot with the 8 directional movement changed to 2 directional, animatorStateInfo calls to tell which state of animation the kaiju was in and damage detection.  The hurt detection was going to be called outside of this script but to keep the kaiju still when it was taking damage it was easier to include it in this script because it could prevent the character from moving too.
  • Pursuit from practical 9
    • This script was used similar to the way the PlayerMovement Script was used instead it used the enemies.  It was used with Mover to detect where the kaiju was in the world and to bring the enemies towards it.  It was changed to include two spots where it would target and those targets would be either side of the kaiju.  When the enemies reached that target they would attack in the direction of the kaiju to deal damage.  Again, it also included the damage handlers to recoginse if it was dead or not.
  • EightWayAnimation from practical 6 (used by enemies.  Altered to work for left and right directional sprites only)
    • This script was used to handle the animation of the enemies, not the kaiju.  The only changes were that it was changed to only work with left and right directional movemtents.

Unchanged practical scripts are

  • Mover from practical 9 (for use with Pursuit)
  • Scene Switcher from practical 4 (for screen transitions)

My Assets:

  • Bop Left/Right (for enemies)
    • Used to check for hit collisions on the kaiju from enemy attacks.
  • Stomp Left/Right (for kaiju)
    • Used to check for hit collisions on enemies from attacks.
  • Auto_order
    • Used to place characters on a sorting layer based on the Y position of their feet.
  • GameOver
    • Used to check when the players health is 0 and transition to game over screen.
  • PlayerScore
    • Script used to set the score during the game. Also contains a global variable that is used by Pursuit to add to the score after an enemy has died.
  • Stomp
    • Used to shake the screen whenever the kaiju stomped and set the stomp bool In the animator to true to initiate an attack.

Prefabs:

Bad

    • Used to shake the screen whenever the kaiju stomped and set the stomp bool In the animator to true to initiate an attack.

User Guide:

Super Stompy Kaiju Revenge


Control the kaiju by walking with the WASD keys and stomp using the Spacebar.

When the game begins, enemies will start to enter from either side of the street, coming towards you.

Each enemy can be killed in a single stomp, but the kaiju has 10 hit points which can be seen at the top of the screen.

When the kaiju gets hit, it will remain invulnerable for a short amount of time.  Use this to get out of sticky situations. 

Avoid getting overwhelmed with enemies.  Being outnumbered puts you at a disadvantage and makes it harder to escape attacks.

Stomping an enemy is 10 points and you can even stomp multiple enemies at once.

Stomp as many enemies as you can before they can lower your health to 0 to get the highest score you can!

Files

Super Stompy Build 5.2.zip Play in browser
May 30, 2021

Get Super Stompy Kaiju Revenge

Leave a comment

Log in with itch.io to leave a comment.