28 May, 2010, Orrin wrote in the 41st comment:
Votes: 0
Igabod said:
Kavir is right, we'd spark more interest if every entry could be used with any codebase with little to no alterations.

Except that's not ever going to be the case, particularly as some of the features which have been suggested are reliant on a wider game framework (OLC for example). Even if they aren't, someone with an LPC mud is going to find it hard to incorporate your cool Ruby module for example. There are arguments against using a stock codebase of course, and KaVir mentioned motivation to use the code in his own project, and that's fair enough. I was just suggesting it as a way of allowing the contest to cover areas which might be more game dependent but could still be interesting and hopefully advance the art a little.
28 May, 2010, 3squire wrote in the 42nd comment:
Votes: 0
Having read quite a lot of mud code, I am of the opinion that codebases are more-or-less straight jacketed by their core architectures anyhow. The whole reason you can't write a good OLC for Diku is because Diku needs to be re-factored in a major way but it's restrictive license makes it poison (at least that's why I won't fix it). In codebase after codebase, the sigil advantages are also the tragic constraints – you get a world with rooms and items privileged with and limited by the architect of the original mud from whence it's grown – that's why everyone can "feel" it when they play ROM or GodWars or LP - because you can't really make them different than what they are.

Allow me to give an example. I would like my NPCs to have a menu-driven conversations system where the player is given a set of responses and asked to choose which they would like to give, like in a Baldur's Gate game. Implementing that sort of functionality really requires native support from the mud engine I'm running – I can't script around its absence without making it look like a genuine hack and actually doing a lot of genuine hacking at the engine.

So when people talk about their codebases and how they want it to be "pluggable" my response is always – You can read the resulting code and translate it in a day or two back into your own environment but let's shoot for stubs of new innovative codebases. It's the ideas that count anyway, it's the composition and the inheritance and the innovation. Competitions that are confined to narrow ambitions like pre-existing (or worse, as KaVir suggest, skeletal) code-bases may be destined to draw a larger crowd – but such guidelines guarantee my own non-participation.
28 May, 2010, KaVir wrote in the 43rd comment:
Votes: 0
Igabod said:
So I guess the OLC contest wouldn't fit into what I just said, but I think it would still generate a lot of developer interest.

You could create a fairly generic OLC - I've seen area builders that really are standalone applications, and if it supported an easy and flexible way of adding data fields it could be used for a fairly wide range of codebases.

Most OLCs are heavily tied to a specific codebase, but it doesn't have to be done that way, and it would be pretty nice for builders if they didn't have to learn a new OLC when moving from one codebase to another.

Igabod said:
The quest system would probably generate the most interest from both developer and player out of the options so far.

I'm undecided on it. It sounds interesting, but my concern is that it might be too open-ended.

Igabod said:
I like Kavir's idea of a bot writing contest, but I don't think this would be as big of an attention getting contest as some of the other options that have been mentioned.

It would have a much lower entry barrier though - you could even have players taking part, as many players know how to write their own scripts. Perhaps some muds might even offer in-game prizes to their players for taking part and/or winning? On the other hand, there's still plenty of freedom for creativity and showcasing software development skills.

In my opinion, the biggest hurdle for a contest is participation. OLC and quest systems might be cool, but they aren't quick and easy jobs - they'd require hours of work, and a level of programming ability beyond that of the average mud developer. How many people would sign up for such a contest? And how many of those would actually submit an entry before the deadline?

How many developers in this thread would submit an entry if it took them a week of work? How about a day? How about an hour?
28 May, 2010, quixadhal wrote in the 44th comment:
Votes: 0
Orrin said:
Igabod said:
Kavir is right, we'd spark more interest if every entry could be used with any codebase with little to no alterations.

Except that's not ever going to be the case, particularly as some of the features which have been suggested are reliant on a wider game framework (OLC for example).


Agreed. If you want to start from an existing platform, I think SocketMUD (or the ruby/python/etc equivalent) might be the only viable option. Even then, you're already limiting yourself by doing so. For example, there's no reason we couldn't have a MUD that uses curses for full terminal support, accepting connections via SSH… except that nobody has written a barebones framework that can do that yet.

I also like Kavir's bot idea. The contest could be to write the most successful bot that can connect to and play multiple games, with criteria like "How good is it at playing?", "How player-like is it?", "How resiliant is it if bad things happen to it?". While judging, they could either be put through the same set of (randomly chosen… or set up) muds to ensure they can handle a wide variety of environments.

This could be win on several levels. On the bot side, it'd be a good example of how to advance AI (you know you'd love to have NPC's that play more like players do). On the anti-botting side, it would help folks learn how to spot bots if they don't want them on their own servers.
28 May, 2010, KaVir wrote in the 45th comment:
Votes: 0
quixadhal said:
I also like Kavir's bot idea. The contest could be to write the most successful bot that can connect to and play multiple games, with criteria like "How good is it at playing?", "How player-like is it?", "How resiliant is it if bad things happen to it?". While judging, they could either be put through the same set of (randomly chosen… or set up) muds to ensure they can handle a wide variety of environments.

It would be considerably more difficult to create bots that can handle any mud But on the other hand, tailoring them to a specific mud would require a lot of insider knowledge. I think the only way to do this would be to hold the contest on a stock codebase.

I could also see cooperative entries being a problem. Imagine a mud submitting a dozen entries from its players, which all form a big group and start hunting down the other bots.

If the contest required reaching a certain level, or was based on a series of one-on-one fights, then you wouldn't even need judges - the whole process could be automated, and people could even watch the scoreboards update in real-time while the contest was underway. It would be nice to judge categories such as maintenance, etc, but that would add a lot more work, and might prove excessive if there were a lot of entries. Maybe the scoring could be simplified though.

Another option might be to produce conversation bots, but they would be more difficult to write and judge.

quixadhal said:
This could be win on several levels. On the bot side, it'd be a good example of how to advance AI (you know you'd love to have NPC's that play more like players do). On the anti-botting side, it would help folks learn how to spot bots if they don't want them on their own servers.

I'd be more interested in using them as an army of audit-bots, for stress-testing the difficulty of new content ;)
28 May, 2010, 3squire wrote in the 46th comment:
Votes: 0
Frankly, I see this is the devolution from

'potentially involving contest ideas'

to

'we must limit the scope to prevent extremely unlikely scenarios'

and

'in the interest of getting people involved, we should choose rules and topics that are sure to keep people away'
28 May, 2010, Idealiad wrote in the 47th comment:
Votes: 0
We should have two contests, the bots and the features.
28 May, 2010, KaVir wrote in the 48th comment:
Votes: 0
3squire said:
Frankly, I see this is the devolution from

'potentially involving contest ideas'

to

'we must limit the scope to prevent extremely unlikely scenarios'

and

'in the interest of getting people involved, we should choose rules and topics that are sure to keep people away'


I see it as an evolution from:

'complex and open-ended pipedream which will have no submissions'

To:

'simple yet fun and useful feature with the potential to attract many submissions'


I would decide whether or not to take part based primarily on the following five criteria:

1) Who is hosting, promoting, and taking part in the contest?

2) Do I find the contest interesting?

3) How much time and effort is it going to take?

4) Could I use my submission to improve my own mud?

5) What are the prizes?

While your competition proposal to "make a mud that feels like no other mud you've ever played" may be something I'd find interesting, that's already what most mud owners have been trying to do for the last couple of decades. It's not something you just throw together at the weekend and hand in as a competition entry.

I can understand wanting the competition to be about something 'cool', but if you make it too complex nobody will take part. I would far rather see a simple contest with a hundred submissions than complex contest with one submission.
28 May, 2010, Sryth wrote in the 49th comment:
Votes: 0
Quote
I can understand wanting the competition to be about something 'cool', but if you make it too complex nobody will take part. I would far rather see a simple contest with a hundred submissions than complex contest with one submission.


I agree. I like the bot/AI ideas myself.

Quote
While your competition proposal to "make a mud that feels like no other mud you've ever played" may be something I'd find interesting, that's already what most mud owners have been trying to do for the last couple of decades. It's not something you just throw together at the weekend and hand in as a competition entry.


Also agreed. These small contests, especially the first one or two, need to be something people can put together in no more than a weekend, and give people at least 2 months to get it done so they can choose which weekend to do it…or draft it and edit on another weekend, etc.
28 May, 2010, David Haley wrote in the 50th comment:
Votes: 0
KaVir said:
1) Who is hosting, promoting, and taking part in the contest?

Out of curiosity, which hosts, promoters and participants would you need to see to get involved?
28 May, 2010, Runter wrote in the 51st comment:
Votes: 0
Orrin said:
Igabod said:
Kavir is right, we'd spark more interest if every entry could be used with any codebase with little to no alterations.

Except that's not ever going to be the case, particularly as some of the features which have been suggested are reliant on a wider game framework (OLC for example). Even if they aren't, someone with an LPC mud is going to find it hard to incorporate your cool Ruby module for example. There are arguments against using a stock codebase of course, and KaVir mentioned motivation to use the code in his own project, and that's fair enough. I was just suggesting it as a way of allowing the contest to cover areas which might be more game dependent but could still be interesting and hopefully advance the art a little.


Lawl, as opposed to edging out anyone not using a specific language? How about you focus on the algorithms being clean and anyone should be able to re-implement it in language X.
28 May, 2010, KaVir wrote in the 52nd comment:
Votes: 0
David Haley said:
KaVir said:
1) Who is hosting, promoting, and taking part in the contest?

Out of curiosity, which hosts, promoters and participants would you need to see to get involved?

No specific preferences, but I would feel more comfortable if the host was someone with a (good) reputation, the promoters were people I knew could actually provide exposure for the winning entries, and there were definitely other people taking part.
29 May, 2010, Chris Bailey wrote in the 53rd comment:
Votes: 0
Well, I'll compete. =)
29 May, 2010, Mudder wrote in the 54th comment:
Votes: 0
I would attempt to compete, simply as a challenge. It's something I'm not ready for but will hopefully learn from the attempt and then see how others did it.
29 May, 2010, Tyche wrote in the 55th comment:
Votes: 0
Igabod said:
@Tyche regarding char generation competion, what exactly did you have in mind here? There isn't too awful much that can be done with character creation except in the case of RP muds where you can choose aesthetic attributes that have no real function within the game. Or were you thinking of a competition to make a clean more legible nanny type function?


I'm a fan of paper & pencil FRPGs and game systems in general. And I'm sort of an anti-fan of the Diku/Merc/Circle/Rom/Smaug take on the 2nd edition Ad&D game system. Believe me there are many more interesting and creative ways to create and describe characters, to resolve actions and to do character development. Of course a personal pet peeve of mine on game systems probably isn't enough to inspire a creative contest or competition. ;-)
02 Jun, 2010, Igabod wrote in the 56th comment:
Votes: 0
I admit it's been many years since I played AD&D but I don't really remember the char creation process to be anything more interesting than the rom char creation process. Well, it was interesting creating the back story of the character but even that is just aesthetic details to further RP. Doesn't have any impact on game-play.
02 Jun, 2010, Mudder wrote in the 57th comment:
Votes: 0
Tyche said:
Igabod said:
@Tyche regarding char generation competion, what exactly did you have in mind here? There isn't too awful much that can be done with character creation except in the case of RP muds where you can choose aesthetic attributes that have no real function within the game. Or were you thinking of a competition to make a clean more legible nanny type function?


I'm a fan of paper & pencil FRPGs and game systems in general. And I'm sort of an anti-fan of the Diku/Merc/Circle/Rom/Smaug take on the 2nd edition Ad&D game system. Believe me there are many more interesting and creative ways to create and describe characters, to resolve actions and to do character development. Of course a personal pet peeve of mine on game systems probably isn't enough to inspire a creative contest or competition. ;-)


I'm curious… How would the Tyche (I feel like your name could be the new Rock) do things differently?
02 Jun, 2010, Runter wrote in the 58th comment:
Votes: 0
Mudder said:
Tyche said:
Igabod said:
@Tyche regarding char generation competion, what exactly did you have in mind here? There isn't too awful much that can be done with character creation except in the case of RP muds where you can choose aesthetic attributes that have no real function within the game. Or were you thinking of a competition to make a clean more legible nanny type function?


I'm a fan of paper & pencil FRPGs and game systems in general. And I'm sort of an anti-fan of the Diku/Merc/Circle/Rom/Smaug take on the 2nd edition Ad&D game system. Believe me there are many more interesting and creative ways to create and describe characters, to resolve actions and to do character development. Of course a personal pet peeve of mine on game systems probably isn't enough to inspire a creative contest or competition. ;-)


I'm curious… How would the Tyche (I feel like your name could be the new Rock) do things differently?


Obviously, you're trying to steal awesome unique ideas. (Tm)
03 Jun, 2010, Tyche wrote in the 59th comment:
Votes: 0
Mudder said:
I'm curious… How would the Tyche (I feel like your name could be the new Rock) do things differently?


Well when I have the time, I'll spawn a discussion of different game systems.
18 Jun, 2010, donky wrote in the 60th comment:
Votes: 0
Regarding the raised concerns about entries being codebase specific, and reusable by the author in their MUD, I was wondering whether there was any feasible way for the following idea to satisfy these?

Is it possible to have a layer of abstraction against which an entry can be implemented where the resulting code would be sufficiently decoupled from the actual MUD engine of the author? Decoupled enough that others could compile or run it against their own layer of abstraction, or a standard cross-platform one made available for the contest, to get it to work. But not so decoupled that the code is not able to be incorporated with the author's MUD engine.

The most obvious way this might be done is through sockets. Where the abstracted engine that is connected to provides networking support, optionally parsing and other tedious low-level elements that might be considered relatively standard and the availability of which would allow entrants to get right into the high-level features of interest.

I am inclined towards the idea of a popular C or C++ codebase being used to provide the standard cross-platform, with precompiled binaries being provided and perhaps example layers of abstraction in a variety of languages so that entrants can get started with minimal effort. Another approach might be to have a virtual machine which acts as a black box to provide access to an abstracted standard engine, which anyone on any platform can run to have access to on an external local socket.

Now, let's pretend for the sake of interest that the work to provide a workable layer of abstraction has been done. Also the work to modify a suitable codebase or create a usable virtual machine, and the example layers in the variety of languages. Would the barrier to entry be sufficiently low? Could you see yourself writing code you could use in your own MUD, as an entry over an abstracted layer?

If these questions have positive responses, then it might be worth moving onto getting the resources created and available.
40.0/67