Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 01-07-2004, 01:38 AM   #1
Mierza
Member
 
Join Date: Jan 2003
Location: Hope Valley, Perth, Australia.
Posts: 33
Mierza is on a distinguished road
Send a message via MSN to Mierza
Hi, some of you know me, many do not.

For those that don't, I'm an experienced RP player and administrator of various types of RPG's. About 3 months ago, I started on a new game project - a new, innovative mud. My co-partner /lead coder in the project unfortunately had to leave. However, being the team leader, I'm not about to give up, and I'm currently in search of a replacement programmer.

That said, I'd like to note that I have little clue about programming, and I'm here to gain more essential insight.

I'm going to post a few segments from records of my game development, as posted by my former coder.

What I'm asking is for anyone with experience to give their input, or explanations, for any of the code situations brought up. These are the game concepts designed between myself and former coder, and I'd appreciate any help. So here we go:

In relation to Movement and Space~


1. Characters interact with something more than a box. -Rooms have real dimensions. When building a world, builders will work with coordinates and hence the need of integrated tools within the main game client. Movement will actually be much more intuitive and easier than diku muds where you just specify a cardinal direction to go somewhere.

Builders will have the chance to specify the shape of the room they are creating (rectangle, oval, round, triangular) and then specify the size depending on the previous selection. Then comes the creation of entities (aka. objects). World entities have shapes too, and do take space. These entities are usually not caried by players as they are too heavy. Carrying one would probably require the use of two hands and help from somebody else at the least. A lot of flags and factors still have to be decided but these will determine the properties of these entities. Templates for common entities will of course be available for faster and less error prone creation.

A lot of math is involved to create such a world, but none of the people using the system will have to do math on their head as the game is designed to hide as many numbers from the player as possible. Builders will most likely have a graphical interface for much easier editing. Players will simply have to type: "go lamp" to be able to walk up to the closest lamp. If they type get lamp then the game will be smart enough to move them to the lamp and then make them take it.

Traveling is also rather easy. You could follow routes or trails that lead to other places (travel road to city) or you could even just say travel north and the character would do so.

There are a few basic movement rates that determine how fast you get exhausted and also how fast you move and how much sound you make. Stop, sneak, walk, speed walk, run, sprint and flee. Other than inputting go (which makes you do whatever you did last time) you can also put speedwalk as your argument. (sprint lamp) would make you sprint to the nearby lamp. The same would be for traveling long distances.

2. A player should be able to set the level of their voice. It could be very soft and go up to screaming on top of their lungs. What this would do is create a sphere from the player whose radius is as big as the level of their voice. Then the code would determine if something that might be affected by the voice is within the circle (very easy to do). Then the code would send a ray towards that target to determine if there is anything blocking it like a wall or such and then send the appropriate message. Examples: You hear a buffered sound coming from the south.

3. Everything has shapes, which will allow us to have a very interesting combat system where people actually move all around the rooms and such and tactics could very well be used.

4. Descriptions would mostly be dynamic. The game would look at the current weather, lighting, objects in the rooms, events happening, and generate a description from these factors and more. One can always override these descriptions when a place definately needs a special description. And the goal is that all the descriptions would actually sound nice, being taken by the objects surrounding the player.

5. The option of being able to click a co-ordinate (say on a small graphical map) to travel.

6. As for rooms and how they work: There's an idea based on the old Duke3d build system. You define the dimensions of the room using points. A square room would have four points, one in each corner of the room. The entire area would be a 3D or 2D coordinate system, you could define the size of the area by the range of the cords. So a small hotel might have 1000 cords, whilst a planet may have 100,000 cords.

In this case, how would you build rooms? Simple. So you define some 'walls' in this rectangle we are building as having its top left point at 20,15 its top right point at 40,15 its botton left point at 20,-5 its botton right point at 40,-5. Now imagine those points on a graph, what does it form? It forms a square. Now each of the cords within that room will be able to have objects in them, players, programs, etc.

It creates a more dynamic world, where players of course would never see the cords nor any of the complex maths. They'd see the map.

7. As for rooms that don't have walls? Like a three walled room that is missing a fourth wall, the fourth wall becomes an exit/entrance -and not all exits are just doors or windows. And speaking of which, windows that you can see and climb out of, ladders that can be propped up against walls?

If there are two walls, or even just a single wall, it becomes just that - a wall. Walls should also have heights, if possible. They either join to a roof, or can be a barrier that you can see over, but would have to climb to get over, or go around if you can.


And there we have it, some food for thought and discussion.

The above thoughts are from myself, an assistant coder, and a former coder that have been working with me on my current project.

The reason that I'm sharing this with you all, is not only for some input and suggestions for myself, but to possibly help inspire some new directions to look at when building a MUD.

~Jade (aka. Mierza)
Mierza is offline   Reply With Quote
Old 01-07-2004, 09:53 AM   #2
Burr
Member
 
Join Date: Apr 2002
Posts: 123
Burr is on a distinguished road
I'm only a beginner programmer, but I thought I'd mention that you only have to input or store three points to define a square (or any other rectangle). The fourth point can be derived from the other three. Example: for given coordinates (20,15), (40,15), and (40,35), the fourth point must be (20,35) for the object to be rectangular.

I suppose you might use the redundancy for error checking, but getting rid of the inconvenience might be worth the occassional error, since you will likely be proofreading/editing each area anyway.
Burr is offline   Reply With Quote
Old 01-07-2004, 10:42 PM   #3
karlan
Member
 
Join Date: Apr 2002
Location: Brisbane Australia
Posts: 74
karlan is on a distinguished road
How 3D are you talking here? if it is reallly 2D with arbitary room shapes and levels, it is handled differently to if it is properly 3D with no requirement for alignment of rooms.

For example, if it is 2D with a fixed height, and a rectangular room Must be aligned on the x, y axis, you only need 2 points (top-left, bottom right, the same if it is 3D and aligned -> top-front-left, bottom-back-right), circular/spherical rooms are trivial also (need a centre(X, Y, Z)-radius pair). Oval rooms can get more complicated, (again assuming that everything is aligned), a 2D ellipse has a minor and major axis to be considered, and a 3D ellipsoid, doesn't have to have a circular cros section, it can have 2 minor and 1 major axis in addition to it centre point. Then you have situations where the rooms touch, where do the touch, distance between centre of rooms, how much do they overlap...

Assuming you do not want a MMORPG style thing, and are using a 3D array or roomlets (sorry brainfried today) you can approximate a round (or oval) room and still keep thing interesting.

So... in short there are a lot of things to keep track of, you could even have a look at some RPG and FPS world editors to see how they handle 3D room/world designs (it wont directly help with the code, but...), you will also have to consider how much information will need to be transmitted to each character as they move around.
karlan is offline   Reply With Quote
Old 01-16-2004, 12:16 AM   #4
Mierza
Member
 
Join Date: Jan 2003
Location: Hope Valley, Perth, Australia.
Posts: 33
Mierza is on a distinguished road
Send a message via MSN to Mierza
A coder friend of mine answered my Q's so I won't be needing anymore replies really, but thanks for your help anyway.

~Jade
Mierza is offline   Reply With Quote
Reply


Thread Tools


3D Movement and Space - Similar Threads
Thread Thread Starter Forum Replies Last Post
Advertising Space available lovechiefs MUD Announcements 9 04-11-2006 12:17 PM
Advertising Space available lovechiefs Advertising for Staff 1 04-07-2006 08:20 AM
New Space Game Alexander Tau Advertising for Staff 2 10-31-2005 01:06 PM
OS: Space... Brody Advertising for Players 0 10-20-2005 04:41 PM
Space Combat Nerzule Advertising for Players 0 05-26-2002 01:12 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 09:09 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014