10 Jan, 2013, Kelvin wrote in the 21st comment:
Votes: 0
Lyanic said:
I was directing that at HK, not you.

Sure, just felt that I didn't help the situation with my vague choice of words :)
Lyanic said:
However, if someone just throws up a stock game - is that not "playable"? It's boring and uninspired, certainly, but it is playable. </Devil's Advocate>

For some codebases with starter areas, it would be "playable", and is an MVP if your game design matches 1:1 with the stock game/world. Whether that's a good game design is another question entirely. I tend to think in this case, your game design would fall under the realm of "unimaginative", to say the last :) While your time to opening would be extremely short, the "product" part of your MVP would be so lacking that you'd probably fail to do any better than the leagues of other people who decided to compile and throw a stock MUD up over a weekend.
11 Jan, 2013, arendjr wrote in the 22nd comment:
Votes: 0
Quote
I was just looking at PlainText, and Murk++ is on my desktop.. but I'm curious why you suggest Murk++ specifically? Thanks for the input!


Hi yue, I'm the PlainText author :) If you get it to run on Windows, I'd be happy to accept patches and/or a guide for how to set it up. I'm on Linux and Mac myself, so the hosting as Rarva mentions shouldn't be an issue :) If you have specific issues or questions, just send me a PM.

Cheers!
11 Jan, 2013, Kelvin wrote in the 23rd comment:
Votes: 0
To get this discussion back on track, I propose the following: as an exercise, provide a brief list of what your game needs in order to be "playable", at its most base level. We'll define "playable" as "functional and fun enough for an average MUD player to be entertained enough to have the desire to return for at least two weeks". Obviously we'd be aiming for more, but we'll use that as the standard for this discussion.

For those of you who haven't "finished" your game yet, this list of "things" may be easier. For those that already have a game running, cut away all of the secondary/fluff things/systems and list some of the critical core components of your game.
11 Jan, 2013, arendjr wrote in the 24th comment:
Votes: 0
I'm working with a story writer on a game that goes under the working title District 21. I thought about your minimal viable product exercise, and it actually is pretty tough to think about it like that. We already try to keep our scope limited for the first version so that we won't get lost in the desert before we open our doors, yet still… the things we really want to do are pretty different from a lot of other MUDs and it's already taking many months to implement those ideas. Don't get me wrong, I'm a code junky, so I love the work and will keep working on it for as far as I can see. Anyway, leaving absolute basics aside, here's what I want for our base level:

  • Sounds and visuals propagating through multiple rooms (be able to overhear conversations, hear people approach from your back, see people walking afar)

  • Reasonably intelligent NPCs that you can have limited conversations with

  • Enemies and a combat system (even if there are still very few weapons and items)

  • Ability to build barricades (very limited crafting)

  • At least a few floors of a skyscraper building modeled as our "world"


I'm also improving the graphical map editor, which I guess should be considered a prerequisite, without which designing the skyscraper is going to be a hell…

Item 1 has been implemented. The map editor is currently in progress. The others are yet to be started. And even when all is done, we will have to do beta testing before we will really start opening to public. All in all, I hope I can reach the beta testing phase at the end of the year :)
11 Jan, 2013, Kelvin wrote in the 25th comment:
Votes: 0
arendjr said:
I thought about your minimal viable product exercise, and it actually is pretty tough to think about it like that.

Yes, it is challenging. It's basically taking a game design document and paring it down to the essentials. Also, I've found that outlining and documenting game mechanics can be a good deal more challenging than the eventual implementation details. After all, we're building a relatively simple piece of software (to start, at least).
12 Jan, 2013, Telgar wrote in the 26th comment:
Votes: 0
arendjr said:
  • At least a few floors of a skyscraper building modeled as our "world"



  • I'm also improving the graphical map editor, which I guess should be considered a prerequisite, without which designing the skyscraper is going to be a hell…

    Item 1 has been implemented. The map editor is currently in progress. The others are yet to be started. And even when all is done, we will have to do beta testing before we will really start opening to public. All in all, I hope I can reach the beta testing phase at the end of the year :)


    I guess I should not encourage you to implement grid mechanics and open spaces so that items dropped from rooms above can fall and land in the appropriate space in the skyscraper, so you can do things like lure monsters out into an atrium and then safely drop bombs on them from above, distract guards, descend and ascend using ropes, and swing back on the ropes with realistic abseiling, pendulum traverses based on the length of rope descended… or other stuff like that. But it would make for fun play and game mechanics.
    12 Jan, 2013, arendjr wrote in the 27th comment:
    Votes: 0
    Hehe, I'd be lying if I said none of those ideas had been discussed yet, but yeah some of these might make it in indeed. Not to mention our idea of collapsing floors :) Anyway, these are all out when it comes to minimal viable product :)
    12 Jan, 2013, KaVir wrote in the 28th comment:
    Votes: 0
    Kelvin said:
    To get this discussion back on track, I propose the following: as an exercise, provide a brief list of what your game needs in order to be "playable", at its most base level.

    That's exactly what I did when I created Gladiator Pits III. I stripped out a load of unfinished stuff (like classes, powers, advancement, magical equipment, etc), tied off the loose ends, and gave it a quick polish. The post is the admin section of my forums so I'll quote instead of providing a link:

    Quote
    Due to my real life situation (primarily girlfriend and job hunting), God Wars II is coming along VERY slowly, and I've been thinking more and more about putting together a Gladiator Pits III spinoff. After throwing together various ideas, I've finally decided that I might as well go for it.

    Why? Various reasons:

    1. It's going to take ages to get GW2 up and running, but this will at least let us have something to show for our time and effort so far, without requiring too much extra effort (we don't need to add anything specially, just make a few minor things).

    2. With something publically available, I think it will motivative me much better, and if we get a lot of positive feedback the rest of you might feel the same.

    3. It'll give us a way to test the balance between the fighting techniques throughout the development of GW2, as well as stress testing the core engine. The beta just isn't doing it, because nobody stays around.

    4. With a proper mud up and running, we can finally start to show gryphonmud some thanks for their hosting, by bringing them some publicity (ie "sponsered by", in our adverts and on the mud, etc).

    5. When GW2 finally goes online properly, the combat and movement system won't be too much of a shell shock for the players.

    The basic concept:

    A pure PK mud which tests player skill in terms of pre-battle preparation, on-the-spot reflexes, and ability to adapt to new situations. There is no character advancement, and so it is purely a test of the player's skill and knowledge.

    The system:

    Each Player starts with an average rating in each stat, but may rearrange the stat distribution by going to the gym. A player may not leave the gym (or save) unless their stats are balanced.

    Players may travel to the smithy to choose their equipment (no cost, it's free - but everything has disadvantanges as well as advantages, so for example chainmail gives better protection, but slows you down).

    Each player gets 85% in each basic style, 40% in each advanced, and 25% in each super. These values never change, and there are no bonuses gained from "inherited" stances. This may be tweaked somewhat, but the idea is to try and make each style worthwhile, so that people will try them all out (and thus utilise the techniques available to each). Equally, players get the same rating in each weapon skill, to encourage people to try out new weapons rather than sticking with one.

    Winning matches awards "Fame", while losing removes "Fame". The idea is to earn as much fame as possible - the high score table should list ALL players, not just those currently logged on. We could later add special matches such as teams, chariots, etc, etc.

    Changes required:

    * Stats are reorganised, so that everything is physical based.

    * There are no classes.

    * Updated help files.

    * Combat is only permitted within one of the fighting arenas.

    * The "who" command displays wins/defeats.

    * "Death" should send you to the temple.

    * Fame is earned instead of Primal.

    * Cannot quit while in a combat zone.

    * Movement speed changed to 1/2/3 for walk/jog/run.

    * Allow players to choose to fight against certain mobs (eg animals).

    * Allow players to practice against training dummies.

    * Add some buildings (building code almost complete): Town (the Nexus equivilent), the tavern (where you can socialise), the smithy (where you can equip up), the hospital (where you can purchase healing), the central arena (all vs all combat), the gym (where you can rearrange your stats), the temple (where you go when you die), and various private arenas.


    I did the same again when we came out of beta - although I didn't manage to implement everything I'd planned, I split the features into "must have" and "would be nice", and just tried to do as much as I could before the deadline I'd set myself.

    You can see the list here: Features needed to come out of beta.
    12 Jan, 2013, Kelvin wrote in the 29th comment:
    Votes: 0
    Very handy, KaVir, thanks for sharing this. It's interesting seeing how these differ from game to game.
    12 Jan, 2013, quixadhal wrote in the 30th comment:
    Votes: 0
    Nice, KaVir.

    One point I'll disagree with in your list is "Cannot quit while in a combat zone." I believe you should ALWAYS be able to quit, no matter what. Of course, quitting in combat should probably result in an automatic loss, but quit is a meta-command and shouldn't be affected by in-game mechanics. It is a more polite way to drop your connection without having to force the user to close their client, and sometimes a real-life event causes you to want to be sure you're simply not logged in, regardless of consequences.
    12 Jan, 2013, KaVir wrote in the 31st comment:
    Votes: 0
    There are some occasions when the character shouldn't be allowed to vanish into thin air. In theory you could have the 'quit' work like disconnect in those situations, but that could cause accidents (and result in some very angry players), with people typing 'quit' and not realising that their characters are still hanging around and vulnerable to attack.

    Another option would be to add a 'disconnect' command, but think about it for a moment - you're adding a command to reproduce functionality that's already (and intuitively) built into the client. Why would anyone bother typing it? It's just cluttering up the command list, something which is already going to look intimidating to newbies. If anything you should be streamlining your command list, not adding obsolete commands.
    12 Jan, 2013, Lyanic wrote in the 32nd comment:
    Votes: 0
    quixadhal said:
    Nice, KaVir.

    One point I'll disagree with in your list is "Cannot quit while in a combat zone." I believe you should ALWAYS be able to quit, no matter what. Of course, quitting in combat should probably result in an automatic loss, but quit is a meta-command and shouldn't be affected by in-game mechanics. It is a more polite way to drop your connection without having to force the user to close their client, and sometimes a real-life event causes you to want to be sure you're simply not logged in, regardless of consequences.

    I agree with KaVir that there are certain situations where players should not be allowed to "quit". As for merely disconnecting, most clients have a button/command for that, which does not require closing the client.
    13 Jan, 2013, quixadhal wrote in the 33rd comment:
    Votes: 0
    So, let me ask you this then…

    If the player can disconnect at any time, what's the harm in giving them a command called "quit" which does the SAME THING?

    Some of us don't play with fancy graphical clients that have buttons. I don't care if "quitting" causes the same penalties as disconnecting, but if I type "quit" to go do something, I damn well want it to quit, not give me some smart-ass message about being in combat or any other circumstance that might make quitting less than ideal.
    13 Jan, 2013, Kelvin wrote in the 34th comment:
    Votes: 0
    quixadhal said:
    So, let me ask you this then…

    If the player can disconnect at any time, what's the harm in giving them a command called "quit" which does the SAME THING?

    Some of us don't play with fancy graphical clients that have buttons. I don't care if "quitting" causes the same penalties as disconnecting, but if I type "quit" to go do something, I damn well want it to quit, not give me some smart-ass message about being in combat or any other circumstance that might make quitting less than ideal.


    Honestly, this is pretty far off topic, and you probably shouldn't have broken up a good discussion for this.
    13 Jan, 2013, Lyanic wrote in the 35th comment:
    Votes: 0
    Kelvin said:
    Honestly, this is pretty far off topic, and you probably shouldn't have broken up a good discussion for this.

    Honestly, you have to just let it go. Tangents are going to come up in any forum thread, but especially those on this site. It is what it is. You can't stop it.
    13 Jan, 2013, Kelvin wrote in the 36th comment:
    Votes: 0
    Lyanic said:
    Honestly, you have to just let it go. Tangents are going to come up in any forum thread, but especially those on this site. It is what it is. You can't stop it.

    Nah, they did the best thing and took it to another thread. We all win.

    With that said, Lyanic, do you have anything to add about the core, critical bits of your game(s)?
    17 Jan, 2013, Paperback wrote in the 37th comment:
    Votes: 0
    Interesting to read the opinions in that article, Kelvin. I got a lot out of the comments, too. The majority of MUD owners seem to be tinkerers, not computer scientists or "hardcore" programmers. Even so, they have good ideas and sometimes can implement them appropriately. I'm working on a project that takes a step back from MUD "codebases" and attempts to create something malleable from a new approach. I'll probably be posting about that here on MudBytes later on. However, my opinion is just that: take that step back. Start fresh.

    The one thing I guess I don't agree with on a personal level is the part in the article about not making robust, distributed services. Certainly something stable is preferred.
    17 Jan, 2013, Rarva.Riendf wrote in the 38th comment:
    Votes: 0
    Quote
    Certainly something stable is preferred.

    We are talking about text games, that draw very little ressources. Distributed services only makes the thing harder to maintain and upgrade, hence breaking the stability you look for from the beginning.

    Quote
    I'm working on a project that takes a step back from MUD "codebases" and attempts to create something malleable from a new approach.

    Maybe you should look into something like this: http://www.mudbytes.net/index.php?a=topi...
    17 Jan, 2013, Paperback wrote in the 39th comment:
    Votes: 0
    Quote
    something like .. this


    Interesting, but not very interested in digging too deep because I'm heading toward my own conclusions. Nice web terminal. I was disappointed to see no one was online.

    Quote
    …distributed…creates…instability


    Only when improperly crafted, my friend.
    17 Jan, 2013, Idealiad wrote in the 40th comment:
    Votes: 0
    Rarva.Riendf said:
    Distributed services only makes the thing harder to maintain and upgrade, hence breaking the stability you look for from the beginning.


    Distributed services make it easier to share services and code.

    They make it easier to upgrade individual sub-systems.

    They make the overall system more fault-tolerant and error-resistant by isolating sub-systems.

    Note that 'distributed services' can mean lots of things. Systems on the same process, on different processes, on different servers. Whatever.

    So how do they make it harder to maintain and upgrade?
    20.0/204