Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Possible new client written using wxWidgets?
Possible new client written using wxWidgets?

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2  3  4  5  6  7  8  9  10 11  

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #135 on Thu 11 Oct 2007 07:25 PM (UTC)
Message
Actually, just to be argumentative, your right and wrong. Some patches for EQ2 have included changes to the icons, so you can tell some items apart easier, but usually the patcher is fixing something in the main engine, or a few things in specific zones, most of it not dealing with graphics changes. The two nights ago was an engine patch, which took like two hours on dialup, so it was still a pain. Usually, most of the patching happens in a dozen xml files, and more rarely in their graphics packages. Thankfully they can just patch the smaller new file into the older one somehow, otherwise it would take 10 days, instead of 10 hours (I know, that is roughly how long the "first" patch took to update it from what was on the CD. Shudder!!)

So, yeah, for a text client, or even one that uses some limited graphics, like icons, its not going to be that bad. But that is also why I would consider a torrent style update. Let the people that have broadband shoulder the burden of downloading it all at once, when the update happens, then let everyone else leech it at the pace "they" can handle. Unless its critical to game operation, which it shouldn't be in a text game, it won't matter if some guy with dialup has limited the bandwidth to like 0.5k/s to avoid lag, and it takes him 3 days to patch. He can always just sit out a day, on his own option, and let the client download it at 4k/s, or what ever. Normal FTP can't bandwidth limit, and will grab as much as it can, to the limit of what the server its getting it from allows, to get the file to you, which is **horrible** for someone without lots of bandwidth to do that.

But yeah, I can sort of be of two minds about it too. The problem I see is mostly that MS and some others are pushing the idea of everything sitting one "someone else's" server, then only loading it as needed, which means some twits are going to go, "Heh! Great idea!", without considering the complications of the system, the bandwidth they will lose all the time, if say every player clears their cache every day at the end of the session, etc. For a big company, who can afford the overhead, its not bad, though too many users trying to get the application will lag the system like hell, but for the little guy running a mud... You might want to rethink hosting any but the most *basic* client on your own server. lol
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #136 on Thu 11 Oct 2007 09:49 PM (UTC)
Message
I also would have to say, anything like an AJAX sort of thing in a muck client just plain isn't for me. Even if it wasn't browser dependant. Mentioned it before, but I'd be a lot more happy with a "real" client, if I may it so bluntly.
Top
Posted by Mojosmitty   (5 posts)  Bio
Date Reply #137 on Sun 14 Oct 2007 05:56 AM (UTC)
Message
Hi guys. I just ran into this thread. It's kind of ironic. I've been building a GUI front-end to smaug for the past month and a half and my thoughts were very similiar to what has been discussed in this thread. We're basically replacing all the 'obvious' elements with graphics and everywhere else we think is possible. I have a demo client already working, written from scratch, ansi support, and some graphical features working. We also have two graphic designers atm that will be adding front-end graphics.

It's all written in .NET C#. The current client is .net 3.5 using ClickOnce, and the web-client is written in Silverlight 1.1 alpha. And the smaug server is of course, written in c. (and using 1.8b currently)

My primary goal is to create an interface that cuts out a lot of the steep learning curve of muds and makes it easier for a new generation to get into mudding. I think there's a lot of work already put into these muds and i'd like to harness it but make it more palatable for people who are used to WoW and other modern-day mmo's.

If you're interested in any more info feel free to email me at tarlyn72@hotmail.com. I'm currently the only coder and reaching the point where I really could use some help coding-wise. If you'd like to help i'd love to discuss it with you. I'm also not opposed to maybe one day releasing the source if it ever comes to the point where it's working fairly well.
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #138 on Sun 14 Oct 2007 12:21 PM (UTC)
Message
Does that new client also work with simple, plain mucks? The point of those mucks is to basically tell stories in roleplaying. There are no stats to keep track of whatsoever. Quite simple actually. For a good muck-client you'd basically need really good text editing features for the input area, cut & paste support and all that jazz. All these mud related features, except ANSI support, a muck client doesn't really use.

However, I'm still, of course, focused on the idea of a new MUSHclient, 'cause so far that handles mucks with excellency. Running it through wine however is not my thing.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #139 on Mon 15 Oct 2007 12:08 AM (UTC)
Message
Lot of muds have started to do that Mojosmitty. The discussion is mostly about how to do it "generically", so that, much like how you start with a code base, then just design what ever you want, you can start with a client, then just do what ever you want, with some ideas for how the mud/muck can send basic layouts and other data, to customize that generic client for "their" server, without having to code one that only really supports that they wanted. So far, I haven't seen a trend in that direction. Its mostly been either the VB theory of design, "You can do anything you want, as long as it still *looks* like a VB application.", or the, "You can do anything you want, as long as you are willing to code it yourself.", method. The intermediary kind of, "Here are the features we support, you figure out how to use them and what to skin them with.", type client isn't really seen much in mud/muck style clients yet.

That's been kind of the point of this thread. What do you need to make one that is generic enough to use any place, but flexible enough that you can skin and script it to work from anything from a story muck, to a single D&D style stat system and RPG, to something really complex, in terms of both the character data and how the world is interacted with? Custom built clients that limit you to a specific set of "features" just won't cut it any more. ;)
Top
Posted by Mojosmitty   (5 posts)  Bio
Date Reply #140 on Mon 15 Oct 2007 03:22 PM (UTC)

Amended on Mon 15 Oct 2007 04:48 PM (UTC) by Mojosmitty

Message
I couldn't agree more with Gammon when he say's: "I am inclined to think that ... a new paradigm could be developed, by also developing a new server, that starts to use some of the new technology that has been developed over the last 20 years. In other words, drop the pure text-only interface between client and server, and have "event messages" that more neatly encapsulate what is going on in the virtual world, and lets the client display it, unambiguously, in a neater way."

That is exactly what i am doing with my client. Now, whether it is actually generic enough to support all other forms of muds is a good question. From the client side if it doesn't care what type of mud it is interacting with, as long as it gets the correct "event messages" as Nick put it. I am of course designing custom graphics because i'd like to make my world to be unique, but if the client had some simple scripting interface, all of that could be modified by the user. It's just a GUI responding to event messages from the server after all.

But if we're talking about a generic client that supports all types of muds/mushes right out of the box, without the mud server implementing the special "event message" syntax, i don't believe that is very feasible. Parsing out text strings only gets you so far. The server (like my modified smaug server does now) will have to support those "Event Messages" to pass to the client.

If we want to have a generic graphical client we'll also have to agree on an Event Message syntax for our server's to implement, and then actually implement it correctly in the various mud's/mush's, etc. which isn't trivial at all.

In my case, my client sends a handshake to the server, and once completed the server knows the "Custom Client" is connected. The server then sends Event Messages to the user for the client to interpret and parse out. Otherwise the server acts just like a normal Smaug server.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #141 on Mon 15 Oct 2007 07:08 PM (UTC)
Message
Well, yes and no. Realistically, if you want it to work well, you do need a new protocol, with events linked to the server content you want displayed. *However*, a lot of content that is already generated uses existing client triggers to do everything from auto-rolling, to modification of how ones inventory looks, to storing data on what specific items do. There is no real reason why lots of things, including your character inventories, can't just be trapped, as they are now, and displayed through the same GUI elements. The point being to make one flexible enough that you can do that, if the mud supports "anything at all" that could be put into GUI, but not the more sophisticated protocol.

And, using script to *change* the GUI kind of depends on what you mean. If you mean something like applying a different GUI layout to something the mud "expects" to work a certain way, then yeah. That is part of it. But, one issue I have discussed is separating the *design* from the *code*, such that you could create an inventory layout, store than in XML or something, then have it "loaded" in the script, instead of having to use the script to *code* the whole thing, which isn't going to be practical if the server is updating only the GUI, or it has to update the script, but not the GUI, etc.

Mind you, the other trick is to support some way to *merge* scripts, so you only send the updates you need, not an entirely new script or GUI setup. The reason to keep them separate is that if they are the same, then changes to your GUI layout could scramble changes to the code, and vice versa. In the best cases, you would want to avoid changing the "code" from the user end at all, instead providing a way to get a different plugin to also receive the same "events" if needed.

Basically, you need the server to be in control of *what* the elements are that make up the GUI and the main code used to handle them, but you want the user to be able to loadUI over the layout of the GUI and maybe provide some method to have their own code react to things like button clicks from the GUI, or data from the server (such as if storing the tooltip for an inventory item as it arrives, so that they can put it in a database).

This is a bit more complicated than just scripting everything, then hoping the user doesn't mangle the code for everything from the events to the GUI itself. lol
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #142 on Mon 15 Oct 2007 09:13 PM (UTC)
Message
I hope this doesn't come across as 'rubbing the wrong way':

So far I've thought that the idea was to create a new cross-platform client version of MUSHclient without all that much changed about it.

But instead, it seems like many of you are looking for 'the' client for 'the' the new breed of servers. And I'm getting worried if this will still be a MUD or muck client at all, in the end. I'm sure that new stuff is going to be great, with the exception of running things in a browser (god forbid) using flash or or whatever, or to virtualise the client in any way whatsoever.

Just don't leave the low-end out. At least those're my thoughts as a non-programmer.

While you focus on that next evolutionary step, don't regress the client in terms attractiveness for use with "simple", normal MU*'s, if possible :).

Top
Posted by Mojosmitty   (5 posts)  Bio
Date Reply #143 on Mon 15 Oct 2007 11:00 PM (UTC)

Amended on Tue 16 Oct 2007 03:37 AM (UTC) by Mojosmitty

Message
Well, Jammet, i guess we have hijacked the thread somewhat :)

It's probably off-topic, but i'll address your concerns from my point of view.

My purpose, at least from the server side, is to make sure that "older' clients like zmud, gmud, mushclient, etc. can all connect, and people can play like normal. But also support the new graphical client as well.

From the custom client side, your fears are probably semi-realistic. My client at least is honestly not really going to be much of a mud/muck client at all in the traditional sense. At least thats not the -purpose- of it anyway. We're doing a Silverlight client, which is basically Flash on steroids. I really want to target the Flash game market, and get a lot of new people playing muds, and having a 1-click in-browser experience with graphical support is imo the best way to do that. But that's maybe not as bad as you think. There is the traditional telnet capability built in, and it would be fairly trivial to provide a 'non-graphical skin' type option, to give you more of the traditional look on the client, if one wanted to do that.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #144 on Mon 15 Oct 2007 11:05 PM (UTC)
Message
A standard MUD is essentially a special case of the enhanced "event-based-special-protocol-thingamjig" server, in which every character sent by the MUD is to be interpreted as the event of putting that character on the screen. So I wouldn't worry too much about a fancier client not being able to handle standard servers.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #145 on Tue 16 Oct 2007 11:51 AM (UTC)
Message
Ah, thanks for explaining in some more detail.

I'll get back to talking actual MUSHclient now, but before I do I share my opinion (I'll be real honest) on the Silverlight client / server.

It sounds pretty promising for the future. I will never use a flash client, (I really loathe the idea, sorry sorry), but a whole lot of people will. And attracting more casual crowds with that will probably work. Let's hope they're not too casual -- so far I thought the broad masses not being present on mucks I play on is a bliss, as more casual online-d00dz as we've come to know them from World of Warcraft really wouldn't fit in the specific games I play.

Well, something like Silverlight is still a great idea, so by all means, do it. You could perhaps even help having a 'new' MUSHclient be compatible with it.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #146 on Tue 16 Oct 2007 06:53 PM (UTC)
Message
Well Jammet, if you where paying attention at all, one reason to use wxWidgets would have been to allow for a lot of stuff that just isn't practical in the current MFC based client. That includes the GUI elements, etc, which have been brought up in one form or another a lot of times. Any cross-platform client would likely support better user-definable GUI, and it then becomes the question of, "Ok, now that we have that, how do we use it effectively, and is it reasonable to come up with a better way to have the server control some of this stuff than MXP or the other messes that currently exist?" ;)
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #147 on Tue 16 Oct 2007 07:41 PM (UTC)
Message
Of course I'm paying attention? I hope I didn't write anything that upsets you. Certainly didn't mean to. :)

The thing is, I do not know much anything about programming. I'm here because I like MUSHclient, and there's a chance to have something a lot like it become crossplatform.

I may be somewhat ignorant with what's practical and what's not without even realizing. However, I simply favour a program storied on my harddrive, a native binary, over anything based on a third party plugin, interpreter, browser or the likes.

So I went on describing what kind of client I'd hope the follow-up to MUSHclient is going to be like, that's really all there is to it. :)
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #148 on Tue 16 Oct 2007 08:04 PM (UTC)
Message
You could have a browser application stored on your local computer too, actually. Unless it needs to read files off of the server without talking to the server using HTTP (debatable whether a client needs to do that), you could just run the application in your browser from your local machine and have it connect to another computer.

Basically, the choice of language isn't really a limiting factor, even if it's browser-based technology, in terms of where you can run/store the program. Now, you still might prefer a standalone client over a client in the browser (but perhaps not for the reasons you might first think! it's kind of subtle) but that's a separate issue. (What I meant by that last comment is that a browser can, e.g., run a Java applet; you'd have nearly the full power of Java available to run your client which means you could do pretty much as you could have done in a normal Java app.)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Jammet   (14 posts)  Bio
Date Reply #149 on Tue 16 Oct 2007 09:39 PM (UTC)
Message
Sorry that I'm repeating myself twice over :). Having it on a local harddrive is possible, but as you mentioned, it's not my thing if it's wrapped up using in the browser, flash, or java.

As for the reasons, well, there are several.

I'm not happy with the overall stability of browsers, or java applets or flash.

Standalone Java programs that simply require the Java-Runtime are fine though.

And I have yet to see a single Java/flash application that works for me, meaning usability, configuration, looks, performance, cpu hogging and what not. No two look alike, no two work alike, no two are configurable alike.

I need the configuration stored in my home directory like with all the other applications, where I can look at it, back it up, have full control over it.

There are several other reasons. Generally, I think I just feel way safer and more comfortable with applications that I can control. If they're the child processes of the children's childrens children, meaning encapsulated, wrapped up in a much bigger package, I can't warm up to them. Never played browser games twice for the same reason.

But again, that's just me. =) Your idea is brilliant and it's going to be great, no doubt. Just felt compelled to reply, outlining why I feel this way.


Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

370,936 views.

This is page 10, subject is 11 pages long:  [Previous page]  1  2  3  4  5  6  7  8  9  10 11  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home