Assignment 3C - Documentation + User Guide


1.0 Final Devlog - Documentation

This will be the final devlog for this game project and the final implementation uploaded. It has been quite an experience in developing, discovering, and learning all the concepts and techniques required to make a game, and I truly have come out of this assignment with a new found admiration to the creation of games, and gained a new viewpoint on how games are made, as well as the colossal effort it requires to make one. 

This devlog will be dedicated to the documentation of my final game project, and a user guide for the game itself as well. 

2.0 Concept to Reality - Differences

There were various different outcomes reached in the goal of making this game, from the first concept to the eventual end of this journey. For the final game, there are some notable differences from the original vision that are due to be noted, these include:

  • Swinging mechanic. This was a feature that took several attempts as mentioned in the first two devlogs that I, in the end for the sake of movement flow, had to drop. I was wanting it to work similar to the "feel" of the spider man swing in the Spider man PS4 game. However, this would cause constant issues, with regards to the feel and practical use of it as a movement tool. I decided to drop it for the sake of improving and influencing the rest of the movement. So, while at first I was focused on tools rather than the player moving themselves, this caused a big shift from tool management, to the player's ways of interacting with the level design. 
  • Level Design. This was another aspect that took form in many different ways throughout the process of development. Firstly, it was intended to be purely in the skies jumping between islands with a consistent tile pixel vibe that would be consistent. But as the development of levels developed, I made all of the objects that were accessible to the player to be simple colored blocks, allowing freedom of level design, to a point where in the end, I was able to create 7 different unique levels. There was quite a passion in making these, as well as frustrations, as level design philosophy changed, and feedback given influenced what went where, in regards to difficulty or in ways to make it more evident what blocks allowed the player to move in what way. Even the art design went from islands, to obtuse obstacles. 
  • The Audience. The original aim was to have an audience for a causal player, but allow the opportunity for time trials and speed runners to take the game to its limits. As time progressed however, and the more feedback I received not only in the testing stage but previous devlogs, there was clearly a more hardcore aspect to the gameplay. While I was still wanting to achieve an equilibrium, I found myself more edging towards the hardcore audience, and after the testing session, decided that while minor tweaks were needed to make the game more fair, I leaned more into the hardcore aspect. This was influenced by testers saying the movement was enjoyable, and can definitely see more hardcore players becoming accustomed to it, and that because of my level designs constantly edging towards the hardcore aspects, i leaned into it and created what I felt was suitable for the movement and designs I created. 
  • The Story. I would still love to do a story for this game. Not only mentioning the development of characters but the true plot driven goal that only snippets can be seen in the game. The original goal was to have a love story, with intentions to have slight Voice Over for the little green slime on the head, as well as gripping story-telling. Alas, it could not be, as many other development problems needed to be solved for the gameplay sake, and if possible, I might add later when there is more time to craft such a story. This one was a bit of a personal disappointment for me that i did not complete, but I know that it can always be updated in the future if i so wish.
  • The Second Genre, Platformer. The platforming of the section was achieved 100%. The puzzler not so much. A bigger focus was given to platform early on and stuck its course for the remainder. 
  • Lastly, environmental factors. The last thing I intended to add was weather conditions. In one feedback session I added wind and gust effects, and to Ian's experience that I watched, it looked awkward and not fun for the player, even being compared to the difficult sections in Celeste. After this session, i decided to remove environments for now, and focused on much simpler but still fun level designs. 

3.0 Testing Feedback Summary

In my Testing Form, I specifically wanted to ask and address issues that I thought I could improve or wanted to determine how the average player found the game, and whether it was fun or not. In total there are 8 broad questions that I wanted to address, these include:

  1. How fun did you find the game?

Out of all the testers, there were only answers above 8, and even one at 10. Clearly, and hopefully, this points the picture that the gameplay and fun-factor to be a resounding success, but there is still more feedback that was given that paints an interesting picture, about the difficultly of the game, and the possible merits to it: 

2. How Difficult did you find the game



This question received an astounding high results, signifying that the testers were people who enjoyed a challenge, and that just because I was leaning towards the levels being a bit harder than i would've started off with, it was producing results for people that enjoyed these challenges. Although there was still room to make improvement on box colliers for death zones, as some testers ran into death zones that should be no means should have killed them. I took note of this to make the game more fair and enjoyable. With this feedback i decided to lean into the hardcore player base, as clearly, they were enjoying the challenge. 

3. How did you find the level design? 


The results show that a lot of testers found the level design to be quite enjoyable, with over 80 % Giving it a 4 while 1 even gave it a perfect 5. Minor feedback given during the live testing was of course the iffy box colliders on some death zones, which were adjusted right after. 

4. Was there any spots for extra or less checkpoints you thought of?


This was a minor question that I wanted an answer too, as I was unsure as to the location of the checkpoints. In regards to the reset button as given in the feedback I was thinking it over quite a bit, but decided to implement the idea of accidentally hitting a previous checkpoint as another point of tension in some levels, so therefore i decided against it, but a great idea none the less. 

5. How did you find the movement? 


The movement was praised a bit, which is relieving to see for sure. However issues that have been present in previous devlogs, like wall jump delay jumping back, were brought up again, which is understandable, therefore I tinkered a bit further with the delay until a nice middle ground was achieved. The added challenge of the controls being mentioned again as well made me reinforce the idea of this being a game geared towards hardcore players. 

6. Which elements did you wish were improved?


The change of the W and Space was considered, but after testing the code, for some reason the change greatly affected the code by the swap, So therefore I decided to keep W as dash and space as jump as I had many other matters to attend with the project. Level difficulty was brought up again as well, and I did snip some more "accurate" sections in the levels that involved small death zone caps. 

7. Casual, Hardcore, or in-between players?


As expected from previous sections, the audience was skewed mostly towards hardcore players, and therefore the aim of the rest of the game from this information was to make the game fairer mentioned by players during the live testing and to build around speed with a timer as well as making the levels a bit more fleshed out for the use of multiple paths. 

8. Was there any other feedback that you had? 


The checkpoints idea was considered, but decided for other issues to be resolved first, and therefore ran out of time for this idea. Still quite a good idea though. Also really liked of course the positive feedback by testers. 

Speaking of which, I would like to thank all testers who played my game, your feedback was invaluable to the creation of this game and helped me create the best product possible, so thank you. 

4.0 Asset List

The Following are all assets involved with making the game project, some created for sellers on the unity asset store, some assets created by me as well as some scripts that required some help from ChatGPT to sort out the kinks, make up the full list of assets of Moon Summit. 

4.1 Unity Store Assets

Firstly, I want to acknowledge that I used art and music assets from the Unity Store Assets, as I am not the greatest artist and cannot make music at all, let alone read a music sheet. The following are all assets that I download from the store: 

  • Dead Revolver - Pixel Prototype Player Sprites. This pack held all of the player sprites and movement animations, which greatly served the purpose of creating a sense of flow for the game and allowed me a great deal of flexibility to map out the movement how I wanted too. This came out really well in the final version I believe. 

Dead Revolver, (2024, Nov 20th) Pixel Prototype Player Sprites. https://assetstore.unity.com/packages/2d/characters/pixel-prototype-player-sprit...

  • FeonY - Background Images - I used quite a few of the backgrounds at the beginning of the games development cycle, but opted for more pixel backgrounds later on, I did keep the space one for the title screen however. 

FeonY, (2023, Nov 27th) Animated Pixel - Art Backgrounds | Free https://assetstore.unity.com/packages/2d/environments/animated-pixel-art-backgro...

  • War - Slime Enemy. I had decided to have cute little slime meant to represent a character, a checkpoint and the end goal, found them to be quite cute and fit the pixel theme well.

War (2022, Oct 7th) Slime Enemy - Pixel Art https://assetstore.unity.com/packages/2d/characters/slime-enemy-pixel-art-228568 

  • GWriterStudio (Jul 12 2022) 8 Bit Music - This is where i got all the tracks needed for the background music

GWriterStudio (Jul 12 2022) 8 Bit Music - https://assetstore.unity.com/packages/audio/music/8bit-music-062022-225623

  • Pixel Skies Demo - Backgrounds. These assets served as the main pixel backgrounds used in the project, and can be seen in almost every level.

Pixel Skies Demo background Pack (Aug 18 2022) - Digital Moons https://assetstore.unity.com/packages/2d/environments/pixel-skies-demo-backgroun...

  • Thaleah Pixel Font. This pixel font served as the title screen, timers, ending screen text and the movement text, to help stylize the game with the pixel theme. 

Thaleah Pixel Font. (April 5th 2019) Tiny Worlds - https://assetstore.unity.com/packages/2d/fonts/free-pixel-font-thaleah-140059

All of these should be the assets that I used from the store and has been loaded into the game project, all of these were amazing to use and enjoyed each creation from every creator. 

4.2 Prefabs

Next are all the prefabs that I created and needed consistently throughout the project in multiple levels. Here is the full list with each explanation: 

  1. Buddy Respawn:  A cute little blue slime fella from the War slime enemy pack, that serves as a checkpoint in every level, when the player walks past them they have set their respawn point to them. 
  2. DeathZone: Deathzones are red rectangle objects that "Kill" the player, and send them back to the players respawn point. Some move, some stay still, and some set the limits of the level. 
  3. Ground: One of the more important prefabs, Ground allows the player to jump off this platform into the air, used frequently for level building
  4. Moveable: An object that was experimental in that it could be flung into the air, had some testing where the Moveable platforms would fling it into the air and allow the player to land and jump off the moveable prefab, was not used in the final version however. 
  5. MovingPlatX: This platform is controlled by the player and can be moved on the x axis with a certain set range
  6. MovingPlatY: This platform is controlled by the player and can be moved on the y axis with a certain set range.
  7. Music: A simple empty gameobject that would allow music to be played on loop, used for background tracks. 
  8. Player Himsbee: The playable character that could jump, dash, wall jump and slide and was able to move particular platforms. They also have four children objects, being ground check, wall check, the trail and also Icarus, the little green slime above their head. 
  9. Portal: The object that would allow the Player Himsbee to move between scenes. 
  10. SelfMovingX: A platform that would move on its own between two points on an X axis
  11. SelfMovingY: A platform that would move on its own between two points on an Y axis
  12. ShowTime: An object that would allow the scene to show through a text object what the players recorded time is for a particular scene
  13. Timer: The timer that would start when the player entered a level, and the would stop when they left the level
  14. Wall: One of the more important prefabs, Wall allows the player to jump off the side of this platform into the air, as well as sliding down or up, used frequently for level building

That is all the objects that were made into prefabs and used consistently throughout the project. 

4.3 Other GameObjects

There are a few other objects that were used for scenes at points, mostly grouped together or specific for the scene. They are as follows: 

  1. Environment: This would contain all level building objects, to ensure that there was a clean and easy to navigate Hierarchy. 
  2. Points 1/Point A...: These would be empty GameObjects that would serve as start and end goals for moving platforms or deathzones.
  3. Cameras: There was 3 important camera objects, these include Main Camera, Follow Player Cinemachine Character and camera bounds. Main camera is of course the main, follow will follow the player's movements within the box collider camera bounds. 
  4. StartingPoint: An empty game object that was also a spawn point for entry for the player. 
  5. Image Backgrounds: There are also a few background gameobjects that were from the Pixel Skies Demo pack littered around in each scene. 
  6. Random Folder: This contains some images, animations and some animators for the slimes and other bits and pieces. 

These are the other game objects and should account for each object. 

4.4 Inspirations & Scripts

There are a few scripts included to make this game operate and work throughout. I will acknowledge that ChatGPT was used to work out some kinks with code and to comment as well. Some of these issues with the scripts helped by AI was issues with the moving platforms, issues with wall jumping, issues with the timer and a few minor issues here or there. 

I would also like to acknowledge that the Youtubers: Bendux and Dawnosaur were really helpful in teaching 2D movement concepts and a lot of the philosophy and coding of the movement was helped significantly by their videos, so I wished to reference them here as well: 

Another person that influenced the use of movement and was a great base game to be inspired by, suggested by Ian, was the Itch.io game project OVERDRIVE V1.0 by Flynn Delta. This game greatly influenced how I designed levels, how the movement worked, as well as the choice to not include the swinging feature for the sake of flow. This game does include a swing, but arguably can halt momentum at some points. I was never able to achieve a swing close to theirs however, so still very impressive. I highly recommend anyone that would like to play something similar to my game to play theirs as well: Flynn Deltas: OVERDRIVE V1.0 https://flynn-delta.itch.io/overdrive

Now that all references have been mentioned, here are all scripts used: 

  1. Checkpoint: Used with buddy respawn to set the players spawn point if they die.
  2. Moving Platform: used to both have self moving platforms as well as player controlled platforms. 
  3. PlayerMovement: includes all player movement, including running, jumping, Dashing, wall jump, wall slide, coyote time, double jump, limit to falling speed, and other minor movement improvements. 
  4. PlayerPlatformStick: This was placed on the player to ensure that stayed on any platform that moves, used in conjunction with a few others. 
  5. PlayerRespawn: This would be placed on the player to ensure they are set to the checkpoints
  6. PlayerSpawn: This would be used to ensure that if no checkpoint had been reached that they would spawn back at the start of the level.
  7. Portal: This would allow the player to go between levels, as well as start and stop the timers for playable levels. 
  8. ShowTime: This would allow a text box to display the achieved time in a certain level. 
  9. TimeManger: This would start at the title screen and record all times achieved. The game must be started at the title screen so this loads and remains for the rest of the game. 
  10. Timer: This would start when the player entered the level and stops when they exit from the portal. The time will be then sent to the TimeManager Script. 
  11. VelocityPlayerPlatform: This was another script that would ensure the player follows along the moving platforms and ensure a smooth transition on and off the platforms. 

Those are all scripts used for this gameproject. 

4.5 Scenes

All scenes/levels are listed as the following with a screenshot each and a little look behind the camera:

Title Screen:

Portal 


3. 

Tutorial


Level 1

Level 2 

Level 3

Final Level

Ending


User Guide


5.0 Final Name

Moon Summit is the final name of the game project, as was decided since the start. It simply represents the goal of reaching toward the moon to reunite two lovers, reaching the summit that is the distance between them. 

6.0 Basic Description of Game/Movement

Two lovers, separated by the distance between the moon and lands, raise the very earth so that the player can go skywards. Traversing between 2D rising islands as well as controlling certain platforms to make way for their journey to the Moon! No matter how many times the player falls, gets pushed, or are zapped, they will continue ever forwards, to reunite the passionate love of these two separated soul slime mates!

7.0 Controls

8.0 List of Sources

Dead Revolver, (2024, Nov 20th) Pixel Prototype Player Sprites. https://assetstore.unity.com/packages/2d/characters/pixel-prototype-player-sprit...

FeonY, (2023, Nov 27th) Animated Pixel - Art Backgrounds | Free https://assetstore.unity.com/packages/2d/environments/animated-pixel-art-backgro...

War (2022, Oct 7th) Slime Enemy - Pixel Art https://assetstore.unity.com/packages/2d/characters/slime-enemy-pixel-art-228568 

GWriterStudio (Jul 12 2022) 8 Bit Music - https://assetstore.unity.com/packages/audio/music/8bit-music-062022-225623

Pixel Skies Demo background Pack (Aug 18 2022) - Digital Moons https://assetstore.unity.com/packages/2d/environments/pixel-skies-demo-backgroun...

Thaleah Pixel Font. (April 5th 2019) Tiny Worlds - https://assetstore.unity.com/packages/2d/fonts/free-pixel-font-thaleah-140059


9.0 Features

Player Movement is something that has been exetnively explored before, but also mentioned is the player controlled platforms. This feature allows the player to control certain platforms in set range of motion. This allows neat gameplay, and can be shown in the gif below



9.0 Thank you for Playing
 

Thank you to everyone who tested, gave feedback and played my game. It was truly fun to make and in the future I might try to make even more levels with the tools I have crafted here. Thank you!

Leave a comment

Log in with itch.io to leave a comment.