Source:GEnieLamp A2, November 1993
| This page is a verbatim reproduction of original source material and should not be edited except for maintenance. | |
| Description |
A section excerpted from the November 1993 issue GEnieLamp A2 in which Darrel Raines and Tom Zuchowski discuss Eamon for the Apple IIgs. |
|---|---|
| Source |
No source specified. Please edit this description and provide a source. |
| Date |
November 1993 |
| Author | |
| License |
It is believed that the use of this copyrighted item in Eamon Wiki qualifies as fair use under the copyright law of the United States. |
| Previous item | |
| Next item | |
IIgs gaming environment
Well... Actually, I have seen a version of Eamon converted for use in HyperCard GS. I cannot remember the author. It was the equivalent of the master disk and the beginner's cave. It also seemed to have a few problems.
And I might also add that I happen to know of one ongoing effort to create an Eamon gaming system for the IIgs. The non-interactive demo effort is essentially complete and should result in an upload within the next few weeks. The system revolves around a database system and does not require any programming skill to "write" new adventures. Therefore, all that you have to do is script the adventure rooms, monsters, treasure and other goodies. The system is a combination of color text and static (not animated) graphics. The program is also the first software (that I am aware of) to use both the 320 and 640 resolution graphics modes on the same screen! A database editor (could be a text editor) and a graphics program are all that is required to create an adventure.
It is true that this system is not a conversion of the original gaming system. However, the original Eamon series is written in Applesoft BASIC and there is no "standard" version of the game program. Each adventure uses a tailored version of the original software. I believe that Tom Z. has stated before that he did not anticipate anyone ever converting each individual game to Micol Basic GS or some equivalent. I happen to agree that the effort would be too great for the gain.
You may wonder how I know so much about the Demo that has an impending release? Well, I happen to be the author of the software in question. I have long wanted to add something significant to the public domain for the Apple IIgs. I hope that this game will be my lasting contribution.
I should add one warning: I am a bit slow about finishing something like this. Drop me a line if you get antsy about seeing the demo.
Happy gaming, Darrel Raines
[D.Raines]
(D.RAINES, CAT16, TOP8, MSG:48/M645;1)
>>>>> Darrel, I know about the Hypercard version of the Eamon Main Hall. However, as you said, it has problems, and no one has seen fit to fix them, so I don't count this as a serious "Eamon-GS" effort.
Your new gaming system sounds pretty exciting! What are you planning to call it? How similar is it to 8-bit Eamon?
You seem to have some misunderstandings about Eamon. Eamon adventure design does not require any program modification, but is database-based, just like your system. In fact, the vast majority of Eamons use unmodified programs. Where the conversion effort falls down is due to the fact that there about a dozen different incremental versions of the program, as bugs were fixed and enhancements were added. Also, most of the best Eamons do have extensive program modifications, as the authors redesigned the system to make it do what they wanted for each adventure.
If you are locking the authors out of program redesign and forcing them to do everything the way that you have envisioned, then your system will never see the rich diversity of play that Eamon has enjoyed. Indeed, virtually all of the very best Eamons were hand-built by their authors. I have always viewed Eamon's Applesoft base as a strength rather than a weakness because it has permitted ordinary people to design extraordinary adventures.
Heh. I'll be interested to see how many versions your system runs through in the next few years, before you get it the way you want it. *8-)
TomZ (T.ZUCHOWSKI, CAT16, TOP8, MSG:49/M645;1)
<<<<< TomZ - You make a number of good points. I want to make it clear that I am intending to create a gaming system that is as flexible as possible. I am also trying to stay true to the spirit of the original Eamon games. Therefore, I want the system to be text based for the most part. The graphics are meant to suppliment the text in much the same way as the last Infocom games used graphics.
>If you are locking the authors out of program redesign and forcing them to
>do everything the way that you have envisioned, then your system will
>never see the rich diversity of play that Eamon has enjoyed.
Well, again, this is not my intent. However, the problem lies in the fact that no standard programming language has been established on the Apple IIgs that lets the average home user write his/her own programs. I know that many people will disagree with this statement, but each of them will probably argue for one of a number of different "languages": HyperCard Script, HyperStudio Script, ORCA/Pascal, Micol Basic GS, etc. The arguments themselves will serve to prove my point.
This leaves me with a difficult decision to make as a software author: "How do I allow the users to create their own games without forcing them to use the source language that is not a standard?" I have been leaning toward providing a flexible system that uses flags in a database to "script" the course of the adventure. This allows the adventure creator the ability to produce a unique adventure within the predefined parameters of the adventuring system. It does not allow the creator to make unique effects that are not already available within the system. (Contrast this technique to the vampire that walks around in the dungeon of the Haunted House: a unique effect.)
>I have always viewed Eamon's Applesoft base as a strength rather than a
>weakness because it has permitted ordinary people to design extraordinary
>adventures.
I understand your point here. I don't know how to address it in light of my earlier statements. It appears that the only alternative to a strictly database approach is to release both the adventure authoring system and the source code for the main program. My current language of choice is ORCA/Pascal with some assembly language as needed. If I were to go with this approach, I would not be able to control the direction of program enhancements.
This last item is not an ego issue. I want you to think about the state of Eamon on the Apple II before you began to work toward a "clean" set of adventures. Most of the Eamon distribution houses were interested in disk copy money only. Very few took the time to make sure that the adventures ran correctly. Very few people took the time to fix problems and collect a complete set of Eamon adventures. Your efforts have gone a long way toward making the Eamon world a safe place for the novice adventure gamer. If I release the code in source format, I run the risk of incompatibility and loss of user confidence.
One alternative that I have considered is allowing programmers to update the gaming system on an individual basis. If someone wants to add a feature to the system, then I would give them the source code, and they would produce the changes. This would allow me to enforce backward compatibility and such. But this technique does not allow complete freedom for the adventure game creator. I hope that this discussion makes clear my dilemma.
In the mean time, I am sure that most people would rather see some type of demonstration and subsequent game rather than nothing at all. In light of that fact, I will continue to develop with my original design goals and will entertain changes to the design goals after people can run the demonstration.
Thank you for your feedback and ideas, Darrel Raines
[D.Raines]
(D.RAINES, CAT16, TOP8, MSG:55/M645;1)
| ||||||||||||||||||||||||||||||