Top Mud Sites Forum - View Single Post

Mierza · 01-07-2004, 01:38 AM

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)

01-07-2004, 01:38 AM	#1
Mierza Member Join Date: Jan 2003 Location: Hope Valley, Perth, Australia. Posts: 33	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)