07 Mar, 2010, Blinx wrote in the 1st comment:
Votes: 0
Hi, there.

Name's Mark Bauermeister. As you might see, I'm brand new to this board :)

I dreamed of programming my own MUD for years but always lacked the time/consciousness. I have planned it thoroughly over the last couple of years, however.

But first things first:

My idea is an open-world fantasy MUD. Players may choose between the typical fantasy races (Halflings, Humans, Elves) each with their own start location. The player may then buy houses (each placed in special locations. Limited to 2 properties per player), become a farmer, hunt or tame animals in the woods, craft armours, weapons or jewelry, finish quests or volunteer to the Army of the West.

The game screen itself should consist of the typical text screen (including a parser), a combat screen (basically a picture of the enemy and some stats), a inventory (character stats + items + a player image showing the player in his equipped armour) and a map (pre-rendered 2.5 D landscape, player characters and houses shown in an animated form)

Now I know that the graphical part is kinda overwhelming. That why I have to ask: Has this ever been done before? What client/language would probably be best suited for such an idea?


Languages I'm experienced in: HTML, PHP, JAVA (rather minor skills, though), Dark Basic.


Should I need C++, C, that's not a problem at all. My brother could help me with that part.


PS: I actually tried to turn my concept into a browser game before. That was after I found an easy to use engine. Turned out bogus, though. With the time spent modifying all those PHP files, I could've easily learned C++. :biggrin: This aside, it never worked out. It took me a day and a half to realize that this kind of complexity belongs into the realm of MUDs.

PSPS: My favourite MUD is BatMUD. If I could use (or modify a client to make use of those features) a client similar to this one + a graphical combat window + a bitmap based map + a graphical inventory, I would be quite happy.
07 Mar, 2010, KaVir wrote in the 2nd comment:
Votes: 0
The "graphical" aspects will be handled by the client - so if you want that sort of thing, you'll need to develop (or customise) a client as well as the server.

Generally speaking, the server and the client are independent applications. You can get better results if they're designed with each other in mind, but from a development perspective it's probably easier to view them as separate projects.
07 Mar, 2010, Blinx wrote in the 3rd comment:
Votes: 0
I see.

I'll probably program my own server app (JAVA or C++, I suppose). However, my question is: Is there an existing client that you would say is more versatile than all the others? A client one could easily modify to one's own needs?
07 Mar, 2010, Orrin wrote in the 4th comment:
Votes: 0
Blinx said:
However, my question is: Is there an existing client that you would say is more versatile than all the others? A client one could easily modify to one's own needs?

Mushclient has the ability to display graphical content in mini-windows so that could be an option perhaps. It's also open source so you could modify it to suit your needs. Otherwise you'll probably want to roll your own. Flash/Flex/Air or Silverlight would be well suited to the task, but you could develop the client in whatever language you're most comfortable with.
07 Mar, 2010, Blinx wrote in the 5th comment:
Votes: 0
Orrin said:
Blinx said:
However, my question is: Is there an existing client that you would say is more versatile than all the others? A client one could easily modify to one's own needs?

Mushclient has the ability to display graphical content in mini-windows so that could be an option perhaps. It's also open source so you could modify it to suit your needs. Otherwise you'll probably want to roll your own. Flash/Flex/Air or Silverlight would be well suited to the task, but you could develop the client in whatever language you're most comfortable with.


Thanks. I'll look into that, as soon as I get my Windows PC back (can't really do too much with that Macbook replacement unit).

Wondering, though. Would it be possible to use 2D graphics on top of the 3D Mud client (rather than 3D graphics)?


EDIT: Mushclient looks like it might do for a 1st version of my MUD. I think I'll put the "player representation" idea back in the drawer, though. Having each player presented by a sprite on a bmp map seems utterly complex to integrate.
07 Mar, 2010, David Haley wrote in the 6th comment:
Votes: 0
Quote
Wondering, though. Would it be possible to use 2D graphics on top of the 3D Mud client (rather than 3D graphics)?

Yes. You can draw 2d images even in a 3d rendering program, if that was your question.

Quote
Having each player presented by a sprite on a bmp map seems utterly complex to integrate.

Yes, it would mean having every frame of every combination of race and equipment stored somewhere, which sounds like a lot. :) Another approach is to animate the equipment pieces, and to assemble them dynamically.


EDIT: oh and re: language, you want to pick a language with a strong graphics framework. Such things exist for C++ etc., but as others said Flash & friends naturally come with a lot of graphics support and a lot less mucking around on your part to get it set up. Especially if you want it to be web-based, you should consider going with one of those.
07 Mar, 2010, Orrin wrote in the 7th comment:
Votes: 0
Blinx said:
I think I'll put the "player representation" idea back in the drawer, though. Having each player presented by a sprite on a bmp map seems utterly complex to integrate.

This isn't necessarily complex, and certainly isn't going to be the most challenging problem you face when developing a persistent multiplayer networked game. Assuming your server is authoritative it would notify each client about objects that it is interested in according to whatever game logic is in place. In a room based MUD you could use a very simple line of sight system where objects in adjacent rooms are visible to each client. If you are using a room-less world then there are different algorithms which can be used to determine which objects are in range. Updates could be sent regularly or only when the information changes. On a traditional MUD server you could send this information using your own telnet subnegotiation scheme, or perhaps using an existing protocol such as MXP or ZMP.

Edit: Looks like David answered this in respect of avatar customisation and itemisation, whereas I interpreted it as an interest management problem. If your graphics are already very low tech then displaying only a limited variety of sprites, perhaps based on possible class/race combinations, might be a compromise worth making.
07 Mar, 2010, Blinx wrote in the 8th comment:
Votes: 0
David Haley said:
Quote
Wondering, though. Would it be possible to use 2D graphics on top of the 3D Mud client (rather than 3D graphics)?

Yes. You can draw 2d images even in a 3d rendering program, if that was your question.

Quote
Having each player presented by a sprite on a bmp map seems utterly complex to integrate.

Yes, it would mean having every frame of every combination of race and equipment stored somewhere, which sounds like a lot. :) Another approach is to animate the equipment pieces, and to assemble them dynamically.


EDIT: oh and re: language, you want to pick a language with a strong graphics framework. Such things exist for C++ etc., but as others said Flash & friends naturally come with a lot of graphics support and a lot less mucking around on your part to get it set up. Especially if you want it to be web-based, you should consider going with one of those.


Hah. The bolded is exactly what my brother told me. Doesn't seem to be the worst idea.

I however, was actually thinking of a different approach. Since characters on the map are pre-rendered, I was thinking of redoing them only for as much as character classes exist.

The only time someone is going to see the full equipment on ones character, is when he's accessing the character screen/inventory.


My bro actually calmed me down a bit. He told me not to haste things too much. What I should do first and foremost is developing the basics, using a standard MUD client (gonna use Mushclient here) and a standard MUD server (rather than programming one myself on the first day), he said.

And that's exactly what I'm going to do. I mean. Graphics can look as awesome as they want, but if all you do in the game is moving straight through a cave with no interaction whatsoever, then … Well. You get the point.
0.0/8