Skip to main content

Exponential = dangerous

Note: This post was initially written in 2013, right after the release of Pacifism. For some reason I never published it. It's still relevant today, so here it is seven years later.

In PP2's pacifism mode, you can blow up enemies with bombs. I wanted to encourage people to take risks and not just blow up all the bombs they see, so I decided to give players an incentive to explode large amounts of enemies at the same time. To do that, I crafted a formula that gave players bonuses that exponentially grew along the number of simultaneous kills:

x=number of enemies killed.  f(x)=the bonus for x enemies killed.

I made sure that the exponential grew slowly: even if a player managed to be twice as good as me and destroy twice as many enemies as me (200), they would only make around 55000 points, which is high but not absurdly so.
Once I was pleased with the feeling of the game, I released it and waited for the scores to come in.
As the high scores started coming in, I got to see the replays of people playing the game mode for the very first time and figuring out how to play. That was really cool.
Quickly though, you could see in the replays the players getting better and better. 

And eventually, some players realized that by using the fastest ship, you could simply circle around the level dodging the bombs for a minute with the enemies never catching up with you. When they did blow a bomb, several hundreds enemies would explode resulting in bonuses of hundred of millions of points.


Eventually what had to happen happened, and people started scoring more than 2 billion points, which is a bad thing when you store your scores in 32 bit signed integers.

The lessons I learned:
  • Use 64 bit integers for scores.
  • Put a cap to exponential scores, or at least be very careful. You never know what the player are going to.
  • Be ready to reset the scores and prevent people with old version of the game to send "bad" scores.
  • Replays are so useful, it's ridiculous. Without them, I would have had no idea what the players were doing, and I probably would have assumed they were cheating and sending fake scores.
Labels:

Comments

  1. BoomSeptember 25, 2021 at 3:22 AM

    In the original pewpew asteroids game over half the topb50 scores are fake ...videos end early with low score but high score entered

    ReplyDelete

Post a Comment

Popular posts from this blog

PewPew Live's look in a nutshell

Occasionally someone will asked how I obtained the PPL look. In a nutshell: Draw everything with lines, including the text and the various icons. It's a lot of work, but besides looking unique it creates a consistent appearance which is a thing that a lot of indie games struggle with. The lines are screen-space projected lines with miter joins. Draw the lines with additive rendering. This means that if a red and green line overlap, the overlap will be yellow. There are a few things not drawn with additive rendering (like the background of buttons to improve readability), but they are exceptions. Add bloom. There's lots of different bloom implementations. Nowadays I use a bloom that is similarly to the one in  blender's eevee . If you see banding, use dithering. Optional: Add even more post-processing like (very slight) chromatic aberration, lens dirt, scan lines, curved monitor, and vignette. No post-processing, just lines Bloom! Ignore the missing bloom at the top All the...
Post a Comment
Read more

A general state rollback technique for C++

I wanted to write this post for a while. It describes a C++ technique to implement rollback in the context of multiplayer games that I feel is quite interesting and useful. The tl;dr is: don't bother serializing individual objects, just rollback all the memory. Rollback-based multiplayer I've been working on a multiplayer version of PewPew, and for reasons that are outside of the scope of this post, I chose to implement multiplayer with deterministic lockstep and rollback. The basic idea behind rollback-based multiplayer is that the inputs of players are replicated to all the players. Whenever a player receives the inputs of another player, the state of the game is rolled back to the point where the input happened and fast-forwarded back to the present so that the state shown to a player takes into account the inputs of the other players. Because history is being re-computed, some events get undone. For example, it's possible a player saw themselves taking a bonus, but aft...
2 comments
Read more

Ridiculously cheap depth of field effect for lines

I'm working on PewPew's sequel, for which I've revamped the graphics. Instead of drawing lines directly using OpenGL, each individual line segment is made up of two triangles whose vertexes are computed with shaders. Getting lines in 3D space to be properly displayed on a 2D screen is not trivial. In PewPew's sequel I use the screen-space projected lines, a technique very well described in the  Drawing Lines is Hard  post. The upside of drawing the lines yourself is that you are fully in control, which allows you to implement nice things such as joints, perspective, and even simulate depth of field. https://en.wikipedia.org/wiki/Depth_of_field Usually depth of field (DoF) in video games is implemented using a post-processing step that blurs the pixels with an intensity that is a function of the depth of the pixels. When we are rendering lines, we can approximate DoF directly when rendering the lines by having the vertex shader increase the width of lines and r...
1 comment
Read more