PROJECT PURPOSE AND DESIGN GOALS
-
The aim of this project was to improve my polishing skills through research and by producing a prototype that has a variety of polishing features
-
This project is meant to showcase how important game feel is and how it can completely change the way the game experienced by focusing on player experience
-
I hoped to addresses my inability to make games fun and marketable. By focusing on game feel and player experience, I am able to concentrate on the fun factory and develop a workflow when creating game juice.
I started my research by looking into what game feel is and the theory behind it.
Game feel was defined as a very instinctual experience that players would feel when interacting with a video game. If the game’s plot, level design, music and graphics are stripped away and the game is still enjoyable to play, then the game has good game feel.
What defines good game feel is when the player is able to immerse themselves in a game in an engaging way.
I did further research by viewing GDC talks on game feel.
Many of the talks emphasize that game feel is the second to second gameplay. Input, responsiveness and feedback are extremely important when creating good game feel. The talks also emphasized that it was important for game feel to be the fore front of your game if you want to sell it.
Game feel is primarily about giving feedback to the player and giving weight to their actions. Therefore, by giving feedback or some form of polish to the interactions and mechanics of the game, I can create a chart for what needs polish in my game.
Additionally, I studied video games and how they were polished. I wanted to see how these games and identify techniques or methods that are used to make them feel polished. Some games that I looked at were: Binding of Issac, Hotline Miami and Thomas was alone.
RESEARCH
PLANNING & DESIGN
MECHANICS AND GAMEPLAY
After finishing my research and deciding on a game, I wanted to make an extremely basic prototype that covered the core mechanics of a top down shooter. Top down shooters had responsive movement and really simple shooting as the core of their gameplay.
I started by making a basic prototype with simple movement and shooting first to have a benchmark of what to make.
USER INTERFACE
I didn’t want to add too many UI elements as that would require more art and polish to make the game look nice.
Originally, I had it set up as a health counter for the player on the top left of the screen similar to a HUD.
Over time however, it became hard for players to see how long it would take to kill someone and health bars were one of the feedback points.
LEVEL DESIGN
Originally, when I was planning the game, I focused on a dungeon room style level.
The rooms would be boxes that would connect to one another and I would fill the rooms with content.
But later down the line that became more problematic as I expanded on the camera and how the player explores.
Originally, I had a room based level with set enemies, each room was more or less the same size and the camera would be fixed on each room.
However after prototyping I changed it up so that way the rooms would be of different sizes with varying enemies. The camera would also spread out towards multiple rooms and give the player more visibility.
NARRATIVE PLANNING
When I first started researching, I didn’t have a narrative in mind and as I was focusing on polish I felt it wasn’t really necessary.
But as I was studying and learning more about research, I realised it was important to at least have a setting and some clear direction as to where the level is set and some information about the characters.
It helped give the game more context and made the actions more meaningful. It kept the experience consistent for the player.
I decided on a simple narrative after acquiring the art assets:
You play as a Hitman who is tasked of assassinating a scientist. However, before you set out, you die and are resurrected as a zombie.
You must fight through enemies, absorb their life power and complete your contract.
By keeping the narrative, I have an explanation and reason for the polish pickups and gives reasoning to the player’s actions.
POLISH PLANNING
After all my research and setting up the game, I made a list of the different types of polish I could implement into my game and categorized them.
They were:
-
Animation
-
Audio
-
Particle Effects
-
Screen Shake
-
Game Speed
-
Lighting
-
Permanence
After gathering all the data for what I wanted to implement as polish, I placed all of the information inside an excel sheet table.
From my research, polish and game feel is all about heightening the core of the game. With that in mind, I drew a conclusion that making the game feel more responsive and interactive was the most important factor.
I added an interactions section, which was every possible interaction that could happen in the game, from player interactions, enemies, UI, pickups. Anything that the player could interact with or the game did was going to be listed in this excel sheet.
Then, I would go through each individual polish and see if it were possible to add polish to heighten the action and why.
This way, I can keep a record and track what polish I’m applying and the reasoning behind it.
IMPLEMENTATION
CORE MECHANICS
The core mechanics of my game includes the player movement, the shooting and the player dying.
All my game components were made to heighten and to make the core mechanic feel heavy and fun to play with.
CAMERA MOVEMENT
The core mechanics of my game includes the player movement, the shooting and the player dying.
All my game components were made to heighten and to make the core mechanic feel heavy and fun to play with
ENEMY AI
Enemy AI was important as shooting enemies was core to the game. I wanted to have some variety to the enemies so the game would be more fun to play and engage with.
For enemy AI, there were three different types of enemies:
-
Shooting
-
Follow
-
Charging
USER INTERFACE
For the UI, the game features health bars that appear over the player’s and enemies head, to show the player how much health each game object has.
Every time a character takes damage, a number will show representing the damage they took from the hit.
I built a health bar script that would handle all the logic for individual health bars and just called those functions depending on the character’s corresponding health.
TILEMAPING & LEVELS
LEVEL DESIGN
Level design for Joy Ride was done through tile mapping.
Any interactable such as the doors, pickups or enemies are gameplay objects that are manually placed in the level.
ROOM FADES & DOORS
Any time the player enters a new room, the room will fade in and reveal any enemies and objects within the room.
This was done to make the game feel more realistic. You don’t know what’s behind the doors, but once you open them and explore you see and react to the situation at hand.
I set up with Unity’s animator, since I couldn’t get the tile maps to fade through code. Every time the player steps inside a room’s collider the fade animation will play.
For the swinging doors, I simply used a 2D hinge joint. If the player or any enemies walked through the door it would easily swing open.
I also placed trigger boxes in front of the doors to allow the room fades to work.
DEVELOPING POLISH
POLISH CATEGORIES
Before I started developing the levels, I wanted to focus on polishing my game and making the core experience as satisfying as possible.
I worked side by side with my excel worksheet when developing polish.
After making my gameplay elements, I filled out all the possible interactions that could happen in the game in my table.
I then added in what I could add polish wise to make the interactions more juicy.
Animations:
Animations for 2D games would include anything that changes frame by frame or some form of motion to the sprite itself.
I’ve added really simple animations in the form of sprite changes and color fades to give feedback to the players about what is happening in the world.
Particle Effects:
I’ve made particles using Unity’s built in system. Any action that felt explosive or needed some flair was given particle effects. Generally any element that had a change.
Bullets colliding with walls, enemies dying and pickups were all given particle effects.
Screen Shake:
Screen shake was much easier to implement as there was a built in function with Cinemachine. I built a camera manager and I just had to call this function whenever I wanted the camera to shake.
Game Speed:
Game speed was a little finicky to implement, since unity’s way of handling game speed is similar to pausing it. It required a bit of manipulating and spaghetti code, but after tying it to a manager, I could call the code at anytime.
Permanence:
Permanence was the hardest to implement in the game. There were so many ways to implement it, but I finally decided on permanence blood and bullet shells after testing other ways of permanence like heads rolling or permanent bodies.
Audio:
Audio was easy to implement. I made a simple Audio Manager that would hold all of the sounds and with a single line of code, I could call the sound whenever I wanted.
Lighting:
Lighting was implemented using the Unity pipeline. Placing lights was all about dragging and dropping and testing which lights worked and which didn’t.
A lot of lighting was trial and error and deciding what were the most important elements and needed lighting.
PICKUPS
Out of all the polish I implemented, I made three of them activate when you acquire their respective pickups.
They are:
-
Audio
-
Screen Shake
-
Lighting
POST MORTEM
WHAT WENT RIGHT?
-
The project was solid in terms of a development aspect. I was able to create almost all of the polish features I wanted and was able to create a fully playable demo that showcases the polish as gameplay elements.
-
Having knowledge of Unity beforehand definitely helped in speeding up the development process and producing ideas quickly
-
From a planning and research aspect, I was able to focus on what I wanted to complete and was able to make a clear and focuses polish worksheet that I can use in the future.
WHAT WENT WRONG?
-
The project was slightly over scoped. I wanted to end the game on a boss fight. I had built the functionality of the boss, but I didn't have enough time to tie the boss with the level, polish the boss and end the game on a satisfying scene. Therefore, the boss had to be cut to polish the rest of the game.
-
The narrative was insensitive and the art and store for it needed to be adjusted.
-
The process of filling out polish for actions in the planning stage didn't work out well. Often the game's core design will change if an idea doesn't work out, which results in the polish work book being overwritten entirely to fit the game's new design.
HOW I OVERCAME THEM
-
For over scoping, I realized early on that the project was too large. This was because I had planned out everything on my Trello board and realized I wouldn't be able to make it at the pace I was going. Which resulted in me cutting additional content ahead of time.
-
I changed the narrative to be more sensitive by changing the art pieces to give better context to the game and make the player's actions feel more reasonable.
-
For this project, I made a new polish worksheet that fit the game and actions. The new workbook encompasses all the actions and new ways.
WHAT I LEARNT
-
I learnt a lot during this project. I especially learnt a lot about what is considered game polish / juice ad how it should be implemented into my projects in the future.
-
I learnt that it's not something that should be left for last, as game juice can be very important and help in user experience.
-
With the except project workflow, that I had created for myself, it will be much easier for me to plan and implement polish into my game projects further down the line.