Sigh. I am thinking in broad terms of what someone "may" do in the future. Sure, you are correct in that, in general, if all you are doing is sending a list in some format that will show it one way in the GUI and one way in the text system, its not a big deal. All I am saying is, you might want to have a means to negotiate clearer about what is and isn't allowed, so that, to use your inventory example, you don't get something as bad as:
<shop>
<item level=1 num=inf price=20>an Aylorian Dirk</item>
<item level=1 num=inf price=20>an Aylorian Sword</item>
<item level=1 num=inf price=20>an Aylorian Axe</item>
<item level=10 num=1 price=10>a scimitar</item>
</shop>
vs.
<shop>
<item level=1 num=inf price=20>an Aylorian Dirk image=adirk.jpg 3d=adirk.obj
effects=flames.efx texture=aylorian_metal.inc</item>
<item level=1 num=inf price=20>an Aylorian Sword image=asword.jpg 3d=asword.obj
effects=flames.efx texture=aylorian_metal.inc</item>
<item level=1 num=inf price=20>an Aylorian Axe image=aaxe.jpg 3d=aaxe.obj
effects=flames.efx texture=aylorian_metal.inc</item>
<item level=10 num=1 price=10>a scimitar image=scimitar 3d=scimitar
texture=iron.inc</item>
</shop>
Which is nearly doubling the data involved, when half the stuff in the list is "not" essential at all to display in text. Mind you, no mud is *currently* likely to do that. But something coming from EQ2 might ask, "Well, why if you have a GUI can't you at least show some pictures of what the thing is, and provide something sort of like the "dressing room", where you can look at it in 3D? Hell, I would love to see that myself, even if I had **never** played EQ2. To me, it adds something to at least get a sense of how big a "huge sword" really is, just how spiky the spikes on the mace are, etc. Sure, I can imagine it, but which is seriously more stunning, the battle scene with Sauron in the movie, or the convoluted prose of Tolkien? Some people may want to former, even if the rest of the game is text. And, if you start adding that sort of data into the stream, you may want to make sure there is "at least" some concept in the protocol which allows a client to negotiate "down" to a level that won't be sending all of it, instead of relying on the server coder to implement some addon hack, which only works with their server, and which ever client they cobbled together to do it.
And sure, they could set it up to simply let the person enable/disable some content on the server end, for that character, but that only works where someone bothers to do it, in which case, you are right back to getting 2-3 times the data, and throwing 1/2-2/3 (or more) of it out, instead of just requesting, "Don't send me what I can't use.", in the first place. Have thing that would require a GUI capacity, or a plugin for graphical elements, place those items in a category of "graphical features", which you can negotiate out of.
At the very least, make sure that there is a clear concept of how those additional elements "must" be included in any protocol, and negotiated, so if someone does come along with something of the sort, you can extend to protocol in a way that the client can deal with effectively, not just figuratively scratch its head at and throw out. If it can't use it, then have the protocol establish it, and the protocol on the server end figure out what to send and what to not bother with, not the client, which is a bit like closing the barn door after the herd has already stampeded over you lawn.
See what I am saying?
We don't need to implement the features to do any of the stuff I put in my example, but we should have the "server" end firmly in the position of being responsible for determining if it should cram all those things into it in the first place, or if, perhaps, the guy with GenericClient++ shouldn't have all the extra stuff thrown at him to start with. Color markup, etc. would be handled in a style sheet system instead, so you could "override" the styles for inventory, or shops, etc., to make it fit your aesthetic, or you could use what the "mud" wants you to see instead. That is fine. Some data though, is not needed, wanted, or useful, to a text client, so it makes no sense to send it anyway, instead of negotiating with the server using something like, "Can do 3D, can't do 3D, can do images, can't do images, can do tables, will do tables, etc." That gets you *your* example, and tells the server, don't send me the other stuff.
|
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3 ![[Go to top]](/images/gototop.gif){kind=small}
top