15 Oct, 2008, KaVir wrote in the 41st comment:
Votes: 0
DavidHaley said:
In general, my interest would be in adding something that hasn't really been done, or hasn't been done often or well.


Same here. My interest would be further increased if the entry were something that I could reuse in my own mud (because then it wouldn't feel as if I were taking time away from my mud to enter the competition).

Vassi said:
I also agree that the better question is what the judging criteria is, I.E. are you judging purely for efficiency in the design, or the robustness of the user experience? Personally I'm in favor of the latter, since that's what actually matters. (Not to say that a badly written piece of code should win just because it's feature crammed, but a sublimely 'elegant' design should lose to a slightly less elegant, but vastly more 'fun' product.


That really depends on what the entry is supposed to be used for. If it's something intended to be used out-of-the-box then obviously "fun" is a very important factor, but if it's only intended to serve as a foundation for further enhancements then IMO a stable and elegant design would be far more important.

The 16K MUD competition gave features a weighing of 1.6 and fun a weighing of 1.3, while maintainability and stability were given a weighing of 0.9 and 0.6 respectively. In my opinion that was the wrong way around for a barebones codebase designed as a platform for people to build their own games on.

I would also appreciate it if the weighings were made clear in advance (the 16K MUD competition didn't do this).

The_Fury said:
I think, in general, smaller projects that can be used across a number of bases with minimal porting would be a boon here.


That's what I'd prefer as well. For the mudmagic coding contests I ensured that my entries could be compiled and tested as standalone applications, but also came with clear installation instructions for Merc 2.1. I then submitted two copies of my code - one on its own (with the standalone option enabled), and the other preinstalled into a copy of Merc 2.1 (note that I picked Merc 2.1 because (1) I'm familiar with it, and (2) it's the parent of most modern Diku muds and thus reasonably familiar to a wide range of developers, but I think any other well-known codebase would be fine as well).

My second entry also compiled cleanly as both C and C++, so that it could be used in any codebase written in either language, with minimum programming effort.

Obviously I'm highly biased, because it's the approach I already favour, but I think it's one that makes sense considering the wide range of different codebases out there. The more easily a snippet can be ported to different muds, the more likely it is to be used.
15 Oct, 2008, quixadhal wrote in the 42nd comment:
Votes: 0
Strictly my own desire being pushed here…. but maybe it would be the right kind of scope for such a competition.

One of the things I've kept tossing around for a few years now, but been put off really working on due to my past habits of not doing my math homework, is creating a world-map system using Perlin noise. I say Perlin noise, to distinguish it from other fractal systems that require you to make the map finite size, or generate it in blocks and store them. Any system that gives you numbers that share the same properties (the same output from the same input, seemingly random, but adjacent numbers are close to each other) would work.

Obviously there are a couple parts to making that a useful system.

DikuMUD's don't use seperate values for terrain height, vegetation, climate, etc… they just have a single sector type. So, if you were aiming for a DikuMUD snippet, you'd need to use several noise functions and map the combinations of values to sector types. A high value would be a mountain, but a low value might be water in one climate, but ice in another.

Once you have a terrain system working, you need a dynamic description system which, at the minimum, would need to look at all the adjacent room terrains to not be worthless.

Of course, to integrate with the existing hand-built vnums, you'd want a way to specify points of entry. In other words, rooms along the border would need to store coordinate values so if you try and "generate" something using those coordinates, it would instead say "AHA! I already have a saved room, here ya go!" That would also let you roam around the virtual wilderness, decide you want to add a crumbling stone pillar to a particular place, and "save" the room, making it a real vnum-based room.

Lastly, there would be cleanup details to handle, like what happens when a player quits (or disconnects) in a virtual room, how long do you let such rooms hang around before nuking them, if you drop things in them, do the things just go away? If you have OLC, those systems need to become aware of virtual rooms and coordinates, so they can be integrated.

So, maybe not a small enough project for a competition afterall. Then again, I do recall one or two of the entries in the 16K version had dynamic room generation, so maybe not so far off either.

Anyways, I wanted to write that all in one spot and see what anyone thinks of it, competition or no. :)
15 Oct, 2008, David Haley wrote in the 43rd comment:
Votes: 0
Idealiad said:
allow for any language to be used, but if your panel of judges doesn't cover a particular language, simply say sorry, you don't get points for the judging of (a) if you enter with an obscure language.

IMO the only way this could possibly be acceptable would be for the list of languages to be known ahead of time, or at the least allow people to request if a language would be accepted.
15 Oct, 2008, Noplex wrote in the 44th comment:
Votes: 0
DavidHaley said:
Idealiad said:
allow for any language to be used, but if your panel of judges doesn't cover a particular language, simply say sorry, you don't get points for the judging of (a) if you enter with an obscure language.

IMO the only way this could possibly be acceptable would be for the list of languages to be known ahead of time, or at the least allow people to request if a language would be accepted.

Agreed, I'd like a list ahead of time. I am assuming that languages such as Python, Ruby, Java, etc; I'd like to know if linking in non-standard external libraries (such as boost) would go against the overall size of the code. The rules need to be straightforward, but other than that, count me in.
15 Oct, 2008, Chris Bailey wrote in the 45th comment:
Votes: 0
Quixadhal said:
Strictly my own desire being pushed here…. but maybe it would be the right kind of scope for such a competition.

One of the things I've kept tossing around for a few years now, but been put off really working on due to my past habits of not doing my math homework, is creating a world-map system using Perlin noise. I say Perlin noise, to distinguish it from other fractal systems that require you to make the map finite size, or generate it in blocks and store them. Any system that gives you numbers that share the same properties (the same output from the same input, seemingly random, but adjacent numbers are close to each other) would work.


I hadn't thought of using perlin noise to generate a wilderness but it's an excellent idea, especially for very large overland terrain. I'm going to go look at some of the generators for 3d terrain and see what I can come up with.
15 Oct, 2008, David Haley wrote in the 46th comment:
Votes: 0
I think that a line would have to be drawn to differentiate common and uncommon external libraries. If you forbid external libraries, people writing in C/C++ are significantly disadvantaged when compared to languages like Java or Python that provide very large standard libraries. I think that again a list would have to be drawn up ahead of time.

For example, almost anything I do in C/C++ would be very likely to involve a Lua embedding. Sure, that's non-standard, but it seems (to me at least) like a reasonable thing to do. Part of being good at this stuff involves reusing things appropriately instead of writing a home-grown solution every time. Of course it depends on what the topic is…
15 Oct, 2008, quixadhal wrote in the 47th comment:
Votes: 0
Not to mention perl, where you can find a CPAN module to do almost anything.
15 Oct, 2008, Vassi wrote in the 48th comment:
Votes: 0
DavidHaley said:
Of course it depends on what the topic is…


I vote for a cooking system. If you don't have french toast, you're out.
15 Oct, 2008, David Haley wrote in the 49th comment:
Votes: 0
Actually, we were talking about a planning system in some thread… the more I think about it the more I like the idea of doing something where agents are required to go through some kind of decision process to accomplish a goal. It would let you use higher-level constructs in, say, mudprogs.
15 Oct, 2008, quixadhal wrote in the 50th comment:
Votes: 0
while(ch.IsHungry()) {
if(cost = buy_food(ch, ch->room)) {
ch->Money -= cost;
ch->hunger -= cost/10;
} else {
if(ch.Money > 10000)
move(ch, find_room("blue.dolphin");
else if(ch.Money > 1000)
move(ch, find_room("red.lobster");
else if(ch.Money > 100)
move(ch, find_room("taco.bell");
else
send_to_room(ch, "Can you spare a dime?");
}
}
15 Oct, 2008, David Haley wrote in the 51st comment:
Votes: 0
Fail! No French toast. :biggrin:
15 Oct, 2008, Chris Bailey wrote in the 52nd comment:
Votes: 0
class Person
def initialize
@last_eaten = nil
@food = ["French Toast", "Pancakes","Cereal","Cheeseburgers","Waffles","Steak"]
end

def eat(food)
if @food.include? food
puts "You eat the #{food}, yummy!"
@food.delete food
@last_eaten = food
else
puts "Aw, too bad. You don't have any #{food}."
end
end

def burp
if @last_eaten == nil
puts "You cover your mouth and burp as politely as possible"
else
puts "You let out a long belch. It tastes like #{@last_eaten}."
end
end
end


Bob = Person.new
Bob.eat("French Toast")
Bob.burp
Bob.eat("French Toast")
Bob.eat("Steak")
Bob.burp

Output is….
You eat the French Toast, yummy!
You let out a long belch. It tastes like French Toast.
Aw, too bad. You don't have any French Toast.
You eat the Steak, yummy!
You let out a long belch. It tastes like Steak.
15 Oct, 2008, quixadhal wrote in the 53rd comment:
Votes: 0
DavidHaley said:
Fail! No French toast. :biggrin:


They have french toast at the Blue Dolphin. In fact, they have Monte Cristos. :evil:
15 Oct, 2008, David Haley wrote in the 54th comment:
Votes: 0
Oh… forgive me then for not knowing what the Blue Dolphin is. :tongue: (what is it?)
15 Oct, 2008, Vassi wrote in the 55th comment:
Votes: 0
DavidHaley said:
Fail! No French toast. :biggrin:


Actually, I was thinking about it after a while and I think that would be cool =(

Anyone ever play Lost in Blue? I'd love a game like that - only with 90% less suck. I could see systems like that being really cool for RP-Heavy games, just chill while ya catch some fish, cut up some veggies, and simmer it in a pot =X
15 Oct, 2008, quixadhal wrote in the 56th comment:
Votes: 0
DavidHaley said:
Oh… forgive me then for not knowing what the Blue Dolphin is. :tongue: (what is it?)


I figured the others in the list would make it obvious my mob was meeting his goal by going to the best restaurant he could afford. The Blue Dolphin is one of the few black-tie places we have around these parts, so while I didn't expect anyone to recognize it, I figured it would be fancy enough to get you whatever you wanted. :)

Actually, I'd love to see a MUD with a real crafting system. My favorite graphical MMO (Everquest II) has a decent one that has you do a short mini-game to combine your materials into an item. Star Wars Galaxies (pre-CU) had a very impressive crafting system with a fully player driven market hooked into it. The quality of your materials affected the quality of the end products, and those were often materials for further products. For example, using good timber when building walls made better quality walls. You needed better walls for larger housing, but building your smaller housing from superior walls reduced your upkeep costs.
15 Oct, 2008, David Haley wrote in the 57th comment:
Votes: 0
Right, I figured that it was a restaurant, I was just wondering if it's one I should have heard of. :wink: I guess part of the problem is that I don't know where "these parts" are!

I'd also love to see crafting, along with resource management, refining, etc.
40.0/57