top of page
  • gabestott

TDEMO Spinny Clicky

Updated: May 19, 2021

At the time of writing this, we are well into the first year of university and have already started our second teaching block (TB2).

Some time has passed since I developed Spinny Clicky and the development process certainly isn't fresh in my mind. In hindsight I should have written a dev log for Spinny Clicky during or immediately following the development process for the game.

We were asked to create a one input game. i.e. a game which is played entirely with only one input, excluding menus. I settled on the idea of an arcade style/ mobile game and begun concepting.

While concepting I had two initial ideas. The first was an adaptation of "calibrate distributors", which is a mini game found in the popular game among us. In calibrate distributors you have three rings and you need to click to stop a rotating "needle" in the correct place. The second idea was to build on a concept I found in a CSGO custom map. In this custom map a circle is placed on a wall and after an unspecified pseudo-random amount of time the circle changes colour to red and you need to shoot the circle in that moment to score.

Planning and concept notes

I had been playing a lot of among us and was quite inspired by the mini game task in among us "calibrate distributor". It reminded me of the similar mini game in old school ratchet and clank games where you had to align the laser grid to open locked doors. I wanted to take this initial concept and see if I could add some extra features.

The proposed additions were:

1. A countdown timer which created a fail state if you run out of time

2. Having two moving pieces which need to be aligned instead of one static and one moving

3. Utilizing changing direction of rotation. clockwise/ anti-clockwise I got to work on the design phase which required me to create several rings. I am not an exceptionally talented artist, I am not even a talented artist. As a result the final look of the rings was really rather appalling. The colour scheme and the resolutions made the game look garish and that hugely detracted from the overall experience.

In regards to the code. I have little experience with coding and up until shortly before attempting this task, I had not touched any kind of coding software for some number of years. Despite these challenges I thoroughly enjoyed learning how to program this simple game. I utilized my own knowledge and the documentation provided by YoYoGames to successfully make the required game logic and conditions. In hindsight the code used for this game is very over simplified for game development and could be seen by some to be somewhat limiting. However, for an out of season, very rusty developer like myself it's a real gift because it's super easy to learn and utilize to make simple applications like this. I can see now how useful this tool may be in creating prototypes for simple 2D games and apps.

While coding I came across challenges for the mechanics. As explained in these notes, the main challenges faced in the coding were:

1. Getting the rings to spin at different random speeds while still aligning together frequently.

2. Getting the rings to spin clockwise or anticlockwise randomly.

3. Preventing/ punishing spam clicking.

Looking back at these challenges with the knowledge I have now I am certain I would have approached them differently. I particularly struggled to make it so that the player needs to stop each ring individually and in sequence to score a point. Instead I opted to simply make it so that you wait for all the points to align and click once to score. I'm sure I could easily create the functionality which I originally intended, using the knowledge of conditional logic and game data I have now.

Reflecting on the feedback from after the game jam was interesting but expected. Many of the players complained about the unfairness of the system. The collision boxes were much smaller than the representation of where you'd expect them to be. This was a deliberate attempt to add a level of difficulty but with retrospect it's quite a cheap way to make something harder. It's akin to a rigged game at a fun fare, and a badly hidden one at that. The player becomes annoyed with losing what looks like an obvious win.

The other notable feedback was that the game just "looks crap". This is a totally fair criticism because it really isn't very visually pleasing, the colours contrast very strikingly and the design of the rings is just ugly. On top of this there are obvious issues with the UX. Firstly there is no menu so the only way to exit the game is to use a keyboard shortcut for switching tab ALT+TAB, closing a window ALT+F4, bringing up the task manager CTRL+ALT+DEL, or some other known shortcut. The user should be able to exit the game through the game's in built navigation without needing knowledge of these shortcuts. Even if these shortcuts are widely known it just makes the game feel more polished and user friendly to have these menus.

In conclusion, the concept is good but the execution leaves much to be desired both in the visual representation, UI and mechanics. If I were to go back to it I could easily add more of the functions I wanted to add in the original concept and I would definitely add a new UI. Once that's done I'd work on improving the look of the game but ultimately if I were to publish it I might employ some help or advice from someone with a better eye for graphics and style than myself.

6 views0 comments

Recent Posts

See All


bottom of page