Leaderboard

First update! This is picking up sort of mid-stream, but hopefully it'll make some sense anyhow. This update deals with identifying role identities for expected retail-inspired builds, and using a three-point gradient 'role chart' to start the process of turning a build from a loose concept into something actionable. So, we're aiming for using a perk tree for character creation and development in v4, and otherwise going classless with the system. This means that, from a player perspective, you build your character by looking through the perk tree, and making choices to obtain the abilities and advantages that fit with how you envision your character. But from a design perspective, we have a bunch of things to consider to make something that seemingly simple actually happen and work well. The first thing we have to consider is that while players will definitely want to make their own unique builds and come up with cool combinations of perks, there are also players who will want some kind of a baseline to work from, and the retail class specs are a great starting point for that. And for us, they can actually give us an avenue for starting to design the perk tree, since--if we know we want to accommodate retail specs (within the constraints to which we can)--we know we have some 'pre-set builds' to design as our templates. Structure is good! But retail specs weren't designed with a classless 'free-form' character creation and development system in mind like how our perk tree is shaping up. So what we have to do is figure out how to 'convert' a class-based design into a classless design. And for that, we use a 'role chart.' Basically, what a role chart does, is it allows us to first identify what capabilities/responsibilities are common to different specs and builds, and use those to identify major, overarching roles. And then we can use those roles as axes on a chart, to loosely categorize builds, and 'reverse engineer' them into collections of perks. I know it sounds complicated--and it is. But it's a necessary process to try to make sure that, for instance, a mage you build to be a certain kind of mage, actually performs and feels like they're that kind of mage. It allows us to build baselines and have a conceptual foundation to work from so that we know that something built to be a certain way should function correctly, instead of having the pitfalls that earlier versions of the system have had. So, let's look at the current version of the role chart! Kind of a lot going on there visually, but it's actually pretty simple to understand. Our three main axes of the role chart are Control, Attack, and Support. At the top-left, the main capabilities/responsibilities (or 'verbs') of an axis are listed. These are conceptual more than mechanical, and act as guiding concepts for developing abilities and perks. For example, classic 'DPS'-focused abilities serve the 'Eliminates Enemies' verb, and so are more heavily found in roles which are higher up the Attack axis. For any given build, the more (and more fully) it exemplifies a given axis's verbs, the higher it should be on that axis; for example, the more a build does the things listed under the Control axis, the higher it should be on the Control axis. Pretty simple, right? Each section of the chart pertains to a certain classification of a role. At the top right, the 'guide' shows what the generally expected balance of a role should be, given its place on the chart along a given axis. We then name these roles in a way which makes them consistent and understandable: Any role which has no (or very little) influence from more than one axis, is considered a 'Pure' role on that axis. For example, a role which is all or nearly all Attack, is considered a Pure Attack role. Any role which has a meaningful but not high degree of influence from a secondary axis (or two) is considered a 'Flex' role on its primary axis; for example, a build which is mostly Control, but has some amount of Attack, is considered a Control / Attack Flex role. Any role which has a high degree of influence from a secondary axis (or two) is considered a 'Hybrid' role on its primary axis; for example, a build which is strongly Support, but has a high amount of Attack, is considered a Support / Attack Hybrid role. And finally, a role can be both Flex and Hybrid. This relates to roles which are strongly mixed and adaptable; for example, a role which is strongly Control, but has meaningful amounts of both Attack and Support, is considered a Control Flex Hybrid role. So now, we have a terminology and a classification method to start reverse-engineering retail builds, by plotting them on the role chart. This lets us know what the balance of abilities and perks we design for that build should be, so we don't--for example--design too much healing for a DPS build, or too much CC for a healer build. From there, we can start breaking down retail builds and using these guidelines to identify key mechanics which make the build unique and special, how those key mechanics feed into the build's role balance, and what kinds of abilities and perks we should design to express those key mechanics. Right now, everything is still in the concept phase, but what this lets us do is go from nebulous ideas of what a build could be, to start narrowing down and identifying what actual actionable things we can design that can bring these builds to life. These can then be plotted onto a work-in-progress perk tree in the appropriate places, and we can start toying around what what a player could make out of those building blocks, and add, remove, or revise things as necessary. The end result--hopefully--being that players who want to make reasonably retail-faithful familiar builds, as well as those who want to take a traditional build and tweak it, and even those who want to make experimental and original builds from scratch, can all choose from the same broad selection of perk options in the perk tree, and have fun finding the combination and style that works best for them. To finish up, let's look at an example retail build breakdown, with the Shadow Priest. I want to emphasize that this is not finished work, and was only created as an example of how a build breakdown could be written up to be useful from a design perspective, and that not all of the things contained in this example are likely to be retail-accurate; I just spun this one off the top of my head to illustrate the method. The actual in-depth retail build breakdowns are slowly underway by people who know retail way better than I do! But hopefully, this should give a glimpse into how builds are being classified, broken down, and turned into ability and perk concepts at this stage of development. Whew, a lot of stuff in this update! Stay tuned for more as work on v4 continues!

As many of you are likely aware, an announcement was made a few weeks back about changes coming to NPCs, specifically, play owned ones. Due to real life time limitations and my own school work, I've been slower on getting this out then we wanted. What we are doing, is changing both, how the keeper team handles NPCs and how players interact with them. Up to this point, recruiting NPCs has required a keeper ticket, where then a keeper DMs the interaction with the end goal being the recruitment of said NPCs to work for the player character. This has put a severe strain on our small team, as it ends up requiring us to be rather lack luster in the name of consistency, and fairness, while respecting a player's ownership of the NPCs, like a building or possession. This has led to a great deal of NPCs feeling lifeless and generic. The major change, for players to understand, is recruitment will now work much differently. If a player character wishes to start a business, or recruit workers for one, instead of seeking out the NPCs, or going to a place to 'shop' for specific races, you will work with a 'help wanted' system. This means, you will post a 'help wanted' poster up in the Doldrums. This can be done with our writables, through the architect profession, or noticeboards. Once this is done, a player may then make a keeper ticket to notify us of the placement and its location(s). The ticket will be closed when a keeper has checked these posters, and logged its contents for the team. When a keeper has time/npc are available looking for the work, they will approach a player character, either at an agreed upon date by the keeper and player, or when the keeper next catches the player on. The interaction will be DM'd out and if the NPC agrees at the end, they will work for the player. However, another major difference, is currently, once an NPC is 'hired' by a player character, be it guard, or worker for a business, they have been treated as 'possessions' of the player. This will change, while not every NPC will be given a unique name, they will all have goals, ideals, morals and opinions tied to them. And their general attitude for the player character they are employed by aswell. What does this really mean for our players? Well, this means that if you hire a group of devout, naaru-fearing draenei and they hear you summoned a gaggle of imps, and took up warlocktry, the draenei may decide to quit. This is in an effort to make consequences for a player character's actions, and for NPCs as a whole to feel more 'real'. Starting from this point forward, all NPCs who work for a player will follow this. Meaning, once their information has been logged, your character's actions will have positive or negative consequences. NPC behavior, once owned, will apply to ALL NPCs, including those in settlements. Speaking of settlements. We are going to also be rolling out some new rules for them as well. These will apply only to PLAYER run settlements. A post will be made in the guild sections of the forums with a more detailed outline on all the rules and information we will require from players. We will also have requirements for a place to become a settlement. Current player run settlements will be grandfathered in, meaning they will maintain their status. The requirements, as a quick preview, will be... 1) A settlement must have at least three players active in it. 2) There must be one business present in the settlement. 3) There must be four workers for the business. 4) The settlement must has at least three, NPC guards. 5) The players must fill out a form with required information for keepers on the settlement. Once these requirements have been met(again, the rest, including the form, will be in another post.)the 'place' or 'camp' or 'base' of the player characters will become a settlement. This will change how recruitment works. Based on the information filled out, NPCs will randomly approach settlements. Either looking for work, a place to stay or live. Notices to 'move to X town' will be automatically removed by staff in other settlements, unless said settlement specifically allows it. Again, this will depend on NPCs in the Doldrums, as well as keeper time. To give a quick example, a group of elves recently arrive in the Doldrums. Highborne, use to posh, comfy living conditions. They hear of a town that has a bathhouse, and being dirty, uncomfortable and miserable, they go there. But, along the way they are accosted by some danger, and a group of gnomes save them. The gnomes hear of their plight, and say, that while they do not have baths, they have working plumbing, and warm showers. A few of the highborne go off with the gnomes to check this out, finding a likely warm source of water more appropriate, while the rest continue. Then, those who went with the gnomes, find out the showers broke a week ago and still are not fixed. Maybe they stick around for a bit to see if they are fixed, or feeling lied to, leave to rejoin their friends. Once they do, they find the bathhouse was a lie, and leave again this time deciding to form their own camp and try to eek out a comfortable living. Of course, it could be simpler or more complex. Perhaps a group of desperate dwarves demand a player proves their ability to ply them with decent alcohol, or a group of humans wish for swords to defend themselves. These both can incur more people to a settlement, and things player character do can incur them leaving. To summarize our end goal with this method, we wish to make the world feel alive, while also releving the keeper team from handling bog-standard work during the hours we have to DM, and hopefully freeing up time for more interesting events and things to be done, both for players who wish to pursue building settlements and businesses or not. I would also like to state that NPC upkeep for workers or guards, will still remain as -silver-. The reason for this is ease on staff and a consistent, fair upkeep cost for all players. In-Character, this silver can represent food, clothing, weapons, armor, mead, or your character is paying the NPC in. And to wrap this up with a revival and addition rather then just a change... we are going to be working on adding in quest giver NPCs, merchants who sell Common Request Tokens and adding dialogue to your average citizen NPC. I'll break this down a tad below. Quest Givers - Anyone who has been on shores from its initial launch in the summer of 2018 may remember there use to be an orc on Menhirs who asked for mana shards and rewarded silver. For all intents and purposes, it was a repeatable, daily quest. I used this idea during the Razorbranch Invasion event chain. We'll be bringing this back, and trying to make it a little more interesting. Each settlement that we are able to, will have a quest giver that is looking for something different and rewards different things. Some will be much like the orc I mentioned, wanting an item for silver. Some may send you off to a more dangerous task, and ask for proof of your deed for something greater. We will be starting small on this, to test it out and see where we can go with it. The idea is these are tasks that need to/can be regularly done in an In-character sense. So, if you do one of these, it is valid In-character, even if someone else did it too. Basic Gear Merchants - This is something I've been wanting to add for awhile, merchants who sell items for silver. Specifically it will be common request tokens. This allows newer characters and players the ability to earn some better looking cosmetics without the need for finding a player crafter. We are starting with commons as they are not something a player can specifically craft in the current professions. If it goes well, we may continue down this path, we may not. NPC dialogue - During the time Silver-Eye was around, all the NPCs in it had dialogue, some of it amounted to 'screw you' or 'go away', but it set the tone for how the NPCs in Silver-eye were. We plan on working to bring this back. These last changes will be rolling in as we complete them. We'll make announcements in the discord as we get them out.

Where: The Baron's Highway between Haven and New Moonbrook When: Wednesday 2nd October 19:30 server-time. Who: Friends and allies of Haven / New Moonbrook Event Type: Social GM Assistance: Brief (single object moving) Following the initial discussion of the construction of what would be dubbed 'The Baron's Highway', it would seem that the first segment to be constructed would be between the settlement of New Moonbrook and Haven. This track-way allowing wagons, carts and other means of transport not suited to the uneven jungle ground to move easily will now allow for ease of trade between the two settlements and later ones when the highway makes its way around Opej'nor. As part of this, a ceremony is to be held with dignitaries from Haven and New Moonbrook to celebrate the completion of the first segment of the highway. The main element of this ceremony is to compose of the hammering of the 'final spike', a solid gold carpentry nail to signify the official opening of the highway and the symbolic connection between the neutral and alliance settlements. Of course, no ceremony of this caliber is complete without alcohol, music, merriment and food! So an open invitation is expressed to all friends, allies and neutral trading partners of both New Moonbrook and Haven to attend the ceremony.