The post A slight change to our update process appeared first on Arkenforge Tabletop.
]]>First of all, the core development loop will remain the same. All new features will go into the Beta version, and once the Beta version is polished, the entire Beta update series will be moved into the Public version all at once. This is a system that we’re quite happy with, and it ensures that all new features come across to the Public version as polished and bug-free as possible.
We will also be continuing with a large number of smaller updates in the Beta version, rather than a small number of large updates. We enjoy releasing new features quickly, and a fast turnaround time on bug fixing is something we are quite proud of.
Some notable issues appeared during our last update cycle. The biggest one is that with such a long beta update series, a lot of bugs appeared in the Public version that we were not able to address. From now on, we will be restructuring our development process to allow us to continue putting out bug fixing patches to the Public version.
On the Beta version front, each Beta update series will now begin with an incremented version number. For the upcoming beta series, this will be v0.5.1.
This change will make it clearer that the Beta version contains new features and functionality. It will also allow us to continue incrementing the public update version without overlapping update numbers with Beta.
We will also be endeavouring to reduce the duration our Beta update series in future. Ideally, we’ll have update series that are only a few months long at the absolute most. This means a tighter update series with a smaller feature set, but also that these features will end up in the Public version faster.
We hope that these changes will lead to an even more stable and feature-rich Toolkit moving forward.
The post A slight change to our update process appeared first on Arkenforge Tabletop.
]]>The post Preparing Dungeondraft Asset Packs for the Arkenforge Toolkit appeared first on Arkenforge Tabletop.
]]>
Allowing content packs to be used in the Arkenforge Toolkit requires setting an option when creating the pack. This option, or ‘flag’, is a variable in the Pack.json file of the Dungeondraft asset pack. This flag tells us whether or not your pack can be used outside of Dungeondraft.
Megasploot, creator of Dungeondraft, has graciously included a flag in the Dungeondraft packs that allows third parties to import content. Without this flag set, your content packs can not be used in Arkenforge.
Allowing your packs to be imported into Arkenforge is a very simple process. All it requires is is setting the ‘allow_3rd_party_mapping_software_to_read’ value in the pack from ‘false’ to ‘true’. That’s all! One simple change, and your existing content packs can be loaded into the Arkenforge Toolkit.
There’s a few ways to do this, depending on how you assemble your content pack.

If you’re using Dungeondraft’s own ‘Package custom assets’ feature, you’ll want to enable the ‘Allow 3rd party mapping software to use this pack’ checkbox.

Any third party Dungeondraft Pack Builder tool should have the same option available. Enabling this option will allow the Arkenforge Toolkit to import your pack.
Pictured here is Ryex’s GoPackager, available at https://github.com/Ryex/Dungeondraft-GoPackager/releases/
If you’re creating your own Pack.json file, you’ll need to include the variable ‘allow_3rd_party_mapping_software_to_read’, and set it to TRUE.
We do our best to ensure that your content matches how it appears in Dungeondraft, while also making them integrate seamlessly with our map building features. Both Dungeondraft and Arkenforge use a 256×256 grid, so your assets should appear at their native size with the Arkenforge Toolkit.
First, we organise your assets into a set folder structure. Then, we set Textures as Tile placement types by default, and walls and paths as Line placement types. We also support recolouring. Any assets in the colorable folder will have their red channel recolourable via our Chroma Key function.
As your assets are treated the same as all other Arkenforge content, users can also use our vast range of map customisation features. This means users can fully recolour your content, not to mention adding animated using our effects system, or lighting and sound effects (and more!).
We care strongly about the rights of artists here at Arkenforge. Some creators have only licensed their content for use in Dungeondraft. That’s a position we 100% respect. For that reason, the Arkenforge Toolkit can only import your packs if you have allowed them to be.
If you have not allowed your pack to be usable in software outside of Dungeondraft, users will see the following message when they try to import it into the Arkenforge Toolkit.

If you have older content packs that pre-date the ability to opt-in to non-Dungeondraft importing, you need not worry. We won’t import those either.

Don’t hesitate to reach out if you have any follow-up questions. You an reach me at [email protected].
I hope that this information has helped to make your Dungeondraft asset packs Arkenforge Toolkit-ready 
The post Preparing Dungeondraft Asset Packs for the Arkenforge Toolkit appeared first on Arkenforge Tabletop.
]]>The post It’s here! The v0.5.0.0 Arkenforge Toolkit is out now appeared first on Arkenforge Tabletop.
]]>After over 2 years of solid development, the day is finally here. We are releasing the Arkenforge Toolkit v0.5.0.0 into the Public stream!
It’s been coming for a long time – 30 months, to be exact.
We’re incredibly proud of this release. We’ve poured so much into the Toolkit, and the end result is something that feels better to use than ever, has a huge range of new features, and has never run smoother.
We want to hear your feedback on this update, so please jump into our Discord and let us know what you think! You can find it at https://discord.gg/Arkenforge
Well, it means that all Arkenforge users are about to have access to over two years of new features, bug fixes and optimisations. And most importantly – the update is free for everyone.
As with all of our previous major public updates, all trials have been reset. This gives everyone another 30 days to check out the new Toolkit.
Now, let’s take a look at just a few of the exciting new features you’ll have access to.
If you’d like to check out the full patch notes – we’ve included them at the end of this article.
One of our most requested features over the years, and something we’re very happy to finally have in the Toolkit. You can now place text directly on the map.
As a bonus – text is treated the same as any other map object, meaning you can add Effects to it!
The Toolkit now features the d20 dice system! The 3D dice can be rolled openly or secretly, and you can roll without the 3D effect to instantly generate your dice results.
We aim to include more dice systems in future updates, as well as important features such as exploding dice. For now though, enjoy your rolling!

You can now add 5e 2014 and 5e 2024 stat blocks to your notes. This should make it much easier to view the information of your monsters and NPCs at a glance.
Determining the outcome of your party’s actions has never been easier! Rollable tables are now a part of the Arkenforge Toolkit.
These tables also allow for weighting by letting you set a range of rolls for each outcome.
Previously, touch control would only reveal fog where the touch occurred. This meant that every touch point would reveal the same vision radius, and other effects could not be added.
Now that you can directly move tokens with touch, each touch point can have completely different vision values.
In previous Arkenforge Toolkit versions, proximity-based ambience would trigger based on the position of the player screen. With this new update, all tokens can have Listeners attached!
Listeners will allow tokens to hear ambience as they approach it, increasing the immersion of your games.
Accessibility and personalisation are important cornerstones of Arkenforge’s design philosophy. In line with these principles, we’ve added several new UI elements to the ‘can be recoloured’ pile.
We always enjoy seeing screenshots with different UI colouring. Don’t hesitate to show off yours!
Many of our users enjoy building maps in the Toolkit for use online. For that reason, we’ve built on our existing map export functionality so that you can match what you get in the Toolkit with your target VTT as closely as possible.
Video export is now significantly improved, allowing for custom sizing and DPI. We’ve added WebM and WebP as export options, alongside an updated FoundryVTT Module exporter.

We’ve reworked every panel and window in the Toolkit to make it much clearer and simpler. Controls are now organised into toggleable sub-headings, so you won’t feel as overwhelmed by the number of options available. Widgets have been moved to the right-hand side, and the number and visibility of them can be fully customised. We’ve also moved the important features down to the taskbar, meaning you’ll spend less time in menus.
We’ve worked hard to get the Toolkit running as smooth as possible. It can now handle even larger maps, even more animations, and even more effects, all while maintaining a minimum of 60FPS.
Even the UI feels snappier to use 
The v0.5.x update series has one central focus – Players. The finer points of what that means is something we’ll announce in the future, but we can guarantee the end goal of the v0.5 update series – a free player app that will connect to the Toolkit.
That’s not to say there won’t be other things in there as well. We have a whole heap of other features and improvements that we’ll be bringing out as we roll out these updates. We’re incredibly excited for what we’ve got coming next, and we can’t wait to show off some amazing new features!
We’ll also be releasing a bunch of content that we’ve got in the wings that required this update before release. Look out for some exciting content releases throughout the year! In the meantime, please enjoy the new public release.
Thank you for sticking with us on this journey.
– The Arkenforge Team
The post It’s here! The v0.5.0.0 Arkenforge Toolkit is out now appeared first on Arkenforge Tabletop.
]]>The post The Dark Fantasy Construction Kit has launched on Kickstarter! appeared first on Arkenforge Tabletop.
]]>

The post The Dark Fantasy Construction Kit has launched on Kickstarter! appeared first on Arkenforge Tabletop.
]]>The post Project Sigil: A Presumptive Farewell appeared first on Arkenforge Tabletop.
]]>As we did with Astral tabletop, we will now offer a eulogy to Project Sigil, a spark that burned out before it could reach its potential.

While rumours had long been circulating that Wizards of the Coast was developing a digital virtual tabletop platform (VTT), commonly known as OneD&D, Project Sigil was officially unveiled at Gencon 2024. It was a 3D VTT prophesied to be the ultimate platform for the new edition of Dungeons and Dragons. A tool intended to bring all D&D players, and through the terms of service, bind them.
The Alpha version launched in September 2024. It released in February 2025 with a limited feature set. The release was met with a lukewarm reception, with many users complaining of bugs and usability problems. This is something that most software deals with, and these are typically ironed out through the alpha and beta process. In extreme cases, such as Cyberpunk 2077 or No Mans Sky, developers can power through and release a product that meets its original promise.
This is not what lay in store for Project Sigil. Instead, it was barely given room to breathe before it was put on life support. Allegedly, it is now being maintained by a skeleton crew before its final send-off.
This quick turnaround from announcement, to release, to cancellation, naturally begs the question. What went wrong?
We will try to explain.

From its inception, Project Sigil has held a curious place in the tabletop landscape. Its niche was incredibly small. Several decisions, both early in development and later in its release cycle held it back.
We’ll cover a selection of them here.
First of all, the target audience. The official announcement in the D&D Direct on August 19, 2024, explicitly calls out Baldur’s Gate 3 players as the intended userbase for the VTT.
Clearly WotC thought they could capitalise on Larian’s monumental success. It seems though, that they attributed the success more towards ‘3D D&D’, and not ‘Incredible storytelling and implementation of game mechanics’. A simple mistake, but one that Wizards tends to make over and over again. We saw this as well with the attempted OGL changes at the start of 2024. The pattern suggests WotC thinks that third party products are successful solely because of D&D, and not that D&D is hugely successful due to the large range of supporting third party products.
The crossover between Baldur’s Gate 3 players and D&D players is likely much lower than one would expect. By attempting to convert these players who had not played a tabletop roleplaying game in the past, they had ignored the millions of folks who already play D&D. It was clear that this product wasn’t for them.
But for those that it was…

This single decision to chase the Baldur’s Gate 3 crowd led to a number of follow-on decisions. The first of these is the requirement for high-fidelity 3D graphics.
In order to actually use this though, users would need a reasonably powerful computer. Let’s have a look at the recommended specs:

This is a solid mid-range PC these days. For those who don’t have one already, this requires an up-front purchase of, conservatively, $1500. Compare this to the recommended specs for a long-running 3D VTT, Talespire.

Had the platform been given time to develop, rounds of optimisation could have brought these requirements down somewhat. Even with these though, there would still be a minimum requirement that is a significant investment for those that already play D&D.
Some reading may point out – DnD Beyond has millions of users. Surely a lot of these would be interested in Project Sigil.
Wizards of the Coast certainly thought so, tying Project Sigil’s subscription to a DnD Beyond account. However, a majority of these users play on mobile, tablet, or Chromebook. None of these devices would be capable of running Project Sigil.
Now, if a D&D Beyond user did have a powerful enough computer, they would run into the next problem.
Building your own maps is a difficult thing, even with tools designed to make it fun and easy. 3D map builders are a different beast entirely. Compared to 2D mapping, which uses a top-down camera, users now need to handle a free-moving perspective camera. The third dimension also adds difficulties in placing content. Having to correctly align objects in 3D space can be a fiddly and time-consuming task, especially when needing to consider different camera angles.
This is why tools such as Dungeon Alchemist have become wildly popular. By including procedural generation, platforms can generate 3D maps quickly from a set of simple parameters. Users can then adjust the maps afterwards to fit their game.

Another issue with 3D map creators is the difficulty of using custom and third party content. There is 50 years of RPG content available, almost exclusively 2D, not to mention hundreds of creators putting out maps on Patreon. All of this content can not be used effectively in a 3D VTT.
In the rare occasions that 3D mapping tools allow for 3D model imports, users need to both create a 3D model and manage UV mapping and texturing. This is a much more complicated task.
And, with a much lower amount of custom content, homebrewing becomes more difficult. Most users who would be building maps would be creating their own custom ones. With only a set number of assets available, the number of different kinds of maps that can users can create is limited.
In all, it’s a choice that raises the barrier of entry to content creation, while lowering the number of content themes available.

Due to design decisions in the way Project Sigil was developed, a subscription would be necessary to keep the platform running. Unlike other locally installed VTTs that are self-hosted, Project Sigil made heavy use of cloud infrastructure. From our analysis of the platform, even maps seem to not be saved locally. Rather, they would be downloaded from the cloud each time you wanted to access them.
In our current climate, this is a rookie mistake. More and more, VTTs are turning away from the subscription model. Consumers are tired of monthly payments, especially as practically every service in their lives are trying to extract as much money from them as possible.
The post-2016 generation of tabletop platforms are largely subscription-free. Platforms such as FoundryVTT have exploded onto the market with a one-time-purchase model. These are much friendlier to consumers, and they don’t risk losing access to their content if life throws unexpected hardship their way.
Admittedly, D&D Beyond already features a large subscription userbase, which, if the previously mentioned problems didn’t exist, would seek to work in their favour. Unfortunately their target market for Project Sigil overlaps very little with their existing D&D Beyond userbase.
During Gen Con, Wizards of the Coast ran a stage game with Project Sigil to show off its capabilities. You can watch the game below:
The cast performed fantastically, putting on an entertaining performance. But the intended star of the show, Project Sigil, came off looking second best. The game came to a stop multiple times as the cast figured out how the software worked. Plus, showing an entire group of players sitting around a table staring at their screens does not evoke the joy and social engagement that tabletop provides.
The demo failed to show off the best parts of the platform, while highlighting how it can negatively impact both the game and the atmosphere.
(P.S. If you are looking to bring digital tools to your table, try out a tool that’s built for it specifically.)
A surprising number of people were not aware the Project Sigil existed. Outside of the D&D Directs, there has been little to no marketing about its release. Here are a couple of comments from /r/dnd


This was not a small indie release. This was supposed to be a flagship product release by the largest company in tabletop gaming. A company as large as WotC has the budget and experience to promote Project Sigil. Such a failure of marketing can only be a deliberate act, or spectacular incompetence.
All of these points worked together to create a lacklustre launch. With all these issues, it is no surprise that Project Sigil failed to find its place in the market. At this point, WotC had two options before it.
Guess which one they chose…

(You can read the original post here.)
Lay-offs in the games industry are common. Especially after the release of a new product. Firing 90% of a development team before a project is feature-complete however, never bodes well.
Industry sources state that there are anywhere from 3-5 developers remaining on the project at most. This number tracks with the 90% figure given in Andy’s post. With a project the size of Project Sigil, this is practically a guarantee that the project is being wound down. The remaining developers will be maintaining the service until it is finally let go. This could occur in a matter of days, or weeks.
We feel for the development team, and hope they find gainful employment. Lay-offs are happening all over the tech industry at the moment, and finding work in a similar area will be difficult.
Many commenters find Project Sigil’s demise hardly surprising, albeit possibly sooner than expected. This is because in life, there are three things of which you can be certain; death, taxes, and Wizards of the Coast failing to create a digital D&D platform.
The most notorious example is their attempt at a D&D4e VTT. Billed as an online subscription-based character management and virtual tabletop tool, it was announced alongside D&D4e at Gen Con 2007. This service did eventually launch with some of the promised character creation, but never reached its full potential. Before that was Master Tools / e-Tools for third edition. These are but a couple of notable entries in WotC’s extremely checkered past of digital products.
For those new to the VTT scene who were excited for Project Sigil, never fear. There are many other VTTs out there that you can use to enhance your gaming experience, depending on how you play and your technical proficiency.
If you’re playing in-person, Arkenforge is the way to go. Built specifically to use while sitting around a table, and your players won’t need to use any screens.
If a 3D VTT is what you’re after, then grab a copy of Talespire. It is a highly competent 3D mapping and playing tool, and was even featured on Dimension 20!
If you’re playing online and have some solid technical know-how, then FoundryVTT is the platform for you. With a single purchase and an incredibly active modding community, it will do just about anything you want it to.
If you still want the single purchase, but want less technical hassle, then give Fantasy Grounds Unity a go. It’s been around for over 20 years at this point, and has thousands of modules ready to download and use.
If you want to run games in a browser, Roll20 and Owlbear Rodeo are both excellent options, however both require subscriptions to get full feature access.
And with that, we conclude the service. Refreshments will be available in the reception, and we will see you in 5 years to commemorate WotC’s next digital toolset.
The post Project Sigil: A Presumptive Farewell appeared first on Arkenforge Tabletop.
]]>The post A Year Of Change, Phase 3 – Audio Changes appeared first on Arkenforge Tabletop.
]]>
Hey folks! Nathan here. It’s a nice and short one today as I’ll walking you through some changes we’ll be making to audio in the Toolkit.
That is – everyone is getting it for free!
That’s right!
All of our music and sound effects from every Arkenforge content pack is being moved into the Arkencore Pack. That’s over 10,000 audio tracks, now available to every user in one massive 3gb update!
As we’ve released more and more audio through our major packs, there’s been one particular nightmare that has kept us awake at night.
Playlists, Ambience Presets and SFX Palettes.
Because our audio content has been bundled into packs until now, we can’t easily build these into audio collections that pull from multiple packs. You may have noticed that we have playlists with names like ‘Battle’, and ‘Battle (Wild)’. There’s no ‘Battle (Towns and Cities)’ because we realised that having the same version of the same playlists in each pack is a bit silly.
Dante in particular has been wanting this problem solved for a while. The Arkencore Pack has provided the best opportunity to do so.
This is also part of why we brought down the price of our content packs in Phase 2. It wouldn’t be right to charge the same price for a pack that now had less in it.
With all of our music and sound effects being in a central location, we can give future packs their own custom playlists and ambiences. These would be curated specifically for the theme of the given pack, and would use the same songs and sound effects that everyone has access to.
This change will also allow users to more easily share their created audio collections without needing to worry about what packs other users have installed. In future, we’d love to see Community Playlists and Community Ambiences sections, as well as Community Maps. With the ability to edit the individual stems of our tracks, I’m personally excited to see what folks come up with!
Phase three of our Year of Change is now done. The Arkencore patch should be available to you already.
Stick around and watch out for our article on Phase 4!
While you wait, check out the Arkenforge Toolkit at https://arkenforge.com
The post A Year Of Change, Phase 3 – Audio Changes appeared first on Arkenforge Tabletop.
]]>The post Arkenforge Devlog – Designing for Accessibility appeared first on Arkenforge Tabletop.
]]>
Hey folks! It’s Disability Pride month, so this month’s devlog is Designing for Accessibility. We’ll be looking at it from a general software lens, so there’s nothing here specific for VTTs.
We’ll be focusing on the things that we currently do, but we’ll also add in a section at the end on future things we’d like to implement.
Let’s learn how we can make our VTTs (and software in general) more accessible!
Arkenforge currently allows UI scaling in 4 discrete increments: 75%, 100%, 125% and 150%.

Providing UI resizing options has two major benefits.
Adding UI resizing options takes some careful design. Sure, you could just add a UI size slider that goes as high as the user would like, but a larger UI without designing for a larger UI can easily make the situation worse. UI elements can overlap, and text can end up off-screen or wrapping to the point of unreadability.
To ensure that everything works well at our largest UI scale, we build all UI at 150%, then downscale from there. It’s significantly easier to downscale a large UI than it is to upscale a small UI. This also lets us see what the largest feasible size for UI is inside the Arkenforge Toolkit, which is why we cap out at 150%. Any larger than that, and you begin to flirt with usability issues.
Right now our UI scaling is uniform. That is, every UI element is scaled by the same amount. In future we’ll be adding in UI scaling on a per-UI basis. This would mean that your widgets could be scaled differently to your Arkenbar, which could be scaled differently to your left-side menu panels. This high level of customisation would improve the experience for our users while allowing for larger UI scaling values.
In order to implement this yourself, you’ll either want to have all of your UI adjust its scale value, or adjust its height and width based on the new scale. We like to do the latter, as it works better with our anchoring.

Recolouring UI elements is another accessibility feature that assists those with vision impairment and colour blindness. By allowing users to recolour elements of your software, you don’t need to worry as much about colour-blind modes. Your users will set their own UI colours to best fit their needs.
That being said, your default colour scheme should be colour-blind friendly to start with. Users shouldn’t have to fight against your default UI to set the colours that they need.
Outside of vision impairment issues, recolouring can help with many flavours of neurodiversity. Being able to set colours for different sections of your software can help users to find things faster, and ultimately use your software more effectively.
Finally, you can’t discount the personalisation element. While not a disability-specific benefit, accessible features aren’t just for those that need them. They ultimately help everyone. We’ve seen screenshots from our users with all kinds of different UI colouring. Giving users the ability to set up their software to look how they want it to helps them feel more attached.
We use an event system to manage UI recolouring that all UI elements are subscribed to. When a colour is changed, all active UI elements are notified, and they update their colour accordingly. This allows for real-time visualisation of the changes while editing, rather than needing to do an ‘Apply now’ button and having the user repeat the entire process again.
About two years ago now, we had a user reach out with the following info (paraphrased): “My daughter has CP. She struggles to hold down left click and drag a mouse.” With most of our software being built on click-and-drag functionality, this was obviously something that needed addressing.
At the time we had the ability to hold down the spacebar to move selected content (and still do!), but this was also not feasible. Holding down any keyboard key for any length of time was something that would cause pain.
We ended up going with an option to set middle click as a simulated left mouse button toggle. To put it simply, clicking the middle mouse button when hovered over a map object or UI element would put it into ‘dragging’ mode. From here, you could move it to wherever you liked, then click the middle mouse button again to drop it. It took a bit of work to implement into our UI code, but as a result, someone can now use the Arkenforge Toolkit without pain.
This one relies on writing your own custom input manager. We do this in Arkenforge to unify input between touch and mouse control for map building, but it also lets us do these kind of accessibility features.
The only part you’ll need to add in is a ‘simulateMouseDown’ bool that flips based on the input of choice (In our case, the middle mouse button). When testing your ‘GetMouseButton’ function, you’ll just need to add in the ‘simulateMouseDown’ value to test as well. If the value is true, then you’re holding down the mouse, and can set up your drag events accordingly. Just make sure that you’re adding a simulated ‘OnMouseDown’ and ‘OnMouseUp’ function as well (depending on the toggle state) when you hit your input, otherwise you end up with a dragging event with no pick up / put down events to go along with it.

OpenDyslexic is a free typeface designed to help with some of the common issues that those with dyslexia face. Being a free typeface, it’s a simple addition that all platforms can implement.
The Arkenforge Toolkit provides a checkbox that allows users to swap all font to OpenDyslexic.
If you’d like to implement this yourself, you can find the typeface at https://opendyslexic.org/.
Arkenforge implements OpenDyslexic in a similar way to its recolouring. All text UI elements in the Arkenforge Toolkit are subscribed to an event that pings when the ‘Use OpenDyslexic’ checkbox value is changed, and update accordingly when the setting is modified.
By allowing users to adjust the speed of a double click, users who aren’t able to click rapidly can more accurately interact with your software. There should be options for this in your user’s operating system settings as well, but adjusting these will adjust the setting for all software on their computer. Providing the option to set this on a per-software basis can allow your users to make the necessary changes in your software without affecting their experience in other software applications.
When managing your input system, have a timer start the moment a mouse button is clicked. If the timer is below the double click time threshold, then a double click has occurred. If it’s over, then it’s another single click.
Make sure your double click event is also looking at the distance the mouse has moved, and that the same button is being pressed when calculating your double click. Adding a small allowable distance that the mouse can travel for a double click to occur can also help those with tremors and other such conditions to interact with your software.
Adjusting the click and drag threshold will change the distance in pixels that a held click with mouse movement becomes a drag.
Users with motor function issues or hand tremors may have trouble with click and drag functionality. For some, the standard value is too low, and they can accidentally drag content when they just want to click. In our software this can lead to placing content in the wrong spot, accidentally creating content links, or accidentally revealing parts of the map.
By allowing users to set the click and drag threshold to a custom value, we can alleviate these issues.
For UI, Unity has this built into its EventSystem class already through the EventSystem.current.pixelDragThreshold variable.
When it comes to scene content however, this does not exist. Therefore we need to add it into our custom input manager. It’s quite an easy one if you’re already detecting content dragging. You just need to do a distance check between the current mouse position and the position that the mouse was first clicked.
Sound effects on your UI are more than just some flashy sounds that respond to input. They can be a helpful tool that provide an extra layer of information to your user. In the Arkenforge Toolkit, we use UI audio in a variety of different ways.
First of all, we provide different kinds of UI audio. Each of these can be toggled on or off depending on what sounds the user wants to hear. The following are offered currently in the Arkenforge Toolkit:
We could certainly add more options, but these ones provide a responsive sound effect for every major function of our software.
Rather than just adding the sound effects in, with a little extra work you can increase the accessibility of your sounds. For example, our slider sound will adjust in pitch depending on the fill percentage. This provides simple responsive feedback that can alert a user as to the state of the slider. To go one step further, you can base the sound’s panning on the element’s screen position. In Arkenforge a UI element on the left side of the screen will be louder in the left channel, and one on the right will be louder in the right channel. This is one that we borrowed from, of all places, Animal Crossing. This provides just that little bit of extra feedback to let a user know where the mouse might be on the screen.
Watch the below example with your eyes closed, and see if you can tell which slider is being updated, and to what value.
We use a singular UISoundManager class with a PlaySFX function that feeds in the sound type, screen x position, pitch, and volume. From here, it selects the correct sound effect and, if that sound type is enabled, play the sound effect at the correct volume as determined by the UI audio volume slider and the volume variable passed into the function. We also use the screen x position for panning the audio. You don’t want to go from a -1 -> 1 with this, as you frequently end up with audio in only one channel. We max out at 75/25, so there’s always some element of audio in one side. It gives enough of a difference that it’s quite noticeable, while still feeling satisfying in both ears.
These are just some of the ways that you can make your platform more accessible. On top of this, here a few additional accessibility features that you could add into your project.
I hope this has been a helpful guide, and that if you’re developing your own software that you’ll implement at least some of the above features.
If you’d like to see them in action, check out our Arkenforge Toolkit at https://arkenforge.com!
The post Arkenforge Devlog – Designing for Accessibility appeared first on Arkenforge Tabletop.
]]>The post Arkenforge Devlog – Content Management appeared first on Arkenforge Tabletop.
]]>
As the old song goes: “How do you solve a problem like managing hundreds of thousands of user-generated files in a way that provides quick access, organizability and searchability, while also keeping a low barrier to entry and minimising resource usage?”. Ok, that might not be exactly how it went, but it’s what we’re covering in today’s Arkenforge Devlog – Content Management
It took quite a few iterations to reach the point we’re at, and there will probably be more in the future. Each step has solved new sets of problems that have arisen as the Toolkit has grown and developed over the years, and as our community has become more and more ambitious with their content usage. For anyone else building a VTT, or really any platform that required file management on a large scale, this article is for you! If you aren’t a developer, have a read anyway 
This follows on from our previous article on the subject from 2020. We’ll summarise it below in the ‘early years’ section, but you can read the full article here: https://arkenforge.com/content-management-and-arkenforge-a-history/

Did we know what we were doing? It’s a strong maybe.

The Arkenforge Toolkit is locally installed software. That gives us challenges that many online platforms don’t have to deal with. Mainly – that the only limit to your content library is your hard drive space.
We went through a lot of iterations, from a 5gb file that was loaded directly into RAM, to a map asset management system that was easy to use, but incredibly convoluted to configure. Eventually we landed on a system that allowed users to easily see their imported content, but made it difficult to actually use that content in many cases.
At the start of 2020, COVID appeared on the global stage. Throughout most of 2020 and a good portion of 2021, we were locked down in Melbourne. As we couldn’t go to conventions, or really leave the house much at all at times, we decided that we’d go through and fully redesign the Toolkit. When it came to the content system, the version at the time had its flaws. There were issues with content management and usability of imported assets. Primarily, users with lots of content could take 15 – 20 minutes to load the Arkenforge Toolkit software. This had to change.
We identified two core problems with our current content management system. Two problems doesn’t sound like a lot, but they were large problems. Problems that went to the very core of how the Arkenforge Toolkit software operated.
You see, meta files were an incredibly useful tool. But, while we lazy-loaded the main content, all meta files were loaded into the Toolkit in RAM. This essentially brought us back to the .rwpack days of old, but with significantly smaller file sizes. The main issue here was our power users that had imported huge quantities of map assets. When the Toolkit was launched, it would go through every folder in the ArkenforgeData folder to find the meta files it would load into the Toolkit. When you’re dealing with tens, if not hundreds of thousands of files, this takes quite a long time. Effectively, we were punishing users for using more of the Toolkit.
Not a great thing to do.
We were also still using the Palette Tool. It was an excellent function back in the early days of the Toolkit, but like much of the UI, it was quickly becoming unfit for purpose. Not only did it limit things to category/subcategory, leading to large amounts of content in each subcategory, but when users were importing content they would have to create their own categories to move their content to. With the benefit of hindsight, this was a terrible idea. However, progress occurs incrementally, and this was needed to increment upon.
So, we needed to find a way to stop all of these files loading in at runtime, but still be able to access them when needed. We also had to give users a way to easily manage their imported content, without having to spend hours creating categories to assign that content to. There was a clear solution.

There’s already something out there that provides a clear way to organise files. One that requires minimal effort on part of the user and allows new files to be added and accessed immediately. One that you’re using right now to read this article.
An operating system.
It was a bafflingly simply solution. Mimic the operating system’s folder structure, and show content as it’s physically organised on the computer. How hadn’t we thought of it earlier? Well, honestly we hadn’t needed to.
So, we updated the Content Library once more. We put in fixed folders that each content type would be placed in. Users could create their own custom folders within them. This kept content where it should be, and it let users easily organise their imported content. We could also use this system with our content packs. It allowed us to split content into a greater number of categories, and eventually genres, keeping the number of assets per folder relatively low.
As we were swapping to a folder-based system, we no longer needed to know every file in the Toolkit. The operating system was handling that for us. This meant that we could now lazy load our meta files as well! Meta files were only loaded when the relevant folder was opened. Some types of files, namely playlists, ambience presets, and SFX triggers, would be loaded in the background when the Toolkit started. This was because audio content could be assigned to them through a right click menu, and if the content wasn’t loaded, it couldn’t appear as an option in those menus. This loading was done in a separate thread after the Toolkit was launched.
Boy, it was nice to have finally solved the problem once and for all! Well, for about two years…

With the new changes, the load time for the Toolkit was now effectively zero. All content could now be managed easily through the file browser, so our organisation problem was sorted. All were rejoicing!
But there were small, pesky problems that kept coming up. Our notes system updates meant that people were using them more. That meant lots of data added, and naturally the desire to link all that content together. We’d also optimised our mapping quite heavily, so people could now add more and more assets to their maps. With our new content packs, there were tens of thousands of new assets available to build with.
You can see the singular big problem that this is all leading to.
How do you search through hundreds of thousands of assets without slowing down, or even in some cases, freezing your software?
Our existing method wasn’t great. Since we were relying on the folder system to show content, we were also relying on it to search content. Do you know how long it takes to search hundreds of thousands of files to find all the trees? Too long. Especially when that process involves opening every meta file in every folder to read the contents. If you could just search by name, the problem wouldn’t be quite as bad. At least then you’d be able to just read the file names without needing to open them. Still a long process, but nowhere near as long as opening the meta files. But no, we gave people filters. Content type, content pack, creator, artist, etc. All data that you can’t easily keep in a file name.
Suffice to say, when you’re dealing with as much content as many of our users, that search began to take a while to return its results. Fortunately there’s a relatively simple solution for this one.
An index is essentially a phone directory for your content. When building our index, we essentially pull all of the information out of our meta files and put them into a very long list.
A list of text is significantly faster for a computer to parse than opening and parsing multiple files. It’s even faster when the full list is in RAM. By running our search system off the index rather than the file system, it can find content near instantly. The primary issue at this point is keeping the index properly updated.
Importing and deleting content from the Toolkit updates the index accordingly. For any content not indexed, such as users who copy files into the Toolkit through the OS file browser, individual folders can be reindexed, as can any given content pack, or the entire Toolkit if a user so wishes. We keep the content library using the folder system for this reason. If a user has unindexed content, it can lead to confusion if it doesn’t appear in the content library. When viewed in the content library, all content has a UI element to show its indexed state.
The index update also revealed a small weakness of the old system. Some content types didn’t have meta files attached. As these files were rather small, we would just load them directly. In order to index them effectively, we had to create meta files for these types of content. This also meant updating the existing Toolkit systems to base decisions on these meta files, rather than on the content files directly. Something seemingly simple such as dragging and dropping content relies on knowing what type of content is being dragged and dropped. If the content type changes from a Playlist to a Playlist Meta, the logic breaks, because everything was built to handle Playlists.
This change also allowed us to streamline quite a lot of the file management and display code in the Toolkit. When every shown file is a meta file, then we don’t need different classes for the meta-less content types. We removed a lot of conditional logic, which provided a small boost to performance when loading files.
The new Content Library system we’ve built has a few extra features that aid with usability.
Firstly, folders are now treated as a content type. This means that users can drag and drop them onto the Arkenbar, onto the map, or into notes.
We also include folders into the index file. This increases search functionality, as users can add part or all of a folder path as a search filter. This helps when users have multiple instances of content with the same or similar names.
Finally, by unifying our file viewing code to only look at meta files, it allows opportunities in the future for custom folders with mixed media. This would allow audio, images, video, and the various collection-based content types to co-exist in the same folder.
All of these new systems work together to allow our users to find and access their content faster than ever before.
That’s where we with content management are as of the Q2 2024 Arkenforge Toolkit Beta Version. A mixture of native OS folder structures and content indexing that provides management of hundreds of thousands of files while allowing full searchability in under second.
There are some updates that we could make in future, mostly around removing the requirement of every content type needing its own fixed folder structure. This would give users more freedom in managing their content, as well as removing a level of confusion that can arise from where certain types of content are stored. That’ll be quite a large and painful update though, so it likely won’t be happening any time soon.
Thanks for reading, and we’ll see you in the next one!
The post Arkenforge Devlog – Content Management appeared first on Arkenforge Tabletop.
]]>The post A Year Of Change, Phase 2 – Standalone Toolkit Release appeared first on Arkenforge Tabletop.
]]>
Hey folks! Nathan here. Today we’re unveiling the second phase of our 7th birthday changes. The Standalone Arkenforge Toolkit. If you missed the announcement of Phase 1, you can read it about it here.

It’s something we’ve heard time and time again over the years. “Why can’t I just get the software with no asset packs?”. Historically we’ve been apprehensive about giving the software out without any content, as there’s a base level of assets that folks expect from a tool such as ours. This was a large reason we brought out the Arkencore Pack.
With all users having access to the Arkencore Pack, we can now set up the Toolkit as its own standalone product. This is intended for those who primarily want to use Arkenforge for running their in-person games on a screen or projector.
The Standalone Toolkit provides the full software experience. No features are being spun out into separate products. We’re staying true to our goal of all Arkenforge Toolkit features being available with a single purchase.
With the Standalone Arkenforge Toolkit software product comes some updates to our pricing.
Yes, prices are changing. I recognise that this is often the point where companies jack up the prices of everything, citing ‘cost of living’ or ‘Too much value for customers.’ That’s not what we’re about at Arkenforge.
Overall, things should be better for our users.

Wait. Isn’t the Arkenforge Toolkit already US$35? Yes, but read on.
Arkenforge is at a point now that it can be considered fully-fledged commercial software. It excels at its job, which is providing the best in-person TTRPG experience. On top of this, it is a highly competent map builder, audio tool, and campaign manager. With that in mind, we’re now providing the option to purchase it as its own standalone software. No Fantasy or Sci Fi Essentials Pack bundled in – only the standalone Arkenforge Toolkit.
This is also why every user will receive the Arkencore pack for free. By purchasing the standalone Arkenforge Toolkit, not only will you have access to world class TTRPG software, but you’ll get a free library of content along with it. If you’re a user who just uses the Toolkit to run your games with imported content, then effectively there is no change. If you’re interested in building some amazing maps, then read on!

The price of the current starter bundles will be raised to $50.
This is admittedly higher for those who just want to dip their toes in and experiment with mapping. But, if folks like what they see and want to get more, it’ll be much easier to dive in.
One of the complaints we hear about our marketplace is the high price to get all of the content. Surely by increasing the base software price, we’re just making that problem worse, right?
Wrong!
We’re dropping the price of our content packs! As we’re continuing to release packs and ramp up content production, it only becomes more and more expensive to get all Arkenforge content. This is great for us, but not so great for our users. So, we’re making it easier for you to get the Arkenforge mapping content you want.
Our pricing will be unified between all Major Packs, Minor Packs, and Token Packs.

Major packs are the packs from our major content releases. At time of release of this article, the Major Packs are:

Minor packs are all mapping content packs outside of the Major packs. At time of release of this article, the Minor Packs are:

Token packs will remain at their current price. It’s important to note that the Dungeon Dwellers and Arkenteam Token Packs are no longer available for purchase, as they have been included for free in the Arkencore Pack.

With our content packs becoming cheaper, our bundles prices are coming down with them!
All pack bundles will be dropping from US$70 to US$50. We’ve aimed for an Arkenforge Toolkit Starter + Major Bundle to be roughly the same price. With the new price being US$100, compared to the old one of US$105, we think we’ve done well there. For all purchases after that point, you’ll be spending less money than you would have under our previous pricing model.
The Ultimate Bundle price will also be dropping quite a bit, going from US$320 to $250. As the Ultimate Bundle includes all Arkenforge content releases, this one will continue to increase as we release new content.
That’s all for Phase 2! We’ve now got the Arkencore Pack, the Standalone Toolkit, and some new user-friendly pricing.
Stay tuned for Phase 3, where we’ll discuss some further changes to our content!
The post A Year Of Change, Phase 2 – Standalone Toolkit Release appeared first on Arkenforge Tabletop.
]]>The post A Year Of Change, Phase 1 – Arkencore Pack appeared first on Arkenforge Tabletop.
]]>
Hey folks! 2024 is shaping up to be a big year for Arkenforge. We recently celebrated our 7th birthday, and it’s the catalyst for some big changes. All of these changes we’re making hinge on a single starting point. That starting point is the Arkencore Pack.
The Arkencore pack is exactly what it sounds like. A core pack for Arkenforge. In its initial release it will contain over 1GB of fantasy mapping content. That’s over 200 mapping assets, many of which are animated. It’ll also be launching with over 100 sound effects. Finally, it’ll be launching with all tokens from the Arkenteam and Dungeon Dweller token packs. Think of it as a new Fantasy Essentials Pack, but with a bunch of content that can largely fit into any campaign.
The word ‘launching’ is the key word here. Over time we will expand this pack with new content, providing even more free assets for all users.
One simple thing makes the Arkencore Pack different to all the others. Every user will have access to it for free. The Arkenforge Launcher will automatically install and update the Arkencore Pack, similar to how the Launcher Patcher is now. We’ll also have the Toolkit install automatically, but patching it will remain optional. This goes live with v6.2.0.0 of the Arkenforge Launcher. The Launcher update is optional, so feel free to hold off on it until you’re ready to experience the full power of the Arkencore pack!
By giving every user the Arkencore Pack, it provides a pool of content that we can rely on every Arkenforge user having access to. That lets us do some fancy things.
We can use the Arkencore Pack wherever we like. Modular objects in all content packs can contain Arkencore assets. This will reduce asset duplication and allow for a much wider range of modular objects than could otherwise be supported. As the pack contains sound effects as well, we can add things like sound triggers to content much easier, as well as creating some simple ambience effects that all users can access.
All in all, we have more content to use for more things in the Toolkit.
This is the first of many content changes we’ll be rolling out this year. The Arkencore is the first phase, and we you’ll love all the new assets and opportunities it brings.
Not only do we have a huge update coming to public later this year, but we’ve also got some really neat packs in the pipeline that we’re incredibly excited to show you.
Stay tuned for news on our future phases by joining our Discord!
The post A Year Of Change, Phase 1 – Arkencore Pack appeared first on Arkenforge Tabletop.
]]>