Coder Transparency - Moon Edition

[Nathvaan]

It struck me that there there could be some impressions out there that adding something like 'just add echos and some different text in the weather command is simple'.  On face value, perhaps that could be the case but there is a lot more process to it than you might imagine!  

I thought, in the interest of transparency, I would detail out as best I can remember, what exactly this process looks like in its entirety.  I think it will help everyone understand that for VERY good reasons, nothing is 'just as easy as' when it comes to development.  So, here goes!

Please note, hours listed are real rough estimates and are in hours worked.  So if four people took an hour to work on something, that is 4hrs time used.

Step 1: The Idea! (unknown hours)

Voilà! We have an idea!  In this case I had heard of the idea from staffers, staff applications as well as GDB postings on a number of occasions.   I had this idea on a back-burner list of things that I would like to see as well so I decided to start moving forward with it.

Step 2: Design. (30+ hrs)

During this step there are hours of back and forth collaboration with other staffers and coders in game and on discussion boards.  It can take days or weeks to hash out all the details depending on everyone's schedules and the nature of the change.  As part of the collaboration, all the feature lists are created and a design document can be drafted, revised and re-revised.  I won't detail exactly how it was all decided to work, but all the lunar orbits, mechanics, phases, rise/set and tides were hashed out and documented.  This included documenting each and every possible state of the moons and was helpful but quite cumbersome.  The moons and their schedules were always in place (mathematically) but we needed to get those into a document. All staff had input in how they wanted the text to look in the weather command at as well.  Lastly, there is usually a time allotted to seeing if there is any other minor changes that need to be made to that part of the code while the 'hood is open''.  So at now there is a detailed design document in place!

Step 3: Code (14+ hrs)

With a design document in hand, it's time to get to the fun stuff, coding!  This really involves many, many iterative changes.  Each one of these changes require compiling and running a test version of the game.  It's time consuming but a very safe way to develop, ensuring it is impossible to affect the main game in any way.  Typically this is done by one person (me in this case).  At the end of this step, a working version of the code is in place a personal test game but it is in NO way ready for prime time!

Step 4: Test Plan. (2 hrs)

Yup, for those familiar with coding, we really do make a test plan and execute against it.  This involves going through every possible iteration of what your code can do and run tests against those test points.  In this case that means mapping out every possible stage of the moons and marking the date/time that they will be in that stage.  Then making a document that lists them and each of the expected results.

Stage 5: Test and Bug fix. (8+ hrs)

Time to run that test plan!  In this case it meant a little over 50 different states of the moons (yes some were repeated as part of the testing).  Since I wasn't about to set 50 alarms for the next 2 RL weeks (IC month) to wake up, login and look at the state of the moons, I wrote in a way to set the lunar state on boot.  This means, I had to change the states, compile and reboot.  Fifty times!  Also during this testing, the bugs were worked out (and there were a few).  Assuming it takes about 6 minutes to make the changes, compile and reboot.  There were at least 5 hrs alone of just rebooting the game in this section.

Stage 6: Peer review. (~1 week)

Holy crap, it's perfect and I love it!  My code is all done so I can boot it into the real game right?  Nope, not even close!  Now is the time for the week long cool down and code review.  Before I can even put it into the test environment or in a release candidate, it needs to be vetted by some other coders as well.  Over the next week, when they have time, they can attach to my repository and take a look at all the code changes I have made.  Then they will let me know if they think something should be done differently or maybe something done in a more efficient manner.  If there are changes to be made, I will loop us back to Step 2 and we redesign, refactor, code and retest.  Lets assume then that I get the a-okay from the other coders.

Stage 7: Merge into test (~3 days to 2 Weeks)

Now I can merge the code into the test environment and give a few days for all the staff to test the code as much or little as they like.  This is also the point where I can schedule this for a release.  Yeah, we have a release schedule and we have someone that takes on the yoke of managing that release schedule.  Typically releases can be scheduled every couple of weeks (excluding emergencies of course) but only where there is code to release, of course.  Now, all the features will be merged into a release candidate and tested all together for a time (up to 2 weeks).  This ensures that there is time to test all the changes together before they get rolled up into production code.

Stage 8: Release the hounds! (1hr)

It's time for the release!  All the hard work is over... or not quite!  The code will be merged into production, documented, put in the main game and it is compiled into the code.  The game is then issued a maintenance reboot and when it comes back up it's all done!  Except we then test once more to ensure that the changes are in place and working.

Stage 8: Finally to the fun stuff, documentation.

Yeah, no one like this stuff.  Documentation.  But this is something that we all have to do and agree, it is very important.  Some things we may have to do here could be, depending on the changes: Add item to the weekly update, issue requests to get Help File changes approved, make changes to staff only documentation, make GDB announcements, etc.

Closing:

What I would love for people to take away from this post is this:

We on staff love this game for the same reasons you as players do.  It is an amazing world with amazing RPers fueling it.  That said, I really would like everyone to have level-set expectations on why it it takes time to move things forward.  It is all approached in a slow, stable and realistic way.  

We won't 'just' make a change because it's neat.  It really does go through a strict vetting and release process, for good reason.  

This is also the case for room changes, room flag changes, object changes, NPC changes and almost every other type of change to the game.  In order to keep what we think is a high quality product that we all have come to love, it is crucial that it be approached in a methodical and professional manner.

[LauraMars]

This is really informative, and offers a lot of insight into the work involved in adding a new feature to the game.  Thanks for writing it up!

Could we sticky this post so people who are eager to see a new idea implemented can get a clear look at what the process would have to be from start to finish?

[Barsook]

Could we sticky this post so people who are eager to see a new idea implemented can get a clear look at what the process would have to be from start to finish?

I agree.

[Nyr]

That can be done. 

If anyone is interested, it probably can be adapted to show the typical work that goes into a major proposal, HRPT, or documentation revamp, to explain why we sometimes can't "just" do this. 

[Desertman]

That can be done. 

If anyone is interested, it probably can be adapted to show the typical work that goes into a major proposal, HRPT, or documentation revamp, to explain why we sometimes can't "just" do this. 

Yes plz.

[Barsook]

That can be done. 

If anyone is interested, it probably can be adapted to show the typical work that goes into a major proposal, HRPT, or documentation revamp, to explain why we sometimes can't "just" do this. 

Yes plz.

[RogueGunslinger]

It's nice to see it, and it's probably good for some to know, but I wish you didn't have to bother. It'd be a much nicer world if people didn't have to waste time explaining why they can't waste time.

[slvrmoontiger]

Staff,

Thank you for all the hard work and all the time and dedication that you put into the coding tricks you do. I suppose we don't say this nearly as often as we should. Without the dedicated staff and their time and efforts Armageddon would be nothing.

I had seriously forgotten what a deep seated pain in the butt coding really is. This post made me appreciate not only the coding but all the stuff of going from idea to actual implementation. This is really a great post to show everyone how much time things take.

Based on this, is there any possibilities that in cases where things like this come up from time to time that staff post something in the forum saying, we know you guys are looking for this and we are working on it. That would make for a lot less posts and for that matter re-posts of things already in the works.

Thank you again for all the hard work and time everyone puts into making Armageddon a complete success!

[Nathvaan]

Based on this, is there any possibilities that in cases where things like this come up from time to time that staff post something in the forum saying, we know you guys are looking for this and we are working on it. That would make for a lot less posts and for that matter re-posts of things already in the works.

Thank you for the kind words, they are always appreciated!

The reason that we typically don't post something like 'this is a work in progress' is because of the nature of an all volunteer system.  We each have a number of active and passive projects at any given time but that isn't to say we will have time to work on most, or any, in any given week.

If I were to say, "I am working on a Spacely Sprocket right now" I suspect I would get questions asking when it will be completed, perhaps just as many posts as the iterative idea posting.  I can't often commit to a time to deliver because of a combination of the process (see above) and the fact that some weeks I may have 20hrs to devote and other weeks only a couple.  The nature of it really predisposes us from giving any updates on progress because it will simply set expectations that will likely slip, turning into something akin to "How can it take 3 months to code one Spacely Sprocket!?!".    The simple answer is, it doesn't.  It would only take a couple weeks if I devoted 20hrs a week, but since I can only devote 2hrs a week to this project it will take months and months.  There also may be weeks where I can devote 30hrs to the project so it is always a fluid timeline.

Hopefully that makes some sense.  I tend to ramble!

[slvrmoontiger]

I understand, thank you for the respsonse Nathvaan.

[The7DeadlyVenomz]

Uh. That was me, saying that shit. I'm sorry.

[Nathvaan]

Uh. That was me, saying that shit. I'm sorry.

No worries at all!  I hadn't really even looked back to see who made mention of that, honestly.

It is a good thing really because it brought to light that it would be beneficial to take a little time to explain the process in the interest of transparency and help everyone understand a little more of the process.  It also helps explain what goes into creating features, fixing bugs, building objects etc.

[Sanvean]

Super post, Nathvaan. Thank you for taking the time to write that up.

[Kol]

This post has made one thing clear to me. We need to enslave more coders. Send out the raiding parties!

Seriously though, thank you for the post, it's helped me understand a lot more why some things just can't be done.

[ibusoe]

Was intending to PM the below, but it's blocked LOL

Sir,

I enjoyed reading one of your posts but I bumped into a typo.  I hate being corrected in public, so I thought I'd PM you instead.

...
Wha-la! We have an idea!  In this case I had heard of the idea from staffers, staff applications as well as GDB postings on a number of occasions.   I had this idea on a back-burner list of things that I would like to see as well so I decided to start moving forward with it.
...

Typically this is spelled Voilà from French where this roughly means "Look here!"


I don't actually care about typos, I just thought you might be curious as to the correct spelling.

Cheers!

[roobee]

So are the main reasons preventing changes to the game being either they aren't good ideas, or it takes so much time to do it (as the main post describes)? If so, is there any way the players could help with the latter? Send skeleton code or something to reduce the work the staff must do?