David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#16 id:11640 Posted Aug 31, 2008, 7:21 pm
|
id Software used a separation of game engine from game logic for several of their games. It's what made it so easy to mod them: they could "give away" the source code to the game logic, which really wasn't the most interesting part of their game, and let people do whatever they wanted with it. It's how things like Counterstrike game about (and, for that matter, how Half-Life itself came about!). Well, anyhow, what Kline is proposing is basically the same thing, but instead of having a core and one dynamic library, you have a core and several libraries. Now, a copyover is just reloading code objects, instead of reloading the whole executable. As a result, you don't lose the data space, which is the problem with persistent copyovers.
|
|
|
Caius
Conjurer
Group: Members
Posts: 115
Joined: Oct 21, 2006
|
#17 id:11682 Posted Sep 2, 2008, 6:27 pm
|
Speaking of dynamically loaded modules. I came across a great article on linuxjournal.com about using the dlsym interface to load C++ classes dynamically, while retaining the ability to use them polymorphically. I also tried the examples provided, and they compiled and worked properly. Worth a read.
|
......................... SWR2 Refactor - The improved SWR 2.0 codebase.
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#18 id:12624 Posted Sep 24, 2008, 12:35 pm
|
DavidHaley said:id Software used a separation of game engine from game logic for several of their games. It's what made it so easy to mod them: they could "give away" the source code to the game logic, which really wasn't the most interesting part of their game, and let people do whatever they wanted with it. It's how things like Counterstrike game about (and, for that matter, how Half-Life itself came about!). Well, anyhow, what Kline is proposing is basically the same thing, but instead of having a core and one dynamic library, you have a core and several libraries. Now, a copyover is just reloading code objects, instead of reloading the whole executable. As a result, you don't lose the data space, which is the problem with persistent copyovers.
I've never really understood what this hotbooting stuff was all about, much like David here I don't see the problem with just making people reconnect. Either that, or don't update in the middle of the day.
On the other hand, the above comment I do agree with. Most of the time, I'm guessing, this hotbooting stuff is to hotfix smaller issues in a command, a spell, or something like that. In which case a scripting language like LUA\Python will do you right by having the logic figured out at runtime. What I do is identical, just recompile the C# command and create, then replace, the instance of it in my command Dictionary with reflection. Its the equivalent of swapping out a .lua or .py command file.
If you're making a core\server update though, I don't see why it's such a big deal to just make people reconnect in 5 minutes or so when you're done.
Edit: If you're not familiar with C# or .NET in general, when I say re-compile I mean at runtime via the CodeDom. It creates another assembly in memory and then I can swap out my command class for the one it just compiled without having to restart the game.
---
V
|
......................... Vassi no Diem et Tharin
< ramble/>
Last edited Sep 24, 2008, 12:37 pm by Vassi
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#19 id:12625 Posted Sep 24, 2008, 12:46 pm
|
One other contribution to this topic that I'd like to make is the idea of a paired client\server or a more widely-adopted (and opensource or not commercial) mud client that features plugin-type architecture for making muds more 'robust'.
There's only so much you can do on the server end before you have to rely on the client end to take things forward that extra notch. For instance, with the advent of Javascript frameworks there has been a huge rise in functionality and usability on websites lately. We need some kind of universal client, or client-pairing on a per-codebase basis, that makes it easier to do slightly fancier stuff.
Things like mapping, GUI bars, etc. Something as simple as keeping the names of creatures\players in the room always visible\updated on some kind of display, etc. The human brain processes things visually, MUDs can become more complex if they can learn to visually display data in more efficient ways. (ASCII art doesn't count, they're still text that has to be interpreted in the brain - and reliant on your use having a monospace font at that, it's pretty much the ceiling on what can be done server-side)
A client supporting an extensible protocol, like ZMP, has to come into existence. Until then, I'll keep writing my own client to match my codebase. Someday(tm) though, I would like to seriously take a stab at making an easily extensible MUD client that can, for instance, connect to a MUD, be recognized by said MUD and fed some startup scripts, use said startup scripts to configure its front-end GUI\Panels and just work without the user having to download files and install plugins and all that crap.
Edit: Here's a video to my current client: http://www.cyra.ws/clientpreviewed/ It loads most of its graphics, like the GUI textures, day\night icons from the web at startup. This kind of client is easy to build in newer technologies - like WPF - but it would need to be ported to Linux\Mac to make it truly universal. I suppose Java is an option, but I don't know much about its presentation frameworks, I've heard not good things about them.
---
V
|
......................... Vassi no Diem et Tharin
< ramble/>
Last edited Sep 24, 2008, 12:50 pm by Vassi
|
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,472
Joined: Oct 17, 2007
|
#21 id:12629 Posted Sep 24, 2008, 2:11 pm
|
On the idea of custom client/server pairs.... If you were to put up a new game, with a nice looking web page, and put a nice easy-to-find download link to a client (for Windows, Linux, and OS X perhaps), I really don't think anyone would think twice about using it UNLESS you call it a MUD. At that point, they will assume they can and should use whatever their current favorite MUD client is, and be annoyed if it doesn't work.
MCCP and a few other protocols were attempts to move the text game community forward (by allowing content to be tagged so a custom client can parse the data stream more effectively), but they all were only marginal successes, or outright failures, because they insist on maintaining compatiblity with raw text sockets (not even proper TELNET, most of the time).
The only problem I see with maintaining compatiblity with the lowest common denominator, is that it means all the extras you MIGHT be able to do, are things you can only use for show. You can't do anything clever with in-game content, because you don't know that all the clients can support it. I'm not one for rainbow ANSI displays, but if I had a custom client and knew I could have it play sounds, or set the font colors with full 24-bit color, I might well take advantage of that to give audible clues, or make an ANSI map that has one part just slightly highlighted. I would not, however, want to put a good amount of effort into something that only a small chunk of my audience can enjoy.
I don't know that a universal protocol is even the right direction to head. There are no existing MUD's that would really take advantage of such a thing right now, and anything that would is likely going to be designed with it in mind. So, if you think you want or need such abilities in your game, I would suggest writing a client that will work hand-in-glove with YOUR server and require that your players use it. If your game is good enough, you'll have enough people. If you document the protocol you end up implementing well, other games might even adopt it, thus leaning towards a new standard.
I think that's a better way to go than trying to cobble up a standard first, and then convince people to use it.
|
......................... 
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#22 id:12630 Posted Sep 24, 2008, 2:23 pm
|
DavidHaley said:MUSHclient shows that you can really do a lot with client-side support for rich window handling, and output from the MUD that is easily machine readable. You don't -- strictly speaking -- need any universal protocols, you just need modules for each client to parse the data from the MUD in question and do something appropriate with it. Unfortunately, this (obviously) means that you'll need one parser module per MUD/client pair. Still, I think that is a more realistic prospect than trying to convince everybody to adopt a single protocol...
I agree,but it still entails that the owner of a codebase do *something*, what that something is is kind of trivial - whether its write a custom parser or learn\adopt a new protocol - they're going to do whichever is easier, or most beneficial.
A module-based approach, for instance, might require you to step outside of your language to whatever the application supports. In .NET you could do Python, Ruby, VB or C# without much work, for instance, but if you're a C\C++ guy you'd have to deal with new syntax. Ultimately this kind of approach would probably be the 'most powerful' in terms of fine-grain control over things, but it would also be more work for all parties involved in that you have to create an external module (potentially in a language outside of your comfort zone) and then go in and monkey with your code to take advantage of the module you just built. Blizzard's WoW client is an excellent example of a module based system, though, that works spectacularly well. I would still prefer, though, that module loading\installing be done solely via the server's request. (I'm a trigger\scripting hater, I'm afraid)
A protocol-based approach still requires you to monkey with your code to take advantage of it but at least (one assumes) you're familiar enough with your own code so that it isn't that big of a deal. the obvious downside here is that you're limited to the functionality the client-builder exposed. Still, if done right, you can get a lot of cool features for relatively little work. I.E. when you're going to display a store menu, if the X protocol is enabled, you shoot out a small bit of markup that gets turned into a dialog on the client side complete with a graphical skin (or some standard skin) downloaded from your site on the fly.
---
V
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#23 id:12631 Posted Sep 24, 2008, 2:36 pm
|
quixadhal said: I would suggest writing a client that will work hand-in-glove with YOUR server and require that your players use it. If your game is good enough, you'll have enough people. If you document the protocol you end up implementing well, other games might even adopt it, thus leaning towards a new standard.
I think that's a better way to go than trying to cobble up a standard first, and then convince people to use it.
Absolutely 100% agreed with everything you said. I feel quite strongly that this is really one of those things you'd want to build with it in mind, rather than retro-fit something that already exists. That isn't to say that you can't\shouldn't retrofit an existing MUD to use a couple of bells and whistles, but a lot of our decisions when crafting the games are based on how much info we can or cannot display or throttling the level of detail to a system based on it being too complex to display\co-ordinate via text only.
Mostly, these posts are in the spirit of the Thread (I think) in terms of what would make an ideal MUD better. Keeping in mind that a large majority of MUD owners are not really programmers, or at least not savvy enough to build their own client or do more than tweak here and there on their codebase of choice, I think that starts to point towards an easy to implement protocol or something to that effect.
p.s. I don't mean to keep double posting but there's new posts after I post an answer to a previous post!
---
V
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#24 id:12633 Posted Sep 24, 2008, 2:51 pm
|
Well, my point was that you don't have to have a "universal" protocol in order to send out machine-readable data. I don't think that the server should be sending anything beyond data: in particular I don't think it should tell the client how to render that data. That is a client-side decision: it might want to render it as plain text, or it might want to send it to separate windows, etc. It's not clear to me if we're actually saying different things; you might be saying that we should just have one mark-up format (e.g. XML, never mind opinions on XML itself) rather than a whole protocol that dictates display. The term "protocol" carries a fair bit of weight for me, much more so than just a data format. I'm not sure why a data format is really all that hard. Again, though, I'm not sure we're actually saying different things in the end of the day...
Being a little brief here, am at work and have lots of stuff to do... 
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,472
Joined: Oct 17, 2007
|
#25 id:12638 Posted Sep 24, 2008, 3:26 pm
|
DavidHaley said:Well, my point was that you don't have to have a "universal" protocol in order to send out machine-readable data. I don't think that the server should be sending anything beyond data: in particular I don't think it should tell the client how to render that data. That is a client-side decision.
I'm in the camp that says it shouldn't BE a client-side decision.
Things that are designed to transmit information (like the world-wide-web, before it became a commercial nest of banner ads and flash sites), should provide the information and let the client decide how to render it. That's because the information is what's important. I don't care what font (as long as it's readable) my news headlines come in, as long as they display on whatever I'm using to read them. That means my iphone might want to render it differently than my desktop, since it has a smaller screen.
OTOH, a game isn't just a source of information. It's an artistic expression that is suppose to be immersive, engaging, and entertaining. If I make a room description with some particular word highlighted in red... there's a reason *I* chose red. I don't care if YOU don't like red, the color is part of the message I'm trying to get across.
I absolutely agree that you don't need much of a protocol to send out data that your client can parse and make decisions about how to render it. For existing games, adding a few tags to say "This is an ASCII map", or "This is a combat message" are more than enough, and you can easily suppress that for players using "dumb" clients.
I don't think that's the smart way to make a new game though. I'd rather know what the client/server capabilities are, so that I, the game designer, can present my vision and know that all my players will have equal footing, and see things as close to what I intend as my technology allows. Do I care if you want all the chat channels in a bigger font? No. But I do care that you get a chance to notice the slight boldface on one phrase of the scroll you were reading.
Sure, you don't need any of that to make an enjoyable text game. We've done fine without it for 20 years now. But every year there is less and less of a compelling reason to stay within those limits if you don't want to. The days of people playing from vt220 terminals in university labs are gone, and the termainl emulators most people use these days are emulating things most of them have never seen. Why not have a true-color text window where you can have more than the paltry VGA 16-color palette? Why not allow sounds as hints that things are nearby that you can't see yet? Well, because you have to bite the bullet and require a custom client.
Your only other option is to NOT make use of any of those technologies as an integral part of your game. Sure, things like MSP can allow you to play sounds... but you still have to make the non-audible versions for people who aren't using it. For that matter, you *SHOULD* make alternative ways to highlight things for people who don't use ANSI color. Because of this, most MUD's only add colors and sounds and such on as fluff. They look pretty, but they're not conveying anything essential to playing the game. I think that's a waste.
|
.........................
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#26 id:12646 Posted Sep 24, 2008, 6:11 pm
|
DavidHaley said:Well, my point was that you don't have to have a "universal" protocol in order to send out machine-readable data. I don't think that the server should be sending anything beyond data: in particular I don't think it should tell the client how to render that data. That is a client-side decision: it might want to render it as plain text, or it might want to send it to separate windows, etc. It's not clear to me if we're actually saying different things; you might be saying that we should just have one mark-up format (e.g. XML, never mind opinions on XML itself) rather than a whole protocol that dictates display. The term "protocol" carries a fair bit of weight for me, much more so than just a data format. I'm not sure why a data format is really all that hard. Again, though, I'm not sure we're actually saying different things in the end of the day...
Being a little brief here, am at work and have lots of stuff to do...
I think we're mostly saying the same thing, but not. For instance, a protocol should be written in some specific way (I.E. XML) but it should 'mean' something. Whether or not the client choses to honor that meaning is one thing, but if a Dialog command exists (just as a for instance) the client should render a dialog with it somehow. Therefore, a protocol (in the way I use it) doesn't have any intrinsic functionality but it does have an implied functionality. Again, I think we're saying the same thing here, a protocol is essentially a data format to me.
I am more or less in agreement with quixadhal on his point, as well, though I will say that colors and such need to be overidable for a variety of reasons such as eyestrain\eye conditions or color-blindness. I guess the bottom line, though, is that even though most programmers are not artists we can all at least understand the concept of widgets\doodads\panels for various things. Simply having certain information available and visible at all times is enough to make the difference between an overly complex battle system and a really cool battle system. I.E. if I have to type five different commands to check five different variables (such as my balance, my opponents balance, their position on a grid, etc) rather than just glance at X panel, then i'm probably not having fun.
---
V
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
elanthis
Wizard
Group: Members
Posts: 772
Joined: Feb 26, 2008
|
#27 id:12655 Posted Sep 24, 2008, 9:47 pm
|
It's dead easy to come up with a new protocol. I've already got a simple message-based protocol (not at all based on telnet, like ZMP) that is compatible with various existing and proposed "web socket" protocols, thus making it easy to add a web-based client.
I fully and whole-heartedly believe that a web-based client is the way forward. It's not about making a nice site with an easy download. It's about not even requiring a download. It's about opening up that site and hitting the Play button and having the game pop up and play right there. #### easy, too, given the features modern browsers have. The only thing missing is an actual way to do networking, but that's easy to remedy if you don't mind using Flash or Java or Silverlight or an ugly HTTP-based protocol. (I'm waiting for the HTML5 JavaScript networking proposals to be implemented in browsers... although the current draft for WebSockets is pure idiocy.) I have a simple Flash applet that does the networking bits for aforementioned protocol and communicates with JavaScript on the page for all the UI. All I'm missing is a nice cross-browser HTML widget for simple terminal output -- getting the scroll behavior and handling screen clears with scrollback is the hard part. Annoyingly hard. Solvable, I just haven't put the effort into it yet, in the hopes some other sucke^Wperson will do it first. ;)
The protocol design becomes kinda easier when you stipulate that it's intended to be used along with an (Open Source) client to be installed on the game's website. See, you're never going to design a protocol that will cover the needs of every MUD out there. Let's say you wanted to implement a paper doll feature, because you're trying to use a very detailed damage system that needs to easily communicate wounds to the player. You just can't make that universal. My MUD might want to just show red dots at certain locations to indicate "wounded." Another MUD might want to show gradients of color at each location to indicate degree of damage. Another might want to be able to completely remove parts to show severed limbs. Another MUD might need all of those features, as well as support a wide variety of non-humanoid body shapes. You can't rely on letting the MUD offer graphics downloads for the paper doll because client A might go with a totally different visual style than client B, and the graphics might match only one of (or neither of) the clients.
Simple protocol, simple Open Source client. Offer extensions to both the protocol and the client for implementing advanced or non-standard features that most MUDs don't need, like paper dolls. Then each MUD can customize the protocol and/or client however they need, and you aren't stuck worrying about whether some third-party client will support your extensions because you only officially support the modified client on your game's website.
You also can then much more easily brand your client, which can be pretty important if you're trying to run a commercial venture (not on most stock codebases, of course). Or even just for MUDs that (thankfully) have a strong theme element, which are often best served by a client that expresses a very specific visual experience.
It also gets rid of the platform issue. I haven't played a great many MUDs in years because jsut about every Linux-capable MUD client sucks donkey balls. The custom clients for games like Simutronics' only run on Windows, and the handful of "top tier" generic clients are also all Windows exclusive (with a possible Mac OS X). The Web is universal. Even when the user's platform isn't an issue, the availability of software may be. Public terminals often don't allow installing software, but they can all run a web browser (and almost always have Flash/Java installed). A web-based client will work for everyone, everywhere. They even make working around firewalls a lot easier, if you do decide to go with an HTTP-based protocol (which will be quite easier once the server-sent events stuff is more prevalent... for now you need to rely on XMLHttpRequest and "COMET" patterns).
Basically, instead of trying to create a ton of inter-operable software that is supposed to somehow magically support an unpredictable set of features, offer a set of tools by which game developers can build their server and client components to meet their specific game design requirements.
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#28 id:12658 Posted Sep 24, 2008, 10:47 pm
|
Sorry, need to be brief again.
quixadhal said:For that matter, you *SHOULD* make alternative ways to highlight things for people who don't use ANSI color.
And that is why I think the semantics are far more important than the formatting. You are trying to convey emphasis. OK, maybe for you, ideally emphasis means red text. But if I'm playing on a white background, that is sub-par. If you already "*SHOULD*" make alternative ways, why not only have one way -- tagging the semantics of emphasis -- and let the client decide how to render that most appropriately? What I do on my smart phone might be different from what I do on my desktop, which might yet again be different from what I do on my laptop, etc.
Vassi said:Again, I think we're saying the same thing here, a protocol is essentially a data format to me.
Oh, I see the difference now. Whereas what you describe can have actions, such as "display a dialog", I am talking about a purely descriptive format. That is, I see no functionality in the data description: it is merely a description. What you choose to do with it -- render it to text, to a window, to colors, whatever -- is up to the person seeing the data. (Where person can be a client, or even a layer in between the server and the client.)
Elanthis said:It's dead easy to come up with a new protocol.
Oh -- sure, it's (usually) easy to design a protocol when you have very specific requirements and know exactly what the client and server in question are doing. The extremely hard part is getting everybody to adopt it. For instance, for us to agree to standardize, I would have to believe that your protocol will allow me to do whatever I want. And if Fred gets involved, he has to agree too. When you get the major server coders and client authors together, the problem is just compounded, because then you have to convince the client programs as well to support the protocol...
|
|
|
quixadhal
Wizard
Group: Members
Posts: 1,472
Joined: Oct 17, 2007
|
#29 id:12675 Posted Sep 25, 2008, 1:27 am
|
DavidHaley said:quixadhal said:For that matter, you *SHOULD* make alternative ways to highlight things for people who don't use ANSI color.
And that is why I think the semantics are far more important than the formatting. You are trying to convey emphasis. OK, maybe for you, ideally emphasis means red text. But if I'm playing on a white background, that is sub-par. If you already "*SHOULD*" make alternative ways, why not only have one way -- tagging the semantics of emphasis -- and let the client decide how to render that most appropriately?
The paragraph that quote comes from describes the unpleasant alternative to having a client and server which were designed to work as a pair. Namely, if you know that some clients will not support some of the features you are using, you have to waste the productivity to try and create workarounds to get your message across in a sub-optimal way. I'm advocating NOT doing this, because if you control both sides of the equation, you aren't forced into that position. In my client/server model, you wouldn't BE playing on a white background. Sure, I'd lose some players that can't stand black backgrounds, or red text... but you can't please all the people, all the time.
DavidHaley said:What I do on my smart phone might be different from what I do on my desktop, which might yet again be different from what I do on my laptop, etc.
Indeed. And for all the kinds of things smart phones, laptops, and desktops can do, it's good to have things that work well on each. Where is it written that I have to shoehorn my vision into a shape that will fit on your smart phone? Why is it a bad thing to put minimum requirements on your game, so that the user gets the experience you want them to have?
The fact that something CAN be done, doesn't imply that it's the right thing to do. I know you CAN play Quake on a vt220 terminal by compiling the game to use AALIB. From a technical standpoint, that's impressive. I don't think being able to do so means the player is getting the proper experience of the game, and I think Quake would have been a less impressive game if they'd limited themselves to what AALIB could render on a monochrome terminal with no mouse support.
As I said, existing MUD's won't gain anything, because they've all been designed to use mostly pure text, with any additional information being tossed in as a convenience factor. If I were to design a text game that used real-time combat where positioning mattered, targeting mattered, and I had enough stats that you had to pay attention to that reading all the text would take too long, you can bet I'd want to use color, and I'd probably want full screen control, and possibly seperate panels or windows. I might even want mouse support to reduce the amount of typing required.
|
.........................
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#30 id:12723 Posted Sep 25, 2008, 9:46 am
|
elanthis said: Offer extensions to both the protocol and the client for implementing advanced or non-standard features that most MUDs don't need, like paper dolls. Then each MUD can customize the protocol and/or client however they need, and you aren't stuck worrying about whether some third-party client will support your extensions because you only officially support the modified client on your game's website.
I guess my major issue with all of this is that people already have the option of 'customizing' a client, it's called their programming language of choice. I mean, honestly, if you're using flash\silverlight for the networking components why not just use flash\silverlight for the entire display as well? 'Customizing' doesn't mean much if the only thing the base package provides is the networking code, that's the part that is usually the absolute least amount of work to begin with. Those codebase owners who have really fancy features, outside of the stock-mud featureset, are probably competent enough to do a little coding of their own (assuming they get an artist to work with).
That said, there are a lot of correlations between HTML and the way I would skin a customizeable GUI. For instance, paper-dolls could be handled via a graphics skin and an Image Map so that when you click on a section you tell the game either the co-ordinates or the name of the hotspot that was just clicked on and let it do it's thing. I'm assuming that your framework (Which is really the flash\silverlight component, at this point) would provide the means for the java-script to send a message to the game and the game to provide a message for the javascript. In effect then, the framework would be kind of like a message pump with the client defining the messages and their implementation in Javascript. I.E. the MUD sends a Key and a data blob and then the flash\silverlight message pump looks for an equivalent hook to match the key and passes it the data blob.
Google's Chrome, with their impressively fast new Javascript engine and the neat little application shortcut, comes to mind. They're planning to go completely multi-platform and I'm fairly sure betting on Google is a safe thing. Other than completely specializing in one browser you'll have to rely on frameworks like jQuery (and be very careful about your HTML\CSS)
I guess my question is "does that make it any easier to do it?" or is it just good ol' fashioned pioneering. I guess my initial approach is to be an enabler, so that even people who just grab a codebase and tweak it without strong programming knowledge can still cook up something decent. Javascript is not friendly =( (Sorry, I'm just bitter. I actually kind of enjoy working with Javascript again with jQuery)
I feel like I kind of just ran around in a huge circle, so I apologize for that. I have to say I'm a little intrigued by the idea though and i have to ask why we've not seen more flash clients.
---
V
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
