Part 9: Total rewrite


This update was  supposed to be all about improving performance by offloading the central processor and calculating the wave formations much more efficiently using the graphics card. 

I did push the heavy lifting to the GPU, but it didn't seem to be that heavy after all as the frame rate only increased marginally. Bummer!

In the process most of the previous code got scrapped, in what is usually referred to among scholars, as a goddamn rewrite.  

All 'n all, a fail? Not necessarily. The upside is that I got a chance to familiarize myself with shaders and some other concepts along the way.

Using Shaders

A shader is a computer program that calculates levels of light, darkness, and color during the rendering of a large number of small triangular surfaces that together make up a complex 3D shapes. My knowledge in shader programming has been limited so the first thing I needed to do was some reading up. The Bevy game engine in particular uses a shader API called WebGPU. 


The "Hello World" equivalent triangle of shader programming

Thankfully Bevy abstracts away much of the nitty gritty when it comes to working with shaders. As an example, developers using a game engine usually don't have to worry too much about how to actually transfer drawing instructions from the main program to the graphics card, an operation that  is quite involved under the hood. Even though working with a higher level API offered by a game engine, shaders introduces novel concepts which can take some time to digest.

Homegrown Physics

As the shader code was being finalized I realized that some bugs had surfaced related to the game physics. Things were going a bit haywire, which is not uncommon when working with physics in computer games. I get a feeling that mitigating things going out of control is an all too big part of working with a physics engine. 

Pirate Sea Jam had thus far been leveraging upon one of the more popular physics engines available for Bevy called Rapier. But as I was experiencing some bugs, browsing around for alternatives became something I spend time on. 

An interesting up and coming game engine called XPBD written by Joona Aalto came up on my radar and I decided to have a go at replacing Rapier with XPBD. 

Paving the Road for Online Multi-playing

Online multiplayer and the concepts of rollback networking and client prediction also surfaced as I was looking up physics programming. A great example of what caught my attention is Chris Biscardi's video "I failed to build multiplayer pong in Rust".  I will get back to rollback networking in a future post, but one key takeaway when building online multiplayer games is the importance of having a well behaved and predictable physics engine.

Unfortunately I also had some issues with XPBD, which is not extraordinary considering that the project is still young. To remove as many moving parts as possible and to facilitate online multi-playing I decided to remove the use of a complex physics engine all together and use something much simpler and homegrown. I went down the path of the excellent tutorial "Extreme Bevy" by Johan Helsing, and implemented my own extremely simple physics together with adding multiplayer capabilities in the background.

The result is a ship that kind of travels like a car on an bumpy moving terrain, and less rocking back and forth. Even thought the physics are more artificial now, it is not necessarily just bad. I find the game feel and the controls to be more snappy and direct. Have a go and try out the updated version of Pirate Sea Jam online for yourself. 

During the ins and outs that lead up to this latest release I also learned some new lingo. Apparently the last couple of weeks I've been "Yak shaving".


Illustration by David Revoy depicting the action of completing seemingly endless series of small tasks that have to be finished before the next step in a project can move forward.

Next up

A result of the rewrite is that I still haven't added all the previous working feature, more specifically mobile friendly controls and shooting. But to not delay this update even further I decided to make a release with what is working at the moment. 

Moving forward and adding cannon balls will actually require some more thought to physics (and collision detection), so that projectiles fly in nice trajectories and are able to smash into enemy ships.

Ship ahoy!

Get Pirate Sea Jam

Comments

Log in with itch.io to leave a comment.

Seen this game a long time ago and circling back now for the updates. I am tinkering with the idea of doing something with pirate/boat simulation gameplay. Loved the blog post and going to try to keep up with the progress. I tried the demo on the web version and I can not get the boat to move forward. I jumped into the github to look at the inputs and I believe it was set to spacebar or enter but neither is working for me. I haven't downloaded the standalone version for security reasons, so maybe this is just an issue with the web version?

This is an very good point. Actually the boat is moving forward, but since there are no points of reference (except the waves going in all crazy directions at the moment) and the fact that camera is moving along with the ship, it looks like the boat is at a stand still :-/ (I haven't re-implemented the space bar boost yet)

I will try to come up with ways to mitigate this problem. A few ideas are foam trailing the ship, other vessels, shooting targets, and islands. Other ideas that make it look like the ship is actually sailing are welcome :)

And I'm glad you liked the blog post. Thanks!