Welcome to our fourth monthly Developer Journal. Each month we take a moment to talk with you about the development process and progress from the past month, while also highlighting contributions from the Ahoy community.
This month is a slightly less visually stimulating one, but important none the less! Optimisation is not an overly exciting subject to cover. However, as we continue to progress towards a playable version of the Port Royal Experience, it is a hugely important step. Whether it’s spending time reassessing previous decisions, fixing up old mistakes or generally just trying things until they work better (very scientific, I know).
For Port Royal, the main challenge for optimisation is the density of content we’re including. When you consider that the town includes some 300 buildings (some of which covering about half the size of a football pitch), its no wonder that we’re starting to see some frame rate complaints. That doesn’t even begin to touch on the amount of foliage or the interiors of some buildings being littered with objects. We’re not even dropping in hundreds of NPC citizens yet either.
So something has to be done – and regularly! One of the first challenges is figuring out why things are slow.
One of the more obvious areas for optimisation is foliage. We’re making use of two very new bits of tech in Unreal Engine 5 (Nanite Virtualized Geometry and Virtual Shadow Maps). These are incredible tools to allow us to reach new levels of mesh detail and quantity but they come at a cost when used for foliage.
Put simply, foliage isn’t great unless it moves with the wind. Static foliage can be used in some cases (usually ground-level cover which doesn’t see much wind anyway), but large trees and bushes really do need some motion to feel alive. One drawback of the combination of Nanite and VSMs is that meshes that are getting distorted or deformed at runtime incur huge costs in performance. However, the catch here is that NOT using these features only for foliage actually costs us more.
While Nanite thrives with dense meshes, generally the advice is to make as much of your scene Nanite as possible. For us, that includes everything except translucent surfaces (glass, water), the underlying terrain and the sky. These outliers are largely omitted from being Nanite due to limitations of Nanite itself. Nanite currently doesn’t support translucent surfaces, and while terrain can certainly be Nanite there are a number of features in Unreal’s terrain system which do not work if Nanite is enabled (namely, you can’t paint the terrain to represent different surfaces). As for the sky – It’s made up of volumetric clouds and a very very distant sky sphere, neither of which cast true shadows, doesn’t really benefit from being Nanite and isn’t considered by the VSM system either.
Another area that is rather simple to optimise at first is texture sizes. Generally when creating textures for games, artists create these textures at large resolutions (4096×4096 or 8192×8192 pixels) because it’s great to have an original file which has the highest possible quality should you ever need to increase the texture quality in some future update. Though once imported into a game engine, anything above 4096×4096 in resolution is essentially never used, and even textures that big are often way larger than they need to be for the area on screen they take up.
So a quick way to reduce the amount of texture memory required in a scene is to select folders worth of textures at a time and nock them down a few pegs. A texture only seen in the distance can probably be 512×512, perhaps a terrain texture from first person eye-height only needs to be 2048×2048. Each step down reduces the texture file size to a quarter of it’s previous size and often you can’t tell the difference at all.
The more frustrating part of optimisation is when you’ve tried the above and yet something still isn’t quite right.
Port Royal was running at a measly 15 frames per second at the start of this month. Try as we might with the above optimisations, nothing seemed to have a significant enough impact on performance and it was becoming desperate. During a long-running project like Port Royal, the work area becomes untidy. Folders that were once well organised in the scene are now rarely used for their correct purpose (or at all), and generally the focus is on progress rather than organisation. Even with the best intentions, this sort of thing happens throughout any large project and it requires significant effort to avoid (or revisit and organise again).
Port Royal had grown messy. There was very little order to the scene list and it made it a nightmare to quickly test for possible performance reductions. So, over the course of several days the scene was reorganised into the correct folder structure once more and it became a lot easier to show/hide different elements at once and see what impact they were having on performance.
The obvious culprits were there as expected. The dense foliage outside of Port Royal is costing us about 20 frames per second. It was expected, and certainly on the to-do list to fix next. Decals (projected textures for extra detail, similar in concept to those spray decals in the old Source Engine games) cost us 5 or so frames, another potential saving. Candles cost a frame… Something to think about if we’re getting desperate perhaps.
But beds. Beds? Beds cost us between 20-40 frames per second depending on where you were in the town. Ridiculous, right? Completely unexpected, and something you’d never guess in a million years from just flying around the scene. It turns out that the method we used a while ago to randomise the bedsheet and pillow combinations to add variety to the scene was causing a massive CPU bottleneck.
A few small changes, and we’re now from a rather terrible 15fps, to anywhere between 40-70fps depending on whether or not that pesky dense foliage is in view or not. Needless to say, Tyler got a good nights sleep after figuring that one out. Which is rather ironic really, considering it was beds keeping us all awake before!
Anyway, thank you for following along with that rather verbose explanation of the past month’s somewhat boring optimisation pass. We’ve got plenty more to do in that area, but it’s pleasing to see that some of the performance concerns that had plagued us for the last few months were not a result of the artistic decisions we took, but rather the easily made (and corrected) mistakes along the way.
Outside of optimisation, work has continued in a few areas on the art side of things too!
Our master shipwright Loïc has spent a good amount of time re-importing our ship Veloce (based on HMS Speedy) into Unreal Engine. Our previous method of importing ships proved problematic (creating a large number of superfluous materials to control texture scaling across multiple surfaces), and this new method massively simplifies the experience of working with these ships going forward (and also brings a nice performance benefit as well).
Along with this was the opportunity to add additional detail to Veloce using the objects created for Port Royal over the months. It’s great to see the ship full of the tools and belongings so important to a sailor’s everyday life.
Maxime has been exploring a more detailed representation of the flintlock mechanism. Understanding the mechanics of these weapons really helps to build a foundation for the rest of the firearms experience, and we feel being able to show these details in gunsmiths and other opportunities could be a fantastic addition to the project.
Mihai has also completed one of many planned pistols. Here you can see an exploration of materials which we hope will add an additional layer of realism to the first person experience.
Adam has been continuing to improve the foliage quality around Port Royal. Many of the trees were replaced last month, but more plants are being replaced to achieve a higher quality of wind animation (among other benefits). Take a look at these new banana plants:
We will also be joined by a Lighting Artist over the next months who will work with the team to completely revamp the lighting of Port Royal’s exterior and interior spaces, as well as prepare various lighting scenarios for times of day and weather conditions.
Additionally, we’ve been looking into getting civilian clothing, makeup and hairstyles together to populate Port Royal in future. These are very work in progress (note the hair not fitting the head correctly, and the face shape and texture lacking significant detail, using a very slightly modified masculine facial structure in our earliest of tests), but we hope they show the direction we’re planning to go to show the fashion of the time as accurately as possible.
As mentioned at the top of this months update, this journal is perhaps not as representative of significant progress as previous or future months might be. However, we feel that sharing the less exciting parts of development is just as important! If we are to succeed in building a transparent development environment and a community that understands what goes into the process of making games, it is vital that we don’t solely focus on the flashy images.
Over the next month, our efforts will continue to be on optimisation. The aim is to reach a solid 60 frames per second on our development hardware, and then take steps to tweak settings based on mid-range and lower hardware specifications. Work will commence on the relighting of Port Royal, and we’ll also start to see more sounds introduced to the town and surrounding environment as well.
In the background, work will continue on the underlying systems that will support the release of the Port Royal Experience, such as a comprehensive settings menu (to better allow you to tweak graphical settings for the best performance), the necessary networking to allow you to connect and explore the town together, as well as the introduction of the Ahoy characters and mocap animation, which we hope will bring a huge momentum to gameplay development.
This month’s community mention is a look forward, rather than a particular call-out. We want to thank everyone who answered the call for musicians who might be interested in recording sections of music on their own instruments as part of the future Ahoy soundtrack.
Our composers, Jens and Nico, will be working through the many applicants and figuring out the next steps for recording. As music is still very much in the discovery phase, we’re happy to accept additional applications for musicians with particularly appropriate instruments. You can read the announcement for more details on the Ahoy Discord server:
Check out the message on the Discord server.
Finally, last week we discussed a slight change to Journal scheduling going forward. From next month onwards, Journals will be shared on the first Friday of each month for Contributors, and the second Friday of each month for the public.
This is in an attempt to reduce the amount of time the team needs to spend preparing content for these updates on weekends. With a schedule fixed to the 1st/8th day of the month, this can sometimes fall on Saturday to Monday which makes it more difficult for the team to collect content together and for Tyler to write and prepare the updates for release. We hope that a change from a numerical schedule to Fridays will remove this issue and likely reduce the chance of future months being delayed because of other weekend commitments.
As such, the next Journal update will be live on Friday 4th August for Contributors, and Friday 11th August for the public.
We hope this decision isn’t an incontinence!
Our Journal updates are often discussed at length in the official Ahoy Discord server. Whether you have questions about the topics covered in this update, or you would like to leave your own feedback or suggestions, please join our Discord server to discuss!
Join the Discord