Platform Status

Platform Status, Functionality and Planned Development

While BrowserQuests™ has been (off and on) under development since 2013, its scope is nearly limitless and so the platform is--and will continue to be--constantly changing and evolving. Accordingly, it's important for authors to know and understand the current status of the platform (along with its current limitations), what features are being planned for near-term development and what potential improvements are on the drawing board over the longer term.

Note that if you're interested in contributing to the ongoing discussion regarding how best to move the BrowserQuests™ engine forward, just bop over to our dedicated Discord channel, find the appropriate text channel and let us know. We definitely welcome any and all feedback!

Current Platform Status

Currently, the BrowserQuests™ platform is still undergoing a variety of beta-related updates and changes that were initially launched back in the summer of 2020. This transition from alpha to beta was quite extreme and some of the kinks in the system are still being worked-out, but a small collection of modules that begin "The Sorrow of Sisla" original campaign are fully playable, requiring 5-7 hours to complete. Note that the next module in the campaign is in the works, but likely won't be ready until sometime in early 2021.

At the moment, the most challenging (and, admittedly, most fluid) aspect of the platform is the player interface. Determining how best to simulate a virtual game master (GM)-led persistent online RPG is extremely challenging, and presenting a UI (user interface) that not only makes sense to players and authors alike but can also be developed using the platform's current (and, honestly, a bit dated) Microsoft-based, server-side technology stack is even more challenging (especially considering that BrowserQuests™ has been developed to work equally well across desktops, tablets and even smart phones). Every potential change to the platform requires a variety of considerations and often the full ramifications of a change aren't determined until the players actually utilize the changes.

Platform Limitations

So, even though the platform already consists of over 12,000 lines of VB.NET programming code across dozens of database tables and hundreds of SQL Server stored procedures, it's still in its relative infancy. Therefore, the platform is currently rather limited:

  • Race & Class Limitations - Only the four primary races (dwarves, elves, halflings and humans) can be played, along with the four primary classes (clerics, fighters, magic-users and thieves). If playing an elf, the fighter/magic-user and magic-user/thief combo classes are available as well.
  • Level-based Limitations - The platform can only accommodate character levels one through three, as only the first-level cleric and magic-user spells have been integrated into the system (along with one or two second-level magic-user spells such as Web). The future incorporation of all cleric and magic-user spells will certainly require a significant developmental effort.
  • No Tactical Combat - A standard (grid-based) approach to combat has not yet been implemented (and may NEVER be implemented). Rather, combat is merely text-based, meaning that there are few tactics involved (combatants can either attack from a distance if they have the ability/weapons, or they attack in hand-to-hand combat). Potential implementation of a grid-based combat system is being reviewed.
  • Very Limited Bestiary - Only a few dozen monsters have been integrated into the platform. Mechanisms exist to rather easily add new monsters, but they likely won't be added unless an author requires a specific set of them.
  • Random Encounters and Loot - The platform hasn't yet been developed to allow for random encounters when travelling from one area to another (or, perhaps, resting within a fairly dangerous place). Likewise, no mechanism exists yet to randomly assign loot to an object (such as picking an encountered chest, where the quest author hasn't already placed some valuables within).
  • Limited Ability to Travel - The BrowserQuests™ platform is certainly NOT an "open world" game where players can travel wherever and whenever they wish. Rather, players are limited to only those encounter areas that are "reachable" from the current area they find themselves within. While the Mairigan continent is fully mapped within the game (so players can view all 60 or so countries within the continent and learn more about them), they currently can't travel outside the beginning country of Pirapa.
  • Variety of Other Basic Fantasy RPG Rules - While the Basic Fantasy RPG ruleset has been adopted by the BrowserQuests™ platform, many of its more intricate rules have not been integrated (while others have, but were subsequently changed to better fit the online, persistent context of the RPG).

Naturally, these limitations will be worked-on over the months and years to come!

Near-Term Development

Given the platform limitations introduced above--and prioritizing the work to be done--the following list below should give authors an idea of what improvements are coming and in which order:

  1. Improved UI - First and foremost, the UI (user interface) needs additional work and will receive the highest priority moving forward. This work is expected to be implemented and completed by the end of October 2020 (implemented on 31 October 2020). 
  2. Hero Equip Settings - Currently, the game automatically equips most items for a hero, such as which armor, weapon or shield to use (while, with equipment elements such as magical rings, those items must be manually selected). A mechanism by which players can equip their party heroes with whatever carried items they wish is needed to allow more flexibility and consistency within the game (implemented 8 November 2020).
  3. Random Loot Functionality - If a thief currently picks a locked item (such as a chest), nothing will ever be found within (unless the quest author deliberately assigned items to the object in the first place). A new mechanism needs to be implemented by which randomly-generated loot items can potentially be added to locked objects (implemented 15 November 2020).
  4. Thievery Skills Limitation - Any thief-based action (find traps, remove traps, pick locked door and pick locked object) currently allows the thief to try as many times as needed to succeed, which is quite unrealistic (if a thief has a 25% chance to open a locked chest, she shouldn't be allowed to keep trying until a 25 or less is rolled on d100 percentage dice). Accordingly, new programming is needed to record all such thieving activity so that if a thief fails at a given action, that action cannot ever be repeated (implemented 15 November 2020).
  5. Second-Level Spells - All second-level cleric and magic-user spells need to be integrated into the platform so that characters can proceed to level four.
  6. Module #4 - "Racial Justice" - The fourth module of "The Sorrow of Sisla" campaign needs to be developed, integrated into the platform, thoroughly playtested and released at some point in 2021.

Longer-Term Development

Finally, quite a bit of future development is planned, elements that aren't as high a priority as those listed immediately above but are important to the health and success of the platform all the same. In no particular order, this list currently includes:

  • Integration of All Spells - Ultimately, all cleric and magic-user spells will need to be developed and integrated into the platform.
  • Inclusion of New Races & Classes - The Basic Fantasy RPG system does utilize secondary rules that address additional races and classes, many of which should work well if integrated into the platform (although magic-using classes would require a significant amount of extra work to implement).
  • New & Improved Monster Images - As new monsters are added to the platform, associated images will need to be acquired and integrated as well.
  • Potential Combat Grid - A simplified combat grid--detailing the relative positions of all combatants--is a staple of most traditional, GM-based "table-top" RPG sessions and may significantly improve the overall BrowserQuests™ experience as well (assuming that such a grid and its associated functionality is practical given the current technology stack supporting the platform).
  • Random Encounters - Although a "Random Encounters" authoring form was originally developed (along with a "Random Treasure" form), the system was never developed to actually allow random encounters and provide random treasure once the encounter was successfully resolved. This development will be significant and will likely require several months to implement.
  • Sound Effects - Potential inclusion of relevant sound effects into the game.