I thought I read that this runs locally on my machine? Is it updating the server after every click?
for a little bit of relief: you can still select the score itself and type the value you want.
however, it won't help with anything else like powers, feats once you try to make a higher level character.
whoever believed that such a slow round trip tothe server after each click is acceptable, should be fired. like any PROPER web-application, this should post back to the server only after each page.
What I see is that every time you make a change, the client makes a call to the server, which returns the entire character as a huge XML blob.
got to around 80MB download using just the new CB in half an hour. Anyone wonder why it is slow? well, i don't.
yes, it is updating after every click.
for a little bit of relief: you can still select the score itself and type the value you want.
however, it won't help with anything else like powers, feats once you try to make a higher level character.
whoever believed that such a slow round trip tothe server after each click is acceptable, should be fired. like any PROPER web-application, this should post back to the server only after each page.
I discovered that "Choose All For Me" is the solution to my web-lag ills. Click that, and I only have to wait for one of the 5-30 second pauses per choice block.
I mean, sure, I don't get the character I wanted, or even one that's good...
The good thing is that if people actually use this (yeah right!), they'll eventually have to fix/optimise it anyway, or Hasbro will be bankrupted by a huge bandwidth bill.
This. This so much.
whoever believed that such a slow round trip tothe server after each click is acceptable, should be fired. like any PROPER web-application, this should post back to the server only after each page.
On this I must agree.
Ok, there may be some calculations which are too complicated to be done client side but... well we do much much more complicated stuff with java script...
The whole concept of having round trips for every click is not really all that strange or unacceptable. This way ensures all logic is maintained in one, WotC controlled and guarded, place. There are several advantages in that choice from both an architecture and business perspective.
It may be totally possible to put a lot of the logic and calculations on the client side, but that does not mean it is a good idea to do so in any given situation. The CB and the service architecture it seems to depend on (yes I admit I have quite a bit of fun guessing at the CB's architectural underpinnings
) seem to fit toger well in a complex structure. Overy simplistic statements like "it could be done in javascript" do it little justice. * - For example: considering there seems to be at any given time a local (client) version and a remote (server) version of the XML data all it would take is to compare the new XML to the old XML and send diff info only. Possibly combined with a background thread to ensure server and client reality remain synced.
The whole concept of having round trips for every click is not really all that strange or unacceptable. This way ensures all logic is maintained in one, WotC controlled and guarded, place. There are several advantages in that choice from both an architecture and business perspective.
It may be totally possible to put a lot of the logic and calculations on the client side, but that does not mean it is a good idea to do so in any given situation. The CB and the service architecture it seems to depend on (yes I admit I have quite a bit of fun guessing at the CB's architectural underpinnings
While I do agree that there are cases where this is acceptable, I don't think the character builder is one of those exceptions. The logic can still process the data in one push once all values are selected, instead of relying on a push at every minor change of the values. Most every web form works this way with the exception of specific forms that require ajax calls to update specific values based on other selected values and the like.
The only thing that I can see as requiring calculation on the character builder based on attribute change is the stat bonus received for specific attributes. Str 18 = Str bonus (+4). The calculation for this is not hard and can be done by anyone that passed the 4th grade.
Attribute value = x
rounddown(x/2) - 5
Want to get the value plus level?
level = y
(rounddown(x/2) - 5) + rounddown(y/2)
Javascript can be employed to do this with minimal effort and wouldn't require any calls back to the server until the stats were selected.
The point buy system has at least a 5 second delay between clicks for me. Another nitpick is the next button does not appear until after you have used all of your points. I prefer it always being there so I can adjust abilities, skip to the next section to see what modifiers look like.
You can skip it. Just click on the left.
Also, typing it in is faster, as is using the quick buttons and then adjusting.
And yes, it's pretty stupid to send to the sever each time the score changes.
The whole concept of having round trips for every click is not really all that strange or unacceptable. This way ensures all logic is maintained in one, WotC controlled and guarded, place. There are several advantages in that choice from both an architecture and business perspective.
It may be totally possible to put a lot of the logic and calculations on the client side, but that does not mean it is a good idea to do so in any given situation. The CB and the service architecture it seems to depend on (yes I admit I have quite a bit of fun guessing at the CB's architectural underpinnings
While I do agree that there are cases where this is acceptable, I don't think the character builder is one of those exceptions. The logic can still process the data in one push once all values are selected, instead of relying on a push at every minor change of the values. Most every web form works this way with the exception of specific forms that require ajax calls to update specific values based on other selected values and the like.
The only thing that I can see as requiring calculation on the character builder based on attribute change is the stat bonus received for specific attributes. Str 18 = Str bonus (+4). The calculation for this is not hard and can be done by anyone that passed the 4th grade.
Attribute value = x
rounddown(x/2) - 5
Want to get the value plus level?
level = y
(rounddown(x/2) - 5) + rounddown(y/2)
Javascript can be employed to do this with minimal effort and wouldn't require any calls back to the server until the stats were selected.
I dont disagree with your assesment from a technical viewpoint. I am well aware of several ways it could have been done more efficiently. That does not mean that within the boundaries of time, requirements, architecture, burget etc. those ways are all feasible. IT is usually not about what is technically possible, well not anymore
.Lets assume that at the start of this project the design and development team for the CB was given the architecture principle "there can be no business logic whatsoever client-side" to follow. Not an unusual principle.
Now we can argue that common sense dictates this principle should perhaps not be treated as completely inflexible (architecture principles usually shouldn't). Compromises could have been made on some minor logic client-side that would have seriously optimized the Character Creation process. But common sense is not all that common (and my common sense is not your common sense nor is it anyone elses.. its weird like that) and most everyone who has workedin strict architecture controled development can attest to the dificulties in getting some rules relaxed..
Of course that is all just me speculating wildly and is probably far from the thruth. Fact is that it is not an uncommon scenario in my experience. All I aim to show is that the situation that lead to the CB in its current incarnation is likely complicated with many factors influencing the development process.
I dont disagree with your assesment from a technical viewpoint. I am well aware of several ways it could have been done more efficiently. That does not mean that within the boundaries of time, requirements, architecture, burget etc. those ways are all feasible. IT is usually not about what is technically possible, well not anymore
Lets assume that at the start of this project the design and development team for the CB was given the architecture principle "there can be no business logic whatsoever client-side" to follow. Not an unusual principle.
Now we can argue that common sense dictates this principle should perhaps not be treated as completely inflexible (architecture principles usually shouldn't). Compromises could have been made on some minor logic client-side that would have seriously optimized the Character Creation process. But common sense is not all that common (and my common sense is not your common sense nor is it anyone elses.. its weird like that) and most everyone who has workedin strict architecture controled development can attest to the dificulties in getting some rules relaxed..
Of course that is all just me speculating wildly and is probably far from the thruth. Fact is that it is not an uncommon scenario in my experience. All I aim to show is that the situation that lead to the CB in its current incarnation is likely complicated with many factors influencing the development process.
That is a sound and relevent judgement and I thank you sir. I guess I'm used to a more relaxed development structure in my line that allows for optimization over strict constraints. Most of the time, I assume that's how the rest of the world works. Seems I may be mistaken
I think they're afraid we might reverse engineer the algorithim for point buy builds if that particular intellectual property were handled locally. Could you imagine how much money Hasbro would lose if people could create their own point buy calculators? It would be devestating to the company and the end of D&D as we know it.
It's not like they publicly released it in any of their books or anything. Wait...