0 registered
and 51 anonymous users online.
|
|
|
#246 - 12/03/07 12:20 PM
Re: Day-to-day, we're okay, but where are the events?
[Re: carmy]
|
Cerberus
addict
Registered: 11/28/07
Posts: 608
Loc: Arlee, MT, USA
|
Having worked on muds before, I know that making a huge change occur is no small feat. It takes weeks at least to plan and then maybe months more to implement fully any idea that's to be seen through to that stage. So I understand that these changes can be draining at the very least, and downright burdensome by the end at times.
A system in which there is a main coder and a paneled review and balance board to follow up that system would probably be beneficial to the well-being of Darke as a whole. I'm borrowing from the Development Processes of another game I play (non-mud), but something that works in these general steps has shown great success for them:
- Conception - This step is where an idea is first hashed out. A single programmer or group of programmers comes up with the system or change that they would like to see, and writes a proposal for it. The proposal is sent to whoever's in charge of these things, where it receives peer review.
- Oversight - This step is where the idea first gets traction. On a Nay the submitter is given reason why Nays were cast and suggestions on how to keep the core of the idea alive for review at another more opportune time. On Darke it would be unlikely that some ideas could ever see the light of day - for instance, cross training under the current system would be obscene - so this may need to be considered. On a Yay, a group of 3-5 programmers are formed as a design group and the same number of people are formed as a development group.
- Design & Development - In this step, the submitter adds one programmer other than themselves to the design crew. The Yay-sayers add one or more people to the design crew, and the programming begins. With this system, a questionable idea can be made possible by outweighing the two like-minded programmers with more than one programmer chosen by the Yay-sayers. A great idea can be bolstered by the Yay-sayers adding more skilled or like-minded programmers to the design crew. The development crew is just the review and tweaking process. It should include the initial submitter, as it will take dedication to maintain focus on the goal at hand; one member of the Yay-saying bunch, as if a system needs the plug pulled it's best to have someone who initially agreed to the idea to determine when it is unsalvageable; and one or more members from the user community to act as beta testers.
- Implementation - This is where the completed work is put into the wider populace. I would expect that from Conception to Implementation on a mud like this there would be a minimum of three months for any non-cosmetic change, but that's all stuff and nonsense really. This is the final phase of the system, and everyone involved should be proud of it by that point.
It's pretty clear that with the programming base we have now (questionable at best), and the player base we boast (mediocre, but sustainable), this system would take a grand effort to get off the ground with. Hiring (or allowing to volunteer? People don't get paid for their work on Darke, do they?) about 10 new wizards would do it, I imagine, with at least two admin to make up the first oversight committee would be plenty to begin.
I'm probably radically optimistic when I say that I believe we at Darke can make something specifically grand, but I really do. With a Single Mud Plan drafted, and a Development Plan in place, I don't doubt that our dedicated core players would see drastic improvements, while newer players would have fully fleshed out, reasonably set, and unquestionably enjoyable experiences greet them.
|
|
Top
|
|
|
|
|
#252 - 12/03/07 12:40 PM
Re: Day-to-day, we're okay, but where are the events?
[Re: Charon]
|
Cerberus
addict
Registered: 11/28/07
Posts: 608
Loc: Arlee, MT, USA
|
... I have a few ideas, and have collaborated with other people who have played them, on not only how to make them suck less, but to make them halfway decent!
I want to see them! Start up a new thread and map out the changes, additions, subtractions, whatever. If you do it without hard numbers, all the better (moving from 12 dev cost to 10 dev cost is irrelevant unless there's some specific number of devs you're trying to make something cost for some reason... but saying "reduce the dev cost of "skill" so as to make <whatever> more accessable in the mid-game." is useful to me, who has never played the guild you're changing. Plus it's a million times easier to defend - "10 dev cost is better because 9 would be just too easy, but 11 is still too many" is an argument that takes hard numbers to back it up, but "This skill takes too many devs to train to the level where it becomes useful, so should be reduced" is easy to understand.
I could just be whining, nosey, and dictatorial here, but in the end transparency breeds trust, and trust comforts us all.
|
|
Top
|
|
|
|
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
|
29
|
30
|
31
|
|
|
|
|
|
83 Members
33 Forums
335 Topics
2543 Posts
Max Online: 3154 @ 05/18/25 09:45 AM
|
|
|
