<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments for Walraven/SIMud</title>
	<atom:link href="http://mud.simud.org/blog/index.php/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://mud.simud.org/blog</link>
	<description>the mudlib will rise again, seriously...</description>
	<pubDate>Wed, 10 Mar 2010 07:33:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on it&#8217;s aliiive by shentino</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/09/its-aliiive/comment-page-1/#comment-89</link>
		<dc:creator>shentino</dc:creator>
		<pubDate>Fri, 03 Jul 2009 23:39:49 +0000</pubDate>
		<guid isPermaLink="false">http://tiffany.simud.org/blog/?p=3#comment-89</guid>
		<description>This is sad...sad sad sad.

The mud is dead.

I'm moving on.

I'll watch from afar though.  If things recover I'll be back, but at the moment only admin voodoo is going to fix things, and in the meantime all I can do is twiddle my thumbs and devote my time to more productive uses.</description>
		<content:encoded><![CDATA[<p>This is sad&#8230;sad sad sad.</p>
<p>The mud is dead.</p>
<p>I&#8217;m moving on.</p>
<p>I&#8217;ll watch from afar though.  If things recover I&#8217;ll be back, but at the moment only admin voodoo is going to fix things, and in the meantime all I can do is twiddle my thumbs and devote my time to more productive uses.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on rebuilding progress by Acius</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/25/rebuilding-progress/comment-page-1/#comment-39</link>
		<dc:creator>Acius</dc:creator>
		<pubDate>Tue, 31 Mar 2009 11:48:52 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=68#comment-39</guid>
		<description>I fixed about a dozen Witac bugs, if you're wondering ;)</description>
		<content:encoded><![CDATA[<p>I fixed about a dozen Witac bugs, if you&#8217;re wondering <img src='http://mud.simud.org/blog/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on standardized buffs by Acius</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/18/standardized-buffs/comment-page-1/#comment-38</link>
		<dc:creator>Acius</dc:creator>
		<pubDate>Tue, 31 Mar 2009 11:48:12 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=30#comment-38</guid>
		<description>I think it's a good idea to centralize the buff system a bit more. However, the old system had some important properties that you have lost:

1. Interface simplicity. I think this can largely be solved by simply making the living object and the buff manager the same thing, and avoiding the "get_buff_manager" thunking annoyance. You're adding a function to living *anyway*.

2. Updatability. Your system here relies very heavily on there never being a buggy object, ever. This is terrible design. The old system guaranteed that the buffs were always correct after a refresh, no matter how buggy the previous buffs were. This system has no way of saying "recalculate all my buffs to make sure they're right." You're one badly-behaved object away from weird, sticky, evil permanent buffs.

I think the solution to this is easy -- make sure the buff manager knows WHICH OBJECTS are providing the buffs, and allow it to ask what the current amount of the buff is. This avoids the ugliness of looping through the inventory, although IMO the correct answer to that is to start making players carry backpacks if they want to carry lots of stuff, thus avoiding the multi-hundred-object inventory problem. I do agree that having more than one query function for different buff types was a terrible idea -- I would do it like this:

query_buff() { return ([ "str" : -2, "dex" : 5 ]); }

I think simplifying the buff system is a good idea, but I believe you've discarded some important and valuable properties with your proposal here.</description>
		<content:encoded><![CDATA[<p>I think it&#8217;s a good idea to centralize the buff system a bit more. However, the old system had some important properties that you have lost:</p>
<p>1. Interface simplicity. I think this can largely be solved by simply making the living object and the buff manager the same thing, and avoiding the &#8220;get_buff_manager&#8221; thunking annoyance. You&#8217;re adding a function to living *anyway*.</p>
<p>2. Updatability. Your system here relies very heavily on there never being a buggy object, ever. This is terrible design. The old system guaranteed that the buffs were always correct after a refresh, no matter how buggy the previous buffs were. This system has no way of saying &#8220;recalculate all my buffs to make sure they&#8217;re right.&#8221; You&#8217;re one badly-behaved object away from weird, sticky, evil permanent buffs.</p>
<p>I think the solution to this is easy &#8212; make sure the buff manager knows WHICH OBJECTS are providing the buffs, and allow it to ask what the current amount of the buff is. This avoids the ugliness of looping through the inventory, although IMO the correct answer to that is to start making players carry backpacks if they want to carry lots of stuff, thus avoiding the multi-hundred-object inventory problem. I do agree that having more than one query function for different buff types was a terrible idea &#8212; I would do it like this:</p>
<p>query_buff() { return ([ "str" : -2, "dex" : 5 ]); }</p>
<p>I think simplifying the buff system is a good idea, but I believe you&#8217;ve discarded some important and valuable properties with your proposal here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on communication upgrades by Walraven/SIMud &#187; forum interface</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/10/communication-upgrades/comment-page-1/#comment-12</link>
		<dc:creator>Walraven/SIMud &#187; forum interface</dc:creator>
		<pubDate>Thu, 19 Mar 2009 18:50:17 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=8#comment-12</guid>
		<description>[...] forum interface&#8230; and it will likely be the springboard I use when actually implementing the communication upgrade ideas.)  The in-game forum system is long overdue. It should be very similar to the mudmail client, [...]</description>
		<content:encoded><![CDATA[<p>[...] forum interface&#8230; and it will likely be the springboard I use when actually implementing the communication upgrade ideas.)  The in-game forum system is long overdue. It should be very similar to the mudmail client, [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on communication upgrades by Untitled :: Blog Archive » mud revived, sorta</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/10/communication-upgrades/comment-page-1/#comment-11</link>
		<dc:creator>Untitled :: Blog Archive » mud revived, sorta</dc:creator>
		<pubDate>Thu, 19 Mar 2009 18:05:28 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=8#comment-11</guid>
		<description>[...] communication upgrades - plan for mudmail/forums [...]</description>
		<content:encoded><![CDATA[<p>[...] communication upgrades - plan for mudmail/forums [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on hunger system ideas by Walraven/SIMud &#187; standardized buffs</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/10/hunger-system-ideas/comment-page-1/#comment-10</link>
		<dc:creator>Walraven/SIMud &#187; standardized buffs</dc:creator>
		<pubDate>Thu, 19 Mar 2009 04:49:54 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=12#comment-10</guid>
		<description>[...] - see the hunger system post for more [...]</description>
		<content:encoded><![CDATA[<p>[...] - see the hunger system post for more [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on hunger system ideas by allaryin</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/10/hunger-system-ideas/comment-page-1/#comment-6</link>
		<dc:creator>allaryin</dc:creator>
		<pubDate>Sat, 14 Mar 2009 17:16:23 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=12#comment-6</guid>
		<description>That's generally the idea, but the D20 method is only about 95% of what we need. I'll address this one further in another post, there's already been a good bit of discussion on it.

As far as ticking hunger on readiness... I'd like to, but I'm convinced it wouldn't work. I've been pondering this one for a while now, and it would be awfully difficult to balance. I think the better solution is to add endurance and mana costs to actions that previously had none.</description>
		<content:encoded><![CDATA[<p>That&#8217;s generally the idea, but the D20 method is only about 95% of what we need. I&#8217;ll address this one further in another post, there&#8217;s already been a good bit of discussion on it.</p>
<p>As far as ticking hunger on readiness&#8230; I&#8217;d like to, but I&#8217;m convinced it wouldn&#8217;t work. I&#8217;ve been pondering this one for a while now, and it would be awfully difficult to balance. I think the better solution is to add endurance and mana costs to actions that previously had none.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on hunger system ideas by Acius</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/10/hunger-system-ideas/comment-page-1/#comment-5</link>
		<dc:creator>Acius</dc:creator>
		<pubDate>Sat, 14 Mar 2009 02:37:55 +0000</pubDate>
		<guid isPermaLink="false">http://mud.simud.org/blog/?p=12#comment-5</guid>
		<description>How about treating all buffs as non-stacking, D&amp;D 3.5 style? That way, eating 1000 cherries and eating 1 cherry are the same buff, but eating a variety of foods would give you synergy naturally, because they'd buff differently.

Assign a general category of buff to each of the food groups and you're good to go.

You could also have hunger tick when *readiness* recharges, which means that just about every form of action would make you hungry. HP/MP recharges mostly only apply to combat, and there's a bunch of active ways to kill time that are light on combat.</description>
		<content:encoded><![CDATA[<p>How about treating all buffs as non-stacking, D&amp;D 3.5 style? That way, eating 1000 cherries and eating 1 cherry are the same buff, but eating a variety of foods would give you synergy naturally, because they&#8217;d buff differently.</p>
<p>Assign a general category of buff to each of the food groups and you&#8217;re good to go.</p>
<p>You could also have hunger tick when *readiness* recharges, which means that just about every form of action would make you hungry. HP/MP recharges mostly only apply to combat, and there&#8217;s a bunch of active ways to kill time that are light on combat.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on it&#8217;s aliiive by Peter Harkins</title>
		<link>http://mud.simud.org/blog/index.php/2009/03/09/its-aliiive/comment-page-1/#comment-4</link>
		<dc:creator>Peter Harkins</dc:creator>
		<pubDate>Wed, 11 Mar 2009 04:12:13 +0000</pubDate>
		<guid isPermaLink="false">http://tiffany.simud.org/blog/?p=3#comment-4</guid>
		<description>I'm going to keep paying attention and may chime in, but I'm leery of getting pulled into development. My time is very unstructured right now, and success at my business will be determined in part by how well I can stay productive. Distractions are a little scary.</description>
		<content:encoded><![CDATA[<p>I&#8217;m going to keep paying attention and may chime in, but I&#8217;m leery of getting pulled into development. My time is very unstructured right now, and success at my business will be determined in part by how well I can stay productive. Distractions are a little scary.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
