Creating Steampunk Panic (Part 7)

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.

More Concepts!


While work was happening on the leaderboard and finalizing the server code, talked about in our last Dev Log, I asked two concept artists to explore two styles of the game: a device object to see and touch, or a full screen UI that makes your phone’s screen look like the body of the device. I provided the various concept art sketches we had already created, for inspiration and information for requirements. Let’s see what happened!

Concept #1: The Machine in your Phone/Tablet


I really liked the idea of the device being an object that you interacted with on the screen, so we asked our first concept artist to explore that area.

So yeah, holy crap! He really went all-in on the idea of the device being a cool machine that you interact with. I could see any of these machines being on the screen for the player to interact with, but I was definitely in love with the one on the left, and some of the features of the one in the middle.

But having the machine in your phone/tablet would make some sections smaller, could make parts of the machine hard to read, and in the end, make less of the screen usable or have important information.

Concept #2: Your Phone/Tablet is The Machine


Now, if your screen was effectively the body of the machine, holding your phone/tablet would feel you were holding the machine. So, let’s just do the full-screen UI. Enter our second concept artist.

The first image reveals all of the important information that we need. It’s not too complex and is easy to read. It has a nice casual mobile game UI feel and that multiplier section is hot! I also like the little flip switch for turning on the fever mode. I really like this concept. When I put it on my phone, it felt like I was holding the device in my hand, and I was interacting with it. With animations placed on the tesla coils, spinning numbers, bubbles and more, this could really shine and be what we need!

The second image goes for a more complicated look, with more bells and whistles. The background would have slowly rotating gears, and that steampunk styled goblin could be an animated character who could slide in occasionally to distract the player by throwing gears or hitting things in the background. Or, he could appear at the start or end of the game to spin up the game, or wind it down. Basically, the goblin could be a character to provide more charm. You’re own little goblin in the palm of your hand.

Concept Winner


In the end, I really like the first image for Concept #2. It looks good and feels good and clearly tells the player everything they need to know. It’s not too distracting and would be a great fit for a mobile game.

With this concept selected, I believe we have nailed down the look and feel of the game. We can start working on the polished version of this screen and start developing the UI art for the game. The logo for the game can also be started, now that we have an aesthetic style!

Android Support!


All Android-specific code is now written and tested. In-App purchase code, ad viewing, server communication, local notifications, done. This is huge, because it means that I all code written from this point on is game code. I also have the Android publishing process figured out and tested, so when the time comes for Steampunk Panic’s iOS and Android release, it should be fairly straightforward for me.

Also, thanks to this work, I can roll this code into Eat the Moon’s common codebase used for all my games. I’ll be able to update the codebase for Idle Realm and Taco Cat Taco, letting them finally pop out on Android as well!

Coming Up


Monetization will be talked about next, as we have finalized what our plan will be.

We also need to start up UI concept art for the game dialogs as well as the game logo!

We also need to pick some music for the game that will match our new art aesthetic.

I can’t wait to share more of this process with you in the next couple Dev Logs!


Creating Steampunk Panic (Part 6)

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.

Leaderboard Server, Done!


These past few weeks, I’ve been wrapping up the server code for Steampunk Panic to handle a global leaderboard for each game difficulty mode. I have worked on leaderboard features before on other products for other game studios, but this was the first time I had to roll my own and handle every aspect. The process was super fun and I’m pleased with the result!

Global Leaderboards


Steampunk Panic is all about chasing the high score and doing better than last time. You can always compete against your own score, but some will like to climb a leaderboard to see how far they can go, and now you can.

I opted for a global leaderboard to start with, but can easily create leaderboards per country or any other type of segmentation that I want. It’s as easy as pointing at a new leaderboard name and running with it. The only reason why I would want to separate users is if the user count gets massive. So, when Steampunk Panic launches, I’ll be keeping track of the leaderboard sizes to determine the next step to take.

For those curious, if the leaderboards get out of hand, I will have the following options:

1) Create leaderboard “buckets” which would be assigned to players. I could have 10 leaderboards, and every new player gets assigned to a leaderboard when they first log in. This would distribute everyone evenly, so if I have 100,000 players, each leaderboard could have 10,000 ranks.

2) Go with timed leaderboards. Right now, the leaderboards are for lifetime scores. But if there is a large number of players, I might need to reset the leaderboard every week. Players who drop out and no longer play will be weeded out from the leaderboard in this manner, with each new week providing players a chance to climb again. The disadvantage of this method is that there is no reward. Steampunk Panic has no premium currency, it has nothing to unlock. What would be the point of climbing the leaderboard that week, if your progress is just going to be wiped?

3) Like the buckets idea, I start segmenting players into countries or geolocations. The game no longer has a global leaderboard and you are competing with local players. This could be fun … but I would prefer to keep it global.

Cross-Platform Leaderboards


I had to make a decision: Do I use the platform’s build-in leaderboard support (GameCenter for iOS, Google Play Games service for Android)? Or do I go with a cross-platform leaderboard?

There are benefits to using the platform’s leaderboard support, especially if there is a friend list built in, letting you compete against your friends or the world. But it’s also easy to cheat these leaderboards, as all you need to do is submit a score to Apple or Google and their services just accept that as a valid score. This is how leaderboard get filled with tons of fake, impossible scores.

So, I opted for my own leaderboard approach that is cross-platform and handled by my servers. Fake scores won’t be able to be submitted because of score validation I do on my end, so when you load up the leaderboard, you should be guaranteed real scores!

Ranks


Players will be ranked, based upon the game mode they played. Everyone playing the Easy mode will be ranked against scores submitted in the Easy mode. This seems fair, as the last thing I want is for someone to plateau on Easy mode at 150,000 points or something and still be at the bottom, since Hard and Expert modes provide way more points.

The leaderboard will show the top 15 players in that mode, as well as the 15 players who are near your current rank. For example, if you are rank #52, you’ll see rank #1-15 on the top section of the leaderboard, and ranks #35-50 on the bottom section. This allows you to see how close you are to climbing the next few ranks, as well as seeing how close you are to losing your current rank.

Score Validation


So, score validation… how does it work? To start, your game client communicates with the server to get some randomized, unique data for your specific game mode that you’re starting. The server locks this info down and your game client spins up the new game. Your game client also knows what your high score is for that mode.

As you are playing the game, a replay of your input is being generated. At the end of the game, your game client will look at your high score and that game’s score and, if you have a new high score, it’s time for score validation on the server!

The server receives your replay input data and the expected score, then spins up a new game on the server, also loading in the unique data it has saved off for that game. It will replay the game with the input data sent and verify that the score on the server is the same that the player said they got. If it is, the leaderboard is updated, the score is saved on the player’s server data. If the score is different, there is a chance that the data was modified before being sent to the server, so it will fail.

Now, in order for this to work, the server uses a deterministic random number generator that will generate the same number sequence, no matter the device or platform. This number generator is also used on the game client, so they will always be in sync.

Since this is a very important part, many tests were created to validate the score validation code. I created test code that would generate a new game and play from 1 to 100,000 hits, skipping over every 10 hits (so, 1, 10, 20, 30, 40, etc.). This would generate 10,000 games, all using the same number seed for the game. I would do this for 100, and then 500 different number seed. Then I could just generate 1,000 games, with 1,000 different seeds, with ending with 1 to 1,000 hits (chosen at random). Every one of these games would be played by an AI, processing all of these games over the span of a few minutes and then validating them. Every game validation passed, with replay data matching the replay data’s replay data that is generated. So, I feel pretty confident that this is pretty solid.

I also tested failures as well, and invalid replays, also with thousands of iterations.

Score validation via replay data is extremely quick, so the server should be able to handle hundreds of replays a second without batting an eye. I expect 1-2 replays a second to roll in, maybe jumping up to 10 per second if lots of users are playing. The great thing is that validation only happens if it is a new high score. If your high score is 90,000, I’m not going to waste time validating your 33 point game, it won’t affect the leaderboard!

User Names


In order to submit a score to the leaderboard, you need a name. So, the first time you start the game, you’ll be asked to pick a leaderboard name. There are rules in place for names:

1) 3-20 characters long
2) No special characters
3) Nothing profane
4) Needs to be available

The first two rules are easy to enforce with simple code. Profane names, however, is a little more difficult. I am not going to be able to cover every profane name or situation, but I am able to cover a lot of common situations. I am using a profanity filter to handle this on the server. But, there will be names that pass through.

So, every day, I have the server compile a list of all new names and an email is generated for me. I can browse it quickly to see if anything jumps out and, if so, I can mark a name as profane, which will trigger a rename. On my end, when I mark a player name for rename, it will generate a new user name (Player ######) and rename the player on all leaderboards. Then, the next time the player logs in, they will presented with the rename dialog and, once renamed, all leaderboards will also have that name renamed again. I don’t expect to be doing this often, but I wanted the feature to be there, just incase someone in the top 15 on the leaderboard (who will be seen by everyone) has a horrible name.

In the future, I might add a report name button on the leaderboard, letting players police the board themselves. After being flagged a couple times, I might see the name in a daily report so that I can review it. If it’s in need of a rename, then I do it. Otherwise, I mark it as safe and it’s good to go. I would never auto-mark a name for rename, it would always need to be reviewed before a final decision is made. I wouldn’t want the button feature to be abused.

Coming Up


Wrapping up Android work!

Monetization will be talked about soon, as well as an update on new concept art and the art direction for the game.

We’ll need to pick some music for the game and start designing UI elements (the menu, leaderboard screen, dialogs, etc.) that fit the art deco steampunk aesthetic.

I can’t wait to share more of this process with you in the next couple Dev Logs!


Creating Steampunk Panic (Part 5)

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.

More Device Concepts


While working on server code, our artist started tackling more concepts of what the device might look like. With Creating Steampunk Panic (Part 3), we decided on the basic shape of the device. Now, it’s time to explore what various parts of the device could look like and what we can do with them!

The Top Area


For the basic shape design, we had a gear exposed at the top. Originally, we thought it could spin slowly, indicating that the device is functioning and doing something. But it was a large moving piece and might not be as interesting, so we opted to try a static section instead. Several ornate art deco pieces were made for the top, each providing a fun and interesting silhouette.

While looking at these concepts, we thought it might be cool to switch the top of the device based upon the game difficulty the player selected. The higher the difficulty, the faster the timer gauge empties and the more points the player would earn per hit. Or, if not for the difficulty, maybe the player could customize the device by adding and removing elements. These could always be unlocked, or they could be unlocked by reaching certain score thresholds or playing a certain amount of times?

Device Body


Next, we tackled various ideas for what the device’s body would look like, connections to the liquid level gauges, as well as what the fever mode button would be.

The body is rectangular in shape, but we can make it more interesting! We tried various edge treatments for the device, mainly keeping it symmetrical. There are 90-degree edges, 45-degree edges, curved and cut edges, etc. Just by adding a different edge to the rectangular shape, the device gains some personality, which is what we want!

The liquid level gauges had different connector pieces added from the gauge to the device, providing more fun silhouettes.

Lastly, the fever mode button had different shapes and layouts. A couple buttons we placed at the top-right, facing the player. I feel like these are the most noticeable for tapping, especially if they light up and start blinking. But we also tried some buttons that would come out of the side of the device, facing to the side. If the device was something that was actually held in your hand, these could be good locations as one of your fingers might actually rest on it. So, a dilemma appears: do we have a front facing button, which is more acceptable as a thing that you would tap, in regards to UI/UX? Or do we do the stylized side button that might not be as apparent, but helps make the device feel more like a real object?

Side Elements


Now, it was time to go crazy with what stuff we could put on the device to make it more interesting.

We added wires, gears and pipes … then tossed even more wires, gears and pipes! The device could become quite bulky with all the stuff we added, but it does help to make the device more unique. Also, again, we could provide these pieces for the player to toggle on and off if we wanted!

Score, Multiplier, and Face


Next up, we switched the placement of the score area and the multiplier area. In most games, we’re used to seeing the score at the top of the screen, so placing the score area at the top of the device makes more sense.

We also tried various treatments for what the score and multiplier area could look like. We added dials, borders and extra elements to these areas to give them more life. The score area is expected to be a rolling number counter, similar to what you would find on a number-based combination lock, mileage counter in older vehicles, etc. It should look mechanical and not digital! This means that as you play the game, the right most number (and the number to the left of it on higher difficulties) might be constantly spinning to the current number it should be. This might be confusing or hard to read, so we’ll need to see what it looks like in-game.

The multiplier area would use a different type of treatment for the numbers. We’re thinking flip-numbers, which could also use a small animation of the number changing. Again, if it is hard to read, we’ll get rid of the animation and just have the number change.

Then there was the face of the device. We cleaned up some of the buttons for this part of the concept so we can see the decorations better. We tried adding etches and designs to the face of the device, on the edges of the buttons, and added a bevel to the hit buttons. The bevel is nice to give the device some extra dimension and feel more real, but the flat buttons also work if they are simply frosted glass that are back-lit.

Materials


The device needs to be made of something! So, we tried a wooden device with metallic elements.

We tossed in sample colors for the liquid level gauges, to get an idea of what everything could look like. We also tried to make there be 2 accent colors for the device, such as silver and gold, or silver and copper. When the device only uses one color for the metallic elements, it does feel like the colored buttons might stand out more, as there is less crazy colors on the screen.

Oh, and we also added a button appearance to the bottom-right gear, to see if that might work out for the fever mode button.

The Hit Buttons


The center of the device has 4 buttons. These are what the player taps while playing. This hit buttons will be various colors and will need to look like they are lit-up. Again, the player needs to always tap a lit-up button. If they tap a non-lit button, the game ends. So, we tossed in some un-lit buttons as well to see what they could look like. The darker the better, so the player has a clear understanding of what buttons to hit and which ones to avoid.

We also colored in the fever mode button on the bottom-right gear to see if that works. We haven’t decided where the button should be, but this would a good time to test having it down there!

We also tossed in some glow reflection on parts of the device to see what that might look like. The original plan for Steampunk Panic was to make the device as a 3D model, and if the buttons glow, we could have that light extend onto the device! But we might go with a 2D version of the device instead, depending on time and resources, as 3D modeling is new for us. But making it 3D with moving pieces would look pretty awesome!

Coming Up


I’ve been doing a lot of work on the server side of the game and will talk about some of this in the future.

Android support is almost wrapped up, leaderboard support is almost done, and our monetization for the game is almost settled.

We’ll need to pick some music for the game and start designing UI elements (the menu, leaderboard screen, dialogs, etc.) that fit the art deco steampunk aesthetic.

I can’t wait to share more of this process with you in the next couple Dev Logs!


Creating Steampunk Panic (Part 4)

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.

Liquid Level Gauges


For the game timer, as well as notating how close the player is to activating the Fever Mode, we wanted to use liquid level gauges. So, we drew up some rough concepts for decoration treatments for the top and bottom of the gauge, different colored liquids … basically an idea of what it could look like:

Slow Mode Effect


On the left side of the device, the player has a timer gauge that starts full, each hitting round, and empties quickly. When the player has the Slow mode activated from the Slow button that pops up, we want to provide visual feedback to let the player know that the Slow mode is active. There will be a color shift on the background image that the device sits on as well as an effect on the gauge itself.

I personally like #1, #2, #3 and #8.

Since the Slow mode slows down the timer instead of locking it in place, most of these effects would cover the gauge too much and make it impossible to know how much time is left. Of course, with the timer going down so quickly (0.75 to 2 seconds), the player might not need to see how much time is left and just know that they can take it a little bit more slowly. Slow mode currently applies a 3x slowdown to the timer.

Fever Mode Effect


Likewise, the right side of the device has a gauge that fills up and can allow the activation of a Fever Mode. So, we tried some concept ideas for what the right side gauge could look like, when Fever Mode is active:

Since the Slow mode has an Cold/Icy theme, we opted for a Hot/Fiery theme for Fever Mode. Again, while Fever Mode is active, this gauge empties and when it is empty, the mode ends. There will also be a color treatment added to the background image that the device rests on.

For these, I prefer #4, #6, #7 and #8. But oh man, dat lens flair tho!

Iteration


With these concepts created, we can put them into the game to see if not being able to read the gauge really is a pain or not. If it isn’t needed, we can stick with a full treatment of the gauge. Otherwise, we will make the effect more transparent where the gauge is, to help with readability.

We could also try placing the effect on the edge of the gauge, or the top and bottom if we need another option.

Lessons Learned


If there are timer bars that the player can see, they shouldn’t be obscured by other UI elements unless the timer is actually disabled. Applying an effect on the bar still needs to let the player read the bar and determine how full it is.

Coming Up


I’ll be doing the work to get this game working on Android next, with all the iOS related features having an Android counterpart.

Also, same as last time, 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!