It’s bloody brilliant this week, with our hotties showing off their blockbuster bloodsucking skills as they take to the screens as vampires. Gather some sharp fangs and red juice to thicken the plot and give our sexy suck buddies a bit of oomph to carry out their roles suckcessfully!!
Event Details -Brand new Unlock Animation with Amber -New sexy threads for Giselle and Candy -Vampire collection with 3 events themed costumes -Collect Mysterious Drinks in America (north and south) and Fangs outside of America -Play the event mission to get more event items (opens after the first level up, only once) The Event goes until the 13th of October at 7AM UTC
As we get closer to the end of a project like Mask of the Rose, we shift our focus from making new things to improving the quality of what’s already present. Some of that takes the form of subjective polish; for example, tweaking a character’s art a little to make them more expressive (or dreamy 😉). On the writing side, we might make changes such as altering the pacing of the game in response to a playtest.
However, a large (perhaps larger, by time spent) aspect of quality is less subjective; bugs! QA is particularly important when it comes to getting to grips with this latter category. During a project we test work continuously, typically performing testing of each new feature or chunk of writing, along with periodic regression testing (playing through the game to check if anything has broken). Normally some of the issues detected during development can be deferred (i.e. don’t have to be solved immediately) because they are dependent on other features that will be done later or because some functionality is intended as a placeholder. We still record everything, because we don’t want bugs to slip through the net; but later on in the project is when programmers tend to focus more and more on eliminating bugs, and spend less time on new features.
In Mask of the Rose, for example, all of our planned feature programming is complete. For example; all the UIs are in place; the game save system is implemented; and an audio system manages sounds and music.
That does not mean the work is over! For the last couple of months our core Mask programmer, Séamus has been working closely with Lesleyann, our Principal QA Tester, to tackle bugs and improve performance. In fact, their work has been centred on a very specific purpose; Mask is the first Failbetter game that will launch simultaneously on PC/Mac and console (Switch).
It’s been important for us from early on in this project to always maintain a working build of the game for the Switch. There are a few reasons for this.
The Switch, being effectively a mobile platform, acts as a hardware baseline; even the more modestly specced PCs and Macs that Mask targets have more usable memory, hard drive capacity and CPU power than the Switch. This next point is oversimplified, but in essence; if we can get Mask running well on Switch, Mask will also run well on lower-end desktops and laptops. Therefore it “keeps us honest” about how complex features like graphical elements can be.
It also keeps us honest with regard to gamepad support. Historically, Failbetter titles have been primarily developed for mouse and keyboard control, with gamepad support either added later or not given the same level of focus. In Sunless Skies, we weren’t happy with how gamepad support turned out in the initial PC release, so when we set out to publish our own console ports (also a first for us) we were keen to take the improvements from console and make sure they made it back to PC and Mac in the Sovereign Edition. However, because we hadn’t given gamepads equal weighting from the start of Sunless Skies, there were technical compromises we did have to make to give gamepad and console players a better experience. In Mask, maintaining a build on Switch forces us to focus on the quality of both the gamepad and the M+KB experience.
A final reason to build on Switch early is because shipping a game on console is a unique challenge. Platform holders have extensive lists of technical requirements that games must fulfil. For example, most consoles limit the frequency to which we can write to the storage memory, to prevent physical wear to the drives. Another requirement might be to only use specific, authorised terminology to refer to the console’s controllers.
Before we can release the game we must check that it is compliant with these requirements, fix any issues, test everything, and then submit builds to the platform holder to perform their own testing. That means the release process on console must start earlier than on PC, and this is what Les and Séamus have been focusing on recently; getting to the point we can submit a build to Nintendo that gets the famous “Seal of Quality” from them!
Our other area of increased QA focus is writing. Here, also, Mask presents new challenges. In previous Failbetter titles, writing was very modular. In Sunless Skies, for example, a story can be tested as a stand-alone unit. This is because the player has lots of discrete, self-contained experiences as they visit different ports across the High-Wilderness. Stories tend to only act on each other indirectly; such as via the resource economy, or the completion state of an earlier story. It is also quite unlikely for a writer to accidentally trap the player in a dead end. Because of these properties, we know that bugs introduced by adding a new story will normally be confined to that one story, and the states of the playthrough that could affect the story are less numerous, making testing simpler.
But if Sunless Skies is like a short story collection, then Mask of the Rose is closer to a novel; every character and storyline is interwoven. Mask is also the first time we have used the Ink scripting language instead of our in-house content management system. The Ink script in Mask is fiendishly complex, reactive and programmatic; this is the most player-responsive title we’ve ever made.
Furthermore, with no way to “escape” faulty content (think about how you can simply leave a port in Skies if a desired option is unavailable), we have to work hard to spot the type of critical writing bug that can cause the game to “dead end”.
This has meant that we’ve had to rethink how we perform narrative testing, and are deploying automated narrative testing for the first time. Séamus has developed a tool that allows the writer to run a piece of content thousands of times outside the game engine before it’s integrated. This acts as a first line of defence against the dreaded dead ends, because we can tell if one of our randomised, automated runs gets stuck on a particular version of the script.
A graph illustrating the player’s routes through Mask of the Rose (simplified)
This approach isn’t bulletproof, because there can be differences between how the testing tool behaves and how the game engine behaves; there are often serious bugs at the interface between tech and writing. A purely stochastic tool will also make arbitrary decisions, which result in many runs that represent an atypical player experience. To bolster our approach we’re also performing extensive manual, in-game testing, and are working on a few ways to extend the capabilities of our autotest tool; for example, to allow writers to specify different “player profiles” that make the computer player focus on certain human-like behaviours such as pursuing a particular romance option.
Every game comes with its own set of challenges for the developers, not least in QA. However it’s easy to overlook this discipline from the outside, because QA work is invisible until something goes wrong. I hope this blog gave you a little peek under the mask! Thank you for coming on this journey with us as we extend the capabilities of our studio to tell a very different tale to the stories we’ve told before.
It's been a chaotic release for us, due to various bugs, performance issues and balance problems. We've already taken care of some of it and I do still have quite a list of bugs ahead but I can only fix them one at a time. That being said, we have one (hopefully) final patch regarding The Great Forge coming in the next few days. It will fix Performance issues for the most intensive builds such as Ray of Obliteration + Arcane Clones or any build using Vindictive Slam, along with the vast majority of bugs and issues regarding Runes.
On a positive note, we're pretty happy with The Great Forge. And from what we've seen from our Discord, players seem to be having fun building massive War Chests, which is nice.
Once the final Great Forge patch has been released, we will be able to move on to new horizons.
The New Roadmap
Now feels like a good time to release the new Roadmap. Nothing has been added or removed from the old one, this is basically us taking a fresh start in our Early Access.
With this new Roadmap also comes the intention of deploying Updates much more often, even if it means releasing less content at a time.
I have to say that working for 5 months on the last update has been pretty hard. Despite the amount of content that was added, we've made almost no progress on the roadmap itself and it feels bad. So right now, we want to go for the exact opposite: Making smaller yet impactful updates, and ticking things off the Roadmap.
And after so much time working on the same thing, we're super excited to work on new content.
Now Behold!
This new Milestones / Features gives us a bit more freedom regarding what we add and when we add it. The Milestones row is what we plan to follow, meaning that the next update is "The Luxuriant Update I", while the Features row is what we plan to add at any given point in-between updates.
We are also done with adding new layers of customization or new mechanics for a while. Our goal is to focus on what we currently have and work on it. This means reworking what needs to be reworked and grow on existing layers such as adding Environments, Enemies, Slorm Reapers, Ancestral Skills and Legendary Items.
We actually plan on finishing all these layers before even considering adding something entirely new. As for the last 2 endgame modes mentioned in the Road Map, both are based on existing mechanics that simply needs to be polished and fleshed out.
In the near future, for the next 5 to 6 months, it should all be about building content for what we already have. This usually requires very little brainstorm or tests, which was the most time-consuming thing for our Slorm Temple and Great Forge updates.
The Luxuriant Update I
Half our team (so 1 person) is already working full time on the new update, while I'm still here fixing bugs, writing devlogs and stuff. And while we have nothing absolutely new to offer, here are a few (fairly old) screenshots of what's coming: The Luxurious Gardens.
Added: [Onboarding] What's new panel to improve new features discoverability [Onboarding] Rename old Welcome to "Home screen" [UI] Resolve scaling issues for high-DPI screens [UI] Avoid persistent error messages in the UI [UI] Rework save menu [UI] Save and Export/Share UI layouts Add copy/paste actions for blending modes/opacity of a layer Apply blending mode/opacity to all channels of a layer Reload mesh with a keyboard shortcut (CTRL+SHIFT+R) Reset Substance parameters to default Reset paint brush to default Right click to reset individual Substance parameters to default [Assets panel] "Pin" favorite assets to appear on top of asset panel [Assets panel] Delete, reload and rename assets [Color Selection] Add blending modes to Color Selection effect [Layer Stack] Add blending mode and opacity on filters [Layer stack] Allow tiling values bigger than 128 for fill layer/effects [Layer stack] Cylinder caps for cylindrical projection in fill layer/effect [Log] Show an error message if mesh part are in negative space when trying to create a UV Tile project [Project] Indicate version in error message "data too recent" when opening a project [Viewport] Allow to light the mesh from underneath [Viewport] View R, G, B and Alpha in viewport (solo display mode) [Shader] Allow to set User channels as RGBA in Material Layering shaders [Export] Allow to export textures as SBSAR [Export] Expose 16bit option for EXR file format [Python] Add event to know when Texture Sets are modified [Python] Allow to get and set Mesh Map resources in Texture Set settings [Plugins] Remove option to get other JS plugins [Content] Add new Roblox template and export preset Update Substance Engine to last version (8.6.3) Optimized build for Apple Silicon chipset (Apple M1 / M2)
Fixed: Crash when using 16k exr [Crash] Ctrl Z After deleting a shader instance [Iray] IoR is blocked to 1 for some shaders [Win][Baking] Some high poly fail to load [Color Management] Incorrect color space name in UI with filters [Python] Resource objects returned by import function don't have a type
Known issues: [Color Management] HDR color space conversions with ACE on Linux produce clamped colors [Layer Stack] Input source not saved per layer [Painting] Temporal anti aliasing causes artifacts when painting in some cases [Export] 2DView exports randomly uniform map
Her Name Was Fire is releasing on October 11th - which is only 5 days away! The full version will contain new cards, card levels, play modes, enemies and bosses.
One of the new bosses you will find is The Tower:
The demo will be available until October 10th (full day), until the full game releases on the 11th.
The supported languages will include:
English
Spanish
Catalan
French
Portuguese - Brazil
Japanese
Simplified Chinese
If you want to get all the updates about Her Name Was Fire before its launch, you can follow and wishlist the game!
It's been a while we have not posted any news here! If you want to know a bit more on the reasons why, I recommand you check the post I made on the forums a month ago
But now it's time to rejoice, because as Snowtopia is getting close to it's full release, we are opening a beta for you to help us with the final verifications!
As said in the forum post mentioned before, because of the difficulties we had with this project, our time on it is limited. That's why we unfortunately won't be able to add any feature anymore. However, while we tested it, we still are limited in term of different computer configurations, and this beta is here to be sure that it's running well on different computers. Also, there might be some major issues that we missed, and we want to correct them before the full launch, should there be any.
To access the open beta, simply go to your library, right click on Snowtopia and select "Properties". Then, click on the "Betas" tab, and select the "Public_beta - v0.16.15 for public beta" branch.
One last thing before you're off to the mountains : I communicated on different places (forums, reviews, discord) something about the full release date. I said that the full release should be between now and the end of year 2022. This still stands as of today, and we should be able to give you a release date soon! So stay tuned!
I wish you all a wonderful day, and to have fun on the crazy slopes you'll create!
- Add dialog importer in dialog editor, now you can import dialogs written in MS World, Google Docs, etc. - Fix a bug that the initial value of a passive skill's multiplier is 1 instead of 0. - Update a tutorial about the game resource cache.