Genre
InfiniteRunner
Production Time
4 Weeks, 100%
Team size
10
My Contributions
- Gameplay programming
- Player Camera
- Playtest implementation
Overview
“Archtillery” is a mobile game where you fire a ballista into enemy forces and guide it as far as possible. Once you hit a target, you reel the bolt back and crash into as many enemies as possible on your way back.
I was one of two programmers working on this project. I focused on gameplay programming while the other was responsible for UI programming.
The game is available on itch.io, so follow us there to play it!
Gameplay
You want to travel as far as possible while avoiding obstacles. You can do so by tapping the screen to move your character right or left. Once you inevitably collide with an obstacle, the game changes and you need to hit as many objects as possible to start chaos. The more chaos you create, the higher your score will be, earning you currency that can be used to purchase cool upgrades.
Gameplay of avoiding
The reeling sequence after hitting something
Available upgrades
Implementing Pooling
I made an enemy spawning system that uses pooling, which saves on performance by enabling/disabling prefabs instead of creating them during gameplay. It’s easily modifiable in the hierarchy.
To add new enemies to the spawntable, simply add the enemy prefab and give it a type. Size determines the number of enemies created. In the case of the goblin in the screenshot, there will be 20 goblins instantiated at the start of the game. This technique reduces system load during runtime, as mentioned previously but only 20 goblins can be visible at one time.
The image shows how to adjust the enemy spawn rates. A weight of 0.5 means a 50% chance of spawning. The hierarchy is implemented with my best attempts to make it readable for my team by adding headers and tooltips. Here, I hover over the weight for a tooltip.
Problem-solving
I initially used pooling for the management of the ground, but this caused issues. The issue was that there was a slight gap between ground tiles. This small gap between the ground was hard to figure out, but the reason was that when the pooled prefab got assigned its position, there would be a microscopic delay when it calculated the in-game position.
This meant that on long runs, a small gap would eventually become more and more revealing. To fix this issue, I removed the pooling functionality from the ground and added a script that oversees how far behind the ground is to the player. If the ground moves past the assigned distance, it updates its position to be in front of the player. This means that I only need four ground tiles and don’t have to create new ones, which is good for the preformance. The result is visible in the gif below.
Visual representation of how ground is moved