The purpose of these Dev Logs will be to share with everyone the creation process for Steampunk Panic. A way to look behind the curtain, so to say. Some of these Dev Logs will be simple, others will give plenty of in-depth explanation for how things work or why things were done the way they were.
Steampunk Panic will have a lot of button types that the player will be able utilize in order to increase their score. One of those button types was the fever mode button. While having this be a random button that appeared was cool, I didn’t like the fact that if the player wasn’t paying attention, they might miss it and have to wait for it to appear again. Of course, reaction speed and being able to read the button grid quickly is essential for this game, I want fever mode to be a reward and not a random chance. Thus, the fever meter was born!
While playing the game, every button hit can fill up the fever meter. The amount that the fever meter fills will be based upon how quickly a button is pressed, so it is linked to the timer bar much like the points you can earn per button tap. Once the fever bar is full, there will be an effect on it to draw your attention, a separate button near the bar will also light up and can be tapped. Once tapped, fever mode will activate and you’ll be able to tap any of the buttons in the button grid as fast as you can.
Device UI Concepts
For now, we’re focusing on concept art for what the game UI will look like, with the menu UI coming later.
For this UI, we had to make a decision on whether it should be a minimalistic UI, similar to what the early prototype was using (basically, just floating buttons on a colored background), or if it should be a more physical or themed UI that the player interacts with.
– Simple and clean
– All elements are typically interactable
– Easy to add new elements
– Easy to fit any screen size
– Memory use is minimal
– Not much of a textured theme to stand out
– Can look sterile
Physical or Themed UI
-Interesting and unique
-More of the UI can be animated
-Feels like a toy or object that you interact with
-Harder to add new elements without updating lots of art
-Extra care is needed to make interactable elements clear
-Memory use is much higher
There have been lots of games popping out with a minimalistic UI style that revolves around geometric shapes and colors. They are easier to build and really distill the experience into just game mechanics and touching the UI. They look clean and easy to use, and that’s a huge advantage. But then there are games like The Room and Hearthstone that have physical UIs in the game world that you interact with. For Steampunk Panic, we decided to go with a physical UI like a device you might find in The Room.
So, what should the device look like? Since the game will be played in portrait mode on a phone or tablet, we need rectangular buttons instead of squares. Circular buttons waste too much space on the UI and feel like there is less space that is valid for tapping. So, using rectangular buttons and a tall device to interact with, we tried various layouts and options, then quickly colored parts of these devices to get an idea what it could look like. Here’s a very, very, very rough concept of where we’re going:
Gears, gauges, wires and pipes … basic silhouettes for the device started to pop out for us and we settled on taking parts of some of these concepts and combining it with others to get this basic device shape and layout:
The device would be rectangular, with a gauge on the left for the timer (started filled with liquid and empties) and a smaller gauge on the right for the fever meter.
Current score would be displayed on the top of the button grid, in a style similar to a combination lock with spinning numbers. These numbers would spin to the current score, so the right 1-2 numbers might be constantly moving. The multiplier number at the bottom would use a flipping number display, like old school flipping number analog clock or calendar.
The left side of the grid shows a base score number wheel, which will probably go away. The idea was to show what percentage of the base score you would earn when you hit a button, but this can be also portrayed by adding percentage notches to the timer gauge itself.
The top gear and the bottom right gear are examples of where moving elements could go, with an example on this concept showing how fast the game is running by spinning the bottom right gear faster.
The purpose of this concept piece is to show the important elements and how they might function. The next step is to iterate on what the device’s non-interactable element might look like. This will be where some art deco influences will come in, adding texture and features to the device to make it look more like an actual physical device.
While the concept art of the device layout was happening, I tackled the score validation aspect of the game. When players are connected online and playing, they can submit their score to a global online leaderboard. To prevent cheating, I needed to provide a way for the server to replay the game submitted with the score and ensure it’s valid. There isn’t much to show about this feature, but the general idea is that the game records what the player presses in the game (the replay data) and the server replays it and, at the end of the replay, the scores need to match up.
I have some test cases set up that has gone through 1 hit games all the way up to 10,000 hits in a game and the scores all came back validated and correct, so even with the random aspect and different modes being turned on and off, everything is validating correctly!
While testing out the slow/freeze button and the fever buttons, we decided that the fever button needed to separated from the button grid. But we also saw too much similarity with the fever mode’s “locking of the timer bar” and the slow/freeze button doing the same thing. So, I made this button type just be a “slow” button, so the timer is slowed down for a small amount of time. I mentioned trying this in the last Dev Log, and sure enough, it was a good decision. It provides a breather for the player to slow down for a sec and then have the game pick up again. It is still a little jarring to go from a very fast game (due to having been playing for longer than a minute) to a slow timer and then immediately going very fast again. I will try adding some code to speed up the timer to the correct speed over the span of a few button hits, to let the player get used to the speed jump.
Having the fever button be separated from the main button grid has opened up extra strategy for the player, while at the same time, allows for all players to be able to access the mode as long as they hit enough buttons to unlock it. Although there is a “slow” button type as well, it doesn’t feel as much as a special mode as a small modifier, so keeping it in the game grid feels pretty good.
The button for the fever mode, like the button grid, also needed to register a hit when touched, not when released (which is how a button would work in a game). Since it this is a speed based game, I need to make sure that input is quick and has no delays.
When I added the concept art into the game, it was still not tall enough to fit the screen, so we’ll be making it a little more taller in the future. The button grid feels good when tapping it, keeping the four button hit boxes as rectangles behind the scenes, instead of forcing it to conform to the shape of the button. That way, you could tap a little bit outside of the curved rectangle button and it still registers as a hit.
There are still a few extra button types I want to prototype, as well as an easier way for me to balance the game by stating how often and when button types can start appearing.
Leaderboard support and some server work will be happening soon as well.
Monetization is also still a thing and since this is a score chaser, there won’t be many options for me to pursue … most likely ads and an option to disable ads.
Since we like the art deco steampunk aesthetic, we’ll need to start looking into music options as well, perhaps electro swing?
I look forward to sharing more of this process with everyone over the next couple Dev Logs!