Allow a bard to "give" another player their bardic inspiration point, where the other player then is able to see a use "bardic inspiration" button under/ with DM inspiration point. Please ensure the tooltip reflects the appropriate school, level, and ability given by the bardic Inspiration
That is a very involved feature you are asking for. As of now, character sheets can't communicate with each other at all. This feature will require character sheets to be able to send, retrieve, and store information from other characters. There is also the issue that bardic inspiration has a time limit, which the character sheet is also not yet able to track.
It is a good idea, but not one that can be implemented anytime in the near future. Try asking again once character sheets can send items to each other and toggle temporary bonuses.
Having player A press a button on the char sheet so something happens on the sheet of player B is a huge undertaking, I'm not expecting that to see the light of day anytime soon.
However, an upgrade to the current inspiration feature would be nice. Instead of a simple boolean on/off toggle as it is now, we could use something a little more advanced. Like the ability to specify what kind of inspirations we have, and how many. You can have rerolls or advantage rolls (DM inspiration) or addition rolls (Bardic Inspiration of varying die size) and specify the count for each because some DM's allow unused inspirations to stack.
"Having player A press a button on the char sheet so something happens on the sheet of player B is a huge undertaking, "
Not really. Campaigns already have characters assigned to "sessions" by including their alias' into the same campaign. This is a simple change to the player table, adding a new leaf modified by another character's ability charge count. From an engineering perspective, it's an hour's (1hr) worth of work, maybe another hour to include a lookup reference with testing.
I'm glad you recognize that Bardic Inspiration is too hidden. I constantly have to remind my party that they have charges available, then reiterate what "kind" of bonus they get. Putting a Bardic Inspiration box under the DM Inspiration with "what kind" would aid.
Not really. Campaigns already have characters assigned to "sessions" by including their alias' into the same campaign
Having a character sheet assigned a campaign tag and then having a page display all characters with that tag is not the same as cross sheet functionality. We don't even have synchronous behaviour on the same sheet (ie if you change something while another user is looking at it, you need to force a refresh to get the updated information)
This is a simple change to the player table, adding a new leaf modified by another character's ability charge count
No it's not, it's adding the ability for the character sheet to query other sheets for the same campaign tag, then perform an action that overrides user restrictions (only the DM and owner can change a character sheet, this would circumvent that). That doesn't even touch on the fact that the whole character sheet architecture would need to be changed to allow for real time updating.
it's an hour's (1hr) worth of work, maybe another hour to include a lookup reference with testing.
Oh, you sweet summer child, so innocent, so naive.
If we ignore all the backend changes, this would not be an hours worth of work. Let's break it down:
Design and prod get together to hash out the UX for this functionality (that's a days worth of work right there easily)
A UI is designed for the functionality (another day, half minimum)
The UI designs are implemented (adding a new feature? that's a days work)
The backend changes are made to allow one character sheet to affect another directly (minimum days work, I'd expect two or three. You're talking networking, accounts, synchronisation etc)
Now testing begins. A feature like this? Where the actions of one user can affect another? I'd expect a solid week of testing to even be remotely comfortable. You'd have to check for collision states (two bards awarding the same character inspiration), validation states (not awarding inspiration twice), edge cases such as using inspiration at the exact moment it's awarded, network connectivity issues, browser testing, device testing.
Then you have to wait for a suitable time to push such a change.
Now, you may think I am another backseat dev, but I can assure you I'm speaking from years of experience. I work in QA management for a company that produces web based games with account level functionality (similar to DDB in some regards) with almost a decade of experience under my belt. Do you want to know how long it takes to change a typo on a game instruction? A day minimum. You have to change the error, then push the change, commit it and merge it. Then you have to build the asset, deploy it to the test environment and check it's not broke anything else. Then you push it to the pre-production environment, set up a test run against all locations that it affects and run that against multiple devices. For just one location, on three devices (one desktop browser, one phone, one tablet) you're talking 2 hours of testing alone. Then once it's been adequately tested, you then have to push it to the pre-release environment and wait for a live merge.
And this is all if the process goes smoothly and there are no bugs, errors, downtime etc. And this is just for a simple text fix.
For something as complicated as what is proposed, I'd honestly expect a month turn around from prod signing off on the feature to it going live. And that's not factoring higher priority issues pulling dev hours.
"Now, you may think I am another backseat dev, but I can assure you I'm speaking from years of experience. I work in QA management for a company that produces web based [sic] games with account level [sic] functionality (similar to DDB in some regards) with almost a decade of experience under my belt. Do you want to know how long it takes to change a typo on a game instruction? A day minimum. You have to change the error, then push the change, commit it and merge it. Then you have to build the asset, deploy it to the test environment and check it's not broke [sic] anything else. Then you push it to the pre-production environment, set up a test run against all locations that it affects and run that against multiple devices. For just one location, on three devices (one desktop browser, one phone, one tablet) you're talking 2 hours of testing alone. Then once it's been adequately tested, you then have to push it to the pre-release environment and wait for a live merge."
That's so nice! I manage software development teams for a living too! Your argument is invalid. Not only would I have you moved to a less complicated platform for not knowing basic libraries within pretty much all SDK's that follow a basic BLP model, but we would also make sure you're not given any resources to execute beyond your fingertips. You are over complicating this by far too much. You'd deliver this change overbudget, late, and not within the scope of requirements. Your entire SDLC is slow and definitely not agile. I'd recommend scrum, multi-domain cloud environments to support a DevOPS model.
"Having a character sheet assigned a campaign tag and then having a page display all characters with that tag is not the same as cross sheet functionality. We don't even have synchronous behaviour [sic] on the same sheet (ie if you change something while another user is looking at it, you need to force a refresh to get the updated information)"
Sheet modification architecture already exists -- which is why a user can edit and re"publish" their sheet, edit HP, stats, etc... This is just a dynamic form.
"No it's not, it's adding the ability for the character sheet to query other sheets for the same campaign tag, then perform an action that overrides user restrictions (only the DM and owner can change a character sheet, this would circumvent that). That doesn't even touch on the fact that the whole character sheet architecture would need to be changed to allow for real time [sic] updating."
Wrong on so many levels. Please reference the above user-level modifications available and their implementation. D&D Beyond's current webservice architecture already handles this.
Oh, you sweet summer child, so innocent, so naive.
Your letter of resignation is accepted. Clear your desk out, turn your badge in by the end of the day; as account management has already disabled your accesses. Feel free to take a letter of recommendation, pre-signed, with a reference sheet for your next career endeavor -- this team isn't for you.
@DxJxC: "I have noticed it usually takes over a day to fix a typo on the character sheets (compendium typos get fixed in minutes).
Taking a stab -- Likely two different servers and/or teams, WordPress (CMS) operating on a MySQL back performing content management vs whichever (Tomcat, ...) to handle their more intense webservices.
Everything @Davedamon mentioned is correct under the assumption this is a new system altogether, with engineers that haven't already referenced the same libraries in the baseline or are aware of those functions, to begin with, and their entire development lifecycle management is burdened by a waterfall-based project schema. E.g. Requiring one step to finish before working on the next. From what we can see with simple user end interactions with character creation, sheet editing, "buttonology" -- this is hardly the case.
His team's heavily burdened system is demonstrated under his estimated timelines and workflow. For instance, all the corrections and changes he touts take the longest time would have never left the Development Phase or Environment, thus regression would seldom be needed. Merging a branch into the baseline for release is a management function after it's already been tested and demo'd. He does speak from experience no doubt but under extremely negative, toxic, and inefficient work models that waste countless man-hours.
Don't be fooled by people that "know it all, been there done that, then tugs on their belt" or specifically tries to belittle someone they disagree with straight out the gate. Simply because his organization takes one week to make a simple change doesn't mean other, more efficient, smaller productive teams won't take two-three hours. But that's a silly fact people seem to forget.
Not only would I have you moved to a less complicated platform for not knowing basic libraries within pretty much all SDK's that follow a basic BLP model, but we would also make sure you're not given any resources to execute beyond your fingertips
Your attempt at attacking my intelligence fails because I never said I was a developer, I'm QA management. I'm telling you from experience at the pace that changes propagate, not based on how hard I think they would be to implement.
Sheet modification architecture already exists -- which is why a user can edit and re"publish" their sheet, edit HP, stats, etc... This is just a dynamic form.
That's.......not the same thing? Currently each time a user makes a change to their sheet, the change is pushed to the server, but not updated for any other live clients until they refresh their character sheet. For this to work the sheet would need to be dynamically checking for changes continuously in real time (not just on user prompt). This would be changing from a request/response backend architecture to a keep-alive server update request one.
And as for our SDLC, it's pretty quick and certainly agile, I just happen to have a practical sense of project time.
Maybe you should dismiss what people are saying if you can't even read and comprehend what they're saying first.
You're right, you're right. I just get incredibly frustrated when I see comments like "This is an hours work, an easy change" because I have first hand experience of that never being the case and also dislike the implication of all developers being lazy (something I see a lot in this forum).
Even if it was a quick and simple fix, it wouldn’t make much sense to implement. There are a huge number of additional short term buffs that other team members can grant to you similar to a bardic inspiration.
Hopefully once the temporary feature system comes in, and the digital DM screen is finished, that'll lay the groundwork for cross-sheet temporary feature control.
Allow a bard to "give" another player their bardic inspiration point, where the other player then is able to see a use "bardic inspiration" button under/ with DM inspiration point. Please ensure the tooltip reflects the appropriate school, level, and ability given by the bardic Inspiration
That is a very involved feature you are asking for. As of now, character sheets can't communicate with each other at all. This feature will require character sheets to be able to send, retrieve, and store information from other characters. There is also the issue that bardic inspiration has a time limit, which the character sheet is also not yet able to track.
It is a good idea, but not one that can be implemented anytime in the near future. Try asking again once character sheets can send items to each other and toggle temporary bonuses.
Having player A press a button on the char sheet so something happens on the sheet of player B is a huge undertaking, I'm not expecting that to see the light of day anytime soon.
However, an upgrade to the current inspiration feature would be nice. Instead of a simple boolean on/off toggle as it is now, we could use something a little more advanced. Like the ability to specify what kind of inspirations we have, and how many. You can have rerolls or advantage rolls (DM inspiration) or addition rolls (Bardic Inspiration of varying die size) and specify the count for each because some DM's allow unused inspirations to stack.
"Having player A press a button on the char sheet so something happens on the sheet of player B is a huge undertaking, "
Not really. Campaigns already have characters assigned to "sessions" by including their alias' into the same campaign. This is a simple change to the player table, adding a new leaf modified by another character's ability charge count. From an engineering perspective, it's an hour's (1hr) worth of work, maybe another hour to include a lookup reference with testing.
I'm glad you recognize that Bardic Inspiration is too hidden. I constantly have to remind my party that they have charges available, then reiterate what "kind" of bonus they get. Putting a Bardic Inspiration box under the DM Inspiration with "what kind" would aid.
Having a character sheet assigned a campaign tag and then having a page display all characters with that tag is not the same as cross sheet functionality. We don't even have synchronous behaviour on the same sheet (ie if you change something while another user is looking at it, you need to force a refresh to get the updated information)
No it's not, it's adding the ability for the character sheet to query other sheets for the same campaign tag, then perform an action that overrides user restrictions (only the DM and owner can change a character sheet, this would circumvent that). That doesn't even touch on the fact that the whole character sheet architecture would need to be changed to allow for real time updating.
Oh, you sweet summer child, so innocent, so naive.
If we ignore all the backend changes, this would not be an hours worth of work. Let's break it down:
Now, you may think I am another backseat dev, but I can assure you I'm speaking from years of experience. I work in QA management for a company that produces web based games with account level functionality (similar to DDB in some regards) with almost a decade of experience under my belt. Do you want to know how long it takes to change a typo on a game instruction? A day minimum. You have to change the error, then push the change, commit it and merge it. Then you have to build the asset, deploy it to the test environment and check it's not broke anything else. Then you push it to the pre-production environment, set up a test run against all locations that it affects and run that against multiple devices. For just one location, on three devices (one desktop browser, one phone, one tablet) you're talking 2 hours of testing alone. Then once it's been adequately tested, you then have to push it to the pre-release environment and wait for a live merge.
And this is all if the process goes smoothly and there are no bugs, errors, downtime etc. And this is just for a simple text fix.
For something as complicated as what is proposed, I'd honestly expect a month turn around from prod signing off on the feature to it going live. And that's not factoring higher priority issues pulling dev hours.
Find my D&D Beyond articles here
I have noticed it usually takes over a day to fix a typo on the character sheets (compendium typos get fixed in minutes).
That's so nice! I manage software development teams for a living too! Your argument is invalid. Not only would I have you moved to a less complicated platform for not knowing basic libraries within pretty much all SDK's that follow a basic BLP model, but we would also make sure you're not given any resources to execute beyond your fingertips. You are over complicating this by far too much. You'd deliver this change overbudget, late, and not within the scope of requirements. Your entire SDLC is slow and definitely not agile. I'd recommend scrum, multi-domain cloud environments to support a DevOPS model.
Sheet modification architecture already exists -- which is why a user can edit and re"publish" their sheet, edit HP, stats, etc... This is just a dynamic form.
Wrong on so many levels. Please reference the above user-level modifications available and their implementation. D&D Beyond's current webservice architecture already handles this.
Your letter of resignation is accepted. Clear your desk out, turn your badge in by the end of the day; as account management has already disabled your accesses. Feel free to take a letter of recommendation, pre-signed, with a reference sheet for your next career endeavor -- this team isn't for you.
Taking a stab -- Likely two different servers and/or teams, WordPress (CMS) operating on a MySQL back performing content management vs whichever (Tomcat, ...) to handle their more intense webservices.
Everything @Davedamon mentioned is correct under the assumption this is a new system altogether, with engineers that haven't already referenced the same libraries in the baseline or are aware of those functions, to begin with, and their entire development lifecycle management is burdened by a waterfall-based project schema. E.g. Requiring one step to finish before working on the next. From what we can see with simple user end interactions with character creation, sheet editing, "buttonology" -- this is hardly the case.
His team's heavily burdened system is demonstrated under his estimated timelines and workflow. For instance, all the corrections and changes he touts take the longest time would have never left the Development Phase or Environment, thus regression would seldom be needed. Merging a branch into the baseline for release is a management function after it's already been tested and demo'd. He does speak from experience no doubt but under extremely negative, toxic, and inefficient work models that waste countless man-hours.
Don't be fooled by people that "know it all, been there done that, then tugs on their belt" or specifically tries to belittle someone they disagree with straight out the gate. Simply because his organization takes one week to make a simple change doesn't mean other, more efficient, smaller productive teams won't take two-three hours. But that's a silly fact people seem to forget.
Your attempt at attacking my intelligence fails because I never said I was a developer, I'm QA management. I'm telling you from experience at the pace that changes propagate, not based on how hard I think they would be to implement.
That's.......not the same thing? Currently each time a user makes a change to their sheet, the change is pushed to the server, but not updated for any other live clients until they refresh their character sheet. For this to work the sheet would need to be dynamically checking for changes continuously in real time (not just on user prompt). This would be changing from a request/response backend architecture to a keep-alive server update request one.
And as for our SDLC, it's pretty quick and certainly agile, I just happen to have a practical sense of project time.
Maybe you should dismiss what people are saying if you can't even read and comprehend what they're saying first.
Find my D&D Beyond articles here
Alright guys, enough with the passive-aggressive personal attacks or mods will get involved.
You're right, you're right. I just get incredibly frustrated when I see comments like "This is an hours work, an easy change" because I have first hand experience of that never being the case and also dislike the implication of all developers being lazy (something I see a lot in this forum).
Find my D&D Beyond articles here
Even if it was a quick and simple fix, it wouldn’t make much sense to implement. There are a huge number of additional short term buffs that other team members can grant to you similar to a bardic inspiration.
Hopefully once the temporary feature system comes in, and the digital DM screen is finished, that'll lay the groundwork for cross-sheet temporary feature control.
Find my D&D Beyond articles here