Camelot Unchained Wiki

In August, 2017 City State Entertainment began releasing segments of their Beta 1 Doc for Camelot Unchained. It contains information on the content within the game's beta 1 testing phase along with outlines for how the game's beta 1 testing will take place.

General Overview[ | ]

The Beta 1 Doc is broken into several chapters, all presently available on their website.

  1. Thank You: Gives thanks to the developers, backers, and supporters of the game for their patience and contributions.
  2. Guiding Principles: A list of the principles that will guide the beta 1 stage of game testing.
  3. Purpose of this Document: Explains that the beta 1 doc is not intended as a deep dive into game features but rather a broad cross-section of what players can expect.
  4. Key for this Document: Clarifies what various colors used in the document mean as well as why some things are redacted.
  5. The Patcher: Provides an image of the game patcher and lists goals for the patcher during beta 1.
  6. Character Creation: Describes how character creation will work.
  7. REDACTED: Redacted section for CSE devs only.
  8. The Safe Islands: Describes safe islands and their purposes as safe launching areas that should be persistent daily.
  9. Landing Areas: Describes landing areas on the biggest starter islands with docks, banks, and other features.
  10. Building Islands: Describes non-PvP building islands for CUBE.
  11. Plots: Explains how plots with work in beta 1.
  12. Contested Island(s): Describes the starting contested island and how these will work in beta 1.
  13. REDACTED: Redacted section for CSE devs only.
  14. Crafting: Explains the beta 1 crafting goals and the processes for gathering, shaping, etc.
  15. Social Systems and Grouping: Explains the grouping mechanics for beta 1 including Solo Play, Warbands, Battlegroups, and Orders.
  16. Overview - Beta Testing & the Dragon Circle: Overviews how beta 1 will work along with the stats retained and incentives for participation. Introduces the concept of the Dragon Circle™.
  17. The Dragon Circle™: Explains what the Dragon Circle is and how it will work.
  18. Saturday Night Sieges™: Describes the Saturday Night Sieges as one of the first forms of the Dragon Circle™.
  19. To be continued: Future chapters are expected.

Thank You[ | ]

I wanted to show you folks as much of the “official” document as I could without editing. This is what I said to the team after we finished our work on the document. And I do mean our work. CSE is a highly collaborative studio. We talk, exchange ideas, disagree, argue, and—almost all the time—it is done professionally and respectfully. After all, nobody is perfect, right?

Thank You to CSE!

I just want to say thank you to all the people at CSE who read the document. I also want to thank those folks who spent a lot of time on what I wrote before the document went to the whole team, suggesting, commenting, questioning, filling in gaps, etc. Finally, to those who spent a lot of time in the comment section of this document: Once it went to the whole team, you folks did a really great job as well, and I appreciate it. Like our game, this document is what it is thanks to all of us working together.

I’ve kept the older doc up in the previous location so we can always reference it, as well as the comments we all made there.

This document is now the official guide for us for Beta 1. In the coming weeks, I’ll do two more things:

Create a redacted version of this document for our Backers to read. Once that document is complete, we will reveal it serially to our Backers on our website. Work on a “storified” version of this document from the perspective of our Backers.

Thanks again, everybody, you did great!

Thank You to our Backers!

It’s been a longer road to Beta 1 than we expected it would be last year. For that, you have our most sincere and humble apologies. I have always, dating back to old Mythic, believed that CEOs of companies need to take ownership in situations such as these. I’m doing so once again, and saying "mea culpa." However, that’s not enough, at least not in my/our opinion. Mere words are just that—words. They may be heartfelt, true, and meaningful, but in this case, they are just not enough. We have to do more, and we will.

To begin with, speaking on behalf of everyone at CSE, we thank you for your patience and support, truly. It means so much to us that you still support us, send us little gifts, and don’t make our lives miserable. You truly don’t know how much it means to the team and to myself when we see the extra effort some of you have gone to in order to support us with words and occasional deeds. It really is a game-changer for the studio, at times.

On my end, I’ve already committed more money to the studio than I originally planned. I’ve opened the office in Seattle and expanded the team there. We have never asked you folks for additional money to pay for that expense, which is considerable. Fortunately, the results from it have been equally considerable! By the time you read this, we will have moved achingly close to the first of the SNS trials, will be back up to 2.1K ARCs/Bots, the new ability, animation, and VFX systems will be performing as expected, and the programmers’ focus will have turned more heavily than ever to gameplay and not tech.

It’s been a long road, way longer than we expected, but we have kept faith with our Backers and now are almost in the next stage of testing. As always, we thank you for your support, understanding, and most of all, your patience.


Guiding Principles[ | ]

What are the overall Guiding Principles for Beta 1?

We must present a game that, while certainly not a Beta 1 game compared to today’s “almost ready to launch” or “have launched in other countries” Beta tests, should be solid enough to make our Backers excited about the Beta test process. Beta 1 is just the start of our Beta process, not the final part of testing for a game that is feature-complete or is just getting localized to another country.

We must remember that most of our Backers have waited more than an extra year for this Beta due to re-abilitation. We must reward them for their patience, understanding, and support. There is nothing more important than that. Beta 1 should be more about the fun, whenever possible for the players, than Alpha was. While it is still a Beta 1 test, having more fun things to do, such as the Saturday Night Sieges and other such tests/games, will go a long way toward making Beta 1 something that non-Backers as well as Backers will want to be part of over the remainder of the year.

  • Beta 1 tests should be as solid as possible. Shit happens, but we shouldn’t run Beta 1 tests with an unstable version just to keep to a schedule. Unless, of course, the purpose of the test is to help find and fix the instability and we need the Alpha, Beta, and IT Backers to help us out.
  • We must remember that the servers will not be up 24x7 in Beta 1, so we must be able to have sped-up versions of systems such as progression, crafting, building, etc. This is talked about in my crafting documents, other documents, and this document as well. This ability should be able to be changed during a test, whenever possible.
  • We should we have a central spreadsheet, not XML, for all of these variables, as it would certainly make it easier for the designers to work with these values and also for the programmers since they won’t have to worry about building out separate spreadsheets, functions, etc.

MJ Notes - This section of the document reflects the core "principles" of our Beta 1 tests and of our company. I’ve used this term many times in the past, and these are the equivalent of the Foundational Principles of Camelot Unchained. They are meant to serve as a guideline for everything that follows.

Purpose of this Document[ | ]

The purpose of this document is to lay out a broad cross-section of the game that our players should expect to see from us on the opening of Beta 1. It also serves to lay out some of the specific goals for the team as we continue to develop the game through Beta till Launch. This is not intended to be an all-encompassing look at the features of our game, or a deep dive into all the details of any particular feature, system, or mechanic, but more an overview of the things that we think should be delivered for the opening of Beta 1. This document is meant to be fluid, so if there are things that we have to sacrifice being in Beta 1 based on complexity or other things that we might want to replace other items here, I’m open to discussions on them.

After we are comfortable with this document, a redacted form of it will be given to our Backers so they can see what they can expect from the opening of Beta 1. We will not be showing them the Bonus items (covered below) for both competitive reasons and plain old “preserving my sanity” reasons, since I will be dealing with the questions/comments/etc. from our Backers that will result from even the redacted form. Plus, as Bonus items, they are lower on the developmental food chain than other items that need to be in.

MJ Notes - The key for our Backers here is that this document is not meant to encompass everything that is intended for Beta 1, let alone for launch. This document is meant to give you some very clear insight on what you should expect when the game enters Beta 1. It was not written with explanations of each item, details, etc. as that would have pushed this document to 100+ pages. Rather, think of this document as a Minimum Viable Vision of Beta 1. 😊

Key for this Document[ | ]

BLACK = Needed for Beta 1

RED/BONUS = Anything red is just a bonus for the opening of Beta 1, but is something we do need added during Beta 1.

PURPLE = Questions for the programming team. All old questions that have been answered are removed, only unanswered questions and NEW QUESTIONS remain in the document.

BLUE = Specific design question

The material redacted in this document falls into the following categories:

  • Quotes/ideas attributed to specific devs. That information is in our team doc, but as this is going out to you Backers, it doesn’t belong there. Plus, since some folks might not like some of the ideas, I don’t want any member of CSE to be blamed/attacked personally. If you feel the urge to criticize CSE/our ideas on the Forums, blame me (MJ), since I wrote the main document and then approved everything that is in here.
  • Material that we don’t want to reveal yet. As many of us have noticed, ideas from CU have found themselves in other games, just as ideas from other games have found themselves in CU. This is normal, but I don’t want to give anybody a head start on us. 😊
  • Material that is considered BONUS for Beta 1.

The Patcher[ | ]


Beta 1 patcher

  • Improved UI for servers and characters. All UI bugs should be fixed so that players know which characters are on which servers, which character they have currently selected, etc.
  • The Getting Started link should point at a “Welcome to Beta 1” doc. Right now, it goes to the main website for the game, and anybody who can reach this point in the patcher is already a subscriber, so there is no need for it to go there.
  • A player count in the chat section of the patcher. It will be very handy and necessary to have a running count somewhere that is easy for both us and Backers to see. We should be able to see how many people are in which part of our system (chat, patcher, fledgling, etc.) from outside the game as well as inside the game.
  • We will also show the number of people on each server on the patcher itself on each server entry.
  • We will change the way the patcher automatically patches all the channels and replace it with a slightly different system. We will automatically update the currently-selected thing if nothing else is updating, with the play button either queueing or immediately starting the update if something else is going.
  • Links to FAQ, Guide, Known Issues link/section and other material for the game, new Beta welcome screen, our own explanation on how to get a DXDiag, and some additional new screens for Beta 1.
  • A Help Me! button that opens a document which shows the most common problems players have had in the past, instead of the larger, less-focused FAQ doc. FAQs tend to be long, and I want this one to be short and easy for our localization folks to localize.
  • A Banner (or page) that lists the most important issue(s) of the day (if there are any), such as All Servers are Down, Test on Wyrmling Prep today, etc. This will allow players to get important information from us without having to go into the game, Forums, etc. We can also have this page linked on our website, FB, etc. as well. For example, messages that our servers are down, if displayed in the game, can’t be seen from the patcher. The bottom line is that we need to communicate better with our Backers on a lot of levels, and this is a good place to do so.
  • For people on old patchers, what we need to do is send a message to the patch client which would disconnect it and display a message to the user that it is shutting down for an update or temporarily disabled and so on. The user can then click "ok" to show that they read the message, and it updates itself.

MJ Notes: As you can see from this section, we are even focusing on improving the patcher for the opening of Beta 1. We have a lot more ideas for post-Beta 1, and I had to redact this section a bit. We don’t expect that this will slow down the release of Beta 1, of course. However, if that did turn out to be the case, we would be willing to sacrifice some of the items in this section to speed up the opening of Beta 1.

Character Creation[ | ]

Character creator

Beta 1 character creator

  • Players must be able to create a character of any allowable Realm/race/class combination.
  • Change the order of the attribute points so that they are in alphabetical order. We will also call them out in terms of importance to their class by a simple visual treatment, and look at the concept of “concept groups” as in Exalted or some old pen-and-paper games for additional points of reference.
  • All attributes can be changed, even if some of them have no purpose yet.
  • We need to have a number entry box, so players can simply type the numbers or use up/down arrows.
  • Fix the highlighting on the screen so that all text elements look the same. Some of the entries per attribute are dimmed/not dimmed within the same attribute description, which just looks sloppy.
  • A help button for every part of the selection process. Each page should have a help file/information, which is only a button click away, which covers the section of the character creator you are in. If possible, you should stay within the character creation process instead of going to the website for the information.
  • Players can choose from a small selection of Banes/Boons upon character creation. These will be race, class, and general. Right now, we'll have a minimum of 10 Banes and Boons per character created (when you factor in race, class, and general). If we can do more, great!
  • On the B&B screen, change “Minimum Points” to “Minimum Total Points Needed”
  • On the B&B screen, change “Maximum Points” to “Maximum Total Points Allowed”
  • Unique player names per server.
  • Add a different animated background for each race in the game, just as we do for the classes.
  • Players will start with Realm- and class-appropriate equipment; each player will also have a Vox Magus, since we will not have the crafter class for the opening of Beta 1. As I mention below, we don’t want people to be able to create Voxen at will, unless we make it so that the player can’t just keep recreating them and dropping them on the ground.
  • Add a Cancel button opposite to the Next button to cancel the current character creation instead of using Home as we currently do.
  • Hide/grey out the bottom bar of the patcher while we’re creating a character. I want to do that because seeing that bar there can be confusing for some players, especially new players.

MJ Notes – We don’t want to put a ton of effort into improving the character creator for the opening of Beta 1, but we do want to make it a better experience than it currently is for our players. Expect that the character creation system will change a lot over the course of the Beta process. Spending a lot of effort on it now doesn’t make sense, since the underlying systems/stats could change. As we lock down that stuff and confirm it for launch, then we will do a lot more work on character creation.


MJ Notes – Sorry, this section is for CSE only, not for Backers.�

The Safe Islands[ | ]

The Safe Islands are “private” islands that are owned by each Realm. They can only be reached by members of that Realm, which is done through portals. Portals are there as placeholders for what will eventually be the true transport system for movement between islands, via boats and other non-instant means. Portals will not take players of opposing Realms to the wrong Safe Islands. The Safe Islands are, like portals, intended to be placeholders for what will eventually be the main islands for each Realm.

We hope that some of the Safe Islands will be persistent from day-to-day, unless we need to do a full wipe of them. As such, players shouldn’t count on that persistence over the course of Beta, but day-to-day persistence should be, in general, how we do things during Beta 1. As we said during the Kickstarter, we will be wiping often during Beta, especially while all the classes are not in the game.

The number of Safe Islands that we will need for the remainder of Beta will be determined after we have the final Beta 1 tech in place for number of plots, plot size, number of buildings, etc. that can be found on an island, based on an island’s size. Since we want building stability turned on for Beta 1, we will limit the number of plots per island to keep performance optimal, as we still need additional work on optimization. As we optimize more, we’ll expand the Safe Islands to stress the systems even more heavily.

Each Safe Island has a Landing Area, which is described in the next section. Landing areas will be based on the type of Safe Island (Building, Starter Island, etc.). The most complicated Landing Areas will be the Starter Islands.

The Safe Islands with Landing Areas will generally be open the most often, to allow our Builder’s Brigade to help build and change the islands. We should set up a separate server for the Safe Islands (not Hatchery/Fledgling), so the Builder’s Brigade can spend more time building, without worrying about what we are doing on our main development and testing servers. Having a group of dedicated builders testing that aspect of the system is just as important as having combatants testing the combat systems on the Contested Islands. When we get to the section on the Contested Islands, I know our combatants will be very happy with what we have in store for them!

Add a new server (not Hatchery or Fledgling) with a stable copy of either the Hatchery or Fledgling server running, so that the builders can build collaboratively with each other without impediment by server restarts as we commit code. We could limit access to this server by setting up a specific permission flag for these guys and gals, so only CSE and Builders can install and access this server. Without a need for large numbers of players, the server cost would be minimal, especially with the use of our “embedded” systems.

Each Safe Island should have a unique bit of music associated with it when the player enters the area.

There should be another area around the Landing Area that can’t be used for Backer buildings but is large enough for the Builder’s Brigade to build lots of buildings, enclosed towns, etc.

The Safe Islands that are used for player buildings should be large enough to accommodate a lot of buildings and players. However, because of the hardware cost (via AWS) associated with them, we probably don’t want them running 24x7. Once we get the final estimates for cost, as well as for the capacity of each island in terms of number of plots, buildings, etc. that can be made on an island, Design can lay out the number of islands we need for Beta 1.

MJ Notes: The Safe Islands are an important part of Beta 1. Unlike characters, we want them to be persistent, so that our Builder’s Brigade will not constantly have to rebuild the islands. They will also serve to give our Backers something to tinker with and refine when not in combat. A feeling of “coming home” to their land/homes will begin to appear during the various Beta stages and then for LIVE. As the Safe Islands are getting built out in front of our Backers' eyes, the world will start feeling like a real world, and not just a stage for a really cool tech demo. This will, of course, also have the benefit of reassuring the Backers, who after four years have every right to feel nervous about the game’s current state of development.

The Safe Islands will also allow all our Backers to work with and comment on the state of our building system, so we can make refinements and improvements during Beta 1. It is important to work on the building system at that point of the game’s development, in order to ferret out whatever major issues will need extra time and attention.

Landing Areas[ | ]

On first entry, players will begin in a Landing Area on the biggest Starter Island in that player’s Realm.

A player’s location will be persistent no matter which island they are on when they leave the game, unless of course they were on an island that was then closed or was otherwise no longer open and running. In that case, on next login the player will start in the Landing Area for the player’s Realm. In other words, players can’t log within enemy keeps/areas and be there when the server and/or match restarts.

Each Landing Area should have a dock, a number of portals, and some basic buildings and walls. If all goes well, we should have the Builder’s Brigade create these buildings. The Starter Island should be more fully built out than the rest. The other Realm islands should just be carbon copies of the already-existing islands.

For the buildings/portals[ | ]


  • dB should add some ambient pub music. For now, we'll use our current tech of placing an ambient track with a radius. We'll also look at possible additional tech in terms of tying the music to the areas, going forward.
  • Have an NPC pub owner. We'll reach out to our Pub tier holders and see if they want their name as the name of a tavern keeper.
  • Click on the tavern keeper to get some very basic information about pubs. It could be as simple as: “Pubs are a gathering place for people to chat, play games, and generally be social. They can be player-owned and operated, or run by your Realm.”
  • We will need tech so that writer/designers can add this text without programmer intervention.
  • Whatever solution we use, we should set it up in a way that is easily editable by writer/designers, and can then be localized by the folks who will be helping us.


  • Ambient bank music.
  • Placeholder NPC banker.
  • Click on banker to get basic info about how the banking system will work in the game.
  • Bank itself is non-functional for Beta 1.


  • Ambient music for portal.
  • VFX for the portal.
  • Portals should only show VFX when they are working: Not only less confusing to players, but also seems more logical, and makes the world feel more real.
  • Placeholder Portal Keeper NPC.
  • Mouseover the portal/portal keeper to get information about the portal and walk through the portal (if there is one destination), or click/select if the portal has multiple destinations.
  • An Admin Interface for portals that can be used in the game.


  • For portals, and one day, boats, ‘natch. We will make these portals Realm-specific, if possible. The Art Team will look at doing Realm-specific portals that can be scaled to help differentiate types of portals. For example, the smallest portal could be the one that is by the boat. The biggest portals are the most powerful (multiple destinations). Portal triggers are not the same thing as portals, as the triggers for the portal can be a part of the overall portal. For example, a boat could be a portal, but the trigger is sitting down in a seat.
  • Player can then walk around the Starter Island or portal to the other Safe Islands of their Realm.
  • In the center of the Landing Area, there should be a special portal to the Contested Islands.
  • The portal to the Contested Islands should not be running all the time. The Contested Islands, whether part of the ****** ****** (redacted 'til we get to that section) or not, will not be running 24x7, so there is no need for the portal to be continually open. Also, we can use the portal as a gating mechanism/lobby, as discussed below.
  • We need to be able to easily open/close any of the portals without programmer intervention. This would allow us to open and close portals based on certain test conditions (Realm imbalance during a test, for one). The servers would still have to be spun up by the programmers for Beta 1, but I hope that will not be the case by the time we reach Beta 2.
  • The portals to the other Safe Islands, in general, should be in operation whenever the server is up and open for players.
  • Players, other than those in the Builder’s Brigade, cannot build within the Landing Area.

MJ Notes: Like the Safe Islands, the Landing Area is supposed to help bring the world to life. While things such as NPCs might seem a little extraneous at this point, getting real NPCs working now will help us down the road.

Building Islands[ | ]

Building Islands are a type of Safe Island (along with the Starter Island), where there is no PvP, nor players from other Realms allowed. This setting will not be hard-coded, but selectable by the designers, and, if possible, able to be changed by CSE in-game through the Admin Portal. There may be additional Safe Islands added during Beta 1, but as of right now, there are no plans for additional types of Safe Islands for the opening of Beta 1.

Building Islands are open more often than the Contested Islands. However, to keep costs/burnout of our players down, they are not open as often as the main Safe Island. While this might seem to be unfair, it is truly both necessary and fair. First, the costs for keeping open the Building Islands are a lot lower than they will be for the Contested Islands. Second, we will show what we are doing for our combat-focused players in the coming section on the ****** ******. It’s a win-win for all of us, as I expect time will tell.

They should be constructed for building, meaning that the island is not covered in deep, dark forests, but is instead easy to build on and aesthetically pleasing, with groves of trees, lakes, and hopefully rivers running through the island. Plot size should be large enough for people to build a decent-looking structure. They should not look the way they do on our current building island. To keep things fair and not drive Ben crazy to the point where he runs screaming into the night, all the Building Islands within a Realm should look mostly the same.

There should be plenty of resource nodes scattered around the island in convenient places. The key here is that we don’t want to have players waste time running all over the island just to get resources for building. These resource nodes might be removed, based on what happens with mines and Node Centers.

Build “Node Centers” where all the resource nodes are. Place them so that players are never more than a couple of minutes' run from the nearest Node Center. NOTE: Depending on how our work goes with mines and seamless zone transitions, we might be able to dispense with Node Centers and build resource islands where the nodes would be located for each Realm. We could then spread portals around the Safe Islands for players to use. Mines were/are a BONUS feature for Beta 1, so if we need to cut them for Beta 1, we can. I don’t think we will have to do that, but I’ve been very clear with our Backers about such features.

For the opening of Beta 1, resources should weigh very little, so players can easily carry them back to their building plots. The weight of items should also be something pushed to a global value that can be set by designers, so we could have settings like turn on/off weight, modify all weight by %, etc.

Resources dropped on your plot, or a plot where you have permission (see below) to drop, are persistent. Resources dropped anywhere else disappear in (x) minutes. This will be tied into the permission settings for plots.

The maps for the Building Island should allow for plenty of space between properties, so that players can’t seal off any area by building their homes next to each other on the map. The size of the plots, distance between them, etc. will be determined as more of our Beta 1 tech comes online.

Once a player moves into an area where they can own plots, the player will see the parts of the island designed for actual player building on a map, and this will also be displayed within the world via markers/visual aids. This feature will get replaced by a map-making system during the game’s development, but for now, we want to make it easy for players to find their way around these islands.

Stability will be turned on for buildings in Camelot Unchained for Beta 1. C.U.B.E. will remain as it is for now, without stability. Players are, of course, free to build within the Safe Islands with the in-game system, or to import their buildings from C.U.B.E.

For the opening of Beta 1, players will only be able to have one plot on a Safe Island per account. They can still take plots in Contested Islands, but to limit the number of islands/servers that we will need for Beta 1, we will limit the ability of players to claim multiple plots. However, this limit should be pushed to the ***, so we can change this during tests.

MJ Notes: As per above, having the Building Islands in for Beta 1 is important. Getting both Backers and Bots using the system and trying to break things now, rather than later, fits in with our development philosophy. The biggest addition to our original plans is, of course, the Mines. I’m hopeful that this will be solid enough for inclusion in Beta 1, based on our work on it to date. Failing that, the idea of Node Centers still fits in nicely for Beta 1, and won’t make playing our Beta 1 a pain in the ass for our Backers to the point where they don’t want to log in and help test things for us.

I'd also like to reiterate once more that there is a great deal more information to come, including what the "****** ******" is. It's going to be a win-win for all of us, and will make our combat-focused Backers especially happy, I expect. 🙂

Plots[ | ]

Each plot will have a "total number of blocks" limit. This should be pushed to the *** *** ***. The block limit does not directly correlate to the plot volume; they are two separate things.

Building/destruction time on plots should be able to be set by the designers via the *** *** ***.

Plots have a building height limit. As we’ve discussed ad nauseam, this is to help slow down the prevalence of "certain types of towers," as well as to test the building block limit system, which is part of our Builder and Realm Rewards progression system. This should be pushed to the *** *** ***. While it isn’t enough to prevent abuse/griefing of the building system, of course, it’s a start. In the LIVE game, we will have other mechanics, including the Terms of Service, which will help to discourage the building of such towers and other kinds of intra-Realm griefing.

As per above, stability will be turned on for building within Camelot Unchained, but will remain off in C.U.B.E.

Plot ownership is persistent, unless the plot is abandoned by the player or wiped by us. As for what constitutes abandonment, this is TBD based on both Design and player needs. The amount of time that a plot remains with the owner is something that needs to be variable, so that we don’t end up with the Star Wars Galaxies problem: Tons of empty buildings that just cluttered up the landscape and slowed down engine performance. This is another item that should be pushed to the *** *** ***.

Once a plot is fully abandoned, the blocks crumble. We need to determine over the course of Beta what the best way to do this may be. It would be great if we could have them decay slowly in real time. Now, if this is a major performance issue due to having thousands of buildings on a large island, it is something we can push to the daily server restart (this is still only a possible option, not confirmed at all) for LIVE. That way, it won't affect the game while it is running, other than when the buildings are attacked.

We don’t want players claiming, building, abandoning, and filling the world up with structures just to be griefers, especially if they are focused on “time to penis” (which we know some of them will), as per above. The system for having a plot decay over time is something we will need for later Betas, but is not needed for the opening of Beta 1.

One possible way of doing this that shouldn’t hurt performance is to—just every so often (minute, hour, day, configurable)—apply some damage to the blocks at the top of the plot, and to some random ones throughout (again, all configurable).

Plot permission system should:

  • Allow people to be invited/disinvited to build on the plot.
  • Only people from your Realm can be invited to build on your plot.
  • We should have a setting so a player can automatically give everyone in their guild/warband/etc. permission to work on their plot. The default should not be to give them permission, however, for obvious reasons.
  • Give players the ability to set whether an invitee has permission to:
    • Build
    • Destroy
    • Drop items onto the plot - Players could easily grief each other within a Realm by dropping lots of stuff there, especially during Beta.
    • Take items – Same as above, but in reverse.

Players who are given permissions to do things on a plot will be notified if their permissions have been changed.

Plots on Safe Islands cannot be taken over by other players, unless they have been abandoned, or are freed up by us.

Your plot(s) will show up on a map. For now, we’ll just keep it simple with a marking of some kind on the map. In the future, it will be much more complicated, as it will tie into the defenses/information systems that are built into the plot. But for Beta 1, we'll just put a mark on the map.

You will receive an inventory item, a deed, when you take over a plot. The deed cannot be given to another player, dropped, etc.

If you lose ownership of the plot due to it getting taken by another Realm, you don’t lose the deed. And if/when that plot changes ownership, if it goes back to the original Realm, you are automatically the owner. Since you cannot own multiple plots in your Realm in Beta 1, you would have to release your old plot before you took another one. The number of plots that people can own is definitely a value that needs the ability to be changed on the fly by designers.

If you abandon the plot, the deed disappears.

The plot deed serves as UI element that includes various features.

Interacting with it in the inventory lets you see details about your plot.

Deed context menu options:

  • View Plot Info
  • View plot on map
  • Manage plot (permissions and such)
  • Teleport to plot (for Beta 1 - works with safe area plot only)
  • Clear plot (deletes all blocks on the plot)
  • Abandon plot (give up ownership of plot)

We should wrap the building construction queue interface, as well as repair options, into this menu.

Contesting plot ownership[ | ]

Contesting an unowned plot should be a simple procedure, to be determined over the next few months, and the time it takes to contest a plot needs to be settable by the designers. For now, all we need to do is use the current system, but have some settings, like the amount of time it takes to contest an owned plot, pushed to the ***.

The first person—who is eligible to claim a plot—that gets on a plot is the only member of the Realm who can take that plot while the claiming/ownership process is taking place. This will help prevent griefing from groups that try to take a plot while another member of the Realm is taking ownership. The procedure/time it takes to claim a plot in friendly territory will be different from what it takes when you are trying to claim a plot that is in a contested area and/or is owned by a player from an opposing Realm. The following settings should be pushed to the *** *** *** and/or scripting.

  • Time to claim friendly plot – Safe Islands of your Realm are considered friendly.
  • Time to claim neutral plot – The Contested Islands are neutral.
  • Time to claim hostile plot – Meaning that it is in enemy territory.
  • Add a multiple for a plot being owned by a player from opposing Realm.
  • Players from other Realms can try to slow down/stop the changeover of plot ownership while the process is underway.
  • If players group together, they can speed up the claim of plot ownership for the person who is claiming the land. To make things easier for Beta 1, in order to work together to claim a plot, people will have to be in the same Warband.

MJ Notes: Plot ownership is another one of those systems that will need tons of tweaking over the course of the project. With a game like ours, where land ownership/conquest/building is a key aspect of the appeal, we can’t afford to get this system wrong at launch. Without naming names, we all know certain games that had this problem at launch, and it hurt both their short- and long-term appeal to players. So, whatever system we use in Beta 1 will not be the final system for the game. As always, “Don’t Panic!” if you are worried that the system you see in Beta 1 will be the same system at launch.

We also have to make sure that the land ownership procedure is not one that ends up hurting intra-Realm Pride. One of the ways we are going to do this is by avoiding the “land rush” that has occurred in other games. Plot ownership is not going to be a “first come, first served” affair, as players have to earn their rights to intra-Realm deeds...through deeds!

These rights will not be awarded based solely on amount of play time, which would give the folks with more time to play a distinct advantage. Instead, it will be based on your accomplishments during the time you do have to spend. So, a player that plays for 4 hours and accomplishes a lot will have a quicker path to getting a deed than one who players for 8 hours and just sits around and talks. The same will be true for deed expansion. OTOH, players can go into either the neutral territories or enemy territories and claim land without needing a deed from their Realm’s king. This is something we have been very clear about from the beginning of the Kickstarter, and it once again represents our dedication and desire to stick to the principles/goals that we laid out four years ago.

Of course, this is only a Beta 1-focused document, so things like property taxes, building upkeep costs, and other gold sinks are still on the table. These will be discussed at more length with our Backers when we get closer to implementing them in the game.

Contested Island(s)[ | ]

  • We are starting with just one Contested Island, but we will add more during Beta 1, as per the ****** ****** (below).
  • The main Contested Island needs to be large enough to have buildings and RvR, but not so large that players have to run 30 minutes to get to the fight. The time to get into the action and the size of the islands is still TBD, based on tech and design concerns/features such as the ****** ******. I’d consider a large island with a long run time if we decide to put portals on the islands, so people can get to the action quickly if we want to activate them for specific tests.
  • Contested Islands do not run 24x7, and are only opened up for specific times and/or events. This is, as per above, in order to keep the AWS costs manageable and to prevent player burnout.
  • Contested Islands have a limited number of plots that can be claimed by any Realm. Once a plot is claimed, the normal rules for a plot will apply.
  • Members of other Realms on the CIs can destroy blocks/buildings and claim plots belonging to an enemy.
  • Contested Islands are where we will see the first pass of the landscape-changing tech when one side occupies certain places on the map, or when ownership of a specific plot changes. This could slide to a BONUS feature if there are technical issues.
  • The first Contested Island will not be designed just for beauty, but rather for testing the kind of gameplay we want to test at the opening of Beta 1.
  • The Contested Islands will have a number of different portals, depending on where we want people to start. These should be settable via spreadsheet as well as through the zone editor. If we have an Admin Portal, we should be able to do it that way, as well.

MJ Notes: Not a lot for me to add to this section, other than to say that there is a lot more information about what “****** ******” is, and what it means for Beta 1 testing and our Backers. That will all be revealed in the sections to come. 😊 Sorry to be a big tease, but the meaning of those two hidden words will have a huge impact on Beta 1 testing and beyond!


Redacted as BONUS material.

Crafting[ | ]

It’s crucial that crafting in Beta 1 doesn’t feel like a job, especially with the frequent wipes attendant to Beta testing. Important settings will be laid out for the designers, so that we can easily speed up/slow down the rate of all aspects of the crafting system. How much faster it will be in Beta than when we go LIVE will be determined by the length of specific tests, as well as the goals or results of those tests.

Designers should be able to set how many Voxes (hereinafter Voxen, whereas a group of them is called a Chorus) a player can own. To start, each player should have their own Vox, but only one. If they put the Vox on the ground, they should be the only one able to pick it up. If they leave the game without picking up the Vox, the Vox should disappear from the game and get returned to the player's inventory. This is to prevent the “field of Voxen” we have seen during earlier tests.

All players in the game will have access to the crafting system in Beta 1, unless we hit the bonus goal of having a separate crafter class for Beta 1.

1. The Vox Magus[ | ]

The Vox needs to be redesigned for Beta 1. We should keep within the same basic concept for it, but it simply needs to have a more interesting look/sound in the game.

We need to create an icon for the Vox Magus in the player’s inventory that looks like a box. Yes, I know, players will say that it is a Vox in a Box; this is intended. 😊

When the player puts the box on the ground, let’s have an animation/effect/sound for the box becoming a Vox. This should be something really cool, and if we do it right, will be a “watercooler” moment for players. We should play the same animation/effect in reverse when a player goes to pick up the Vox.

When the Vox is fully expanded and gets up and running, it should always have VFX/SFX playing.

I’ll write up a document on how the crystals in the Vox will react based on what the Vox/player is doing at the time. That is an important part of the Vox concept, and I need to cover it in a separate document.

We want a more fantasy-sounding Vox Magus rather than a sci-fi Vox Magus.

As per the original checklist for Beta 1, having a ‘/’ interface for Beta 1 is sort of acceptable, but not desirable at all. Currently, the Backer and Mod Squad member Mehuge is coding a cool interface that will obviate the need for slash commands.

While a Vox cannot be picked up by anybody other than its owner, it can be damaged by other players. We might allow players from another Realm to steal a Vox, but that is not something we will do for Beta 1.

2. Taking/Harvesting/Gathering[ | ]

Nodes should be scattered around the world, but each Safe Island should have the appropriate raw materials for their Realm. We should not make people go back and forth between islands to try and find raw materials. That’s no fun at all during Beta 1.

The main Contested Island should have some special materials to reward people for going there.

Players should be able to go up to Resource Nodes, such as for Metal, Wood, Stone, Leather, Cloth, and possibly Infusions, and take raw materials from them.

We need to determine which raw materials will be available for the launch of Beta 1.

We need to add picks and other associated items, and you will need to have them equipped to be able to get materials from the nodes.

While the final list is TBD, the simple list would include things like a pickaxe, a saw, etc.

Need sound effects to match the supported actions.

Need animations for the supported actions.

For Beta 1, reduce the weight of all materials or adjust encumbrance/carrying capacity so players can carry lots of materials for crafting and building. This will change as we move through the Beta phases to more closely approximate the LIVE game. These settings should be pushed to the Master Spreadsheet/*** *** ***.

Resource Nodes should be recognizable to players at a distance.

We should group Resource Nodes together in Resource Centers, to save players from having to run around looking for them needlessly. We have a very flexible system that we can use for laying these out.

However, it would be acceptable to put mining nodes by mountains in addition to this type of grouping.

We should be able to see some kind of sign indicating Resource Centers from a distance.

When you take something from a Resource Node, we should have a basic animation/sound that can be reused for all the types of Resource Nodes.

Taken items should show up in a player’s inventory as a pile with an icon, text (raw iron, uncured leather, etc. depending on the material type), the amount, and additional mouseover information about the item. NOTE: This section's bullet points are subject to the work already being done on the game.

The item information should be chock-full of actual information in Beta, some of which will be hidden for launch. Like many other things in the game, we promised to give our players all the necessary information they need to help debug/playtest the game during the testing stages, but to make the LIVE game work differently.

3. Purifying[ | ]

This part is truly a placeholder for the next version of Purifying.

Players put substances into the Vox Magus. The Vox will process those, and will spit out the purified substances.

As per the Purifying document, every so often something special will happen. For Beta 1, we should keep it very simple. Sometimes it will speed up, sometimes it will take a little longer, and sometimes it will yield extra purified substances.

Purifying of materials for blocks is confirmed for Beta 1, but is simplistic in design. This could change, but for right now, it is not a complex thing.

Like every other part of the crafting system, the Purifying System is not intended to be a time sink during Beta 1.

4. Shaping[ | ]

Alloy-making is intended to be one of the most interesting parts of the crafting system in Beta 1 and beyond. It cannot be the full “anything + anything = something” system in Beta 1, but will use recipes + infusions. It will be a good approximation, and better than we initially intended for Beta 1. This is one of the things that will be better in Beta 1 thanks, in part, to the delay.

The Alloy/Infusion System gives the players an almost unlimited number of combinations to work with.

For Beta 1, a player can combine a number of substances into an alloy.

In order to give the player more options when creating the alloy, the system will allow players to add the infusions into the alloy at the same time as they create the alloy.

5. Making[ | ]

The Making part of this system is intended to be the least important for Beta 1. This is yet another item that will be more powerful in Beta 1 than we originally intended, thanks to the delay and some great work from the programmers. We already have a system in which we can "build a sword from a handle + blade." Since it can just have the rule of "you can build a weapon from an alloy," it also supports what we want to be able to do further down the road. For Beta 1, if we decide to go down the route of setting up the recipes for items like swords/arrows/etc. to use all the fancy subparts, we'll also want to tweak the item stat scripts.

Social Systems and Grouping[ | ]

1. Overview[ | ]

Grouping and social systems are an important part of any MMORPG, old-school or not. For Beta 1, we are going to focus on some key parts of these systems, while laying the groundwork for a much more advanced system to be implemented through the rest of Beta. We want to emphasize that we are doing some things quite differently from many of our predecessors, yet are staying true to our old-school ethos.

2. Guiding Principles[ | ]

The concept of Guiding Principles for a system is something that MJ has used for, well, longer than he would like to think about. It has served him well in the past, so when he laid out the initial vision for this part of the game, here’s what was most important to him.

  • No multi-guilding per character – We said this during the Kickstarter, and we have to stick to it. In MJ’s opinion, and this is echoed by a ton of writers/posters, multi-guilds have contributed to the decline of meaningful guilds in MMORPGs.
  • Restore Guild Pride – No matter the size of the Order, we need to help restore a feeling of being part of something special when you are in a successful order. This is not just a matter of giving out prizes and progression ranks, but also means that we need to look out for/prevent the problems that hurt guild pride, such as people looting guild bank accounts.
  • Big or small, we welcome you all – We can’t base this game around the concept of mega-guilds (as some other games have done), or even just guilds, if we want to continually attract and retain new players. We need to recognize that our players may want to play solo, or with a small group of friends, or in Orders. We need to understand this, support it, and try to tailor the perks for each group in such a way that people can enjoy this game no matter what they want their grouping or solo play-style to be.
  • We need to tailor our content to all Orders of all sizes – Now, this sounds easy, but it isn’t. For example, we can’t reserve all the cool stuff for the bigger or more successful Orders. We can’t just give perks/benefits to the larger Orders, or make the perks so hard for the smaller Orders to get that they become frustrated. Size should matter, but so should dedication/longevity.
  • A pure RvR game needs to do some things differently than a PvE-based game, and we need to accept and own that.
  • We need to create a sense of belonging/home/family within the Order– Give the Order the tools it needs to help build a social network between people. If we can do that, players will be thrilled with our Order system, even if it is a little less flashy than some other systems.

3. Group Types[ | ]

Camelot Unchained will launch with five group types. These group types will be described in further detail below, but for the purpose of reference and familiarity with naming as you read this document, they are listed here:

  • Solo Player – If you are unsure what the concept of a solo player is doing in a group-focused doc, well, just remember what MJ has said even before the beginning of the Kickstarter: We want to be able to support the solo play-style along with the group play-style.
  • Warband – Think of these as parties with benefits. The features built around parties are geared toward those players who want to group with their friends, but don’t want to go to the trouble of forming an Order (guild).
  • Battlegroup – Grouping of Warbands that join together on a temporary basis to help in RvR.
  • Order – The premier group within Camelot Unchained. We all know the importance of guilds to MMORPG gaming over the decades, and while there has been a decline in their overall numbers, we want to try to reverse that trend in our game. Guilds were an important part of the success of Dark Age of Camelot, and with WAR, MJ and Mythic tried to take guilds to the next level through the “Living Guild” concept. While this game is not WAR (FYI, our total budget is less than a one-year spend on that game), we think we have some innovative ideas and support functions that will excite those who want to see Orders play an important part in Camelot Unchained.
  • Campaign – A temporary alliance of groups that exists to achieve goals through missions with multiple group and/or crowd-sourced participation from players throughout the Realm. ☺

4. What to expect for Beta 1[ | ]

For Beta 1, we are going to focus on some key parts of the grouping and social system: Warbands, Battlegroups, and Orders, which are our version of parties, raid groups, and guilds. There will be a Minimum Viable Product set for each of these groups when Beta 1 opens, just as we said there would be. As we move through Beta, we’ll begin locking down certain features for the LIVE game, but that lockdown won’t happen until the end of Beta 3. In the meantime, enjoy the ride as we look to create a grouping system that will be one of the most useful and deepest systems of its kind. We’ll do that without resorting to adding a lot of features or tons of cosmetics, but will instead build something that meets the needs of our players. We’ll do that via systems that make it easier to coordinate attacks in RvR, while still facilitating everything from solo play to the kind of coordinated mass attacks (not keep-trading zergs) that will make Camelot Unchained the next great RvR MMORPG.

5. Personal Features[ | ]

So much to cover here, so let’s just focus on some of the features of our social systems that apply to all players.

  • 5.1 Friends / Enemies / Connections / Blocked Lists

Solo Player – If you are unsure what the concept of a solo player is doing in a group-focused doc, well, just remember what MJ has said even before the beginning of the Kickstarter: We want to be able to support the solo play-style along with the group play-style.

The friends list in game is mostly self-explanatory, and you will have a lot of power to tailor your list with the permissions system that is discussed below.

The enemy list works similarly to a friends list, with the exception that it works for members of an opposing Realm. But that’s not all! You can add enemy groups to your enemy list, as well. You are not able to communicate with an enemy through any in-game means, so you will not be able to PM an enemy, or send them mail through this list. However, you will be able to see how many times you’ve killed that player or they’ve killed you. You’ll know if you’re mutual enemies. You’ll be able to initiate bounties more easily on an enemy by selecting them from this list.

Like the friends list, players will have a lot of control regarding this feature.

The connections list will give you suggestions of players from your Realm who have either grouped with you in the past or have interacted with you, whether it be via trades, fighting alongside you in a battle, or more. This list can be browsed to find that awesome player you grouped with the other day. You can add them to your friends list if you forgot to do that, and/or invite them to your Warband or Battlegroup! This ties nicely into our Daily Reward system, and will feed into additional systems as well.

The blocked list will allow you to block a player on your Realm, with several configurable options. You can block their text chat, block voice chat, block social posts, or block all communication.

  • 5.2 Personal Bulletin Board

Your personal bulletin board is the place where you can post your own personal bulletins, messages, text, images, and videos, as well as read and comment on a consolidated view of bulletins posted by others. Your bulletin board will allow you to view bulletins posted by any of the groups you are in that have this feature, as well as your friends.

  • 5.3 Personal Record

A player’s personal record contains a history of activities the player has taken part in while playing. This log will be searchable and filterable, to facilitate ease-of-use in navigating the information given. The record will include, but is not limited to, players fought, kills, items crafted, materials refined, resources harvested, and more.

This personal record can be made public or viewable to a configurable set of permissions categories. More on the permissions system below, in the Shared Group Features section. By default, however, this information is set to private viewing by the player themselves only.

  • 5.4 Personal Mail

Every player will have a personal in-game mail account, to which other players on the Realm can send messages. Mail formatting will work similar to bulletin posts in that they may contain text, embedded images, and video. However, they must be linked from approved sources or screenshots directly from the client screenshot function. Mail will not have any attachments, you will not be able to send currency, items, or chocolate-chip cookies through the mail. If you want to trade, you’ll have to set up a contract or meet the other player in-game.

To be completely clear again on this, no communication can be made cross-Realm through any systems provided by CSE, and this includes personal mail. You can only send mail to members of your Realm on the same shard.

6. Shared Group Features[ | ]

All of our Beta 1 grouping systems share some social features. They are listed here to avoid repeating the same information for each of the Beta 1 group types in the sections below.

  • 6.1 Permissions & Permissions Management

Shared by: All Groups We’ve often talked about providing a mass of information about the game and its players to the public through our API servers. Camelot Unchained will be providing an unprecedented level of data accessible to web services, from which players and third-party application developers will be able to provide external inventory management tools, detailed metrics, and more. So much so, you will be able to equip items onto your character from your inventory while not even logged in to the game. This functionality is available through our public API today.

With this level of data availability, the privacy of all players and groups is of the utmost important to us. To this end, a robust permissions system will be built at the core of the Camelot Unchained’s social system tech.

  • 6.2 Ranks

Shared by: All Groups In order to facilitate and simplify permission management for sub-groups of players within a group, ranks can be created that are assigned a permission set. Each group type can create a large number of custom ranks (the amount will vary by group type). Each rank can be named, and in some cases an icon or other visual identifier may be assigned as a designator for members of that rank. These ranks can be created or customized by any member that has a rank with the appropriate permission.

  • 6.3 Chat

Shared by: All Groups What kind of MMO would this be without a chat system? Features discussed here about chat, both text and voice, will be limited to how they relate to groups. Like most of the social features we are building for Camelot Unchained, we want to give players as much control and flexibility as we can.

Each group will have, by default, its own private text and voice chat channel, and will have the ability to create more. By default, these channels are restricted to allow all members within that group access; this can, however, be changed by any member in a rank with appropriate permissions. Ranks can be assigned permissions specific to chat to enable moderation features, disable who can/cannot speak, and more. The chat channels may also be configured to enable or disable certains features as desired by the group, such as disallowing the embedding of images or videos in chat.

While a player can be in multiple text chat channels, a player can only join a single voice chat channel at any time. We will strive to make joining voice chat in the game as simple as possible. Each text chat channel will allow for an associated voice chat channel by default, and a player can click a single button to join the associated voice chat. Each of the group interfaces will also have a one-click button to join the default voice chat channel for that group!

  • 6.4 Metrics

Shared by: Solo Players, Warbands (Permanent), Orders, Campaigns For awarding player progression rewards daily, as well as for our own internal metrics system, we will track all significant actions made by a player and group throughout the day. Much of this data will feed into all of our different grouping systems, including solo players as a group of one. This data also can and will be used to enable group progression; more on that later.

With all this data being tracked, recorded, and logged down into our databases, wouldn’t it be great to be able to see this data yourself? Or to make some cool websites, or a herald of sorts, to look at all this sexy data? Of course it would. So, a large portion of this data will also be made available for consumption through our API servers. It is important to know, however, that not all data is equal, and while some bits may be made available immediately, other more gameplay-sensitive data may be delayed, so as to not adversely affect ongoing gameplay. Additionally, data may also be redacted, fully or partially, as per player and group permission settings.

  • 6.5 Heraldry

Shared by: Warbands (Permanent), Orders What better way to rep your group than by showing off awesome heraldry on your equipment? Heraldry can be designed in the Social UI by a member with the appropriate permissions. This heraldry can be displayed on your character through special cloaks, tabards, and shields! Want to decorate your castle as well? Place your heraldry on various types of banners and flags throughout your plot.

Heraldry item decals can be mixed and matched with any of the groups that you are a member of, to display on the appropriate items. For example, you can wear a cloak and Tabard with your Order heraldry along with a shield adorned with Warband heraldry.

Different groups will also have different levels of heraldry available to them depending on the type of group, with Orders (Guilds) having the most varied customization options, including special work commissioned from CSE.

  • 6.6 Accolades & Achievements

Shared by: Warbands (Permanent), Orders, Campaigns Who doesn’t love getting gold stars? Groups and members of groups can both be awarded various accolades and achievements. These may come from several different sources, though this document will only discuss those related to grouping.

Accolades will come in the form of Banner streamers and/or heraldry modifiers. These will be shown on the player’s profile in-game as well as on the game’s stat-tracking website, if the player has made their profile public.

The leadership of a group can create accolades and award them to members as they see fit. Say your members have really been putting in a great effort: You can reward them by giving them a gold star on their heraldry!

Accolades and Achievements can also be earned through completion of tasks in a Campaign. More on Campaigns will be discussed later in the document.

  • 6.7 Social User Interface Features

Shared by: Warbands (Permanent), Orders, Campaigns Communication is vital to any size of group that wishes to work together toward any type of goal. Instant communication through text or voice chat is not enough to coordinate with a group of players who may not all be online at the same time. Several UI features will be built specifically to facilitate this additional communication.

Groups will have an in-game interface from which you can view the standard information, such as members, ranks, permissions management, and other administration tools. In addition, each group will have a bulletin board, on which those with the appropriate permissions can post messages viewable by the group. Posts can have permissions set to restrict viewing. As the UI for the game is built out of the web, you can post images and videos on your bulletin board, which will embed and can be played in-game! Members of the group can make comments and have a discussion about your post as well. Yes, basically like some of those big social media sites everyone knows about.

Groups will have access to private email lists in order to compose emails to all members of the group or to special ranks.

Groups will have access to an in-game calendar, on which they can plan events. Events can be placed on the calendar with links to a specific post discussing the events. Events viewing permissions can be set by rank, so that only certain ranks may view that specific event posting.

The social interface for a group will also contain a very robust member roster. The roster will allow searching, sorting, and filtering users using many different keys, such as name, race, class, time in group, online time, contributions, and more. MJ Notes: Talking about social systems/features for Camelot Unchained is a bit of a minefield. We want to focus on the features that the vast majority of our players will find advantageous to their gaming experience, and not features that might seem like they belong in an entirely different type of game. For Beta 1, we believe that this focus must be on a limited number of systems (three, in this case), which will be added to and iterated on throughout the entire Beta process. We also hope, as we usually do, to bring some new and/or additive features to well-known and very old-school systems, such as Guilds/Orders.

7. Warbands[ | ]

Size does matter in social systems, and Warbands are our smallest group size. They are more than “parties,” as parties in MMORPGs have merely been an ephemeral grouping of players, that are, like tissues, eminently disposable. In our game, while Warbands can still be ephemeral, you can instead make a Warband permanent by naming it. You can think of them as a semi-permanent task force, free company, etc. that has a little more in common with guilds than with the usual MMORPG party construct, but that doesn't have the vast majority of the perks that guilds/Orders possess, including things like plot ownership.

The addition of named/permanent Warbands is a big addition to the genre for a number of reasons, including the ability for players to have an easy way to group with various friends/Realm-mates without having to constantly create a new party/Warband. And for those keeping score, well, this also allows people to create Warbands that become famous in their own right, without a forced attachment to a larger structure like an Order. It is important to recognize that the way people play MMORPGs in 2017 and beyond is different than the way they played in 1999, 2001, 2004, etc. While we are making an “old-school” game, we have always said that we plan on adding/using features in the game that make for a better RvR experience, and that do not “dumb down” the genre or are too hand-holding. Allowing small groups of people to more easily play with their friends and family—and also achieve recognition for doing so—fulfills all those requirements.

For Beta 1, Warband features should include the following, in addition to the features covered above.

  • Players can create both temporary and permanent versions of Warbands. Permanent Warbands must be named.
  • Permanent Warbands will have a maximum roster size that will be large enough so people can come and go, but too small to truly compete with Orders. Plus, as we said above, the perks for Warbands are quite limited when compared to Orders.
  • Warbands will support up to 8 players for the start of Beta 1. As we have been saying in our updates, we will experiment with different maximum sizes of Warbands until we get it—like Goldilocks’ porridge—just right.
  • Active Warband member health and status is shown on screen in-game, and updates in real time. We will be using this and other UI features for the Beta process to ensure, as we have said, that players will have the relevant information that they need to help us test/debug the game. There is no guarantee that a feature like this will be a permanent addition to the game, especially as we will be working on “Healer Vision” after the start of Beta 1.
  • A player can be a member of multiple Warbands, but can only be active in one Warband at a time. Active status is for the purpose of gameplay mechanics: The player shows up in the group on the Warband UI widget, members of that Warband can see their health and status in real-time, and skill/group effects can affect this member. As an “inactive” member of a Warband, the member can still see and participate in chat for the Warband, and can join any Warband they are a member of at any time to become active, if there are any available slots.

MJ Notes: The addition of permanence to Warbands is an important one for our players. If we’re right that it hasn’t been used before (please tell us if you know of an MMORPG that has used such a feature), it’s something we expect will be picked up by other studios/games. Given the type of game we are making, we need to have a Warband system that supports and enhances the experience our players will have in the game at launch.

8. Battlegroups[ | ]

Battlegroups are our version of the typical MMORPG “Raid Group” for Camelot Unchained. A Battlegroup is a group consisting of an unlimited number of Warbands. Unlike Warbands, however, a Battlegroup may not be made permanent: it exists only as a temporary association of Warbands for organizational purposes.

The role a Battlegroup fulfills in Camelot Unchained is to allow larger groups of players who may or may not be affiliated with each other through another group type to have a temporary shared chat, voice, and permissions management tools.

Battlegroups can create and manage temporary Warbands in order to accommodate adding players who have not already joined as an active member of a Warband.

Beta 1, Battlegroup features include:

  • Players can create a Battlegroup.
  • An unlimited number of Warbands can be invited into a Battlegroup.
  • A Battlegroup UI will be implemented to show—at a minimum—Battlegroup name, member Warband names, and Warband member names (that’s not at all confusing to say, right?).
  • Chat, as described under the Shared Features section.
  • Simplified Ranking system.

MJ Notes: “Raids”, as they are more commonly known within MMO gaming, are not part of Camelot Unchained, because our game is all about raiding the enemy’s lands. As such, we need a way for people to communicate effectively with groups larger than a Warband. The integration and connectivity between players and our grouping systems will help set our social systems apart from those in most MMORPGs, especially the older MMORPGs that we generally look back on fondly. As we have always said, while we want to create an old-school game, we also want to look to more modern games for features that will add value and enjoyment for our players.

9. Orders (a.k.a. Guilds)[ | ]

Orders in Camelot Unchained are similar to guilds in other MMORPGs. An Order is a group of a limited number of players, which can, among other things, create and manage its own permanent Warbands. For Beta 1, Orders are really on the Most Minimum Viable Product (MMVP) path, because they will be less important than the other grouping systems at that time. OTOH, we know we have to lay the groundwork for what will come after we move into and through Beta 1. Guilds were a very important part of the success of older MMORPGs, and while we don’t expect guilds to have the same level of importance as they did back in the day, that doesn’t mean we don’t want to create a great system to support them. Our intent with the Order system, when we go into detail on it, is that those folks who love guilds will look at us and say "That'll do, pig. That'll do."

That said, for Beta 1, we have an MMVP for Order but should include the following. For Beta 1, Order features should include the following.

  • Players can create an Order.
  • An Order will have a limited number of members, which is TBD at a later date, along with some other surprises.
  • Order name displayed on character nameplates.
  • A player can only join a single Order.
  • Chat, as described under the Shared Features section.
  • Ranks – Ranks have both a symbolic and a visible meaning to players, as they come with physical items that display their ranks.

Okay, now that doesn’t sound all that exciting, right? Nope, but keep in mind that Orders are going to be the most minimum of minimum viable products for Beta 1. However, because we love you Backers so much, and because we don’t want people showing up at our office, torches burning, screaming “Bring us the heads of JB and MJ!” we’re going to lay out just a wee bit more on what you can expect from Orders as we move through Beta.

9.1 Perks Among the perks that come with being part of an Order, there will be:

  • Plots – Orders that have reached a certain level can claim their own plot. These plots are the largest, and can come with the most cosmetic perks, of any group.
  • Banks – Guild banks have been a fun but problematic item, at times, in other MMORPGs. We have to create a better system for them.
  • Shops – Orders can set up their own shops for their own members, and for outside folks to access.
  • Order heraldry – Covered above.
  • Progression system – We don’t want to go into detail about this now, but the progression system of Orders will be similar to that of individual players. Reread the Guiding Principles for a hint on how this can work.
  • Caravan routes – Orders can arrange for caravans to deliver supplies to them from individuals and/or caravan masters, depending on size.
  • Clothing – Orders should be able to design their own clothing and register it with the Realm Keeper of the Orders. In order to register a clothing mark, the Order must reach a certain level within the game, and the mark has to be unique from other marks.
  • Order Hall - More details on this during Beta 1.
  • Calendars – Duh, right?
  • Private emails – Nuff’ said.

But wait, there’s more, a lot more! However, we’re keeping our big mouths shut for now on this, because, well, the neighbors have big ears and aren’t afraid of talking about how they invented something months or years after we talk about it. OTOH, I think what we have talked about above is enough to show our dedication to making sure that Orders/Guilds have an important place within Camelot Unchained, now and forever. But trust us: We have some stuff that will once again surprise people and cement our planned Order system as one of the most interesting systems in MMORPGs, even if we don’t have all the cosmetics and other stuff that were in other games with much deeper pockets.

MJ Notes: As per above, Orders are going to get a lot of love from us as we move through Beta. Even though we don’t have the resources to try to create a system that would surpass some of the great guild systems of other games, we are going to create a system that is tailor-made for our RvR-focused game. We will be discussing our plans for that as we move through Beta 1, and again, consider this truly an MMVP, and really, a bonus for Beta 1.

10. Campaigns (not for the start of Beta 1)[ | ]

While not a feature for the start of Beta 1, we are including Campaigns in this document in order to give a more complete picture of grouping systems for Camelot Unchained.

Campaigns are a completely new system designed for Camelot Unchained. A Campaign is a temporary grouping of players working together to achieve one or more goals. They are a flexible group, whose members can be any of the other permanent group types. This includes solo players, Warbands, and Orders. Campaigns exist to achieve goals through missions, with multiple group and/or crowd-sourced participation from players throughout the Realm.

A Campaign can be created in order to attempt large-scale wars, sieges, or the construction of massive castles. They may also be used for something as simple as a group of friends working together to craft items as a team, while keeping track of their own goals and perhaps some fun competition between each other. They are designed to encourage cooperation within the Realm, and allow for both game- and user-generated additional content, while also providing secure built-in features to organizations. They will allow for Campaign creators who wish to organize large events that involve large amounts of resources, weaponry, castles, and siege equipment to lend the use of these resources. This way, they won’t have to risk putting their assets in other players’ hands with no guarantee of return through a “trust trade”.

  • 10.1 Formation

Campaigns are created by players through talking to an NPC in the capital city to register the Campaign. They come with a cost, a start date, a duration, and a listing privacy flag—public or private—that must all be set upon creation.

A public campaign will be viewable to all players in the Realm, and the Campaign will accept all members into the Campaign from the Realm. A private Campaign will be unlisted, and invites must be sent out to individuals and/or accepted by the Campaign leadership.

  • 10.2 Assets, Property, and Permissions

While a Campaign cannot ever own any assets itself, it can be given temporary control over them for the duration of its existence. This will include plots, structures within them, and also large items like siege equipment.

Permissions for access and use of any loaned property can be configured by Ranks within the Campaign.

When a Campaign concludes, all assets and property that were used by the Campaign are retained by the original owners. This excludes disposable items such as swords, armor, arrows, etc. These disposable types of items, if given to other players during the Campaign and not returned, will remain with those players. Which is why we have the concept of a Campaign store and currency, which will be discussed later, as a way to distribute these types of items safely.

  • 10.3 Ranks

Like the other group types, a Campaign can create custom ranks with defined permission sets to assign to its members. Ranks can be assigned to a group as a whole, or to individual members.

  • 10.4 Missions & Contracts!

Campaign commanders can create missions for users, and give out rewards for completion of and/or participation in these missions. A Campaign may contain one or more missions at the same time, and missions that have a completion objective may unlock a follow-up mission upon completion, creating a chain of missions. There will be many different types of missions that can be configured and offered by a Campaign, but for this document, we aren’t going to talk about them yet.

  • 10.5 Currency, Progression, & Shops

More on these unique features of a unique system during Beta 1.

  • 10.6 Rewards, Accolades & Trophies

With all this talk of missions, what do you get for completing them!? Campaign commanders will be given the option to give out all kinds of rewards for completing missions, and for participation in the Campaign as a whole. More information about this will be revealed during the course of Beta.

11. Social F.A.Q.[ | ]

To answer a bunch of inevitable questions:

  • “Can an Order create a permanent Warband and invite a non-Order member into it?” Yes.
  • “Can this Warband have a permanent member who is not also a member of the owner Order?” Yes.
  • “Can a player own multiple Warbands?” Yes.
  • “Will it cost anything to create a group?” Not for Beta 1.
  • “Do you have to talk to an NPC to create any group?” Not for Beta 1.
  • “Are we planning on tying this into Facebook, Twitter, and other social networks?” That is not our focus at the present time.
  • “Can I be in multiple Orders?” No. MJ believes that is one of the things that has hurt the viability and attractiveness of guilds in modern MMORPGs.
  • “If I have an Order called The Arthurian Knights of Camelot, can I stop people from using the word Knights in their Order names?” No. If you have reserved that Order name, other people can’t use that full name in their Warbands or Orders, but this doesn’t apply to the name’s component parts. This way, your Order’s full name is protected, but people can still use the words in other names. Otherwise, there would be the equivalent of a land rush for words.
  • “If I reserve an Order name, can I prevent people from using our name with soundalikes, you know, like The Syndicate and The Sindicate?” Yes. That will involve Customer Service, but yes, we will enforce things like that. OTOH, your reserved name isn’t protected from abbreviations, leet speak, etc.
  • “Will players be able to quickly switch between Warbands to gain a tactical advantage during a battle?” No, that would be too easy and way too hand-holding for us.

12. Closing[ | ]

As per above, this is not the final version of this document, and is not guaranteed to be all-inclusive of all the features you will see in Camelot Unchained at launch. Throughout the beta testing phases, changes will be made. While we might not have the resources of most other MMORPGs, we can still create really good and robust systems without a lot of effort, compared to other things that we will be creating for the game. And, if nothing else, the use of the slash commands will allow us to get these commands in earlier and give a lot of players a sense of “deja who?”. ☺

P.S. Don't forget to thank the man with the coolest name in gaming, Mr. James Brown (JB of course), for his effort not only in writing this document (I just edited/added a few flourishes), but also in leading the design effort on these systems. More are still coming!

Overview - Beta Testing & the Dragon Circle[ | ]

What follows here is an overview of what our Beta 1 testing (and beyond) will focus on, both in terms of the lore of the game and in terms of some of the systems and mechanics we will use to get into and through our Beta 1 stage of testing.

We have been purposely vague with our Backers about what Beta 1 will entail. Now, we did say we’ve been purposely vague (so nobody should be surprised by this statement) in order to, among other things, make sure that we can deliver on what we promised. Given the delays that development of this game has had so far, we didn’t want to be in the position of having to scale back our Beta 1 plans in order to speed up the delivery of Beta 1. There were also other important reasons we wanted to keep some things to ourselves.

As our Backers know, over the last few weeks, the team has been in a sprint/push to deliver on some of the required elements for what is covered in the next few sections of this document. That work is moving along nicely, and we are now comfortable enough with the progress to talk about these things with our Backers.

The Pre-Alpha Test days revolved around a small area with lots of fun gameplay. As we moved through that phase and into re-abilitation, we no longer had that same kind of area or fun experience. During Beta (especially Beta 1), we must have more of this type of testing and gameplay, both to reward/restore the faith of our current Backers as well as to get a higher turnout for the tests. The former is one of the ways we say thanks to our Backers, and the latter is a way to put more pressure on our systems, from both technical and design perspectives.

As part of the Beta testing process, we will present a series of tightly-focused testing areas/islands/games for the players. They will be built around the lore of “The Dragon Circle,” which is our version of the Olympic Games. Please see the Becoming™ story (coming soonish) about that for more information, as well the section(s) below.

For Beta 1, we should have a test open every weekend, but not the way we currently handle them. In order to minimize the financial burn, as well as the impact on the team, most weekend tests will be open for one window on Saturday/Sunday, instead of staying open for 24 hours. We may also do some focused weekday tests, as needed/warranted, when we move closer to Beta 2. The exception here would be the building areas, which we could have open more often and for longer, as per other sections of this document.

  • In keeping with our principle of not treating our European brethren as second-class citizens, we will reserve enough time so that players coming in from Europe will be able to play on “their” Saturday night, and not just North America’s Saturday night. We will also be hosting tests on both European and US-based cloud servers.

We must have a “Break the Build” test with ARCs and Backers no less than once a month, to make sure that nothing bad has crept into the code base in the previous month. Most of these tests will be on the weekend, to ensure maximum player participation. While we will be able to do these tests with ARCs, holding them with players is even more effective, especially when we want to be able to say that we have 2K real players in a battle at one time.

  • We should be able to have Break the Build tests with our ARCs once a week, during the week, to help minimize the probability of something bad sneaking into the code base and then finding it during a weekend test.

A player’s participation in our Beta tests needs to be recorded on their account and easily accessible to us. We want as much information as possible. Although what we'll specifically need is TBD, at a minimum, from a meta viewpoint (not class-related actions), we need to be able to track:

  • Number of tests participated in
  • Which tests participated in
  • Amount of time participated
  • Number of actions taken

Information such as the above will be used to reward players for helping us during Beta 1. (The needs of Ben and I for a metrics system and other tools to help balance the game or a class are outside the scope of this part of the document, but they are also needed for Beta 1.) The rewards for helping us during the Beta process will vary from temporary cosmetic items to permanent items, tier upgrades, and even cash rewards. As always, no items that Backers can earn during the Beta process will grant any advantage in the game, and will not be part of any cash shop for Camelot Unchained at launch or afterward. These rewards are one of the ways we will thank our Backers for helping us get Camelot Unchained ready for launch.

MJ Notes: While this is a fairly short section, it is arguably one of the most important sections in this document, as the principles discussed here will be the foundation for much of the activity that players will experience during the majority of Beta 1. We made the decision a long time ago to make sure that the Beta experience for our players had a higher quotient of fun than they might have expected, especially after what we did in Alpha. As we have said even before the beginning of the Kickstarter, if this game is to succeed, we need to get as much player feedback/input/testing as we can during the entire Beta process. Many other folks haven’t been very successful in doing so with games that were not feature-complete. We are certainly not feature-complete, as we said we wouldn't be, and we have to be a lot smarter and make a greater effort to engage our Backers and encourage them to join in the fun and frolic. How we are going to do that is laid out in the next two sections. However, the most important Guiding Principle for Beta 1 is that we have to be willing to go the extra mile to reward our Backers for their patience, understanding, and support—and we are going to do just that.

The Dragon Circle™[ | ]


Dragon Circle logo

The Dragon Circle is a lore-based construct that will tie all of our Beta testing areas together. It is not intended to create a lot of work for the programming team before Beta 1. The TL;DR (for those that skip to the next section) is that the Dragon Circle is a mixture of the Olympics and the Hunger Games that is essentially a lore-based “skin” for our Beta 1 testing.

We will create a series of areas/arenas/scenarios that will be available to the players. While they will fit in very nicely with the lore of the game, their main goal is to help us test various aspects of the game. The Dragon Circle is not a marketing gimmick, but is really a way to both stress test our system and give our Backers something fun to play in while doing so. Within the Dragon Circle, these scenarios are called Dragon Challenges, and they can be anything from 1:1 matches to large-scale sieges.

  • The Dragon Circle is not meant to replace the main Contested Island, of course, but rather to provide more focused test areas, as well as a way to change up Beta testing for our players. It also gives us a great framework to build upon as we add new test areas that also fit in nicely with our lore.
  • The Dragon Circle, and the Challenges, are only intended to be part of the Beta process, and not part of the main game once we are LIVE, though we may use some of them for "new user battlegrounds," as we talked about during the Kickstarter.

Here are the Guiding Principles for these games.

  • Match-based, have a variable number of max players per Realm
  • Last less than 30 minutes on average
  • Have a number of different victory settings, which can be easily changed by the designers and a minimal amount of programmer involvement, even when running.

All these games are designed to test/playtest various aspects of the main game. They should not require a lot of new code to be written to make them happen. They should, whenever possible, work with the same mechanics as we will have in the LIVE game, with some obvious exceptions, such as travel time. Some examples of these “Dragon Challenges” are:

  • Saturday Night Sieges™ – These should be the first Challenges that we implement. They will center around an attack on a fort. We can start this game even without having building destruction turned on, and add that as the testing regime progresses. More information about SNS can be found in the section below.

Other possible Challenges for the Dragon Circle include:

  • BONUS: Caravan Conflict – In this game, a caravan is attempting to reach a fort. This is a two-sided match, with one Realm defending the caravan and the other attacking it.
  • BONUS: POP the PoP – A three-sided conflict, where each side is looking to take control of a Place of Power and hold it for a certain amount of time.
  • Castle Smash! – Three castles, lots of siege weapons, and not much else: winner takes all.
  • BONUS: This mine is mine! – Realm-based Thunderdome with mines. In other words, “Three Realms enter, one Realm leaves!” Players start within the mine, and only one Realm can exit victorious.
  • BONUS: Hide and Go Slay! - This map is designed for the deeper, darker forests. Players start scattered around the DDF in a Last Realm Standing match.
  • BONUS: Free for all! – Yep, you guessed it, an FFA-style Challenge.

The Challenges listed above are only some of the ideas we have for the Dragon Circle, and are on the larger scale of such things. Other Challenges will be smaller and more focused on things like testing of specific groups and situations. This way, we can set up tests for things like “an 8-person group made up of these classes vs. another 8-person group made up of other classes,” as well as other Challenges. This will be a huge win for us, as we are designing a Rock, Paper, and Scissor game with non-mirrored classes. Having a system like this one in place will be an invaluable addition to the metrics system we will use in helping to focus on class balance before launch.

Tying these games into the progression and Realm Rewards systems will be big wins for us and our Backers/players. There will be more reason for them to participate in the testing besides just helping us test stuff, and they will be rewarded for doing so.

Much of the tech for the SNS and other Dragon Challenges will be familiar to our players. Some of the things we will need for Beta 1 are listed below:

  • Match start countdown (restrict players to staging area).
  • Match start (begin timer, release players from staging area).
  • Reset match (return players to staging area, reset buildings/deployables/etc. on completion, begin next match start countdown).
  • Objectives and victory conditions easily configurable by designers.
  • In-game scoreboard, which is pushed to a web page, as has been done in the past, and exists directly in the game as well.
  • End of match scoreboard (as per above).
  • Pre-loaded characters (starting items, stat and skill progression), so that players don’t have to waste time creating characters for certain tests.

MJ Notes: The use of the Dragon Circle as a setting for this type of testing is somewhat tropish, but for our players that enjoy the lore of MMORPGs, it’ll be a nice extra bit of material for them, especially as some stories will use the Dragon Circle as a backdrop.

However, this will be important to all of our Backers: The Dragon Circle will allow them not only to help test/refine our game, but also to have fun while doing so. We will also devote some additional art/financial resources to make participation a worthwhile endeavor by players. While we might get some pushback from Backers who can’t participate, we need to accelerate the development of this game, and this is one of the ways we can do so. If we can get more people to participate throughout Beta, and can gather the data we need from our metrics systems, we will be able to deliver the game faster—and in better shape—than otherwise.

I've already covered this above, but it's worth repeating: An important part of our motivation here is the desire to give something back to our Backers for their time and patience. This is just one of the ways we will do so. This doesn’t make up for the delay, but it is a way that we can show our Backers that we are, as always, not only serious about getting this game out in a more timely fashion, but also that we are serious about addressing class/situational issues during Beta 1 and beyond, and not waiting to clean it all up post-launch. The thank-you gifts that players will be getting are another way to say thanks for the support and help.

One of the questions that came up during discussions about the Dragon Circle is how far we want to go with dueling. We know we need to allow some intra-Realm dueling to facilitate testing. The problem is that we don’t want that kind of dueling, in general, to become part of the game, because it could damage the intra-Realm camaraderie that is crucial to our game’s success. For Beta 1, however, we will need to be able to get really focused data from these tests, and we need to allow players to participate. While we should record winners/losers/etc., we need to be very careful about how much we expose to the players, and we need to limit them in terms of issuing challenges to other players. Thus, we will have only a limited amount of non-Dragon Circle Challenges that are based around dueling, and they will end before somebody dies.

Saturday Night Sieges™[ | ]


Saturday Night Sieges logo

While the term Saturday Night Sieges might conjure up the image of John Travolta wearing a white suit and holding a dance-off before the walls of Studio 54, they are, of course, the sequel to the Friday Night Fights of our earlier testing stages. As their name suggests, they are intended to be held every Saturday night.

The SNS are more than just trying to break into a castle, and sometimes, they won’t even be that. They will be a series of tests/scenarios designed to help test certain aspects of the game and to be fun (usually) for our Backers.

While SNS are essentially arena-based battles with certain victory goals, time limits, etc., we want these battles to be much more than they are in other games. While we will use SNS in some familiar ways, we also want to use them with a much finer resolution than most games have pursued. For example, it’s not just about meeting the objective of the match, but the exact group composition of the teams (as I talked about above). This will make the SNS much more useful to us as we move through Beta.

In keeping with the Dragon Circle lore, different islands/areas will be created to host the various SNS; they will not all take place in the same area.

Sieges can take place on any Contested Island that has a siegeable structure, either built with C.U.B.E. or handled more like the current fort. Of course, if we are using the current fort, building destruction would not be a thing: the SNS would be about PvP, abilities, and other aspects of siege gameplay.

  • Islands with siegeable structures will be designed to minimize the travel time from the edge of the island to the place where the sieges occur. This is to make sieges more fun and focused.

During Beta 1 (and beyond, of course), buildings can be damaged/repaired during a siege, and they can also collapse.

  • Designers can set the amount of damage/health modifiers (make damage more or less effective) for any siege, including during a test. The method for repair is still TBD, but at a minimum, we’ll have a ‘/’ command for repair when Beta 1 opens.

As per other information releases, most of these sieges will be scheduled by us as part of SNS and the Dragon Circle, as the Contested Islands will not be up 24x7, due to, among other things, the cost that would entail. We want to maximize the amount of fun that players have during Beta, so having servers up 24x7 is not a good idea. It would waste a lot of money, as well as waste a lot of Backers' time when they come in during dead hours.

At the opening of the SNS, each Realm will have at least two siege engines. One is already in: the Scorpion. We will need a second one, which could be “Magic Mortars,” or a more traditional weapon, such as a catapult. The Magic Mortar is just a concept for a second type of siege engine that can be more easily implemented than some of the more traditional siege engines. The key is that we want to have lots of different siege engines during the SNS, but they have to look/play great, otherwise we shouldn’t bother. If we decide to use the Magic Mortars as opposed to another siege engine, here’s how they would work in the game:

  • Magic Mortars are built via the crafting process, and in the later stages of Beta, they will be mage-powered devices.
  • They will not require new tech to make them work in the game.
  • Crafters will make the base item, but then the MM has to be powered up by the appropriate mage class, once mages are a part of the game. In the meantime, we can set them up to be powered by anybody.
  • They will come in different sizes, and the damage that they do is determined by the mage that empowers them.
  • Each MM has a certain number of charges in it, based on the power/sacrifice of the mage that powered them up. Soul-powered MMs last the longest time, blood-powered MMs will diminish faster over time.
  • MMs need to be set up so they can fire automatically at a set target, or manually, so we can use them in Bot testing.
  • BONUS: Additional siege engines added.
  • BONUS: Any of the siege engines can be run autonomously via NPCs, not via Bots/ARCs. Depending on the time it would take to implement, I would change this to a must-have for the start of Beta 1. For the opening of Beta 1, if we had siege engines that could fire by themselves, that would be acceptable as a BONUS item.

As part of the SNS, spawn points for sieges must be able to be set by the designers, without programmer intervention.

  • Respawn time should be able to be set by the designers while the server is LIVE. This way, we can have some sieges where players can pop back very quickly (or instantly), and others where it takes longer.

During the remainder of Alpha, the SNS will take place on one special island with a castle in the middle.

Utilize the Builder’s Brigade to build other structures that will be placed on that and other islands for the sieges. The tech needed to do this still needs to be implemented.

As part of the Dragon Circle, participation in SNS will earn our players rewards for helping us test and iterate on the game.

MJ Notes: Saturday Night Sieges are an extremely important part of our plan for Beta, especially for Beta 1. We want you folks to have fun in our Beta testing process, not just log in and suffer through it for the good of the game. While we certainly could go that route, we are choosing not to do so. In a perfect world, our players will be looking forward to playing in our SNS, not just for the rewards, but for the fun of it. The extra rewards will of course be a nice bonus, but if the SNS and Dragon Challenges aren’t fun, the rewards won’t make a real difference. On a personal level, I want to play in the SNS, just as I did before the re-abilitation process came upon us. In the past couple of days, as we’ve tested the first pass of this tech, folks in the studio were excited again about playing a game, and not just a game engine. I’ve been waiting for this day for a very long time.