Ask the Producers and Administrators

[Nyr]

From what I know of the matter (which is less than codey people), I recall the same kind of thing as Adhira--we need more stuff to be stored in the database.

[Tiernan]

It's an old engine design, absolutely.  One which we have looked at replacing in the past. (e.g. Arm2 / JavaMUG)  That being said, it is nothing like the stock DIKU it started out as.

Just to name a few big improvements:

• That we have Javascript for our unique scripts which are like code-extensions from the base engine, is one sign of our modernization over time.
• That we have XML parsing which we can import data into the engine is another.
• That we have an SQL database which we're migrating things into is another.
• That we have online web-tools for staff builders is another.
• That we have a formal request tool for managing player issues / concerns is another.

Sure, it's always a work in progress and the coding staff take on the workload at our own pace, but the work still gets done.   We're not paid for it, if we were we'd be able to crank out a lot more features in a very short time frame.  We'd be an actual game development company then, but we'd need to make a monetary return on our investment which means Armageddon couldn't be free. 

Outsourcing source code in my experience seldom yields the results you expect.   You do get what you pay for, so if you're cheap with the budget, you get cheap code.  (Typically has to be refactored / rebuilt to the point of new development anyway).  The main point of the question really came down to "Can you break down the coding work and allow outside sources to develop it?"   My answer is that the level of oversight and code-review required to vet any outsourced code may be as intensive if not more  than in-house development. 

Of the main coding staff, each of us have our strengths that we take lead and ownership on.  The work we do, at the risk of boasting, is pretty solid.   We have applied many corporate best practices into our code development, from tools like 'git' to formal review/release cycles.  We've done that in part to help maintain the quality of the code we deliver.   While we still have an occasional crash, we've also seen amazing strides in uptime and reliability.  As much as I'd like more development staff, I'm not prepared to let it go out to the lowest bidder either.  I think we'd end up trading quality for quantity and I prefer to maintain and improve our level of quality.

[wizturbo]

Thanks Tiernan, that's a really interesting/informative post.  It's hard to tell what kind of expertise and work go into things behind the scenes.

[knight]

Hmm, that's all good solid information, thanks for sharing. Interesting to learn a little bit about Arm's tech side.

As far as what I was thinking, well... I was thinking that, if you give me the sequence of commands that need to be entered to generate a room or object or something, I could come up with a web front end. You'd input your data, modify it or whatever, and hit "go". The tool would then format the information and spit out a series of commands that would enter the data correct fields for the room/object/whatever.

Of course, I don't know anything about Arm's back end so I don't know if this an applicable idea. Please correct me if I'm wrong. This process wouldn't require any trust whatsoever, because, again, you'd just tell me the order of commands you input to create your object and I can generate a string of text that mimics those commands. You'd then just turn around and copy/paste it into your MUD client/console of choice.

Thoughts? This technique could also be used for character/NPC generation, stuff like that.

[Nyr]

We appreciate the offer, but we do prefer to do our coding in-house.  It does require trust, working relationships, and quite a bit more information than what we'd be willing to give players.  If coding type people are interested in coding solutions to help, maybe an area to look at would be things that are not on the staff end of things, but on the player end of things.  Something to help players write character descriptions/spell check them/format them, for instance.

[Tiernan]

tl;dr  "Coder stuff you probably don't care about"

When it comes to building for the game, that's where the migration into the DB really is the critical factor.   DIKU is all flat data files.  We've evolved past that but not 100%.    It's a work in progress though.   Once we do have it all stored in SQL, we'll be able to maximize our web-building toolset because they already integrate with our DB.

Like, to the point where we could employ something like Ajax to dynamically render a 'building wizard' page that adjusts as you proceed down the various variables involved in object/npc/room creation and surface up the unique values/properties for what you're building as you specify it.    That would give us the power to use some common templates/rules (such as calculate damage for weapons based on weight,  material type, etc.)  It would also let us add validation rules, so we don't have a simple toothpick weapon dealing 2d30 damage.

When folks earlier mentioned the DB, this is what they were most likely thinking about.   It's not that simple an effort to grind through our existing 'flat' schema and get it into something in SQL that we can manage.  But, we're doing it because we see the value it'll give us and the community when we get there.  As for some kind of open port to accept scripted commands for building, that's not the route  I'd prefer.   Mostly because I feel a webtool can be more efficient than someone cranking out a detailed XML file with all the pieces (they believe) identified in it.   I can't envision a reason for a 'bulk uploader' that would be used more than a web-tool building wizard.   Even as we look to port into the DB, it's more that we're bolting on an import & access component to the current engine so that once we get the data into the DB we can be sure that we'll access it properly.

[Norcal]

Whoa.  Tiernan, I understood about half of what you said, and could probably do none of it.  And I though my job was  complicated. I had no idea things were so complex and it gives me a new appreciation for things.  Thanks for doing all of that stuff you just mentioned, whatever it really is. 

[Nyr]

If coding type people are interested in coding solutions to help, maybe an area to look at would be things that are not on the staff end of things, but on the player end of things.

And I know a few players have come up with such tools in the past/recently.  We can probably do better about helping make those things accessible on our website (giving you the credit for building the tool) if you are willing to work with us on it.  This would be (somewhat) lower priority in general, but it is something that we can look at.

[Nyr]

What is the current process to change some of the world that we see each day?

There's a process.

I'll back up first here.  You are saying:

it is so easy to change the descriptions with a few words

and then

yet some of the pre-written world hasn't changed in decades

What I think you are hinting at here looks like changing things for the sake of change.  You are not giving a reason for change here, your stated issue (if there is one) seems to be that the some of the pre-written world hasn't changed in decades.  This is #1 on an informal list I wrote up several years ago entitled "Things Not To Do."

1.  Don't change things just because you can.  You are a staff member of storyteller or administrator rank, but that doesn't mean that you have a blank check to leave your mark on the world.  Think through what you are going to change.  Are you chomping at the bit to do something that players will notice?  I suggest posting pictures of yourself making silly faces on Staff Announcements.  You will get more bang for your buck.  Do you want to leave your mark on the world?  Go over rooms for typos.  It is thankless work and will never be rewarded (or at least not that much), but you will have left a lasting mark.

2.  Don't make things more complicated for the sake of making it better.  If something is simple, it is also simple to manage.  Complicated things are complicated to manage.  Things that are tough to manage often get managed poorly or not at all.  If you feel an urge to make something complicated because you feel it will make it better, reconsider.  Will it make it better?  Better for whom?  Why?  Think of the staff work involved before it, during it, and after it.  Think of the future.

3.  Don't change things and leave them undocumented.  If you change stuff and leave it undocumented, it is worse than doing nothing at all.  Now there's something out there that a few key players and staffers know about, but the rest of us are clueless.  It's cool for them, but definitely not for us, because we can't administrate something we can't see.  Picture it this way:  documentation is like the Constitution of Armageddon, and we are all Supreme Court Justices.  We can't arbitrate disagreements without our constitution.  Without our constitution, we have anarchy.

4.  Don't leave your work unfinished.  It is better not to start at all than to start and leave something unfinished.  Be realistic about your goals and your timeframes.  Every one of us has a real life, even those of us that manage to log on nearly all of the time.  Plan conservatively.  Leave ample time for review.  If calamity or a joyous occasion strikes, let everyone know, and if possible please defer your project to the person you report to.  If you are unable to tie up the loose ends and cut the project loose, that person can then be responsible for whatever must come to pass.

5.  Don't do stuff that the rest of the staff does not know about until after it has been done.  I don't refer to on-the-spot animation, but larger plots, significant documentation changes, and significantly planned animation.  Your peers are here to review.  We want to make sure that your stuff goes off without a hitch.  We want to make sure you've thought of things, or maybe be sure you aren't barking up a tree one of us has already peed on.  I don't mean for you to wait forever for approval for everything.  Important stuff really needs to be signed off or backed officially.

So to your question, the process response would first be:  'why do you want to change this?'   There must be more to a change than change for change's sake.

What questions must be answered in order to get a change implemented?

For a typo or bug, the current process to change it is "identify the problem, determine if it is a problem, then remediate."
For an idea, the current process is "is this a good idea, is this something we want to do and can do, how much work is involved in doing this, how many steps are there between what exists now and what is suggested, and do we have time to do it now?"

For bigger proposals, each of them follow a set of requirements to make it an official proposal.  These requirements use a template.  Not all of these are required, but they help in shaping all parts of a project.

PROJECT TITLE
PROJECT PURPOSES
WORLD FIT
OBJECTIVES
OUTCOMES
GROUP STRATEGY
BACKGROUND
RESOURCES
TIMETABLE AND COMPLETION DATE
SPONSOR (role: giving clear direction and support)
PROJECT LEADER (role: facilitating the team process and ensuring project and related tasks are completed on time and within constraints)
TEAM MEMBERS
METHOD (strategy to achieve objective and outcomes, how this will look in game)
ADDITIONAL INFORMATION CAN INCLUDE: NOTES, SAMPLE SCENARIOS

[Bushranger]

If I ever become a Storyteller can I use the name Mictlantecuhtli?

Thanks!

[Nyr]

If I ever become a Storyteller can I use the name Mictlantecuhtli?

Thanks!

Only if you don't mind every staffer intentionally mangling your name on a regular basis.

[Xolotl]

Only if you don't mind every staffer intentionally mangling your name on a regular basis.

It's not so bad.  

[Iiyola]

Just curious since I'm a fan of these boards: Will the GDB ever turn to a PhPbb forum?

[bcw81]

Just curious since I'm a fan of these boards: Will the GDB ever turn to a PhPbb forum?

That's disgusting, why not just suggest InvisionFree.

[Barsook]

InvisonFree isn't that bad.  Why not Discourse? 

[Iiyola]

Just curious since I'm a fan of these boards: Will the GDB ever turn to a PhPbb forum?

That's disgusting, why not just suggest InvisionFree.

Do you kiss your mother with that mouth?

[Nyr]

An actual forum upgrade is something Ness and I have talked about, but we've yet to do more than talk about it.  Are there forum options that, as a player, you feel would be excellent to have?  You could make a thread for that if you are interested. 

There are plenty of SMF mods that we could use, but we mostly don't futz around with things like that.

[Fujikoma]

Who is: the level 5 assassin?

Spooky.

[Norcal]

Things that will cost CGP if/when it gets implemented can only be applied for by special app at this time.

Adhira, why the if?  Is this not something we should be hopeful for?

[Nyr]

Things that will cost CGP if/when it gets implemented can only be applied for by special app at this time.

Adhira, why the if?  Is this not something we should be hopeful for?

ADHIRA:  Ok, bcw.
Bcw81:  Hey there, guys.  My next question has to do with the CGP system and its implementation into the actual character creation, like what you were talking about before the database loss--what was it, back about two years now?  Are we going to see that ever put into place, or are you guys comfortable keeping it in the spec-app only area?
ADHIRA:  Ok.  Well, I'll start that one.  The reason it's special app only now is because we don't have the code.  I wanted to see these extended subguilds in game.  We designed the whole CGP system around both to complement extended subguilds and with bumping up normal skills.  I would like to see that in-game, and Morgenes was working on that.  I believe he got 3/4 of the way through, but there were a few holdups.  Just this week (in fact, just today) we have been tapping Nathvaan on the shoulder and saying, "Hey...Nathvaan...is this something you might possibly be able to complete for us?"  I don't know if Nathvaan would want to do that.
Nathvaan:  Sounds good to me.  Just today got looking at it, though...so...it is in its infancy.
Bcw81:  Alright, that's cool.  It was just something that I'm sure most of the playerbase has been thinking of.  Thank you for your answers!
Nathvaan:  One thing I did do--this has been a couple months back--I did change it.  Anyone who has done an extended subguild since would have seen this.  Now when extended subguilds go in-game, the staff member approving it can set up the extended subguild prior to entering the game without requiring an Admin+ to do it in-game.  There's definitely a lot of work that will go into making the CGP stuff work as it should.
Bcw81:  That answers my question thoroughly, thank you.

That might help a bit.  It is on the list of things to get done eventually, we want it to get done, but at the same time, all beta parts of the project can be handled by staff now.  Expanding the beta to full implementation minus code means that we on staff would have to do the math and tracking every time an application was put in, and all of them would still have to be special applications.   New code to allow more extended subguilds/spec apps is not really the way we want to go right now. 

We'd rather have it implemented as suggested/announced, where (as I recall):

your karma level determines your CGP level
your CGP level regenerates after use, at a rate of one per two weeks
you can select an extended subguild without approval and it automatically deducts from your CGP
you can select a skill bump without approval and it automatically deducts from your CGP
special applications can be used for things outside of your current range (karma + 3), allowing the approver to give you 3 more "burnable" CGP to your account much like they can set a spec_app_guild/spec_app_race that is burned after use

This is all stuff we want to see implemented properly.  Nathvaan has looked at it but I also know some other stuff he is working on directly with regards to code, and those are some needed/immediate desires for other areas.

[Norcal]

Thanks!

[MeTekillot]

Idk if it's the same in Diku, but coding things that react to RL measures of time is a pain in the butt

[Zoan]

It is a pain in the butt.

[Ouroboros]

Given the recent changes I feel the need to ask...

What good stuff are you guys and gals on? And more importantly, why aren't you sharing? And even more importantly, can we supplement your good stuff stash to ensure the momentum continues?

Also, Tiernan... My heart goes out to you in the flat-file-to-SQL migration. Some parts of the DIKU code just don't wanna cooperate. Keep up the good fight though!

[Adhira]

I'm hopped up on life and that I'm going to continue living it. Also that I have a great team of people that are willing to get invested in projects that we've laid down as things that are important to us and we want to work on. It makes a huge difference when your team is all pulling in the same direction. And when stuff is getting done then I've found I'm far more receptive to adding in more stuff.