Skip to main content

PewPew Live released!

PewPew Live was released today on Android!

Let's go over what's new compared to PewPew 2:

  • LAN Multiplayer

Multiplayer is the main difference with PewPew 2, and the reason PewPew Live exists in the first place. The initial plan was to support online multiplayer, but this proved to be very complex. For now, the game will only support LAN.

  • Support for custom levels

Custom levels are another big new thing. Allowing users to create levels will increase the replayability of the game.
I had to choose where on the spectrum would the creation be: should the players be given building blocks that they can remix (low barrier of entry, low variety of levels), or should the players have to directly write code (high barrier of entry, high variety of levels) like I do when creating levels? I chose the latter because that's what I would have liked as a player, it introduces people to programming and tools that lower the barrier of entry can always be built on top.

  • New game modes
  • Unlock-able ships, trails, bullets
  • Improved graphics

There are also numerous under-the-hood improvements.
The original PewPew was started around 2009, at the beginning of the smartphone era. Many assumptions made back then do not make any sense in today's landscape. On top of this, the original game's feature set grew organically without much planning. I took PewPew Live as an opportunity to fix everything, including:

  • Support for high-refresh-rate screens

PewPew Live supports refresh rates higher than 60 fps because the rendering system can interpolate between game states.

  • Abstraction of the rendering API

PewPew 2 was directly using OpenGL. PewPew Live has an abstraction over the rendering API that improves portability. For example, using directly Vulcan should be possible.
Shader-based rendering
Now that shaders are available on almost all mobile devices, PewPew Live can depend on them for animations.

  • Resizable window support

The UI now dynamically adapts to the size of the window.

  • Deterministic replays

I had retrofitted determinism in PewPew 2, but there were some bugs that I never solved. Now the game is designed from the start to be deterministic. This should make it harder to cheat.

  • An overall better game architecture of the game

It gives me more flexibility to do weird things. E.g. you can run multiple instances of the game simultaneously.

  • Editor

In PewPew 1 I was editing SVGs in Adobe Illustrator and exporting them to PewPew. This time around I invested time to make a tailored editor for graphics and level. This should lead to higher quality models and levels.

  • Better collision detection for walls

In PewPew, a single wall was a quadrilateral with a width. This made editing levels painful, and if the wall was too thin compared to the velocity of an entity, collisions would be missed. This time around, the walls are actual lines and collisions can't be missed.

  • Sound synthesizing

In PewPew sound was made of .wav files. In PewPew Live, the sounds are synthesized at runtime. This allows more flexibility in the sounds and takes less space. It does limit the kind of sound effects the game can have, but the upside is that it makes the sound effects more consistent.

Comments

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