23 Aug, 2011, Vatiken wrote in the 1st comment:
Votes: 0
When creating a MUD most developers have some sort of tiered progression when it comes to moving their game to the next phase.

—–

Step 1: acquire codebase or create custom one

2: Implement "X" amount of features, and "X" amount of areas.

3: Seek extra staffing help.

4: Beta Test

5: List MUD and open to players.

—–

Or something of the sort. My question is, to those with experience, what marked the next steps in your MUDs life-cycle, and if you could do it over again, what might you change? IE: longer beta, more staff sooner, not taking on staff, etc…
23 Aug, 2011, AppendixG wrote in the 2nd comment:
Votes: 0
I think one of the most important things you can do, first, is create a coherent design document.

Never leave anything to chance, design every mechanic and run every equation to ensure that, once you start programming, you're not wasting your time programming things that just don't work.

Aside from that, its important to have a clear story in mind. Movies, games, books… they're all the same… they all aim to tell the 'reader' a story. What story are you going to tell? Who are your main characters? What are the major events? How do all of these things tie in with and affect how the player interacts with the world?
23 Aug, 2011, Vatiken wrote in the 3rd comment:
Votes: 0
Valid points, however I'm referring more so towards the big picture. If I use building a house as a metaphor, then that would be key number 1, "a solid foundation", but my question would be, when do you call in the plumbers? When do you start showing your house to potential buyers, etc…

I myself have previously fell victim to opening the doors to a MUD too early and displaying an unbalanced product which led to projects demise.

Often times, and I'm sure I'm not alone, working for months alone on project can become a tedious and lonely endeavor, and an injection of a couple playtesters, builders etc, can help rejuvinate potentially lost motivation, however, receiving influence on a project too soon can sometimes cloud the original concept for the MUD.
25 Aug, 2011, Omega wrote in the 4th comment:
Votes: 0
First and foremost, its never too early to have a betatester or 2. Nomatter how many features you have, from 0 to a million, having someone who will do things you don't think of, as you progress, is never a bad thing.

Personally, I have 1 betatester for my new mud; and every feature I put in, is tested by me, then by her when I move it over to the live port. As it is a ground up mud, theroughly testing everything is key to ensure a stable base/root structure for the muds development down the line.

I am a firm believer that if you crash the mud as much as possible before opening it to public playing, you'll most likely have less-to-no crashs by the time you open. But thats just me. I spend allot of time in gdb/valgrind while running with my betatester. The main thing is. With me personally, I insist that after I put in a new feature, that she try all the other features again; which she does happily, because you never know, a small change can affect allot; even out of scope. So as I said, it never hurts to have a betatester right from the start.

My own setup is as follows:

Every build (successful) it increases the current muds revision code; beta-testers keep track of said revision (its available in-mud) if something works, or does not, they keep track of it. So revision 749 the internal mail system worked, but string formatting did not. Then revision 750 came along, and the mail system was broken, all string editing within it failed because 1 line of code change. But 751 all was well.

And that is my key point to pass on to you; keep track of your revisions, whether it be via svn/cvs/github, and know what revision's were stable, and what were not. so you can see exactly what changes you made per revision.

The first thing I implemented was my revision control system.

After that, I got a beta-tester right away, handled betatesting right from barebones socket server up.

Secondly; have a detailed plan of features/products you wish to produce within the mud. And only work on 1 at a time, do not get ahead of yourself. Simply put, if you are working on a worldmap system, don't go working on combat. Simply work on the worldmap until you have confirmed it is 100% working; then branch out to the next project.

Third, Always back-betatest. So while you may of confirmed a feature to be 100% when you add a new feature, try all the old features again and ensure that you didn't corrupt something (it never hurts) sure it slows the process, but it leads to a more stable product.

Fourth; when your features are all implemented and tested (that means a basic world to test any object/mob/creature interaction/ai/combat and the like) expand slightly; construct a more detailed world; then step back to step 3; (back-betatest); because your code might not support the world you have developed properly (exceed your projected limits and what-not).

Fifth; profile code, find out where your bottle-necks are; this requires your world to be active (so game AI and a small series of playtesters/staff active); optimize where necessary. Then jump back to step 3 again (back-betatest).

Sixth; open to full beta-test / full build; At this phase, you want as many players online as possible; as well as builders; Construct your world fully (pwipe will be necessary at the end of this as there are usually balance issues discovered at this phase (mainly due to builders overpowering gear))

Seventh; World constructed by this phase; bugs worked out; full pwipe and open for players; move staff(builders) to a builder-port to continue construction for future expansions; this port houses your new code/areas.

Eighth; have fun with your open world. And continue with beta-testers on your dev-port following the original steps. Always when world is really ready, pull it over(and new code) to the play-port; (avoid pwipes though on play-port, they hate that)

Anyways, thats my methodology for my mud; I am following it right now and it seems to work, I know what revisions of my mud worked; what did not. And I have an active log (both in my github repository) and offline of what worked, and what did-not. Any issue's my play-testers find when I am not home, they simply submit an issue to my github so I can know what they were doing when it pooched out.

Anyways; questions/comments/concerns, feel free to ask. Should you be interested in it.
31 Aug, 2011, Athanos wrote in the 5th comment:
Votes: 0
I've been out of the MU* scene for quite some time. The last time I posted here I was still very inexperienced in coding though I still consider myself a novice. The actual programming of the mud is not an issue for me, but determining development progression has been an issue I have had as well. I wanted to chime in and say thanks to those who replied to this post. I have started back coding now and this time I am going to work on doing it 'right'. Previously I just jumped in head first and made it more difficult for me to complete anything.

AppendixG made the suggestion to make a coherent design document. I am an extremely impatient person when it comes to documentation and as I thought about this I became overwhelmed with the idea that if I design every mechanic or equation and write it all out I will eventually start programming my mud in 2025 (exagerating, maybe I could start by 2022). I'm not so sure about a design document including every little detail. Maybe it's just me, but I think of a design document being a guidline for development not an all encompassing document. It can be used as a base for the actual documentation that is produced later (or even as things are completed). Am I wrong in thinking this? Should the design document include EVERY possibility in it? Or should it just be a guidline on how everything will be implimented?

Thanks Darien for your detailed steps regarding how you develope. This will be a great reference as I start coding again and I think this sort of approach will be helpful to me as I get back into the swing of things.
31 Aug, 2011, KaVir wrote in the 6th comment:
Votes: 0
Athanos said:
AppendixG made the suggestion to make a coherent design document. I am an extremely impatient person when it comes to documentation and as I thought about this I became overwhelmed with the idea that if I design every mechanic or equation and write it all out I will eventually start programming my mud in 2025 (exagerating, maybe I could start by 2022). I'm not so sure about a design document including every little detail. Maybe it's just me, but I think of a design document being a guidline for development not an all encompassing document. It can be used as a base for the actual documentation that is produced later (or even as things are completed). Am I wrong in thinking this? Should the design document include EVERY possibility in it? Or should it just be a guidline on how everything will be implimented?

Documentation is like sex. When it's good, it's very good. But even when it's bad, it's (usually) still better than nothing.

On a more serious note, let me repeat what I said in my GamingHUD inteview:

For a commercial project youd want to perform a requirements analysis before writing up the design. For a hobby you dont need to be quite as strict, particularly if you view yourself as your own customer, but its still very beneficial to describe the general scope of the project before doing anything else even if its little more than an elevator pitch. Likewise, you dont need hundreds of pages of design document, but you should at least plan out your major features before you start implementing them. Otherwise you may end up with a Frankensteins monster of randomly slapped-together features instead of a consistent, cohesive game.
31 Aug, 2011, Runter wrote in the 7th comment:
Votes: 0
You gain understanding of problems by trying to solve them. Technical design documents are great, if you already know the answer to the problems. Otherwise you should do what everyone else does. Design something, discover why you were wrong, modify. Repeat until it's Good Software™. Unit testing can close the cycle, and if done properly, you'll find that software you write becomes robust very quickly.
31 Aug, 2011, Athanos wrote in the 8th comment:
Votes: 0
Quote
Otherwise you may end up with a Frankensteins monster of randomly slapped-together features instead of a consistent, cohesive game.


That is exactly what happened to me the last time. I had very poor planning and no direction.
01 Sep, 2011, Littlehorn wrote in the 9th comment:
Votes: 0
It's never a bad idea to develop a production plan for your MUD. It's also never a bad idea to develop something many refer to as the design bible that holds all the fine details of what your MUD should be when it's a finished product. Ideally, sticking to short documentation (meaning not documenting everything; only the important stuff like system design) can also be a good step.

For example, I went ahead and created a archive of documents for my classes. Every class had it's own document with descriptions, abilities and etc. I had an attached spreadsheet for all classes (tabbed out) that contained the abilities (skills/spells) for every class in my MUD. Later, this was useful for making help files and taking the ideas from paper and putting them into code. If it didn't exist, I would spend a lot of time writing and going back during the times I just needed to focus on one thing, getting shit coded.

Anyways, it's good to not get too detailed in the production phases of your MUD. Just keeping things simple, following a small plan and everything goes a long way. Getting more detailed, more involved iterations and etc are for much larger teams when you need everyone on the same page. If you're a couple of guys, then you don't need to get all crazy in planning that will more than likely backfire in your face. But, writing documentation on how you should scale your stats or how to define power in the game when say, building or making new abilities is not a bad thing. So, keep to defining what is most important (systems, building requirements, etc) and don't focus on every fine detail like how many houses should be in a area to what you expect players experiences should be when using a specific race or class.

Handy tools I've used is TaskFreak, Mantis/Bugzilla, MS Word, UltraEdit and various tools within CMUD. I use TaskFreak to plan our my tasks and Mantis or Bugzilla for my iterations and bug reporting. UltraEdit is my file management and CMUD for my mapping.

Cheers!
01 Sep, 2011, Vatiken wrote in the 10th comment:
Votes: 0
I've found over the years that my best, and most helpful design documents, were written with a shorter "term" in mind. Often, especially with MU*s, it's easy to get lost in what they "could" be, and not what they "need" to be.

IMO, writing a design doc, with the "final goal" in mind is more or less a waste of time, as could be easily related to giving someone street by street directions to some place 5000 miles away. A simple road closure, detour, or a change of plans could render all future directions useless. That being said, if you don't have a rough estimate of where your destination is, all hope is lost already.

When I write my designs, initially I start with a rough "destination" or "end game" goal. Asking my self, "If a player spends 100 hours in the MUD, what tasks will occupy how many hours?". Then once I decide that I want my players to spend most of their time exploring and gathering new items, I need to ask myself why they would do that, what kind of items they will recieve, how will they acquire them, etc… Answering these questions in detail, allows me to form a more precise and detailed document with how I want my project to look after completion of "Phase X".

Once completed, it's time to go through the code a bit, clean up, run some valgrind, do some profiling, make sure nothing is going to hinder me down the road. Then test the various features I've implemented as thoroughly as possible, and then lastly, evaluate what I've implemented.

KaVir had an interesting read over on mudlabs with regards to "It looked good on paper", and often that's the case of a lot of new ideas that are implemented by MUD developers. I personally take a lot of time to evaluate properly any thing "outside the box" I implement, to make sure it will function the way I expect now, and expect in the future, and if not, to rip it out and replace it now as opposed to many "Phases" down the road when it is intertwined with everything else. I recently had to do this exact thing when I originally coded in a coordinate based room system, and while I enjoyed the ease of controlling exits, pathfinding, and mapping I felt that it would only truly benefit me in a large scale, which was not what I was looking for, and as such I had to move to an alternative way to handle rooms.
01 Sep, 2011, Littlehorn wrote in the 11th comment:
Votes: 0
Vatiken said:
KaVir had an interesting read over on mudlabs with regards to "It looked good on paper", and often that's the case of a lot of new ideas that are implemented by MUD developers. I personally take a lot of time to evaluate properly any thing "outside the box" I implement, to make sure it will function the way I expect now, and expect in the future, and if not, to rip it out and replace it now as opposed to many "Phases" down the road when it is intertwined with everything else. I recently had to do this exact thing when I originally coded in a coordinate based room system, and while I enjoyed the ease of controlling exits, pathfinding, and mapping I felt that it would only truly benefit me in a large scale, which was not what I was looking for, and as such I had to move to an alternative way to handle rooms.


This really depends on the team structure though. I've been working in video game development for awhile now, and you have to factor in the team and structure. Some Producers require different structures. For example, writing the formula or how to accomplish a function is not ideal form. Keeping it basic, like how you want a NPC to have 3 phases that scale in damage for a 5-man group allows a scripter to define the equation of how much damage is per phase, how damage is dealt per phase and at what health percentage each phase kicks in. The same applies to abilities in system design in how you attain 300 damage with a fireball. You wouldn't write the equation on how you attain that 300 damage over 50 levels, the programmer defines the correct math, you just tell them at level 30 you want the fireball to be an endgame direct damage ability. That way the system designers can tweak the numbers for all spells or skills according to the balance over every other class etc.

You can find some really good presentations on how to write better game documentation through the archives of GDC or other developer conferences aimed for AAA game development. Those same concepts can be applied to MUD design, or at least give you a good idea of how you can conform it to your 1-man, 3-man or 20-man teams.
01 Sep, 2011, Vatiken wrote in the 12th comment:
Votes: 0
Littlehorn said:
Vatiken said:
KaVir had an interesting read over on mudlabs with regards to "It looked good on paper", and often that's the case of a lot of new ideas that are implemented by MUD developers. I personally take a lot of time to evaluate properly any thing "outside the box" I implement, to make sure it will function the way I expect now, and expect in the future, and if not, to rip it out and replace it now as opposed to many "Phases" down the road when it is intertwined with everything else. I recently had to do this exact thing when I originally coded in a coordinate based room system, and while I enjoyed the ease of controlling exits, pathfinding, and mapping I felt that it would only truly benefit me in a large scale, which was not what I was looking for, and as such I had to move to an alternative way to handle rooms.


This really depends on the team structure though. I've been working in video game development for awhile now, and you have to factor in the team and structure. Some Producers require different structures. For example, writing the formula or how to accomplish a function is not ideal form. Keeping it basic, like how you want a NPC to have 3 phases that scale in damage for a 5-man group allows a scripter to define the equation of how much damage is per phase, how damage is dealt per phase and at what health percentage each phase kicks in. The same applies to abilities in system design in how you attain 300 damage with a fireball. You wouldn't write the equation on how you attain that 300 damage over 50 levels, the programmer defines the correct math, you just tell them at level 30 you want the fireball to be an endgame direct damage ability. That way the system designers can tweak the numbers for all spells or skills according to the balance over every other class etc.

You can find some really good presentations on how to write better game documentation through the archives of GDC or other developer conferences aimed for AAA game development. Those same concepts can be applied to MUD design, or at least give you a good idea of how you can conform it to your 1-man, 3-man or 20-man teams.


That's all good, and extremely beneficial to any 2+ coding team at a later phase of development. But for a one man/woman developer, in a hobbyist setting, can often result in a misuse of time upfront. The thing with AAA titles, is the primary goal is profit. As such, 99% of the game design is already recycled from previous and proven titles. If you look at any mainstream MMO, FPS, RTS etc, they all function the same way they did decades ago. I mean is Call of Duty all that different from Doom? Not really. The great things about "most" MUDs is that fun is the primary goal and profit is often not existant, and with this MUD developers are able to experiment with new, unexplored ideas involving gameplay. Some of these ideas pan out, others not so much. That's why, IMO, planning out an entire project in detail often results in many re-writes as various "ideas" come and go.

Once the main foundation is complete, and you are happy with how you believe your new ideas are going to work, then by all means start planning out your formulas and such.
01 Sep, 2011, Littlehorn wrote in the 13th comment:
Votes: 0
Vatiken said:
As such, 99% of the game design is already recycled from previous and proven titles. If you look at any mainstream MMO, FPS, RTS etc, they all function the same way they did decades ago. I mean is Call of Duty all that different from Doom? Not really. The great things about "most" MUDs is that fun is the primary goal and profit is often not existant, and with this MUD developers are able to experiment with new, unexplored ideas involving gameplay. Some of these ideas pan out, others not so much. That's why, IMO, planning out an entire project in detail often results in many re-writes as various "ideas" come and go.

Once the main foundation is complete, and you are happy with how you believe your new ideas are going to work, then by all means start planning out your formulas and such.


I think you greatly misunderstand game design if you believe game designers are only thinking about profit based on recycling proven game design. It's actually the opposite. Game Designers, as in the people making the game are not just thinking about the money. Of course, profit does factor into the formula here too, but it's not something the designers are primarily focused on. Instead they are focused on making the game work, making it fun and getting it out the door in a timely fashion. If that involves reusing something that's proven, then why not? The moment you let ego factor into your designs is the moment you start seeing players moving further and further away from your game regardless if it's pay-to-play or entirely free like MUDs.

Yes, people do reuse designs in every game, including MUD design. However, it's not primarily reused to make a game more profitable. It's reused because foreign designs can lead to tragic downfalls of the game. I know you may not understand that fully, but the reason these games sell is because they have been doing game design for many years, researched it and have a good understanding on what may work and not work for the market. That includes what designs should be reused for the sake that players may not play a FPS if for example, the shooting mechanics were entirely innovative to something they are not familiar with from previous titles like Counter Strike or Quake. AAA or not, it still applies to basic game design of MUDs. If you're entire focus is to do something entirely innovative without reuse of proven designs, then you could find your MUD very much dead because you failed to understand that players sometimes wont take the time to learn something new rather than jumping into another MUD that offers something they've played on previous games.

That being said, you should sub our profit with players in your argument. That more innovative you go, the less (profit) players you may see even in MUD design. That's not because being innovative is not good, it's because players sometimes don't care about what's innovative. They sometimes just want to play something that's familiar to them from previous games with interesting new twists to the overall game, like what Call of Duty does with each new title they bring to the market. They stick to what works and push the mold slightly without going into totally opposite directions with their designs. MUD's are no different in that respect nor is music with your favorite band that keeps to the same theme rather than switching from Metal to Alternative between albums.


But, that's just me. :redface:
01 Sep, 2011, Runter wrote in the 14th comment:
Votes: 0
Quote
For example, writing the formula or how to accomplish a function is not ideal form. Keeping it basic, like how you want a NPC to have 3 phases that scale in damage for a 5-man group allows a scripter to define the equation of how much damage is per phase, how damage is dealt per phase and at what health percentage each phase kicks in. The same applies to abilities in system design in how you attain 300 damage with a fireball. You wouldn't write the equation on how you attain that 300 damage over 50 levels, the programmer defines the correct math, you just tell them at level 30 you want the fireball to be an endgame direct damage ability.


I disagree completely. And in my experience working in the video game industry, programmers should not be writing formulas like these. Especially "scripters". These are things not related to programming or area design. Furthermore, they're things that relate to the overall balance of the game. This isn't something programmers writing from spec should be concerned with. If they are, they're doing more than one job. Maybe with exceptionally small outfits this is preferred. But the spec should in fact tell you the formula to use in your code. It shouldn't describe the problem like this: "player gains small amount of hp each level permanently". In my experience good producers confer with the guys whose job is to write the formulas and they include that in the ticket/spec/whatever system they're using to instruct programmers. I'd describe it as "player gains 10-15 hp per level directly interpolated with their level. max((10 + L * 5 / MAX_L), 15)"
01 Sep, 2011, Littlehorn wrote in the 15th comment:
Votes: 0
Runter said:
Quote
For example, writing the formula or how to accomplish a function is not ideal form. Keeping it basic, like how you want a NPC to have 3 phases that scale in damage for a 5-man group allows a scripter to define the equation of how much damage is per phase, how damage is dealt per phase and at what health percentage each phase kicks in. The same applies to abilities in system design in how you attain 300 damage with a fireball. You wouldn't write the equation on how you attain that 300 damage over 50 levels, the programmer defines the correct math, you just tell them at level 30 you want the fireball to be an endgame direct damage ability.


I disagree completely. And in my experience working in the video game industry, programmers should not be writing formulas like these. Especially "scripters". These are things not related to programming or area design. Furthermore, they're things that relate to the overall balance of the game. This isn't something programmers writing from spec should be concerned with. If they are, they're doing more than one job. Maybe with exceptionally small outfits this is preferred. But the spec should in fact tell you the formula to use in your code. It shouldn't describe the problem like this: "player gains small amount of hp each level permanently". In my experience good producers confer with the guys whose job is to write the formulas and they include that in the ticket/spec/whatever system they're using to instruct programmers. I'd describe it as "player gains 10-15 hp per level directly interpolated with their level. max((10 + L * 5 / MAX_L), 15)"


Depends entirely on the studio-per-studio basis. In most cases, it's the Systems Designers job to come up with the formula and the Programmers job to find a way to make that formula work in the code, or the Scripters job to do the same via script. But, the System Designer does not define how the Programmer or Scripter defines that in the code or script. The same applies within certain teams where various heads are coming together to design an entire system based on a set of rules that are predefined by another.

I've known studios where it's the opposite much like Game Designer transcends into Level Designer. The same applies for Scripters for us where they design the formulas based on the Content Designer for things like Dungeon Design. Nothing is universal now-a-days.
02 Sep, 2011, Vatiken wrote in the 16th comment:
Votes: 0
Are you honestly saying that a project that's facing a $100+ million dollar budget, isn't thinking of profit as their number one priority? Any company willing to spend AAA dollars on a project is going go forwards with a project design that offers the lowest amount of risk and the highest amount of reward. "I know you may not understand that fully" but that's how investments work. A "game designer" or "one who designs the game", who works underneath the company investing the money is in a position similar to the pimply faced kid working at the local pizza shack. He can decide where he places the pepperoni, and use a cool hand twist when tossing down the cheese, but it better look and taste the way the company wants it to.

And I'm not slagging re-using tried and true methods, but with any big budget project whether it be games, movies or music they are hesitant to move away from them, as it would increase the "risk" of a big return on the investment. Which makes sense, however in the world of "text based games created by hobbyists", there is no multi-million dollar budget. Whether my mud is populated by 2, 20, or 200 players will really make no difference in recovering the time spent invested the game. In a AAA MMO of course, each player represents a $10-20 monthly subscription fee, so the game designer who suggested "perma-death" probably no longer has a job.

Game designers of AAA projects need to deliver a product that will be accepted by the broadest range of players. MUDs already cater to such a small niche of the market, they are capable of avoiding some of the redundant systems beaten to death by mainstream games. I personally see no point in developing a MUD thats, "Just like WoW….. BUT IN TEXT!!!", as any players willing to test out a text based game have most likely already sampled their graphical counter-parts and are looking for something different.

Quote
That being said, you should sub our profit with players in your argument. That more innovative you go, the less (profit) players you may see even in MUD design.

Substituting players for profit in my previous argument would make little to no sense, as this is a forum for (Primarily)text based games. If people here are developing games with the lone goal of gathering as many players(profit) as possible, they probably should of scrapped their design documents after writing "It will all be in text."

All that being said, I did notice a dip in the player base when I introduced my new, innovative "Dyslexic Movement System", so maybe you're right.
02 Sep, 2011, Runter wrote in the 17th comment:
Votes: 0
I think it's simplistic to take your view that games are redundant and claim that it's absolutely proven that profit by making a cheaper product is the only motivation for this.

Perhaps it is profitable, but perhaps it's also what people want. I know plenty of people prefer proven mechanics. And they don't need reworking to fit some arbitrary requirement that everything be unique. If profit is the underlying requirement, then it's required that people will buy your product. Unique titles are not top selling titles. There's plenty that go by without any fanfare, because people aren't trying to play a game to meet an artistic requirement. They want fun. And iterations on fun, is fun.
02 Sep, 2011, Littlehorn wrote in the 18th comment:
Votes: 0
Vatiken said:
Are you honestly saying that a project that's facing a $100+ million dollar budget, isn't thinking of profit as their number one priority? Any company willing to spend AAA dollars on a project is going go forwards with a project design that offers the lowest amount of risk and the highest amount of reward. "I know you may not understand that fully" but that's how investments work. A "game designer" or "one who designs the game", who works underneath the company investing the money is in a position similar to the pimply faced kid working at the local pizza shack. He can decide where he places the pepperoni, and use a cool hand twist when tossing down the cheese, but it better look and taste the way the company wants it to.


I'm saying that game designers are not designing a game with money on their mind. There is a huge difference between a developer and a publisher. There is also a huge difference between a game designer and a producer. Game Designers are not running around trying to figure out how much money they will be making by what feature they are adding to a game. There are no meetings being conducted with flow charts of profit per feature added to the game. The Publisher on the other hand may have a different opinion because ultimately, it's their investment in the developer of the game. I would say in the end, it's a good balance of both with the publisher in wanting something that sells well and also meets the demands of the developer in their partnership.

However, what I'm saying is that you're misunderstanding that you can focus on making something that's attractable without the point of how much profit the game will make if you add XY and Z to the final product. Logically, if you make a game that's fun to your target segment, it will sell regardless.

That's not to say big projects don't think about what sells and doesn't sell. That's ultimately up to the publisher and the producers assigned to the project. But to think, that it's all driven by profit is pretty far from the truth. I've never met a game designer, nor worked on a multi-million dollar project where designers are running around thinking what cool new design will pull in the most profit. It's actually more about what will be attractable to the target of players they are aiming for while fitting with the theme of the game. Which might I add, is still the same for MUDs because your goal should be the same – designing something that's attractable to the segment of MUDDers you want to play your game.


Vatiken said:
And I'm not slagging re-using tried and true methods, but with any big budget project whether it be games, movies or music they are hesitant to move away from them, as it would increase the "risk" of a big return on the investment. Which makes sense, however in the world of "text based games created by hobbyists", there is no multi-million dollar budget. Whether my mud is populated by 2, 20, or 200 players will really make no difference in recovering the time spent invested the game. In a AAA MMO of course, each player represents a $10-20 monthly subscription fee, so the game designer who suggested "perma-death" probably no longer has a job.


I think you're missing the point. Time spent is still investment. If you spend a year making a MUD that only caters to 2 or 5 people, then that's a lot of time wasted because you decided to go against the grain. Regardless of money, it's all very relevant to your project. The idea is to make a fun kickass game for the target audience you know your MUD will fill some type of gap. If you decide to go off the beaten path, then like I said, you could find yourself on a very dead game.


Vatiken said:
Game designers of AAA projects need to deliver a product that will be accepted by the broadest range of players. MUDs already cater to such a small niche of the market, they are capable of avoiding some of the redundant systems beaten to death by mainstream games. I personally see no point in developing a MUD thats, "Just like WoW….. BUT IN TEXT!!!", as any players willing to test out a text based game have most likely already sampled their graphical counter-parts and are looking for something different.


That's both true and false. The MUD genre overall is very much niche, but there is still segments of players who prefer different types of MUDs. That's why there is so many different types of MUDs that are still holding solid player bases. The flow of new players to the MUD genre is almost non-existent from what it was 10 years ago. Therefore, the need to re-use systems proven in other MUDs and possibly in popular MMO's is more relevant than anything before simply because everything has been done before… …And ideally, the market for MMO's is so vast now, appealing to MMO players would almost be ideal for saving the MUD community in re-using systems like you find in WoW to pull them over to MUDs.

However, you can look at it any way you wish. You are right, the risk is not as high as say losing millions of dollars. But, if you think that you're going to pull people in a declining niche market with innovative foreign systems, then you may be in for a uphill battle my friend. :biggrin:


Vatiken said:
Substituting players for profit in my previous argument would make little to no sense, as this is a forum for (Primarily)text based games. If people here are developing games with the lone goal of gathering as many players(profit) as possible, they probably should of scrapped their design documents after writing "It will all be in text."


I don't understand what you mean. Do you not design your MUD to be played by others? If so, why wouldn't you want to design something that is attractable to as many players as possible that enjoy the style of game you are developing? I mean, I wouldn't decline having hundreds of thousands of players on my MUD. I have a hard enough time keeping a few dozen with my crazy concepts alone. Why on earth would you not want to pull new faces to your game as well just to the MUD genre? Maybe I lost you somewhere in that statement.

Don't get me wrong on your argument here, it just sounds like you're saying that AAA game developers are only about the profit. I'm trying to make a stance here they are not all about the profit. It's very much still about making games that rock and also sell not because they are so hung up on profit, but because they are hung up on what's fun to play. And what's fun to play by logic, sells. :cool:
02 Sep, 2011, Vatiken wrote in the 19th comment:
Votes: 0
Runter said:
I think it's simplistic to take your view that games are redundant and claim that it's absolutely proven that profit by making a cheaper product is the only motivation for this.


That sir, is complete ignorance on your part as I not once made any claim resembling that, and you cheapen yourself by attempting to slur my point.

My claim was clear, when people invest large sums of money they expect a return on it. If you believe that means they must create a cheap product then you are entitled to your opinion. What it does translate into is a "Game Design" intended to draw in as many people, and their money as possible. If you believe that makes them redundant, once again, your opinion.

My other claim is that MUDs typically accept their niche roll and design themselves as such. There are not too many mainstream, multi-million dollar, MMO titles that feature full PvP, RPI, or suggestive themes for example. And yes, I understand that is due to the fact those subjects are not considered mainstream, and that is my point.

Runter said:
Perhaps it is profitable, but perhaps it's also what people want. I know plenty of people prefer proven mechanics. And they don't need reworking to fit some arbitrary requirement that everything be unique. If profit is the underlying requirement, then it's required that people will buy your product. Unique titles are not top selling titles. There's plenty that go by without any fanfare, because people aren't trying to play a game to meet an artistic requirement. They want fun. And iterations on fun, is fun.


Once again, never claimed everything had to be unique, but never the less this is my ultimate point. Titles that stray from the mainstream content, or are "unique", often are not top-selling titles because they are not considered "fun" by the mainstream. Notch's Minecraft wouldn't be considered mainstream, and by your logic is thus not "fun." Although, I've played it and can tell you it's a very fun and addicting game.
02 Sep, 2011, Littlehorn wrote in the 20th comment:
Votes: 0
Vatiken said:
My other claim is that MUDs typically accept their niche roll and design themselves as such. There are not too many mainstream, multi-million dollar, MMO titles that feature full PvP, RPI, or suggestive themes for example. And yes, I understand that is due to the fact those subjects are not considered mainstream, and that is my point.


This depends on the developer. In most cases, if you're not finding it in the game it's because there was not enough time, not enough budget or the design it self was not ideal for the target (bad game design or not fun).

Fun is very much subjective though. It's not all about what's mainstream. It's really about what is fun to your target audience – filling the gap.
0.0/52