By Gamedevs, for Gamedevs

Notes for Developers – Math Smashers

Note: The following was written in regards to version 1.0 of Math Smashers

 

Everything has a “pace” or “rhythm” to it. Whether it’s the way you walk or the speed of the music you listen to, everything goes at a different rate. Every game has a pacing to it as well. A fast paced game, whether it’s a racing game or a twitch shooter, will get your heart racing and make you sit up in your seat. Meanwhile, slower paced games like puzzle games will make you lie back, breath, and think. Understanding how your game is paced is an important step in understanding how to design your game to give your players the best experience possible. Lately I’ve been looking at the game Math Smashers. Here is an example of an otherwise enjoyable game that is brought down by a shaky sense of pace.

Math Smashers is a simple game where you’re a little guy who has to shoot a grappling hook at little number balls to add them together. You want to add the correct balls together to get a total displayed at the top of the screen. In the meantime, you have to dodge the other number balls as they fly around. On paper, the game sounds active and thrilling. The game title has got the violent verb “Smash” in there. The main actions in the game are shooting and dodging. Unfortunately, the game does not live up to this image. On the contrary, it is almost jarringly slow.

Movement

 

One of the first things I noticed when playing Math Smashers was the movement. Both the player and the number circles move with all the urgency of leaves drifting on a still pond. It takes several seconds for the player to move from one side of the screen to the other. Meanwhile the math balls drift around at an even slower pace than that. If the game was meant to be a more contemplative experience, that’s fine. If the player was meant to sit back, breath, and take everything in, the slow objects make sense. But the addition of coins leads me to think this wasn’t the developer’s goal.

When two balls are added together to match the target number, they drop a coin. You then have to walk over the coin to pick it up, often across a significant portion of the screen. I think in my time with the game, I spent more time walking to collect coins than I did trying to dodge any of the math balls.

 

It’s not as if there isn’t potential for enjoyable action gameplay here. I can tell that dodging between the balls could potentially be really exciting and fun. But unfortunately, right now it’s just too slow to capture that feeling. Instead of feeling like you’re dodging out of the way of an oncoming car, it’s like dodging out of the way of an oncoming snail.

 

If I was making this game, the first improvement is simple: Increase the speed of your objects. I would probably start by making everything 1.5 or 2 times faster. Then I’d tweak from there until I found a balance between fast and easy to control.

 

Shooting

 

Juice Up Your Effects

The second big issue in Math Smashers is the feel of shooting stuff. My first concern is that shooting balls and smashing balls together feels anemic. This is less of a “game design” thing and more of a visual/audio thing, so I’m not going to harp on it too much, but the main issue here is the feedback the player gets for performing any action. The main actions of the game, shooting balls and smashing balls together, has so little fanfare attached to it that it lacks any impact whatsoever. All these actions have is a wimpy sound effect that would be better suited to collecting coins or powerups. But these are hardcore actions that require hardcore effects if you really want to leave an impression. That means screen shake, base-y sound effects, maybe some gravel or dust coming up when you smash some balls together. It doesn’t have to be very pronounced, considering this game seems to go for a lighter, fluffier feel. But having pretty much nothing here does not feel very good at all.

 

Get Your Animations Out of The Way

Now as for the game design problems with shooting. These are much easier for me to express and should be fairly straightforward to fix.  First of all, when two math balls smash together and hit the correct total, they turn into a coin. When turning into a coin, the math balls go through a lengthy transition animation. There’s about a second of wait time between getting the balls together and being able to grab the coin. Once again, this is a problem of speed.

 

Sitting and waiting for the balls to turn into coins is an exacerbating experience. It feels like sitting at a stop light, waiting for it to change so I could continue playing the game. The coin creating animation is going to be played a lot over the course of a single playthrough. As a result, it shouldn’t get in the way of a player’s ability to play the game. It’s like if Mario forced you to wait between hitting a block and getting a coin out of it. Speed it up. Get it out of the way. Your game will feel much better to play afterwards.

 

Let The Player Shoot Their Gun

Secondly, Math Smashers has a big problem with not letting the player shoot enough. In a game about shooting two things to smash them together, Math Smashers decides to force the player to wait until one object is hit before they can fire at the next one. This might be fine in some other games, but this is a game where the player often fires with the intention to grab two halves of the equation at a time.

 

Say you have the numbers 8, 4, 2, and 6, and your goal is to pick a pair that adds up to 10. You will immediately reach for 8 and 2 as a pair or 6 and 4 as a pair. But Math Smashers makes you wait. You shoot your gun at 8, and then you have to wait while the (like many other things, slow) projectile travels across the screen to hit your target. While you wait for it to travel across the screen, you can move around, but you can’t shoot at the next ball. Once you’ve hit the first ball and fire at the second, you have to once again wait for the projectile to travel across the screen before you can start on the next pair. Except once you hit the second ball, you cannot immediately fire again, you must then wait for the two balls to fly towards eachother until they collide, which also takes too long.

 

The Ideal Gameplay Loop

 

At its core, Math Smashers fails to cut the fat off of its primary gameplay loop. Simply speaking, the gameplay loop is the cycle of actions your player takes in your game and repeats until they’re done playing. In Mario, for example, the loop would basically be:

  1. Run Forward Until You See An Obstacle
  2. Jump On or Over the Obstacle

That is a minor simplification due to the existence of things like powerups and coins, but it gets across the general idea. The Loop is meant to be simple and it is the absolute central point of your game. The actions in your gameplay loop are the things your player will be doing the most of, and as a result, they’re the things you should spend the most time polishing. When we apply this concept to Math Smashers, we find our ideal gameplay loop looks something like this:

  1. Shoot at the first ball
  2. Shoot at the second ball
  3. Collect the coin

This is a mostly complete loop with the notable exception of dodging, which would fit in there in a branch sort of position that doesn’t really read well in text. Just keep in mind that the player should also be dodging regularly in a game like this and that should be given the focus of a core action.

 

The Actual Gameplay Loop

Now, the gameplay loop listed above is very clean, understandable, easy to pick up, and generally a solid base idea for a game. If this was the implementation in Math Smashers, this game would be leagues better. Unfortunately, when you take into account the numerous issues I’ve listed with this game, you’ll see the actual gameplay loop has a lot of problems and you’ll understand why the game’s execution is lacking:

  1. Shoot at the first ball
  2. Wait for the bullet to hit the first ball
  3. Shoot at the second ball
  4. Wait for the bullet to hit the second ball
  5. Wait for the two balls to fly across the screen to eachother
  6. Wait for the two balls to turn into a coin
  7. Wait for the character to walk across the screen to collect the coin
  8. Collect the coin

 

When you look at things in the context of that gameplay loop, it’s easy to understand why the game feels so slow. There is more waiting than there is gameplay in a certain sense. When people play your game, the player wants to play the fun parts of the game. They don’t want to spend time looking at irrelevant animations or walking. Unfortunately, it’s all too common to see developers putting too much fluff in the way.

 

In a world where Math Smashers moves at a faster pace, all of these problems vanish and the game goes from being okay to being truly engaging. That’s not to say it is bad in its current state, in fact I found it quite enjoyable. If I were made to play this game back in my school days, it would probably be one of the high points of my day. That said, I’d never seek out this game on my own time. It is important that educational games be both educational and enjoyable. In its current state, Math Smashers meets the first criteria but barely scrapes by on the second. With proper time and care given to tightening the game loop, however, Math Smashers can become a game that players keep coming back to.

 

Other Notes

 

In writing these articles, I find there are some problems that don’t fit particularly well in any larger category. Here are a few minor changes that don’t fit in other parts of the article, but still would improve the game.

  • The coins go from flashing to disappearing way too quickly. The first time I noticed the coins were going to blink out, I barely had time to react before they were gone. If the coins start flashing earlier in their life cycle, players will have an easier time reacting to the game.
  • Don’t force your player to figure out when they’ve screwed up the numbers. If they reach a point where they can no longer get the correct numbers from the remaining balls, the game should just say so and give a game over. It’s frustrating second-guessing yourself on whether or not you’ve ruined the level, and it’s demoralizing to make a voluntary mistake when you realize you’re in a no-win state. This is probably hard to implement, but it would be for the best if the game knew when the player has lost and told them so.
  • The coins jumping into the money counter in the end screen is satisfying, but it can be too long. It should start and finish quicker so as not to overstay its welcome.
  • Allowing balls to overlap with each other creates numerous problems. It hides the numbers from the player, forces them to wait even more for the balls to cross so they can shoot the correct one, and it removes some of the weight from the balls. I think Ludoscience should seriously consider making the balls bounce off of one another instead of overlapping.
  • The teleporter character’s control scheme can be finnicky on mouse and keyboard. Sometimes I would move when I meant to shoot and end up dead because of it. I would rework the control scheme on this character. Find a way for the player to deliberately choose whether they want to move or shoot.