![]() |
#21 | |
Senior Member
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
![]() |
Re: Hi, hey, hello
Quote:
As a matter of fact, I have been testing the truth of this for four years now. I have a pretty typical DikuMUD driving a mobile MMO UI that is quite indistinguishable from any other mobile MMO (except it's better ![]() You are right that just because two games use a database doesn't mean they are at all similar. However, that supports my argument and not yours ![]() Last edited by plamzi : 10-07-2013 at 06:28 PM. |
|
![]() |
![]() |
![]() |
#22 | |||||
Member
Join Date: Oct 2011
Posts: 40
![]() |
Re: Hi, hey, hello
Quote:
HTTP, TELNET, FTP, SMTP, IMAP, etc, etc, IS the very minimal definition of how the software needs to behave in order to be considered compliant with that particular version of the standard. It defines the server (and often clients) basic functionality. While you might be able to coerce an HTTP server into implementing bidirectional TELNET-like functionality or vice versa, this does not change the essential fact that they (by definition) are not the same, nor are they likely to be implemented the same. Quote:
implements its protocol, otherwise you risk blurring the lines between MUD and MMORPG, which could lead to some rather foolish arguments. It is however these "different approaches" regardless of whether they are MUDs or MMORPGs, which leads us back to the original point. Different approaches can lead to different outcomes, and it would be an mistake to assume otherwise. I contend that the choice of protocols could significantly alter both client and server design, in addition to the potentially vast dissimilarity created by the game logic itself. Quote:
How could two separate games have "near-identical" game logic? That makes little sense. What would motivate people to spend their money on such similar products? I know for certain if I purchased Diablo 3, and it sucked as much as Diablo 2, I would demand a full refund! ![]() Quote:
representation (shared with the client), and detect collisions with arbitrary 3D planes? Or would both client and server need to be upgraded before we get to experience these features? Quote:
![]() |
|||||
![]() |
![]() |
![]() |
#23 | |||
Legend
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
![]() ![]() |
Re: Hi, hey, hello
Quote:
Quote:
Quote:
Now you're talking about specific implementations - you're making those assumptions again. Do you think all MMORPGs have collision detection? Do you think MUDs can never have collision detection? This comes back to my earlier point: when you design your game you need to decide whether or not you want collision detection, and you need to make that decision whether you're developing a MUD or an MMORPG. |
|||
![]() |
![]() |
![]() |
#24 |
New Member
Join Date: Jul 2013
Posts: 8
![]() |
Re: Hi, hey, hello
Wow, didn't expect to start such a lengthy discussion, but I'd be happy to contribute.. from the outset, I've been taking notes on developing both applications. I knew a little bit from reading development guides but mostly I've been banging my head into my keyboard.
Position updates taught me the most major lessons. First, detecting when a client has tried to move out of bounds in a 2d plane without any obstacles is trivial. Accounting for solid objects on the terrain, and a third coordinate? Not so much. Second, client software loops very quickly. Many hundreds or even thousands of times per second. Attuning the rate of motion to prevent rubberbanding is a challenge all to itself, and with the client looping that often, you need a substantial amount of packet updates to see entities other than those your client is positioning move smoothly. This amounts to about 15 position updates per second for my client, which also uses prediction to account for momentum. Another 5 are used to provide minimal state information on things that can be affected, like mobs. At the moment, that includes everything that moves. -This raises even more sub-problems of its own. In the textual version, I didn't have to send everyone a mass of packets every second. In the graphical version I'm having to be far more specific when designing objects, to avoid bandwidth waste, and shorten data in general, since n20 space separated strings per second per player is a gigantic cost. That's not to say its been all difficult, though. Learning to code for the mud client standards was a serious pain in the ass. Detecting client types, disabling or enabling feature sets, and applying compatibility filters is a lot of work. On top of this, analyzing input was extremely tedious, having to account for many variations of commands and document all of it. Having control over the client's side of things doesn't mean i can discount the golden rule (never trust the client), but it means i can make a lot more assumptions about the structure of input data and state of the client, and don't have to provide verbose error messages to the client when something is improperly formatted. I'm having fun expanding my horizons, and though much of the functionality and story are changed, it's infinitely entertaining either way to try and build your own little world from scratch. |
![]() |
![]() |
![]() |
#25 | |||||
Member
Join Date: Oct 2011
Posts: 40
![]() |
Re: Hi, hey, hello
Quote:
reliability offered by TCP. Many real-time servers use UDP and possibly some form of compression. Delta encoding - Wikipedia, the free encyclopedia Some servers might even use both TCP and UDP for different purposes. Quote:
I'll try to adhere to the most common definitions, for the sake of utility and to facilitate communication. I disagree, Diku would require significant modification to offer the functionality of a Quake server, at which point it would probably look very unfamiliar, in fact you might be better off trying to convert Quake into a mud. You could provide a pseudo-3D graphical client atop Diku, but this is not 3D in any contemporary sense, based on what modern users might expect if you tried to convince them that it was. They would probably feel deceived (realizing they've seen better 3D on their iPhone), and begin sending angry tweets. It could get ugly. Quote:
issues related to server design. What you said is, Quote:
thing, from a "server-development perspective." They are two very different approaches to providing a virtual space. One is a hard-coded game server, the other provides a virtual platform and language with which it is possible to implement a game server, or something else entirely. So why would you assume graphical mmos would be the same? Differences in server design permeate not just the communication methods chosen by the server, but in some cases, how the game itself is implemented along with its various subsystems to what extent they exist, integrated or separately. Add the complexity of managing complex 3D spatial relationships and the need to frequently synchronize related constructs with the client, to determine visibility/audibility, solve collisions, etc., and it could result in technical differences that defy any reasonable attempt at comparison. Indeed, this message forum might have more in common with text-based muds than certain graphical mmos do. Should we include web servers and web forum software into the mix as well? How about IRC chatrooms, certainly they manage virtual space, and would even meet the "real-time" requirement of Mr. Trubshaws definition. Many web technologies even offer some level of persistence, and make use of concepts like "avatar." Quote:
![]() You missed the point entirely, perhaps you've disregarded the context in which the statement was made. The implication was that the client can only degrade what information is provided by the server. It can take either take full advantage of the information provided, or less. It cannot add information where none exists. Adding a 3D interface to a game which is essentially 2D, or not designed to fully utilize a 3D dataset creates a pseudo-3D game (similar to UO's 3D client, as a generous estimate). These "specific implementations," whether we like it or not, can have consequences with regard to server design. |
|||||
![]() |
![]() |
![]() |
#26 | ||
Legend
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
![]() ![]() |
Re: Hi, hey, hello
Quote:
Quote:
A DikuMUD could be played as a fully graphical game, but it won't look like Quake. World of Warcraft could in theory be played as a text-based game, but it wouldn't look like DikuMUD. However in this particular case the poster is designing his own server, and therefore has full control over what data it passes to the client. He could create a game server that is playable as both a text-based MUD and a full 3D graphical MMORPG if he wished, depending on which client the player uses. |
||
![]() |
![]() |
![]() |
#27 | ||
New Member
Join Date: Jul 2013
Posts: 8
![]() |
Re: Hi, hey, hello
Quote:
Quote:
|
||
![]() |
![]() |
![]() |
#28 | ||
Member
Join Date: Oct 2011
Posts: 40
![]() |
Re: Hi, hey, hello
Quote:
UDP these days, there's been some pretty major bandwidth improvements over the years. Though I'm sure it still sees some use. TCP offers a lot of convenience, which UDP can help you appreciate. In a situation where you find yourself reimplementing TCPs features, then yea, it's probably best just to settle for TCP. In fact, using UDP may be more accurately described as, "going against the grain," for most common purposes. UDP is unreliable, which may not matter so much in cases where you are sending lots of small packets containing data that is not so critical, like movement deltas, where a few losses won't mean the end of the world. Wikipedia States, Quote:
|
||
![]() |
![]() |
![]() |
#29 | |
Legend
Join Date: Aug 2007
Name: NewWorlds
Home MUD: New Worlds
Posts: 1,393
![]() ![]() |
Re: Hi, hey, hello
Quote:
Thing two: On the argument of there being no difference between an MMORPG and a MUD. I think you are all talking about the data stream and not the definition of MMORPG which is MASSIVELY (key word) Multiplayer Online Role Playing Game. That means folks, 1000's to Milions of players, not single digit to a few hundred. Let's not kid ourselves, MUDs are not anything like MMORPGs in the sense of the term which was created by Ultima Online's developer which had over a million players and he wanted to differentiate it from a simple multiplayer online game. Don't lose faith though, one day they might be, afterall "The Hobbit" the book sold more copies that the movie ever will. ![]() |
|
![]() |
![]() |
![]() |
#30 |
New Member
Join Date: Jul 2013
Posts: 8
![]() |
Re: Hi, hey, hello
A little update (and one that makes me feel quite flaky!)
I successfully cobbled together a graphical game engine, client and server. I used freely available assets from numerous indie resources and actually managed to get a coherent theme, somewhat pleasing UI, balanced gameplay and stable, low requirement threaded system. I hated it. I lamented the loss of creative freedom and inability to precisely impart the theme I'm trying for, the increased difficulty in implementing user generated content and the suddenly flat and direct gameplay. So I've decided to go back to making a mud, where the only obstacle in my way is focus. tl;dr i'm making a mud after all, how flaky! Last edited by meae : 10-27-2013 at 03:49 PM. |
![]() |
![]() |
![]() |
Thread Tools | |
|
|