"Paper Football" (also known as "Paper Soccer") is a pen'n'paper turn based game from my childhood days. The game entails simple logic based rules in which 2 players compete on a 7x11 (point to point) grid. The goal of the game is to get the 'Football' into the opponents goal posts by creating line connections and avoiding to overlap an existing line within the given boundaries. As my understanding of game design, engines and implementation skills began to grow, I decided that it would be an interesting and fun idea to digitize this.
The following page gives an incite to the process of my design and development for Paper Football...
Research and Understanding
Before any sort of implementation could begin, I would start off by breaking down the physical game into its most basic rule sets, components, restrictions, and noted them all in a sort of action list. This way I would later be able to re-structure the identified actions and begin unwrapping them further into respective functions and scripts within the game engine.
To further expand upon this I wanted to observe the game from a 3rd person perspective in order to potentially catch out any details I may have missed, or special situations I did not consider during my breakdown stage. To do this, I got some testers to play against each other. Once I explained all the rules, I would only intervene if an ''illegal'' move was attempted. Any and all observations would be noted and gathered together similarly to above. I was also left with a notebook filled with matches that I could analyse and refer back to when necessary.
Moving forward all of my documentation was ported over to an Obisidian repository. While the project was not large, I would retain to formally structure documentation in the form of a highly detailed diagram in addition to any subsequent word docs that explain the functionality of functions or purpose of certain variables as necessary.
The first hurdle was to determine a grid movement system. My initial solution was to generate the grid procedurally, however this proved to be harder to reference each individual grid point for any data.
Ultimately, the coordinate points were set out manually into individual game objects which shared a controlling script. While this may not be the fastest solution, it gave me direct access over all points, and if they needed special conditions such as the corners of the playing field, they could be implemented much easier.
Finally, using a line renderer component, by clicking point to point a line is rendered creating a visual connection.
Once movement was set-up, the next major consideration was to create a system that restricts the players into the identified rules of the game.
The system would have to check for connections, restrict the player from moving along existing lines and allow for extended jump movements. In a way, it would have to anticipate one step ahead checking the possibilities the player has.
Ultimately, my solution was to create a reference list that stores all connections made within the match. Doing so, allows the program to constrain the player from performing overlapping connections between populated points. In order to allow for bouncing a square collider is moved to the current point, this references all nearby points and checks internally whether connections exist or do not exist allowing for a bounce or locking the player.
Once this was done, game feel and UX elements were considered such as the gradual line placement, highlighting which player is currently playing, pop-up of points and colour coded signifiers as well as the background scaled image of grid paper. The game is intended to still give off the feeling of a real life notebook with pen'n'paper.
Generally improved my thought process and problem solving skills as a designer by breaking down existing rules from a game in real life in order to digitise it within an engine. Working to identify all the technical components required to make it work and resemble the original product when on screen.
Improved upon my implementation skills, with careful iterative development and attention to detail in an attempt to try and make the system as robust and as effecient as I possibly could - especially since the game has to function fully in order for the desired rules to work.
The next steps of the project has become to implement networking features into the game. To do this, I teamed up with a dedicated programmer. In order to onboard him onto the project, and communicate all the required components of the implementation and design, relevant documentation has been created that explains all scripts, functions and their respective variables.
The documentation is part of the GitHub repository and is updated with each subsequent change.
Thanks for reading!