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 10-15-2010, 02:39 PM   #1
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
MUD Development Journal

Hello,

I am Dayrinni. I code things. I am a programmer in “real life”. I work for a major tech company as a Java programmer/software engineer. I have decided to make a Java based MUD and tell you the tale. Hopefully, you guys will enjoy this.

Background

While in high school (over 10 years ago), I had big dreams to have my own MUD but I could not code. I tried to get some other people on the internet to work as coders. This usually ended up as a complete disaster. I have some good stories to tell, if anyone cares to hear. So in my first year of college in 2001 I decided it is time to try my hand at MUD programming. I grabbed a copy of fastrom and went to town. Many years later, the game A Tempest Season was born. This was a mildly successful MUD. But I ran into major personal issues and was forced to shut it down. Something I regret. Anyways, that is a different discussion.

Development

I usually do all of my projects in private and then release them when I am happy with the end product. I am going to do the complete opposite with this MUD. I will be posting updates on the game as I make them, which should be fairly consistent. In these posts I will talk about...well everything! The design, the reasoning behind what I did, the code, the story – you name, it'll be there. I shall continue to reply to this thread with updates.

I hope to get people involved by being in an open development environment. I am open to suggestions and feedback on what I have done. I may or may not take suggestions/feedback. If I do take anything major, I will ensure I place your name on a credits command within the game (if I forget anyone, please let me know).

One other piece of information before I give a brief description of the game: since the community will be helping me out in some capacity, I would like to repay that by saying the following: if anyone has Java questions, please shoot me a PM. I will be more than willing to help you out. However, I will not help you do your homework .

The Game


The name of the game will be:
Ascension: Relics of Fate

Yep, another A name strikes!

The genre is your typical middle-ages/medieval. It will be a RP-enforced MUD. I enjoy telling a large story and letting the players take part. So I came up with a simple yet interesting concept. This game is about three kingdoms and how they deal with an ancient evil power that was sealed away thousands of years ago coming back to life. The story will be filled with political intrigue and adventuring. We will have staff ran events that show case the story and allow players to participate in the world.

Some of the features we want to have are: a customizable class system, a quest system (both static and randomly generated one), ASCII map system, some sort of political system where it is actually possible to do non-combat progression and still have an impact. I would also like to include a custom front end, but that will come later on once we design and implement out the systems.

I'm still working out the details on some things, but am making pretty good progress.


Where are we?

The final part of this post is How Far Along Am I?

Well, in 2008, I decided to try my hand at writing a Java MUD from scratch to see if I could do it. And I did in about a month! So right now I have a good base line to work from. For example, all of the networking, ASCII map system, many commands, shop systems, etc, are all implemented. I simply have to start modifying and extending what I currently have. We are on a good start. Once I finalize some additional design documents on the various systems and how the story/world will affect them, I will begin implementing everything. However, the game is not ready for anyone to try it out yet.


Feel free to email me too at: dayrinni@tempestseason.com. My AIM is also: WindHeavenNights

Thanks,
Dayrinni

Last edited by dayrinni : 10-16-2010 at 09:54 AM. Reason: Typos.
dayrinni is offline   Reply With Quote
Old 10-15-2010, 10:08 PM   #2
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

This post will touch on some aspects of the game engine.

My best friend, Actinate, who was the co-owner of ATS with me can be credited to the name of the game engine that I created. I told him about it over the phone and he randomly screamed "TITAN!" at me. Upon questioning this, he said that was the name of the engine. So this is the Titan Engine. I'm sure this isn't the first engine called Titan, but hey, it is what it is.

As previously mentioned, this engine is written in 100% Java. It contains a few important key points: networking, command parsing, storage, and ASCII maps.

Networking

The networking aspect is particularly interesting. When I was in undergraduate college (many years ago) I took an internet programming class. This class used Java as its language. We did some basic socket programming and I learned quite a bit here. However, I wanted to make it easier to use. So I took about a month and made my own networking framework. It is a polling framework, were there is a single thread and it asks each socket if the buffer has data. If it does, then it'll grab it and then execute whatever its supposed to execute. This helps avoid concurrency issues since everything executes sequentially.

This consists of two portions: how input/output is handled and commands.

Input/Output
There are two modes here: instant and buffered. Instant will do just what it says. When a command comes in or out, it will be executed/written from/to the socket. While buffered will not do this – it will collect all of the input/output from/to the socket and handle the processing every set amount of MS. This MUD uses the buffered option.

Commands
In order to completely remove the socket layer from the programmer, simply extend a Command class and place all of the code in a special execute method, that contains the parsed data from the socket. This allows easy handling of any input from the network. I have used this extensively for other programs and it works beautifully.

Since the MUD simply handles text commands on a single line, we only need a single command to handle typed input. This is called GenericCommand and will handle getting the information from the network, the player who executed it (which is based on the connection) and then passing it to the player's state (see below). There is an additional command, ConnectionCommand, which is used to handle incoming connections.

So from a networking stand point, it was very easy to adapt this framework to the MUD.

Command Parsing

The command parsing is particularly important for a MUD.

Each player has a State (a PlayerStat e class), such as JoiningState, LinkDeadState, and so on. Depending on each one, different typed commands from a player are valid/invalid. For example, if a player is trying to choose their race and they are presented with a list of choices, the RollUpRaceChooseState will ensure that the proper way to handle all of the commands for choosing races occur. So for example, the only valid commands would be a number from a list and any help commands.

The main State, PlayingState, is very basic – it simply passes the command input from the network to the CommandHandler. This will handle parsing the command.

This CommandHandler class will parse the data into an array of Strings. The first index of the array, (yes, the parser checks for a blank line) is looked up in the command list for the indicated command. This is done by a partial match using startsWith on what was typed and what is present in the command list. A sequential search is done. So command placement is important.

If the command is found then the array is passed to the commands execute method. Otherwise, an error message is displayed to the player indicating an unknown command. There are some extras in here, like if a player is dead – they can't do certain actions and another error message is displayed.

The commands themselves, they do parsing on the array. This is bad and I intend to change it. It is very easy to run into exceptions with going out of bounds on the array. So I am going to make a CommandArgument class where it has methods such as, hasArgument(int commandIndex) and getArgument(int commandIndex). In this manner, it is possible to specify what number of command is desired. The indexing will use 0 based, but it will be based on the fact that the first element in the array will be the command typed.

For example, if this was typed:
kill john
"kill" would be index 0, and "john" is index 1 (clearly). So a call to getArgument(1) will return "john".

Code will be placed inside of the CommandArgument class to avoid any nasty exceptions. This will provide a much safer way to gather the command argument information and will be much easier to program the commands.

If anyone wants to talk about this aspect more, fire away. I haven't made the change yet.

Anyways, once the command gets a hold of the array, it will parse data from the contents and execute whatever it is supposed to do.


There ya have it.

Storage

Some games use flat files, others use Databases. The game uses XML. Not much to say here besides there are XML parsers to read in data and XML parsers to write out data to files.

ASCII Maps

The game has the capability of displaying both a map and description in the Room Descriptions. The maps can display characters, enemies, shops, exits, and the like. Pretty standard.

I wanted to be able to have the capability to make lots of maps very fast. So I wrote up a tool that can parse in a .map file and then generate a full blown area from it. The map file contains the physical representation of what it will look like in the game. Each symbol has a specific characteristic to it, such as what color it will be. The game will handle the creation automatically. It will connect all of the exits correctly, as well. Anyone could churn out probably 20 maps a day. Sure, they'd be empty, but hey, we got maps!

Another feature I put it was an automatic exit connector between two different areas. Lets say two huge areas are next to each other and connections were desire on a particular side. Just specify the starting and ending rooms, and which direction to go in (w,e,n,s). The game will calculate everything else based on the input and sizes of the areas. Then ta-da, a fully connected side.

My only issue right now is the fact I have made some very large test maps. I think they are on the order of 40x40 and that is far too much. Each character is color coded and that just adds for a lot of extra data that needs to be sent across the network. If I recall correctly, that is around 6 characters per character on the map for the coloring. It is a performance issue. I have a few ideas to tone this down:

1.Make the maps smaller.
2.Make the characters be able to only see a certain distance, say 5 rooms in each direction and send only that. This would cut down the amount of data needed to be sent greatly. However, code will have to be made in order to get exactly what can be displayed each time a player types look.




The End

Well there ya have it. That is a brief description of some important points of the engine for the game. Hope you enjoyed reading it.

Thanks,
Dayrinni

Last edited by dayrinni : 10-16-2010 at 09:54 AM. Reason: Typos.
dayrinni is offline   Reply With Quote
Old 10-16-2010, 08:55 AM   #3
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Re: MUD Development Journal

Quote:
Originally Posted by dayrinni View Post
My only issue right now is the fact I have made some very large test maps. I think they are on the order of 40x40 and that is far too much. Each character is color coded and that just adds for a lot of extra data that needs to be sent across the network. If I recall correctly, that is around 6 characters per character on the map for the coloring. It is a performance issue. I have a few ideas to tone this down:

1.Make the maps smaller.
2.Make the characters be able to only see a certain distinct, say 5 rooms in each direction and send only that. This would cut down the amount of data needed to be sent greatly. However, code will have to be made in order to get exactly what can be displayed each time a player types look.
Most muds go for the second approach, but clients with automappers keep track of where you've explored, and some muds have recently been looking into using out-of-band protocols to let the client download the entire world map in advance. The main advantage of this approach (other than reduced bandwidth usage) is in combination with graphical automappers - it lets the user hover over different parts of the map with their mouse to bring up details, and click anywhere on the map to start moving there. Not all muds want to reveal the world in this way, but if you're considering displaying a full map anyway, it might be worth considering.
KaVir is offline   Reply With Quote
Old 10-16-2010, 10:00 AM   #4
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

Quote:
Originally Posted by KaVir View Post
Most muds go for the second approach, but clients with automappers keep track of where you've explored, and some muds have recently been looking into using out-of-band protocols to let the client download the entire world map in advance. The main advantage of this approach (other than reduced bandwidth usage) is in combination with graphical automappers - it lets the user hover over different parts of the map with their mouse to bring up details, and click anywhere on the map to start moving there. Not all muds want to reveal the world in this way, but if you're considering displaying a full map anyway, it might be worth considering.
Those are some good ideas. I want to have some exploration involved so I will be going with the second idea of limiting the view for the players. The staff will be able to see the entire map because the performance issue isn't as major. I will include a toggle for the staff to turn on/off the full map so they can decide what they want to do.

I've done some thinking and know how I am going to handle the front end. Basically, there will be two modes: regular connection (ie: through ZMud or whatever) and then the front end. The default is a regular connection. On the second mode, the front end will send a special message upon connection which will tell the server that they are a front end client. Then the server will know it can send a lot of extra information. This opens up a whole slew of neat things we can do - some you mentioned and showed me already. For example, upon initial entrance into an area, the server could send the map ahead of time like you suggested and then cache it. Then, as the player moves through the area, the server can send the move updates/room descriptions and the front end can handle the map parsing. This would save on bandwidth. So we have some good flexibility here.
dayrinni is offline   Reply With Quote
Old 10-16-2010, 11:43 AM   #5
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

I've spent a few days working out the details on the class system and here is my first rough draft:

There will be no “strict” classes in the game. A player will create their own custom class by selecting a series of packages during character creation. There will be five main professions: Fighter, Rogue, Mage, Cleric and Citizen/Political (non-combat). Each profession will have 9 packages in them.

The packages are selected in a sequential format. In order to get to the 4th Mage Package, a player must selected the first 3. Players will be able to choose 9 packages. They will be able to combine them into any number of combinations. For example, a player could choose 5 Mage, 3 Fighter and 1 Cleric.

These packages will assign abilities to the player. Around 1-3 new abilities per package. Each character will have 18ish abilities to use. By making a lower amount of abilities, we can make more classes and the abilities more meaningful. The base package (Package 1) will contain several important abilities, so they will have more than the other packages. The level range that the packages add too vary, however generally there will be 1 ability on a lower level and the second ability will be at a higher level. Also, the different numerical packages will offer a general location. For example, the second package may assign an abilities in the level ranges of 4-7 and 33-36. The third package may assign an ability for levels 8-11 and 37-40. While the 9th package may only offer an ability at level 50. This should provide for a relatively even spread. During character creation, all of this information will be displayed to the character. They will be able to see their ability list during package selection and go through a final approval prompt.

Templates will be offered to the players during character creation. If a player simply wanted to be a Fighter, they can choose that and then get all 9 Fighter Packages.

Players will be able to decide to reselect their packages during regular game play. Maybe they made a mistake or simply want to play something different. We have to allow for these situations. However, they must be limited so the system is not abused. The following will be in place:
1.A large fee of in-game money will have to be spent in order to reselect the packages.
2.A reset can only be done after a certain amount of time, most likely once every 2 weeks.
3.There is an ability system that exists, and they have levels (more on this later) but all of their abilities will be reset to the starting level. This will make the player think on if it is really a good idea to switch.
4.For major code/design/game play changes, I will offer free resets. This will help protect the players against future changes.



Specialization System

This system is designed to offer extra growth for when players hit the maximum level.

There will be a Specialization System that will allow the player to select additional packages (3 additional ones) at maximum level (50). Upon reaching level 50, a player can select from a new set of packages. This will open up an additional 15 levels and the max level will become 65. At level 50, the player will have access to a base set of packages and new ones based upon the packages that the players currently has. Depending on what combination the player selected during character creation, different packages will be displayed at this point.

To demonstrate this, consider the following example: A player may have selected 6 Rogue, 2 Fighter, and 1 Mage. At level 50, they are now able to select from additional packages. The game will look at what was selected and display the proper packages to the player. Since the player has 6 Rogue and 2 Fighter, they may be able to take the Assassin 1 Package, which has a requirement of 5 Rogue and 2 Fighter. Or they can simply select additional Rogue, Fighter, Mage, Cleric, Citizen packages to further expand their character in the other areas.

Since there will only be 3 packages for Specializations (1-2 abilities in each package, 3-6 total abilities), it should be fairly easy to design and implement a fair amount of different packages without too much work. Again, since there are a lower number of abilities, they can be made more meaningful.



Overall, this system should allow for a very flexible and interesting class system. The players will be able to customize their characters accordingly to their wants and needs for a game.
dayrinni is offline   Reply With Quote
Old 10-18-2010, 04:34 PM   #6
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

I do not have much to post today except I am talking to a few old players from ATS (my previous MUD) and seeing if they want to get on board as staff members. This could be a very positive development.
dayrinni is offline   Reply With Quote
Old 10-19-2010, 09:39 AM   #7
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 20
Viriato is on a distinguished road
Re: MUD Development Journal

Good evening. Usually, when I read some of the things you wrote 2 questions pop in my mind:
- Why you defined those professions (Fighter, Rogue, Mage, Cleric and Citizen/Political)? Just because you like and plan to implement combat, wizardry, etc, etc, or there is a background already for them?
- Why you say one will have 18 abilities to use. Now that you defined a number, just then, you will create what the abilities will be?

Shouldn't all that be done in the opposite way?

Thanks in advance.
Best regards,
Viriato is offline   Reply With Quote
Old 10-19-2010, 07:54 PM   #8
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

Hello!

Thanks for your post. I shall try my best to answer your questions.

Quote:
Originally Posted by Viriato View Post
- Why you defined those professions (Fighter, Rogue, Mage, Cleric and Citizen/Political)? Just because you like and plan to implement combat, wizardry, etc, etc, or there is a background already for them?
I defined those profession that way because I like to work from a "base" and then put in systems (in this case, the package system) to allow for specialization/customization. Right now, there really isn't any background for the magic/fighter/etc lore. I have put that portion on hold because I am waiting for a response from the potential co-owners on the game. However, this package system can be thought of a delivery system of sorts. We should be able to easily transport the lore within this system. That is because, for the most part, the abilities will shape that lore.

In the previous game, ATS, we had a "focus" system that allowed players to select a base class (Fighter, Rogue, Mage, and Cleric) and then choose one of two focii. Each one had a specific theme - for example Fighters were either Trained Fighters or Talented Fighters. For each focus, they were presented with 10 skills and could choose 7 of them. So by working off of a base like we are, we can do systems like this and allow players to build their own class.



Quote:
Originally Posted by Viriato View Post
- Why you say one will have 18 abilities to use. Now that you defined a number, just then, you will create what the abilities will be?
I wanted to come up with a general number of abilities a class can expect to have at max level for balance purposes. Since players can choose different packages, we have to be careful to ensure that each player will end up with relatively the same amount of abilities. Of course, making sure all of the abilities are balanced in a reasonable fashion in a system like this is also a challenge. So if we know the amount of abilities before ahead of time, then we can know what sort of set we are working with. Then we can start to aim for a balance.

Quote:
Originally Posted by Viriato View Post
Shouldn't all that be done in the opposite way?
You can go in either way. I like to approach things from a mechanical and number based approach. I have found this approach with designing classes seems to work best for me in terms of balancing.


Thanks.
dayrinni is offline   Reply With Quote
Old 10-20-2010, 05:05 AM   #9
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 20
Viriato is on a distinguished road
Re: MUD Development Journal

Ok!
I believe I understood all you said. I am making my own engine because I like to program (and it's starting to be a job) and I like my theme, which is just medieval and based on reality, and the pleasure is building it that way.
Don't have that much experience in coding/building to say I'll have much troubles later about balancing the game, but after your advice I'll think twice before implementing things, from now on.
Thank you and good luck
Viriato is offline   Reply With Quote
Old 10-20-2010, 07:41 PM   #10
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

Quote:
Originally Posted by Viriato View Post
Ok!
I believe I understood all you said. I am making my own engine because I like to program (and it's starting to be a job) and I like my theme, which is just medieval and based on reality, and the pleasure is building it that way.
Don't have that much experience in coding/building to say I'll have much troubles later about balancing the game, but after your advice I'll think twice before implementing things, from now on.
Thank you and good luck
Any direction is better than none. Here is one approach (and to avoid getting into a ton of theory), try to think about the game systems in two general ways "high" or "big" and then "low" or "small". The high is what you, as a game designer, are trying to do. In other words: What is your general goal here? The low is how you answer that question.

For example, taking what I've done above with the class system:
High: I'd like characters to be unique and build their own class.
Low: They will choose packages and have generally, 18 abilities when they are finished building their class.

This'll give you some direction and make things more manageable than just saying "I need a class system." That is pretty open ended, eh?


Here is another example taken from the game:
Note: This hits on combat, which will be explained in a future post!

High: I want combat to be risky and make characters interact with the game during combat.
Low: There will be a risk system that will keep track of the player's risk in combat. This will modify the player's incoming damage. Abilities will affect the current risk - moving it up and down. Also, whenever a player is attacked their risk will go up. This will make players manage their risk and be interactive in combat.


One additional bonus to approaching it from this way is the fine details of the systems can be completely ignored. Looking at the second example, with the combat risk, the designer doesn't have to know exactly how the abilities interact (how much they raise or lower the current risk), how the risk system modifies incoming damage, or any other detail. You can worry about those when it is time to worry about them. They aren't important to the overall design. Though, some details can be made important for whatever reason, such as saying "around 18 abilities". This is important because I wanted the abilities to be manageable from a design/implementation standpoint and to ensure we make meaningful abilities.

I use this approach sometimes, and it has done me well.

Hopefully you find this helpful...I sorta started to ramble there a bit

What language are you making your game in? How far along are you? What sort of troubles have you ran into? What is your biggest accomplishment so far?


Finally...

Quote:
Originally Posted by Viriato View Post
(and it's starting to be a job)
The understatement of the thread!
dayrinni is offline   Reply With Quote
Old 10-21-2010, 12:05 AM   #11
silvarilon
Member
 
Join Date: Dec 2009
Posts: 144
silvarilon is on a distinguished road
Re: MUD Development Journal

Quote:
Originally Posted by dayrinni View Post
try to think about the game systems in two general ways "high" or "big" and then "low" or "small". The high is what you, as a game designer, are trying to do. In other words: What is your general goal here? The low is how you answer that question.
Not quite the same idea, but similar. I keep telling our staff to "Think big, bug plan small"

Think of the dream system. "I want fishing, where you can find different worms by digging in the garden, or other bait, use reels, lines, or nets. Get different times of lines. And then catch different types of fish. And there should be skills involved that the characters can learn."

Then plan small
"I'll make a fishing rod, which you can "cast" and then, after 30 seconds, it'll tell you if you've caught a fish."

That way you can get something coded and working ASAP. You can then continue building on it (make it catch random fish) and work up (make it catch different fish based on your skill roll) until you have the dream system. Knowing what you're aiming for means you can design the earlier steps so you don't paint yourself into a corner. It also means you can stop somewhere in the middle of the process, and have a working, releasable system. And you can always go back and continue improving later.

It's doubly nice, because other staff can build off your system. Someone building a cooking system might start writing code to allow players to cook fish. That code can go into the game even if the fishing system isn't complete, as long as it's complete enough for players to "cast rod" and get a fish.
silvarilon is offline   Reply With Quote
Old 10-21-2010, 05:42 AM   #12
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 20
Viriato is on a distinguished road
Re: MUD Development Journal

Quote:
Any direction is better than none. Here is one approach (and to avoid getting into a ton of theory), try to think about the game systems in two general ways "high" or "big" and then "low" or "small". The high is what you, as a game designer, are trying to do. In other words: What is your general goal here? The low is how you answer that question.
Quote:
Not quite the same idea, but similar. I keep telling our staff to "Think big, bug plan small"
Hmm... thought this is what I said before. I believe that saying at the start "a player will have 18 abilities maximum", or "there will be Fighter/Wizard/Rogue professions", is already thinking small if you care about theme.
In a MUD I play, they have some cool abilities for Warriors that can be used by training 4 different skills. They have also Thieves, but their only true abilities are steal and hide, which use only 2 different skills. The result is that they created 2 more thieves skills to "balance game", so each profession must have 4 skills, but there are no many advantages of having those last 2.
Personally I don't like it: it's kinda ok in balance perspective, but eventually the profession/abilities system shouldn't work that way, because it means you are forced to create X skills, no matter what they do.

Iberia MUD was first made in Emergence Basic, but now that I've started studying computers, I made it from scratch again but now in Java. Advancements happen like waves: in holydays I make more implementations than during classes. Anyway, I could code much faster if had more free time and if I looked at MUD creation as a task to do, but I rather like the way I am creating it.
In Java many things are easier to make: had lots of troubles to make connections/logins in EB (which is similar to C), and with Java I make it work in very short time; also, as Java is an object oriented language, inventory/shopping lists/skills are extremely easy to implement without mistakes. So I believe it is easier to make a MUD engine in Java rather than in other language.

My biggest accomplishment was to make a MUD engine from scratch but using Emergence Basic as coding language Now in Java I just enjoy each piece of code: the more recent advancement I made was to create MUD world generation via PNG file/room models - something I liked when I read it in MUD foruns. Previously, I made the dealing of Telnet Protocols: made MSSP and implemented NAWS, and ignored all the others, but in near future I pretend to implement MXP and a mobile client that can accept MXP (imagined playing MUD in a PDA using the stylus to click in exits, items to get, etc? :P).

Another thing I've implemented was the language system, where MUD engine replaces true characters by random characters if the language skills of both players are different

I've read some posts about languages, and I would like to hear opinions about this: what if just this system that transforms characters based on language skills is the only communication implemented? This would just make sense in a RP enforced MUD?

Thanks
Viriato is offline   Reply With Quote
Old 10-21-2010, 09:28 AM   #13
Milawe
Senior Member
 
Milawe's Avatar
 
Join Date: Jan 2006
Location: USA
Home MUD: Threshold RPG
Home MUD: Stash
Home MUD: Archons of Avenshar
Posts: 653
Milawe has a spectacular aura aboutMilawe has a spectacular aura about
Re: MUD Development Journal

Quote:
Originally Posted by Viriato View Post
I've read some posts about languages, and I would like to hear opinions about this: what if just this system that transforms characters based on language skills is the only communication implemented? This would just make sense in a RP enforced MUD?
Do you mean that the only way to communication is via the say command, and if you don't know the other character's language, you simply don't understand them? This would mean there's no channels for chatting, and there's no tells, I would assume. Your only form of communication is say and with a language barrier. (Please correct me if I misunderstood.)

The quick answer to your question is, "Yes, it makes sense in an RP enforced MUD."

The more detailed answer is that a lot of things can make sense in an RP enforced MUD as long as you have a good story behind it. By a good story, I don't mean that you explain anything that doesn't make sense with "It's magic!" That doesn't fly with today's gamers while you could get away with it 15 years ago.

To specifically address this game design idea, you have to also question what you want to accomplish. Are you going for realism? If so, you have to decide if that's the audience you're hoping to attract. Games are usually an accelerated microcosm that mimic real life, but if they were actually like real life, none of us would play. ("I know a game called Real Life and the graphics are freaking awesome!") Do you want to make communication difficult amongst players? Keep in mind that you're running a multiplayer (hopefully) game. If you DO want to make communication difficult, why do you wish to do so? Is it another grind with the reward being the ability to communicate between players? Grinds can be very, very beneficial to a game, but before you make a player do the grind, make sure it's worth it to them or that there's a very specific game design concept behind it.

Your system sounds cool to implement, and I'm sure that it'll be fun to code. Sometimes, though, you have to take off the coding glasses and look at the whole thing with a gaming perspective. Ask yourself what the benefits and drawbacks of such a system are and what you're trying to accomplish within your game. If it fits and will promote your overall design concept, I would say implement it. If you find that the cons will actually hinder what you hope to achieve, go back to the drawing board. You could still keep the cool code and just implement a basic "common language" system on top of your random letters system.

Again, I'm assuming that you are not allowing any communications besides the say command, and learning other characters' languages is vital to the system.
Milawe is offline   Reply With Quote
Old 10-21-2010, 09:45 AM   #14
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

Quote:
Originally Posted by silvarilon View Post
Not quite the same idea, but similar. I keep telling our staff to "Think big, bug plan small"

Think of the dream system. "I want fishing, where you can find different worms by digging in the garden, or other bait, use reels, lines, or nets. Get different times of lines. And then catch different types of fish. And there should be skills involved that the characters can learn."

Then plan small
"I'll make a fishing rod, which you can "cast" and then, after 30 seconds, it'll tell you if you've caught a fish."

That way you can get something coded and working ASAP. You can then continue building on it (make it catch random fish) and work up (make it catch different fish based on your skill roll) until you have the dream system. Knowing what you're aiming for means you can design the earlier steps so you don't paint yourself into a corner. It also means you can stop somewhere in the middle of the process, and have a working, releasable system. And you can always go back and continue improving later.

It's doubly nice, because other staff can build off your system. Someone building a cooking system might start writing code to allow players to cook fish. That code can go into the game even if the fishing system isn't complete, as long as it's complete enough for players to "cast rod" and get a fish.
Yes, I think you and I are on the same point. You can design other systems that interact with the system, regardless of its state (though, this assumes that all of the dependencies are met between the two). Your cooking example is a great one.

Some people approach things differently. There is no "wrong" way in my opinion. All of our brains work differently and that is what makes us as Humans, great.
dayrinni is offline   Reply With Quote
Old 10-21-2010, 10:03 AM   #15
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

Quote:
Originally Posted by Viriato View Post
Hmm... thought this is what I said before. I believe that saying at the start "a player will have 18 abilities maximum", or "there will be Fighter/Wizard/Rogue professions", is already thinking small if you care about theme.
In a MUD I play, they have some cool abilities for Warriors that can be used by training 4 different skills. They have also Thieves, but their only true abilities are steal and hide, which use only 2 different skills. The result is that they created 2 more thieves skills to "balance game", so each profession must have 4 skills, but there are no many advantages of having those last 2.
Personally I don't like it: it's kinda ok in balance perspective, but eventually the profession/abilities system shouldn't work that way, because it means you are forced to create X skills, no matter what they do.
Well, balance is a tough one. Like you said, even with each class having 18 abilities, I could (by mistake) make 18 rogue abilities under powered and 18 mage abilities over powered. Then again, I could have a completely different system where a player could learn a skill at any point by starting to use it (Dragon Realms). Again, there could be differences between the balance of the skills.

So we have to be careful on how we approach these abilities (and anything else). There will always be issues with balance. It will be a challenge to make sure all 18 abilities are useful and balanced. I surely won't get it the first time! However, that is why I went with a lower amount of abilities. Lately, I usually give classes 1 ability per level. So from my perspective, I am cutting down the amount of abilities and hopefully because of that, I can do a better job balancing them.

To talk a little bit more about your example above with giving 2 more rogue skills. It seems like they just did it for the sake of having 4 skills? This usually won't achieve anything, unless the designers get lucky . There needs to be a purpose for these abilities and this purpose comes from the Class Vision. You know - the typical What role does this class perform or fill? Looking here can give the area of expertise and can help in giving better abilities.

Really, there are a few parts to making abilities for me:
1. What realm is it from? As in, is it magic, melee, holy or rogue?
2. What does the class need now to fill their role? For example, I have just started making the Mage abilities. What do they need right away to be a good Mage? Let's say I am on the 15th ability. What have I already made and what do I need to give the Mage's at this level?
3. Come up with an initial attempt at a balanced version of the ability. At this point, I keep it in mind that we are still in testing phases and the players will know things will change.

I feel this gives me a good way to approach creating reasonable abilities for classes. You can kind of see how I leave the exact numbers and balance issues to the very end. They can always be adjustable.

Quote:
Originally Posted by Viriato View Post
Iberia MUD was first made in Emergence Basic, but now that I've started studying computers, I made it from scratch again but now in Java. Advancements happen like waves: in holydays I make more implementations than during classes. Anyway, I could code much faster if had more free time and if I looked at MUD creation as a task to do, but I rather like the way I am creating it.
In Java many things are easier to make: had lots of troubles to make connections/logins in EB (which is similar to C), and with Java I make it work in very short time; also, as Java is an object oriented language, inventory/shopping lists/skills are extremely easy to implement without mistakes. So I believe it is easier to make a MUD engine in Java rather than in other language.
I have never used EB, but it sounds fairly interesting. Maybe I will do some investigation on this. Sounds like you had a similar experience to me. As you know, I started with C and then went to Java for MUD programming. I used putty and pico for my editing. Good times! But it was a pain in the butt. Now I use Eclipse (I also use it at work), and it is a different realm of reality. Eclipse is extremely powerful and can make programming much easier and streamlined. When I first switched to Java and Eclipse from C, I was much more productive even though my Java skills were lower than my C skills.

Quote:
Originally Posted by Viriato View Post
My biggest accomplishment was to make a MUD engine from scratch but using Emergence Basic as coding language Now in Java I just enjoy each piece of code: the more recent advancement I made was to create MUD world generation via PNG file/room models - something I liked when I read it in MUD foruns. Previously, I made the dealing of Telnet Protocols: made MSSP and implemented NAWS, and ignored all the others, but in near future I pretend to implement MXP and a mobile client that can accept MXP (imagined playing MUD in a PDA using the stylus to click in exits, items to get, etc? :P).
Where you the person who sent me an email about the world generation using a PNG file?

Quote:
Originally Posted by Viriato View Post
Another thing I've implemented was the language system, where MUD engine replaces true characters by random characters if the language skills of both players are different
I like your approach of replacing characters based on skill. That is a good one actually. Very cool.

I haven't done any planning for a language system yet for Ascension (haven't decided on the races yet...I think I want a reptile race that can claw and bite though)...but I can tell you about the system I implemented in ATS, my previous MUD. At first I went with a random character screen but players complained it made the screen look bad and took away from RP. So I went back and I replaced the say text with a generic flavor message. For example, if the player was a Dwarf, then it would look something like this:

Dayrinni says something in a deep tone, from the earth.

It was more flavorful than that but you get the idea, I hope.

Quote:
Originally Posted by Viriato View Post
I've read some posts about languages, and I would like to hear opinions about this: what if just this system that transforms characters based on language skills is the only communication implemented? This would just make sense in a RP enforced MUD?
I pretty much agree with what Milawe replied with about this. It does present its challenges because many MUDs use forms of OOC communication. This could turn people off.

From ATS, we only had a tell system where players could send messages to staff members. This worked OK. But over time, players wanted to talk to other ones somehow. So I put in global CHAT and NEWBIE channels. At first I was against this but as more players joined, I saw that they couldn't build a solid community (which as you know is very important) within the game (not everyone uses forums). This was important so I put in the channels right away. The game really did benefit from it.

Hopefully you can use this experience in determining your decision on what to do.


PS: I have not had all of my morning coffee yet so I do apologize for any errors!
dayrinni is offline   Reply With Quote
Old 10-21-2010, 11:09 AM   #16
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 20
Viriato is on a distinguished road
Re: MUD Development Journal

This was just to hear opinions.

I have the language system in says, also have a global comm (ooc) and individual comm (like "tell <someone> <something>"). There is no common language to every ethnic group, but need to study how widely spread was Latin at 150 BC in Iberian Peninsula, to assume all barbarian ethnic groups understood at least a bit of it (like 10 points in 100, or something).
Iberia MUD is not RP enforced, so I am not thinking in force just use of says. But at least a MUD I know enforces it. And just recently dropped "pay-to-play", having at least >10 players connected at a time :P

Anyway I thought, though, that eventually in the future in RP events turn off tells and comm for a given period of time.

Yes, was me that sent you an e-mail about mapping

Thanks for the comments!
Viriato is offline   Reply With Quote
Old 10-22-2010, 04:06 PM   #17
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

ABILITY SYSTEM

Each ability has a certain training level associated with it. Each level of training increases the ability by a certain %. In order to level up these abilities, a training item must be acquired and used OR the ability must be used a certain amount of times. The training items are generic and can be used on the provided ability type. So for example, a "Rune" can only be used on magical abilities. These training items are as follows:
Magic: Runes
Fighter: Tomes
Cleric: Helix’s
Rogue: Charms

Here are the training levels and the bonuses:
1. Novice: +0%.
2. Accomplished: +15%
3. Proficient: +25%
4. Professional: +33%
5. Veteran: +40%
6. Expert: +50%
7. Master: +60%
8. Legendary: +75%

Here are the uses required to get to the training level from the previous level:
1. Novice: N/A
2. Accomplished: 1,000
3. Proficient: 2,000
4. Professional: 4,000
5. Veteran: 8,000
6. Expert: 16,000
7. Master: 32,000
8. Legendary: N/A – Need to use an item.
Special Note: There will be large quests that assist in getting uses for the abilities. For example, a large and complex quest that deals with a heist would give a lot of uses to the “steal” ability.

Training Items must be used in sequential order of the training level. For example, a Novice level ability cannot go immediately to Legendary. An Accomplished Training Item would have to be used, and then a Proficient Training Item and so on, until Legendary is met.

These training items will spawn from monsters randomly. Each training item has a series of %'s based on the training level that can is used to determine the spawn on a monster.

Each training item has a base % to drop, which is based on the training level it raises. The higher the level of the monster the higher the chance to drop one of these trainings items. Each monster has a chance to drop the same item equally. When a monster is killed, the game will randomly choose 1 of 8 training levels and attempt to generate that item on the mob.
The equation is: BaseChanceToDrop *[(MobLevel+25 + RANDOM(-25, 25))/100] = Actual Chance.
BaseChanceToDrop values:
1. Novice: 3%.
2. Accomplished: 2%
3. Proficient: 1%
4. Professional: 0.50%
5. Veteran: 0.25%
6. Expert: 0.10%
7. Master: 0.05%
8. Legendary: 0.01%
dayrinni is offline   Reply With Quote
Old 10-22-2010, 09:35 PM   #18
dayrinni
New Member
 
Join Date: Apr 2002
Posts: 29
dayrinni is on a distinguished road
Re: MUD Development Journal

I wanted to include a picture of the initial combat:

dayrinni is offline   Reply With Quote
Old 10-27-2010, 01:12 PM   #19
plamzi
Senior Member
 
plamzi's Avatar
 
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
plamzi is on a distinguished road
Re: MUD Development, graphical clients

Quote:
Originally Posted by Viriato View Post
My biggest accomplishment was to make a MUD engine from scratch but using Emergence Basic as coding language Now in Java I just enjoy each piece of code: the more recent advancement I made was to create MUD world generation via PNG file/room models - something I liked when I read it in MUD foruns. Previously, I made the dealing of Telnet Protocols: made MSSP and implemented NAWS, and ignored all the others, but in near future I pretend to implement MXP and a mobile client that can accept MXP (imagined playing MUD in a PDA using the stylus to click in exits, items to get, etc? :P).
A stylus is so 2006

This may be a bit off topic but here's a screenshot of my commercial iPhone MUD client. Not too many people here know about it but I think it's a solid concept that other graphical clients can borrow ideas from. The UI is not easy to master at first but it enables some of my best players to keep up with oldies on text MUD clients like zMUD (and that's using one hand and one thumb for most actions). If you have an iPhone/iPad and you're curious, check out Bedlam LT (free version).




plamzi is offline   Reply With Quote
Old 10-27-2010, 01:48 PM   #20
Viriato
New Member
 
Join Date: Jul 2007
Location: Lisbon, Portugal
Home MUD: Iberia MUD
Posts: 20
Viriato is on a distinguished road
Re: MUD Development Journal

That seems cool
But well, that client it's specific for your MUD. If one creates a client with MXP, it can connect to any MUD and the ones accepting MXP will be extremely cool
Viriato is offline   Reply With Quote
Reply


Thread Tools


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 06:32 AM.


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