The Mudlet Crucible

Developer discussion around the system creation stack for Mudlet.
ixokai
Posts: 63
Joined: Fri Dec 25, 2009 7:43 am

The Mudlet Crucible

Post by ixokai » Thu Jan 14, 2010 6:33 am

I've been working on a personal system, but its not really designed to be a complete "system" in the general sense. Its more of a framework, to abstract common and useful needs into a library, to call and use as one sees fit.

Note, this is primarily designed for Lusternia, but there's no reason it can't be applied anywhere.

Its a meta-system, a set of tools meant to provide well-designed tools to individuals crafting their own needs and to larger systems to allow them to do things in a way which will interact with other systems in a well-defined way.

For example, queues are an important part of many systems; every system can re-invent the wheel, but then you can only ever have one in charge of 'what to do when you have equilibrium'. What if one person has a set of behaviors they want to activate when equilibrium is gained, and then adds another-- they'll step on each-other's toes.

The Crucible project is meant to be more of a foundation then a final product; or a tool for people to add things to an existing system in a well-defined way which is guaranteed to be compatible.

An example is prompts. There's countless things out there which respond to prompts, store variables, and react. I'm currently actively using three different projects which all respond to the prompt to store stuff in their own variables. That's not very ideal, its a duplication of effort and work. If a single prompt-handling system gathered everything and stored it, then raised an event-- everyone could do whatever they want when prompts happen and cooperate.

The types of tools I envision in such a system are, stat gathering (from prompt, score, and such), queue handling (any kind of balance, be it equilibrium, balance, arms, potion, etc), and a system for dynamic actions which are automated aliases which allow one to create commands for users in a way which is easier and automatically ties into the other properties that Crucible supports and tracks.

Is there any interest in others, in participating in this and doing this? If we worked on such a framework, would you be interested in using it as a dependency to your project to ease your life? Or would you prefer to roll your own?

Basically, "systems" have a lot of common requirements. Is there interest in the community in building a foundation together which handles the basic needs, which systems can build upon to provide real value?

If there's no interest, I'll still end up releasing Crucible. People can just incorporate the code they like, ignore the rest. But if there's interest, I'm interested in working with those interested parties in trying to find a best-practice solution to the common needs of system builders and casual users alike.

Thoughts?

User avatar
demonnic
Posts: 569
Joined: Sat Dec 05, 2009 3:19 pm

Re: The Mudlet Crucible

Post by demonnic » Thu Jan 14, 2010 6:36 am

I'm sure this comes as no surprise... but count me in. I'm already using the equilibrium queuer you posted a couple weeks ago... to great effect.

User avatar
Vadi
Posts: 4720
Joined: Sat Mar 14, 2009 3:13 pm

Re: The Mudlet Crucible

Post by Vadi » Thu Jan 14, 2010 1:41 pm

It would be a better implementation of: https://blueprints.launchpad.net/mudlet ... re-package

I'm in, though the only fully-Mudlet system I work parttime on is Mantis I see this being useful in certain scripts not to duplicate the prompt and etc.

User avatar
Alexander Divine
Posts: 65
Joined: Mon Dec 21, 2009 7:01 pm

Re: The Mudlet Crucible

Post by Alexander Divine » Thu Jan 14, 2010 6:49 pm

This is a fantastic idea. I did something like this back in the day on zMud, although it's much less sophisticated since all it was was a package of triggers that ensured variables were saved properly, etc. It would package full prompt-tracking, what I called a "Command-Queueing" system, and it also had a few custom functions to make pretty system echoes like: Auto-Sipper: Auto-sipping enabled. Will sip at 2476 health. The goal was to give everyone a zMud foundation they could build their system on that would also output in a manner that looks identical to IRE games, which is a must for me.

But anyway, that was a lot of rambling. I guess what I mean to say is that although I'm still learning, I'd be in.

ixokai
Posts: 63
Joined: Fri Dec 25, 2009 7:43 am

Re: The Mudlet Crucible

Post by ixokai » Fri Jan 15, 2010 3:54 am

For those interested in participating, check out: http://make.mudlet.org/2010/01/mudlet-crucible-tools/
Also, https://launchpad.net/mudlet-crucible

Let me know what your LP names are so I can add you into the project. I plan on having the tools done this weekend at the latest, and shortly after release all the code I have thus far into it, and then we can probably start planning/criticizing my implementation choices and talking about what all we think should go into such a system.

Or really, we can start talking now. Heh.

Sheia
Posts: 33
Joined: Tue Dec 01, 2009 4:40 am

Re: The Mudlet Crucible

Post by Sheia » Fri Jan 15, 2010 7:35 am

I would absolutely use this. I'll post some ideas after I think about it some more, and Lusternia isn't quite so crazy as it is now.

User avatar
Jules
Posts: 118
Joined: Sun Oct 11, 2009 5:41 pm
Location: Plymouth State University - Sophomore

Re: The Mudlet Crucible

Post by Jules » Sat Jan 16, 2010 6:13 pm

Sheia wrote:I would absolutely use this. I'll post some ideas after I think about it some more, and Lusternia isn't quite so crazy as it is now.
Mmmm... Celestian Drama: It's Not Fun...

But anyway... This is an excellent idea! Count me in! My LP name is Jules, surprise surprise lol!

ixokai
Posts: 63
Joined: Fri Dec 25, 2009 7:43 am

Re: The Mudlet Crucible

Post by ixokai » Sun Jan 17, 2010 6:30 am

Okay, in preparing to release an initial crucible code for everyone to work on, I keep going through multiple layers of refactoring. As I did, I came to a sudden conclusion: it was way too Lusternia specific. Some fundamental design decisions were Lusternia specific, and though they could be adapted without a lot of effort to other IRE games, they couldn't be well-adapted to others.

After a lot of thought, I came to the conclusion the core crucible system desperately needed to be stat-agnostic; it had to understand that stats existed, but the -specifics- of stats needed to be more abstracted.

Previously, the current health was in crucible.health; the max in crucible.max_health, same for mana, ego, etc. But different games have different sets of core values. The problem of 'balances' has bugged me some, mostly from a terminology POV but also that even among IRE games they differ.

After giving it some thought, I think we should abstract all of these details into one of two categories of data points-- pools (with a corresponding pools_max) and slots.

Crucible, alone, has "crucible.pools", "crucible.pools_max", and "crucible.slots", all of which are empty. The Lusternia module defines its pools and slots, as such:

Code: Select all

if not crucible.__stat_setup then
	do
		crucible.pools = {
			health = 0,
			mana = 0,
			ego = 0,
			power = 0,
			endurance = 0,
			willpower = 0,
			momentum = 0,
		}

		crucible.pools_max = {
			health = 1,
			mana = 1,
			ego = 1,
			power = 1,
			endurance = 1,
			willpower = 1,
			momentum = 1,
		}

		crucible.slots = {
			equilibrium = true,
			balance = true,

			left_arm = true,
			right_arm = true,
				
			superstratus = false,	
			id = false,
			substratus = false,
		}
	
		local cost_defaults = {
			mana = 0,
			ego = 0,
			endurance = 0,
			willpower = 0,
			power = 0,
		}
		
		local needs_defaults = {
			equilibrium = true,
			balance = true,

			left_arm = false,
			right_arm = false,

			id = false,
			superstratus = false,
			substratus = false,
		}

		local uses_defaults = {
			equilibrium = true,
			balance = false,

			left_arm = false,
			right_arm = false,

			id = false,
			superstratus = false,
			substratus = false,
		}

		for k, v in pairs(cost_defaults) do
			crucible.action_defaults.costs[k] = v
		end

		for k, v in pairs(needs_defaults) do
			crucible.action_defaults.needs[k] = v
		end

		for k, v in pairs(uses_defaults) do
			crucible.action_defaults.uses[k] = v
		end

	end

	crucible.__pool_slot_setup = true
end
Now you don't have to fully understand how those integrate, it'll make more sense when I show the full / real system.

But on Lusternia, it defines that we have crucible.pools.health, crucible.pools.ego, crucible.pools.power, etc. On Lusternia, we also have several slots, equilibrium, balance, left_arm, superstratus, etc. The difference between needs/uses is not important right now-- its tied to the action system which people may or may not use, as its optional.

The key detail is that the core Crucible system needs to know very little about the /real/ layout of what a game tracks stat-wise. The generic Queues don't have to know what kind of slot you queue on, as a slot is simply "the ability to do an action of some kind, which comes and goes". Queues just wait until a slot is free, and use it. Other systems (largely theoretical) can deal with pools and such without actually having hard-coded knowledge of what pools a game has. Each mud module defines it, on its own.

Does anyone object to this design?

User avatar
Vadi
Posts: 4720
Joined: Sat Mar 14, 2009 3:13 pm

Re: The Mudlet Crucible

Post by Vadi » Sun Jan 17, 2010 1:01 pm

Not a problem for me

Sheia
Posts: 33
Joined: Tue Dec 01, 2009 4:40 am

Re: The Mudlet Crucible

Post by Sheia » Mon Jan 18, 2010 2:16 am

Seems like the perfect answer to being too Lusternia specific. Looking forward to seeing the whole thing.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest