Running The Mine 1

This was my first ever game in unity, the main aim was to create an infinite platformer, however I plan to revisit it to fix glaring errors in the code's logic as well as update its graphical fidelity

Ideation stage:

I have wanted to make this type of game for a long time, but the mine theme came to me from an unexpected source, a painting from Zdzilaw Beksinski of a head with its mouth open eating creatures. That painting inspired me to try to recreate something similar in 3D of a head made with an open mouth growing from a mountain. Although unfinished, this 3D model made me think of what would happen if it was in a game and the beginning of the game panned into a transition where the camera enters the head’s mouth and the game starts as an infinite runner in a cave, which later on I realized was very similar to the beginning of temple run. Due to texture continuation, I scrapped that idea and instead of a long cave tunnel I turned it into a mine, due to the wood being able to hide seams between textures when the generation sections of the game meet. Since a mine wouldn’t make sense with the head in the mountain, I decided to remove that from the equation and just keep it as a standalone mine themed game.Prototype stage:-The first prototype for the game began even before I got the brief, as a personal experiment to help me get used to the game engine which I made by a mix of the things I learned in the first game engines lesson with a mixture of tutorials I found online which I modified and optimized to better suit my needs. -After the first prototype, I started developing on more gameplay aspects, as well as laying out the beginnings of the user interface.-The final prototype has the basic mechanics with a very basic covering that looked like a mine in order to give me a better idea how the mine beams would fit together when generated, so that I can better model the mine body in maya.

Game concept summary:

The main concept for the game is a mine themed 3D infinite platformer where the player automatically moves forward and has to move side to side and jump in order to dodge the obstacles and pick up collectables. The collectibles in this game are crystals (which are the main in game currency) and gold (which is responsible for increasing the player’s life count for the current round). The more crystals the player collects, the faster the player becomes, and the more gold you collect, the more lives the player gets. Apart from the game getting faster, the more crystals the player collects, the more crystals are added to the total count, which is meant to be used in the skin store(which I haven’t managed to code).

Core mechanics/formal elements/gameplay:

The game will be a player vs game system in which the player tries to collect as many crystals as possible in order to get a higher score by getting through infinitely generating obstacles, with the gold pickup giving the player an extra life for each gold powerup picked up, with a base starting amount of three lives. The game starts with the player automatically moving on an infinitely generating platform with stationary obstacles and crystals spawned on it. Due to the infinitely generating nature of this game, the only end is when the player dies. If time and skill allow it, in order to give the player more incentive to play the game, I plan to make an in-game store that uses the pickup points stored in a log file to buy different skins for the character. in order to make the game more challenging, I plan to spawn the crystals in a completely random and unpredictable manner instead of prefabricated locations, preferably with an algorithm which destroys crystals that spawn in the obstacle if my current skill level allows.

The rules of the game are that if a player collides with a crystal, the crystal counter will increase. If the player hits an obstacle three times, or the player hits the side or top boundaries once, the game restarts. If the player dies, the game will have a screen comparing he high score and the game score, giving the player an option to start a new game.

the main separating factor that sets my game out from the majority of the hyper casual infinite running games, such as subway surfers and temple run is that my game requires more skill and dexterity due to the player not being confined to specific lanes, predictable point patterns, or direction snapping, but instead, my game relies on how well the player can control the arrow keys and space bar in a more precise manner when it’s compared to the set and predictable nature of most other 3D infinite running games.

Visualization:

Once you enter the game, you are greeted by a title screen with three buttons made with the wood texture:
- Play
- Skins
- Quit
In the title screen, there is a blurred-out mine in the background.
If the player presses play, the player spawns as a ball right into a long tunnel of rock with the score and lives written on a wooden slab at the top left corner of the screen.
In the long tunnel, there are chunks of rock littered all over the floor, as well as blue transparent crystals and nuggets of gold.
The ball starts moving along the tunnel and passes through 2 obstacles before dying on the third one, with each obstacle hit emitting particle effects, as well as impact sound effects.
- The lives counter will be done with a for loop
- The impact sound effects will be triggered in the same method as the live decrease loop
The game asks the player if they want to play again, along with the number of crystals the player got in this gameplay in comparison to the previous high score.
After the player accumulates enough crystals, the player decides to go back to the main menu so that they can buy new skins for the ball
- The skin menu has the same background as the title screen, but it has a carousel with different skins and their price

If a skin is already bought, the buy button changes to a choose button, which updates the player’s skin next game

Implementation:

The main way I will implement these ideas are by following a tutorial, but at the same time modify it to make the code in the tutorial more efficient and better suited for my needs
I have done a similar game before in unreal engine, so I already had an idea on how I was going to generate the platform infinitely.
All the assets for the game will be made by me in Photoshop, Maya, and FL studio
While making this task, I aim to work alone as I am not confident in my teamwork skills yet and I feel that at my current state I would be restricted when it comes to how I want to do things.
Visual audio assets needed:
- Normal sized rock obstacle
- Long rock obstacle
- Crystal
- Gold nugget
- Main theme song
- Large assortment of stone, wood, and metal textures
- Player ball
- Blurred background image
The visual assets would not take a long time to make, with most of the time being taken for the rendering rather than modelling, texturing, and sculpting

Although I have experience with audio production, it will take a longer time in comparison to the 3D modelling, as it takes me a lot more trial and error to get the desired feeling from the music

Post prototype stage:

The first thing I did in the post prototype stage is 3D model/produce, import and implement the 3D assets and the music. The main issue I had at this stage was the texturing. Another thing I did in this version of the post prototype stage is working with the lighting effects and fog effects in order to give the game a more eerie underground feel that I at first wanted to get from my original idea for the game.
In the second version in the post prototype stage, I decided to focus more on further gameplay mechanics, mainly:
- making the game increase after collecting a certain number of points.
- finding a way to give the player a head start in order to not overwhelm the player in the very beginning of the game.
- starting to implement a high score storage and comparison system.
as of writing, I am at the second version of the prototype stage.
in future versions of the post prototype stage, I plan to introduce more obstacle variation, a no damage powerup, a skin store, and improving the game’s user interface.
I managed to incorporate a high score ant total score system, but I am having trouble with storing them, as even with player refs, if I re start the build, the values are reset.
I was unfortunately unable to fully code a skin store in the game given the time provided, specifically the part where it came to changing the object’s texture, but will probably be able to do it in the submission for the game engines given its later deadline.
I have managed to create a head start for the game, as well as attempted to fix the jumping issues, although not fully fixed they are a lot better than the last build.
- I think that it is mainly a clipping issue as the thing that fixed it the most was elongating the platform, probably the platforms increasing drag, if that doesn’t work, I will try to change the jump method from physics based to purely location based.
- Found that the head start didn’t even need to be coded.
While playing the game, I started considering doing pre-set levels instead of pre-set obstacle generation so there are less spawn overlaps and relatively more varying when it comes to scenery, but due to time constraints, I don’t think it would be feasible to pursue this idea, but I will consider it when I try to recreate this better as a personal project.
I decided to give the graphics a lower polygon count, as to improve performance.
One of my classmates suggested that I change the main character from a ball to a mine cart, as it would make more sense for the context of the game, which after I implemented seems to have unintentionally fixed the clipping issues.
- Although the game doesn’t look as good now with the lower polygon modelling, the performance is a lot better.

Finalized stage:

For the first finalized version of the game, I decided to fine tune the performance and reduce bulk, I had initially planned to work on better quality 3D assets but I didn’t due to possible performance concerns.
Made head start delete after player passes it, made mine cart smaller so it’s easier to go between obstacles, and made the side to side movement speed slower, since that was a very common complaint from my playtesting sessions.

System dynamics chart:

Game Progression Flow Chart: