Review process for Arm code?

Started by gfair, April 26, 2003, 12:26:45 PM

Two things came to mind recently - the idea of the "vigorously defended modules" of certain open/free source projects like Linux and Apache, and noticing a large number of ideas for changing the game from players.

So, with those two ideas, do the Staff of Arm try to follow the same model of vigorously defending the game from change to existing parts of the game?

If so, or if we could hear what criteria the Staff require to consider a change to any part of the game, perhaps that would help people understand Arm better, and what it would take for any one idea to prompt scrutiny to the game?

That's a complicated question.

There are several loosely defined "levels" in the code of Armageddon.  We can and do change the "surface" level quite frequently (as in, pretty much every week).  This is also the level which players see the most and interact with the most directly.  This level is composed of stringing together lots of procedures in a series of (usually) not too complicated formulas.

Below that would be the procedures.  Then the code which drives each component of the procedures.  The more deeply one probes into the code, the more complicated changing it becomes.  One small change might mean fixing one thing but breaking 100 others.  The "modules" I think you're referring to would be at the root/base of the code -- something we very, very rarely attempt to change.  You might call that "vigorously defending" it, but the reality is it's simply a LOT of work, and when one begins a project like that there is no guarantee of success -- and when one compares that to the fact what we have is both stable and allows us to do most of what we want (and so far all of what we need), we would rather work on things which give us a more immediate and definite reward.  We don't have the problem of having to make our code compatible with someone else's programs in quite the same way an OS or web server does, so we have the freedom to change underlying modules -- there's just not often reason to do so.

Having said that, we are constantly throwing out ideas for making changes to the code -- on the surface (primarily as things for players to utilize), and below the surface (often more for game stability or performance in terms of hardware use; memory, disk space, booting time, etc.).  Any surface change must be approved & implemented by a Highlord or higher, and subsurface changes are approved by an Overlord, with backups in the wings in case something goes awry.

-Savak
i]May the fleas of a thousand kanks nestle in your armpit.  -DustMight[/i]

I remember posting at some point in the last few years detailing what we looked at when evaluating whether or not to code something - if someone wants to poke around in the archives for it.