Good luck, Vallar. Keep us posted on your achievements. :)

Maybe this is a good starting point on using PyQt4?

http://zetcode.com/tutorials/pyqt4/

all the best,
uggwar.

Hmm, typically the term MUD brings up a basic image in my mind of a text-based only game. What you seem to be interested in making is a completely graphical online multi-player game.

The trouble stems where you say you want to make a MUD, then you want to make it 2D whereby I assumed you meant "using a GUI running on a custom telnet client". From there you moved straight to 2D, 2.5D and 3D which to me means something entirely different and conjures up images of players directly controlling their avatar through fully graphical realms.

The chances are nearly 100% that you will not be building this as a single growing piece of software. The tasks that a text-based MUD server and its potential clients perform is very different from that of a fully graphical 2D or 3D mmo game. On top of that, as you grow as a programmer you are certainly going to come to a point where all the software you've written before that point will be deemed 'crap'.

I think your best bet is to decide what kind of game you want to make now. Ask yourself: Do you want a text-based game, and will it require a custom client or not, or both? Perhaps you want to make a fully graphical online game, essentially skipping the 'text-based' part but sticking with the server and a required client? Either way, you shouldn't focus on what this software will become down the road because the answer is, "It will be the same." If you want to make a different style of game later you are just going to have to re-write it ;)

Also as a side note, keep in mind that your server and your client don't need to be made in the same language or using the same tools. All that matters is that the data sent back and forth interfaces between them. Good luck!

Quote:
I don't really like Functions. First because it "slices" up the program, second because it slows down the transition between blocks.

A) You will want to use functions. Trust me, they are your friend ;) The fact that it 'slices up' the program is exactly the point of functions, and objects for that matter. When you tackle a hard task do you try to take on the whole thing at once or do you break it down into smaller sections and deal with them one at a time? Rhetorical question, the answer is the latter. It makes it easier to create, test, append to, modify, change, and maintain your programs.
B) Well, actually I have no idea what 'it slow down the transition' nor what these 'blocks' are to which you refer? I have a hunch that you are worried it will slow down your code. Don't worry about that. It's not an issue and functions wouldn't exist if they were that horrendous to use.


And now on to more of your hard stuff!

It's definitely seems that you don't really have a true grasp on the fundamentals of building software beyond the basic 'how to write code' part. But I'll try my best to start you in a direction. If you are going to program in an object-oriented manner then you might as well start with objects. What you have there are a bunch of disparate variables. Your first step should be to clump some of them together in a related way as single, coherent, objects. The next step would be to flex some OO muscles and try to find what they have in common so that they can share it.

In many cases a MUD could simply start with a basic object, let's call it a 'thing'. What properties do these 'thing's have in your world? In most cases, they at least need a way of identifying them and they also usually exist in some place. This brings up another question: How are you going to identify what a 'place' is. Some MUDs treat things and places differently at a fundamental level. I tend to prefer the case where they are both rooted in the same object. So in this example I would say that you would want to make a 'place' a 'thing' itself.

(warning: this code is untested and written by a python infant)


What this does is create a single key object 'Thing' and then derive another object from it with essentially the same properties. You can create a generic thing and pass any type of identifier you wish, as well you can create a place the exact same way. The nifty part is that any changes to the code for Thing will be reflected in Place. From here you could perhaps derive two other classes from Thing, perhaps 'Item' and 'Entity'. Currently the difference between them is none but the idea is that any special properties that should be shared need only be coded once within a base class shared by those objects. For example, in my MUD's codebase, nearly all objects, players, NPCs, weapons, and items share a base that provides a name, short description, and long description. All objects actually derive from a base that provides a basic ID. Items derive from weapons so that all items can be used as though they are weapons. Neat, huh?

Obviously this is a very basic example and not much use right now. You are going to have to take it further, develop it, learn from your success and mistakes and rebuild accordingly. Anyway I hope this helps you towards a direction. Good luck and have fun!

Ok, looking at your example I see a few problems. The first basic one (If I understand correctly myself) is that all classes in newer versions of python should derive from something. Usually 'object'. I also noted the variables of both the objects were being set to stuff like 'Name_Object' and so forth which first of all doesn't have any definition anywhere and second of all looks suspiciously like you are going to be using global variables for something devious ;)

The 'self' reference refers to the instance of object in which the function exists. In the case of 't = Thing("id1")' it would refer to 't'


There is an inherent issue (no pun intended) with that last code you posted. You are avoiding one of the main benefits of having classes and inheritance! Check out inheritance especially. In my example the whole point was to show you that one object can be based on another's existing code. Look at your 'Area' object and your 'Object' object. What do they have in common? A name, a description, the list can go on. For example if you use my example you can do this:

a = Place("areaID")t = Thing("thingID")print a.ID #prints "areaID"print t.ID #prints "thingID"

Do you see how both objects have a property called 'ID' yet only the class Thing ever declared one. On the other hand, Place was derived from Thing so any object based on Place inherits all of Thing's properties and functions.

So for your sake it would be better to create a basic object that represents the minimal amount of info any valid object should have. In this case it might be a name, and some descriptions, perhaps a unique way of identifying it from all other objects in the game. From there you would derive new classes that build on top of this with data pertinent to their purpose. Another thing I was getting at with my example was that you could stick a couple references in 'Thing' that point to its contents as well as its container. Now you have a way of representing the inventory of anything. It could be a player's inventory, a bag's contents, a chest's contents, or a Places's contents. The interesting part is since Place is derived from Thing, technically it means that a Place could be contained within something else... like say a bag of holding ;)

Hehe actually you just opened a big can of worms there that I really don't have the authority to get into since I'm rather new to python myself.

The basic idea is that I wanted, within Place's __init__(), to also call its base class's __init__() function as well. There are a couple ways to do this and none of them are entirely ideal. Suffice it so say that using super() was, in this case, effectively the same thing as calling:

Thing.__init__(self,id)

However, that is not to say that they do the same thing. super() was designed to help alleviate issues with multiple inheritance. You can look up 'The Diamond Problem' for more details. Basically it is a way of making sure each base class's __init__() function gets called only once. In certain situations it honestly doesn't always work out all the well either. Important Stuff About super()

Quote:
Super = place
(Place,self) = belong to the Place class and has a referral in Thing Class?
__init__(id) = that id refers to the Thing class id? Or the Place class id?

1) super() is not Place. It is a built in function for finding the named method
that comes next in the MRO. And as the link above states, it gets really icky somtimes.

2) The "(Place,self)" are the parameters of the built in function super().

3) 'id' is the parameter being passed to Place upon creation eg. p = Place("placename") means that id = "placename". But Place has no direct use for this so I passed it to Thing's similarly structured __init__() so that it could store it as self.ID.


hth