Game Feel Simulator

  • Team Size: 1

  • Engine: Godot 4

  • Production Time: 4 Months

  • Roles: Technical Game Designer, Engineer, UX Designer

  • Link to playable game: Game Feel Simulator

Core Considerations:

  • Create a robust and accurate 2D platformer with a plethora of exposed variables.

  • Create a tool that is informative and honest to 2D platformer development.

  • Make a useful class tool for José Zagal that can be used in lectures and class asignments.

Designing the Process

At the start of the project, I only knew the barebones idea of the plane: we were going to make a 2D platformer tool that showcases how game feel is created and we would use Steve Swink's book Game Feel: A Designer's Guide to Virtual Sensation as a guiding light. After an initial meeting with Zagal, I put together a timeline and a design document. The timeline included what work would be done when, and which chapters would be read. The design document detailed exactly what the game would consist of, although much of this was changed during development.

Now that we had a proper plan and documentation, the tool was ready to begin development.

The Platforming Variables

The most intuitive place to start development was on the gameplay portion. I put together a simple 2D character movement script and added every required variable piece by piece. I was diligent to keep my code clean and with plenty of documentation so that if anything ever needed to be revisited I would be able to do so easily. Unlike a typical platformer, every variable may be changed during gameplay so I had to ensure that changes to variables would affect the character immediately and not require a restart.

The Timeline

We knew from the start that one of the more interesting aspects of this tool would be the variable timeline. This timeline shows character variables and player input on a graph over a 5 second period. This helps users better understand what their character controls are doing, especially when they slow down the time scale of the tool using the time scale slider.

After the initial creation of the character movement, I had an extensive meeting with Zagal discussing what I've made and how to represent it in UI. We decided on adding a few impactful variables for the character and including a distinction between player variables and environment variables. I then made the UI that allowed the user to change the character movement variables. I had to consider how each variable would be bound - its minimum and maximum value - and how it would increment.

The timeline section also contains two other elements: the Show Jump Arc toggle, and the Level drop down menu. When the Show Jump Arc toggle is on, a jump arc is generated from the center of the character. This arc is updated every frame based on the characters current speed and jump height. It detaches from the character when they leave the ground so the user can see the character travel across the line. This becomes especially useful when users notice their character deviate from the arc as a result of other variables, such as variable jump height or max fall speed.

The Level drop down menu allows the user to choose between four different levels: Normal, Open, Tight, and Empty. This was added so that players can design within different space contexts. A large part of game feel is the simulated space that the character controls through, so it would make more sense to control some feels within different levels.

The Save System

The final function that this tool needed was the ability to have different save profiles, both default and user made. José Zagal plans on using this tool in his Game Design class. Aside from using the tool for lecturing on game feel, he will use the tool for a class assignment where students must recreate a game feel in their own save profile. I made a robust and user friendly save system that auto-loads default save profiles, and allows user to create their own save with a custom name. Saves can have hidden variables, non-editable variables, partially editable variables, and fully editable variables. This allows Zagal to customize assignments, such as giving students a profile that only allows the manipulation of acceleration and max speed. The save system has checks in place to ensure students don’t poorly manipulate the JSON file, and resets the save file to default values to ensure the tool continues to function properly.

Finishing Up!

Throughout development I was constantly playtesting and making adjustments for better user usability. Once all of the features were complete my development became all about testing, bug fixing, and improving the user experience. I am eager to get the large influx of user feedback that will come with Zagal using this tool in class for lectures and assignments. I am extremely proud of how this tool turned out. Not only did I gain a deeper understanding of how to design game feel, but I greatly improved as a developer and engineer.