I've been a MUD player for about a year or so, and in the hopes that I can accomplish something out of the several hundred hours of gaming, I've  decided to pick up some programming with Java.

So just for fun I want to try and build a client using Java. I'm very new to programming but I have a couple of beginning books for Java. So anyway, my question is: Where do I start? I can look up many answers related to Java in general, but I have no idea whatsoever how to apply it to programming a client.

So if any of you could give me a few hints or even just refer me to a book or website, I'd be very grateful.

Thanks.

Are you going to make an applet or application?

There are some good examples of how to make java networking in the tutorials at the java site ()

Check this link for example on how to make custom networking:


You will either be using java.io or java.nio. For a client side application the standard io would probably be preferred (easiest to get working). nio (new io) can be a bit more tricky, but *should* offer more scalable networking since it uses non blocking polling etc, and you wont need a thread for each user. For a client side application you only need a single thread anyways so it doesn't matter that much. For the server side though, you could end up with having a single thread for each user, lets say 400 threads running for the networking if you are using the standard java.io...

Feel free to send me some PMs if there is something in particular you need help with.

And if you are having doubts on java (for some reason lots of people do), check out the screenshots of our current client in development.

Hephos - is this an applet, or an application. And once the code is done, have you thought of releasing it in any manner (freeware or for purchase)? The screenshots you have up look great so far!

It is an application. It uses a 100% custom network protocol though that doesn't look at all similar to telnet. So in the current state it isnt much of use for other games.

However, we have been considering to make a similar type of client that is more customizable and uses a simple protocol based on strings that could function along with telnet and diku derivates etc. It would probably be free with a license that says our company logo must be present or something like that. Though to get all the features necessary for a client like this a whole deal of things need to be coded and modified in the game server as well. We were thinking about making pseudo-code snippets for it perhaps. But at the current date we are pretty busy and these are just things we have on the horizon.

A mud client that's more scalable eh?
Think about that. :-P

I was talking about the server side actually in that context. And said that for a client side application on the other hand, you could as well just go with the easier networking solution since it will not be running that much threads anyways.

I admit it might have been unclear though sorry.

We are currently working on a distributed, streaming game client (currently named XML Game Client).

The XML Game Client is a self-guiding Macromedia Flash MX front-end with a 100% Java-based XML parsing gateway that combines the look and functionality of a streaming game client with a background processing system for handling distributed data packages. The distributed game client and its processing system will allow cross-system porting, thus able to run on several operating environments including Windows, Linux, Solaris and MacOS X. More information on the design and creation aspects of the XML Game Client can be found .

-- M

Well, to date, there are two widely used Java-based MU* engines projects that are currently underway: CoffeeMUD and JavaMUD.

CoffeeMUD :
JavaMUD :

Do note: Java-based game engines take ALOT of ram and CPU time (CoffeeMUD is heard to average over 300MB+ of VRam just for running). the JavaMUD project doesn't use as much ram, however the CPU load can be spiked well over 80% in some cases, thus it would be best to run either of these applications on a its own co-located server.

-- M

Ok, thanks Murpe, I'll check those out.

But by the way, what makes Java-based engines take up so much RAM and CPU time?