Design Notes
Where Is My Mind?
Preparing this new edition of Anacreon has been like going back in time and sitting down to collaborate with the 1988 version of me. At times we could complete each other's sentences (or at least each other's code). Many times I thought that I had improved a particular piece of code only to realize that the 1988 me had done it that way originally. Other times, I was glad that we were separated by sixteen years. I don't think the old me would have understood my insistence on using C++.
The other collaboration that made this edition possible has been the one with Adam Luker. Adam maintains the DOS Edition and his bug fixes and new game ideas inspired me tackle the Windows version. Without his efforts, it is doubtful that any of this would have been possible and I offer him my sincere thanks and look forward to all his contributions to the game.
Now for those of you who are interested (and you know who you are—you're the ones who watch all the "making of" features on your DVDs) I offer a few brief notes on the design of the game:
The War Against Entropy
The essential challenge in Anacreon is the eternal war against entropy and chaos. The more ships your empire has, the more power your empire will have. Thus the key to playing the game is to produce as many ships as possible. But the challenge is that producing more ships means creating situations (trade networks, ambrosia addiction, etc.) that are inherently defying entropy. For example, if you have two worlds, you will maximize production by designating one to be a raw material world, the other to be a base planet, and moving material from one to the other (leaving the base planet to concentrate on building ships). The disadvantage of this arrangement, of course, is that if anything happens to your trade route (if your fleets run out of fuel, for instance) you will stop producing ships altogether (and in some cases, might cause starvation).
From the point of view of game design, the trick is to keep the fight against entropy from devolving into micro-resource management. One potential for future versions is to apply the war against entropy to the military arena. For example, if there were some way ships or war machines in one sector could aid units in another sector, then there would be an opportunity for interlocking defenses. This would make an empire's star fleet more powerful than the sum of its ships, but potentially vulnerable if one piece of the network is attacked.
On Programming
One thing that I regret in the original manual is my ill-informed critique of the C programming language. At the time, I don't think I understood the difference between syntax and substance. The essence of a language is not about its syntax. Whether a language uses braces or BEGIN/END blocks is not important. What is important is the ability to express concepts and algorithms succinctly and clearly.
Pascal certainly had some advantages over C. For example, the concept of sets was very useful in the original version of Anacreon. C would have had a harder time with them than Pascal. Fortunately, C++ allows the programmer to define data structures and the operators that work on them. Thus it was fairly easy to define a set class in C++ with operators for union and intersection. That alone is a fundamental improvement over Pascal. Still, C++ has its own issues, and I'm glad that the 1988 me didn't get a chance to examine the source code to the STL.
In Future Versions...
Of course, Anacreon is far from complete. The goal of this first Windows release was to port the main game engine to a GUI environment, but you will no doubt notice that some multiplayer features were sacrificed along the way. In a future version I hope to re-write the multiplayer aspects to take advantage of the Internet. And there are always Adam Luker's innovations to add.
If you have any comments, criticisms, or bug reports, please write to me so that I can incorporate your feedback into future releases.
Write to: [email protected]
George Moromisato
Cambridge, MA
