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.
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.