Let me summarize Russell's points:
o Basing production on finite resources which must be
competed for will make earning a living too difficult.
o I am implementing far too many suggestions from players,
and design integrity is suffering.
o I am implementing far too many suggestions from players,
and the game will become too complex to be playable.
Witness the fact that the documentation is badly out of
sync with the game.
> I suspect that in such a game all
> one's efforts would have to be spent on finding enough income to stay
> alive, and what's the fun in that?
I have studied, observed and pondered the negative effects of infinite
sources, and now believe that resources must be "scarce" to make them
valuable to obtain. This is a more interesting and realistic model,
will foster healthy game conflicts, and will also provide a check on
the explosive growth that some factions have enjoyed.
Olympia has always had at least one infinite money machine; within
the last 20 turns, it's had several. There may be some horrible
unforseen consequences of turning off the money taps; I don't know,
since the game has always had them. There seem to be many reasons
to turn them off. Let's shut them off and see what happens. If there
are awful consequences, we can deal with them.
There are a lot of ways to make money in Olympia now, and there are
going to be many, many more. I find it hard to believe that players
will starve. I do expect that they will have to think a bit each turn.
o I am implementing far too many suggestions from players,
and design integrity is suffering.
This accusation really surprised me. On other projects I've been accused
of being too much of a design integrity zealot. (No killfiles in Tass!
They're an artifact of trying to read news one-dimensionally!)
> Now, if all of those are indiscriminately implemented, the system will
> become unmaintainable, and will collapse under its own weight. I have
> seen more than one software project abandoned for this reason. The
> solution to this is to have one person in charge of the project, who
> decides the direction in which the project is going to go, and who
> rejects all modifications that do not fit in with this plan.
I am acutely aware of the danger of excessive complexity, and have
witnessed and experienced the project abandonment you mention.
However, there is one person in charge of this project. I do have a
vision of where Olympia is headed, and I haven't lost control of the
code. Great amounts of my effort are directed at collapsing complexity
in the oly engine, and making the rules and game systems more uniform.
The new production code is a major feat in this direction: all production
commands will have a uniform base (though many parameters allow each
task to be customized). This is a major improvement over the previous
ad-hoc approach to production tasks.
Note also the guild changes, just begun this turn. Guilds violate Olympian
physics in several ways. Over the next several turns, I will be removing
the features of guilds which overlap other game systems, and eliminating
the inconsistencies with their design.
The view of Olympia design from rec.games.pbm may indeed be alarming.
I get a large number of suggestions through email each week as well.
But few of these ever make it to the To-do list, and fewer still ever
get implemented.
It's amusing that you think I toss in every idea which passes my desk.
The time I have to implement changes is so small compared to the effort
I'd like to put in to the game, that I completely explore each idea before
considering implementation. I often bounce ideas off of the net, or a
random group of players. Having several experienced players argue the
merits of and idea works quite well to expose any weaknesses.
o I am implementing far too many suggestions from players,
and the game will become too complex to be playable.
We've been over this before. I want Olympia to be a complex, meaty
game. Here's my philosophy again:
There is "surface" complexity, and hidden complexity. One measure of
surface complexity might be the number of commands available, and how
many arguments they take. Hidden complexity concerns how each command
may behave.
I want low surface complexity, high hidden complexity. My new production
code is a great example of this. The interfaces to the production commands
remain the same (before: WORK [days]. after: WORK [days]). But the
evaluation of these commands is now based on a detailed, meaty model.
There is another kind of complexity: the kind you get when you have
10 ship types in a wargame instead of 4. I'm going for this to a point.
Havings lots of different weapons and armor adds color to the game, even
if they all behave pretty much the same. I want lots of color and atmosphere.
Commands like POST and SET DISPLAY are real wins here, since the players love
to be creative, but they add zilcho complexity to the game.
Witness the fact that the documentation is badly out of
sync with the game.
This has a simple explanation: Writing documentation is hard work,
and I haven't had time. Documenting a moving target is also rather
frustrating, so I'm waiting for some parts of the design to settle
down a bit.
To summarize, I think you have valid concerns, ones that I share.
I wonder if I'll wake up tomorrow and say "Gak! Olympia has become
unmaintainable!" But I'm not playing this design safe -- I'm going
for greatness, which means taking risks and pushing hard. Give me
a bit more credit here. I know what I'm doing, and I'm fortunate to
have a lot of really intelligent people helping me.
-- Rich Skrenta