top of page
Carom Collision
Overview:
Carom Collision is a turn based player vs player strategy game where players control their units by firing them across the board like a game of billiards.
The goal of the game is to reduce the health of all enemy units to 0, taking careful consideration of the 3 unit types, randomised stats and the aim of your shots.
Design Philosophy:
Going into this project, I entered with the main aim of experimenting with systems design in a personal project. This came in the forms of the physics, unit type and stats systems. As well as this, I hoped to capture the simple joys of carom games such as billiards, being the satisfaction of hitting a ball and seeing the results of physics at work, ending in the desire to make the game enjoyable for a wider audience.
Design Process:
Unlike past personal projects, this was the first that required me to fill out a statement of intent before I began development, because of this, I had a clear idea of how much I wanted to get done for the game from the onset. One of these advantages, was better planning of scope and when different parts of the game would be developed.
Playtesting was established very early on in the projects life, meaning that iteration was a constant factor in Carom Collisions development in regards to many aspects such as sound, balancing, UI and level design. An example of this, was the change of unit controls changing from being controlled by changing power with scroll wheel and aiming the mouse towards where you wanted the unit to go towards, to a different system that felt far more natural to playtesters and was more reminiscent to cue sports.
Reflection:
To begin with reflection, the primary plan of the project was over-scoped, especially with plans of a Player vs AI mode. Fortunately due to the Plans A, B and C system, plan B of the scope plan was executed instead, with the final version including 3 maps, 3 Unit types, a tutorial and the Player versus Player mode of the game. Despite this however, the plan originally was to be on the playtesting and polish phase by week 8 by the latest however core mechanics were still being done weeks later than that, showing this error.
In future works I will do my best to better consider my own abilities and sustain a better work to life balance to keep on schedule and avoid having to use fall-back plans. Fall-back plans however, work very well and I will continue this pre-production habit going forward.
As well as this, in future I will dedicate more time earlier on in projects to utilising placeholder art and more frequent use of prefabs. The lack of large scale utilisation of these till later in development led to multiple times where otherwise complete work would have to be changed to fit new image scales, or in the case of prefabs, changing one of something having to be copied to all versions of it instead of prefabs doing this automatically, taking up more time than I would like over the course of the project.
bottom of page