Source:GEnie Apple II RoundTable Bulletin Board, Eamon topic 8

This page is a verbatim reproduction of original source material and should not be edited except for maintenance.
Description	An archive of the 89 messages posted to the GEnie Apple II RoundTable Bulletin Board, category #16 ("Eamon"), topic #8 ("Wish List for GS-Specific Eamon").
Source	Content was retrieved from the text file eamon.03.txt made available by GEnie.
Date	April 1991–November 1993
Author	Various
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	Topic 7: Known Eamon Library Bugs and Fixes
Next item	Topic 9: Ambitious Eamon modifications

Topic 8: Wish List for GS-Specific Eamon

Message 1
T.ZUCHOWSKI [TomZ] — Sun Apr 21, 1991 at 10:03 EDT

OK, here's your chance to make some input into the development of Eamon for the GS. I won't be writing it myself since I don't have a GS, but I know of a couple of people who are interested in doing one. Let's give them some idea of what people want to see.

Here's a few Eamon facts and guidelines:

Each adventure is a standalone program. The only communication between an adventure and the Master is the character data that goes into the FRESH.MEAT file when an adventure is launched and into the CHARACTERS file when returning to the Main Hall. This means that the sky's the limit for the Master; as long as the character transfer protocol is retained, ANYthing is OK.

The 40-column UC text of the adventures is about 10% in the adventure's MAIN.PGM and 90% in the data files. It seems that it might be possible to add a text filter to existing adventures to perform conversion to 80-columns and lower case. I would think that capitalization would be next to impossible to manage, however.

Well, that's a start. Let's hear some opinions!

TomZ

Message 2
BRYAN.ZAK [A2U Prof] — Sun Apr 21, 1991 at 21:19 EDT

>>> T.ZUCHOWSKI [TomZ]

OK, here's your chance to make some input into the development of Eamon for the GS.

Great! This is very cool!

Is the GS version going to be a full desktop application? Or is it going to use the text screen? I think going to the desktop could be very very cool!

Each adventure is a standalone program. The only communication between an adventure and the Master is the character data that goes into the FRESH.MEAT file when an adventure is launched and into the CHARACTERS file when returning to the Main Hall

Does the same format need to be followed? I've never played Eamon, but to me, it would seem that the best way would be to have the 'main' Eamon application be the Master, and the the individual modules would be simple load files. With this method there would be no need for a Fresh.Meat file - there would be a little bit of work making a 'standard' format for the modules to communicate with the Master, but once that standard was implemented there would be no problems.

The text would work great in TextEdit controls, and before making the 'final' text, one could run it through AWGS which can automatically capitalize words that should be.

Also, if resources were used for as much as possible it would make updates much easier! Imagine, you could even have foreign language versions!!!

Tom,

I would not mind being a part of this project - I can't make any guarantees about anything since I am very busy, but I won't be busy forever! Things should start slowing down in the next 6-8 weeks or so...(is that good or bad?!?! :-)

Bryan

Message 3
R.LODOEN [Jeff] — Sun Apr 21, 1991 at 23:39 EDT

Do we get a new GRAPHICS-MAIN-HALL, too?

Message 4
L.MACKEY — Mon Apr 22, 1991 at 07:01 EDT

>>> T.ZUCHOWSKI [TomZ]

OK, here's your chance to make some input into the development of Eamon for the GS.

Sounds like a great idea to me! Used to play back in old days no my II+ have play some GS when you converted ProDos, but this would make it a lot more fun. Larry

Message 5
T.ZUCHOWSKI [TomZ] — Mon Apr 22, 1991 at 07:40 EDT

Bryan, since I don't have a GS I am not entirely sure what you are suggesting, but it sounds like a complete break with original Eamon. Or would it be fairly easy to convert existing Eamons into load files? My original thought was for a Master that could do/be anything you wanted it to be, but would still be able to run the original adventures. Skifer suggested adding a text filter to existing Eamons to convert them to 80-col. LC text on the fly. This is a great idea that could be ported over to the ProDOS Eamons too.

Hangtime suggested a Hypercard Eamon system. Does that strike anyone's fancy?

Jeff and Larry, I appreciate your words of support. Could you offer some suggestions about what YOU want a GS version to be able to do?

TomZ

Message 6
BRYAN.ZAK [A2U Prof] — Mon Apr 22, 1991 at 08:12 EDT

Do we get a new GRAPHICS-MAIN-HALL, too?

Yes, I think I may have been confused.

Tom, did you want a brand new implementation of Eamon? A full desktop (windows/menus/icons/controls, etc) implementation.

Or, just a GS specific version of the AppleSoft BASIC programs?

If it's the latter, I'm not sure what good that is? It would seem that the effort would not be worth the gain?!?

Bryan

Message 7
BRYAN.ZAK [A2U Prof] — Mon Apr 22, 1991 at 08:38 EDT

>>> T.ZUCHOWSKI [TomZ]

Bryan, since I don't have a GS I am not entirely sure what you are suggesting, but it sounds like a complete break with original Eamon.

I was, I was confused. Now that I see what you are asking, it doesn't seem to be unreasonable. One could quite easily write a full desktop implementation of the master, and then just run the adventures.

To me (only because I know didley about 8-bit programming :), the hardest part would be to launch the adventures - since they are written in BASIC, one must actually launch BASIC.System, but you have to supply it a startup pathname.

In other words, one would have to write an equivalent to BASIC.Launcher for the GS.

So, doing a 'cool' Master is not unreasonable, but I'm not sure what one would do for a text filter. I'm not familar enough with the format yet (yet, I'm download some Eamon stuff right now) to come up with any ideas. But, would it be possible to write a program that goes intelligently goes through an adventure and captilizes what should be? For text files this is easy enough to write, for BASIC files, it's not much harder, although one would have to look for print statements, or data statements that have text in them - I don't think that's unreasonable (is it?!?)

As for the intelligence portion, there could be a set of rules to follow (capitalize first words etc), BUT, more importantly, there could also be a dictionary of sorts (that could be user edited) for special case words/phrases, such as 'The Book of Real Powerful Spells', or 'DANGER!!!'. The trick in the danger example would be the use of multiple punctuation - normally the text converter would ignore a single punctuatio mark at the end of a word, but if there were multiple marks it would act as if it were part of the word.

Am I getting crazy here? I think this could be written without too much work. I know I could write the text file converter :-) (although, if I were to write it it would necessarily be 16-bit). And, I don't think the BASIC converter would be all that difficult. There should not be two programs, and ideally, the converter should be 8-bit so anyone with lowercase can use it.

My idea would be to include this converter and a default dictionary with the Master, then users can use the converter on their adventures as necessary.

Bryan

Message 8
J.ZAJKOWSKI [HyperTalker] — Mon Apr 22, 1991 at 20:01 EDT

>>> T.ZUCHOWSKI [TomZ]

Hangtime suggested a Hypercard Eamon system. Does that strike anyone's fancy?

ME!

And I could do some of the Scripting if you wanted...

I may download some Eamons to figure out HOW to get it into HC format. One plus is that HC can be modified to suit the user's taste, and can import APF Graphics and a 30K or less Text File (and I'm SURE HangTime or me could come up with a logicial way of making it even BIGGER than 30K...)

I'm for it all the way (and I would really like to work on it... (Get the idea yet?))

_________
|                  |
|     Jim       |
|_________|

Using GEM 4.1!

Message 9
D.CROSS10 — Sat Apr 27, 1991 at 22:22 EDT

About the BASIC.Launcher thing, you could use the same BAsic.Launcher. as is on the System.Disk

That is because the BASIC.Launcher gets the name of the program it is to run from a ToolBox call (I can't think of its name right now, but it is a Misc Toolset call) but doing that way wouldn't realy do anything for you because it would still run under ProDOS 8 and BASIC.System.

So the only way to fix this problem would be to come up with a converter, that read the file and analized each command and changed it into OMF format, not that tough, but I wouldn't want to do it.

Message 10
A.HATFIELD — Sun Apr 28, 1991 at 21:14 EDT

Why would the new Eamon need to be GS specific? You would be eliminating way more than half of your users I believe. Right now I am createing what I am calling 'ProEamon' which uses the full capability of a //e,c,gs? wit h the nobrainer user friendliness that Eamon lacks right now, like doing a polling of the online volumes to create a list of the adventures that the player could choose from etc.

As far as having a standard master program, that is an idea that I have in the planning stages right now, it would mainly take over the display functions of the program ie creating a standard user interface for all adventures, although the only way this might work is to have the main.pgm as a standard file, and then have the authors create an exec file that would just contain their MODS to the main.pgm, thus more stuff could fit on a 5.25"...

A lot of things can be done for Eamon without excluding a MAJOR portion of its users from the benefits of a rehaul...

Andy

Message 11
T.ZUCHOWSKI [TomZ] — Sun Apr 28, 1991 at 21:50 EDT

Andy, before you put too much work into it... there is NO WAY that you can use a "standard" MAIN.PGM in the place of the individual adventures' MAIN.PGM's. The "EXEC file" that you propose would consist of anywhere from 20% to 99% of the MAIN.PGM. How could putting together such a file be any easier than customizing the MAIN.PGM for each adventure? The difficulties in identifying all the mods would be huge. And which version would you use for the model? There are 4 major versions and maybe 50 undocumented intermediary versions.

There's a lot of merit in your idea of polling the drives and building a standard interface. However, I don't think that you realize the amount of work that you are proposing to redo just the interface, let alone make any other mods.

Have you tried out the Eamon Masters here on GEnie? How about my own Eamons? What changes would you make in the player interface that I used in my Eamons? I'd welcome suggestions on how to improve them. If I do say so myself, my Eamons have the best player interface to be seen in Eamon, but I don't have all the answers.

TomZ

Message 12
D.CROSS10 — Sun Apr 28, 1991 at 22:27 EDT

TomZ

I have been giving my other idea some thought and I have come up with a BETTER idea!

My new idea is to have a menu bar at the top with all of the commands in a commands menu, weapon status in the weapons menu, etc. and some Game specific menus defined by the games.

In other words, HyperStudio, well what do you think, and by the way I'll be happy to do the work if someone can get me the specs on how the BAS filetypes are put together (for a conversion program). Ideas, comments, rebuttals.

Message 13
T.ZUCHOWSKI [TomZ] — Sun Apr 28, 1991 at 23:08 EDT

From the feedback I get, I gather that the MAJOR thing that GS people HATE about Eamon is the upper-case text, with 40-col. running second. A text filter is what we need, guys, more than anything else. Writing the most incredible GS Eamon Master is meaningless if no one is willing to play the adventures because of the text.

What we need is a utility program that will go thru the programs and the database and convert it to lower-case text. It would need some way of identifying capitalization, too, maybe something like the AW dictionary works when you tell it to ignore a spelling. Some kind of really efficient user interface so that an adventure could be converted in just an hour or three.

I don't see any reason not to dump the upper-case stuff completely for ProDOS Eamon. It's the sheer number of man-hours required that stops me from doing the case conversion along with the ProDOS conversion. As for the II+ guys, no II+ owner in his right mind would be playing ProDOS Eamon instead of DOS 3.3 Eamon. The number of II+'s with adequate disk power (for ProDOS) would be few and far between.

TomZ

Message 14
NEBULA [Jeff B.] — Tue Apr 30, 1991 at 18:45 EDT

>>>T.ZUCHOWSKI [TomZ]

I don't see any reason not to dump the upper-case stuff completely for ProDOS Eamon. It's the sheer number of man-hours required that stops me from doing the case conversion along with the ProDOS conversion. As for the II+ guys, no II+ owner in his right mind would be playing ProDOS Eamon instead of DOS 3.3 Eamon. The number of II+'s with adequate disk power (for ProDOS) would be few and far between.

Waitaminnit!!! I'm one of the II+ guys! Isn't just one or two 5&1/4 floppy drives adequate disk power to run ProDOS Eamon? I know I used to do it with no trouble. ProDOS itself only requires _ONE_ 5&1/4 floppy drive to function. Anyway, it's not hard at all to use a hard drive with a II+, not any harder than a //e. At least I've never found it so in the time I've had mine. ANY II+ can use an Apple Rev. C, CMS, or Cirtech SCSI card and any SCSI hard drive that can be used on any other II. I like ProDOS Eamon so much better than DOS 3.3 Eamon on my II+. Why? Well, ProDOS Eamon is slightly faster, can be run from any hard drive (DOS 3.3 Eamon can't!), and I can keep several adventures (those with save commands anyway) sitting around partially completed without having several floppies sitting around partially used. I also have a better selection of ProDOS Eamons available than DOS 3.3 Eamons here on GEnie.

What you _really_ need is to convert the text in each adventure to 80 columns, mixed case. In each ProDOS adventure add a small machine language filter that intercepts BASIC's screen output, easy to do with a pr#$XXXX command, and, based on the machine's configuration, perform conversion to all upper case and word wrap on 40 column screens. I'm willing to write or help write such a beast if you like. It'll beat being shut out of playing Eamon. (It's just not worth the trouble to shut down my hard drive and reboot with DOS 3.3 just to play Eamon.)

Jeff B.

Message 15
T.ZUCHOWSKI [TomZ] — Tue Apr 30, 1991 at 22:15 EDT

Jeff B., when I said that we don't need to retain upper-case for the II+ guys, I was referring to II+ users who don't have any lower-case ability at all. IIe latecomers and GS owners take gleeful pride in sticking LC text everywhere they can, making ProDOS all but unusable for UC II+'s. Also, most of these low horespower II+'s will only have one or at most two 5.25 drives, and ProDOS is a system for idiots compared to Diversi DOS for such systems.

Obviously, my comment didn't apply to a II+ power user like you. (BTW, if you don't have 40-col. LC, it's really worth getting.)

I started out putting up both ProDOS and DOS 3.3 Eamons, but was getting a lot of complaints from people who weren't paying attention to which library they were in or to the file description and were downloading the wrong version then yelling at me because it didn't work. So I deleted the DOS 3.3 stuff and went with straight ProDOS.

The version 7 Dungeon Designer contains utilities to convert both program text and the data files to upper case "on the fly". That isn't the problem. The problem is that the adventures are ALREADY in upper-case and it would take an absurd amount of time to convert them to LC. And GS people keep telling me that they won't play Eamon because they "don't like being yelled at". That's an incomprehensible statement to me, but I keep hearing it.

TomZ

Message 16
J.ZAJKOWSKI [HyperTalker] — Tue Apr 30, 1991 at 22:33 EDT

>>> D.CROSS10

In other words, HyperStudio,

Um, to have menuBars in HyperStudio would mean Xcmd time or HUNDREDS of Cards.

Whereas, HyperCARD IIgs has the AddMenu Xcfn, DeleteMenu XCMD, disableMenu Xcmd, and the enablemenu xcmd.

And one could stick a "on doMenu" handler somewhere.

Why don't some of us work on a .Sys16 GS Eamon and a HyperCard Eamon. Maybe, with luck, we could have them be interchangeable.

_________
|                  |
|     Jim       |
|_________|

Using GEM 4.1!

Message 17
T.ZUCHOWSKI [TomZ] — Tue Apr 30, 1991 at 23:15 EDT

While kicking the problem around with Flyin' Bryan in the RTC tonight, I think that I now understand how to write a utility to convert existing Eamons into 80-col. lower case text.

Stay tuned...

TomZ

Message 18
T.ZUCHOWSKI [TomZ] — Wed May 01, 1991 at 21:00 EDT

WANTED: a couple of Beta testers for the rollout of the shiny new LOWER CASE text version of my own Eamon.124 "Assault on Dolni Keep". If you are interested in checking this out, I can sure use some outside opinions. I'll have to Xmodem E-mail it to you since I don't want to make it available generally until I am sure I have got the formula right.

Basically, I am doing conversions into 80-col.-only LC-only text. All the text has been converted except for artifact names, monster names, and commands. All user input must still be in Upper Case.

Please let me know if you can critique this for me. Thanks.

TomZ

Message 19
D.CROSS10 — Thu May 02, 1991 at 21:25 EDT

Yo, TomZ, right here, I'll rest it for you (and also fix any bugs I come across, I'm really good at that <Grin>). Also in that thing for UC and 80 columns, there was a program (Magic.Menu) on the old AppleSoft Sampler disk that came with my very old IIe, that is perfect for converting lLC-UC and even has word wrap dependant on if it is run on 80 or 40 cols. (It even tells you what computer it is run on (sort of (no IIgs setting))

I'll check the CopyRight to see if I can email it to you.

Message 20
BRYAN.ZAK [A2U Prof] — Thu May 02, 1991 at 22:02 EDT

>>> T.ZUCHOWSKI [TomZ]

WANTED: a couple of Beta testers for the rollout...

I'd be happy to check it out, but I would only be able to spend a few (30- 40) minutes on it...

Bryan

Message 21
NEBULA [Jeff B.] — Fri May 03, 1991 at 18:26 EDT

>>> T.ZUCHOWSKI [TomZ]

Obviously, my comment didn't apply to a II+ power user like you.

Sorry if I sounded upset about that. I'd meant to put in a smiley or two into my message. ;-) I do have 40 column LC on my II+; I've had it since there was such a thing. I have one of those fun piggyback boards that plugs into where the character generator ROM used to be. It seems to me that 40 col UC II+ non-power users shouldn't be locked out of something as neat as Eamon, though. It ought to be fairly easy to convert 40 col UC Eamons to 80 col LC. I wrote a program for doing something like that once. Followed a whole bunch of rules on what should and shouldn't be UC. Worked okay as long as someone was around to baby sit. I think Eamon should determine the type of computer and screen and reformat its output accordingly. It's really not that hard to do. Let me take a look at what would be involved in writing a program to read in Eamon's room descriptions, etc. and converting them to 80 col LC. Would you be interested in such a thing if I can do it in a reasonable amount of time (say 4-6 weeks, maybe sooner)?

I'm also interested in taking a crack at beta testing your new 80 column LC adventure. I have a ][+ with a Videx 80 column card.

Jeff

Message 22
D.CROSS10 — Fri May 03, 1991 at 20:03 EDT

Hello?

Did you by any chance read my previous message? THERE IS ALREADY A PROGRAM THAT DOES THAT!!!!!

Its name is Magic.Menu and it is on the old AppleSoft Sampler disk. It has routines in it that determine the computer type and whether it has 40 or 80 columns and based on that it computes the word wrap and converts LC to UC if necessary. <<<David>>>

Message 23
T.ZUCHOWSKI [TomZ] — Fri May 03, 1991 at 21:37 EDT

David, I'd be scared to death to "borrow" a routine that came on an Apple disk. Corp. Apple has no sense of humor at all. At any rate, any such routine would have to plug into the standard print statement somehow so that I don't have to hand-code several hundred GOSUBS or CALLs into each program. And any such routine would just about HAVE to go in the page 3 space; there is literally no place else to put it.

Jeff, please understand that the 40-col UC DOS 3.3 Eamons are WIDELY available. I can't conceive of anyone with a 40-col UC II+ willingly using ProDOS over DOS 3.3. I know that *I* couldn't STAND the aggravations and hated ProDOS right up to the day that I got my IIe. If you are concerned, I can give you the names and addresses of about 10 mail-order public-domain houses that sell all 206 DOS 3.3 Eamons.

In short, I envision a parallel path here. Full support for the DOS 3.3 versions will continue (I have already converted two ProDOS Eamons to DOS 3.3 in the past year). And I intend to to the full 80-col conversion on about 100 of the better Eamons. I can't see bothering to convert the poor ones.

Bryan, Jeff, thanks for the testing offer. Early returns have indicated some dissatisfaction with the 80-col. formatting that I intend to address real soon. When I get it done, I'll email you a copy.

TomZ

Message 24
MICOL.SYSTEM [Ron L] — Sun May 05, 1991 at 11:45 EDT

I have a 40 col upper case only II+, and I ONLY use ProDOS with it. Just because you can't stand DOS 3.3, don't assume everybody else can't.

Message 25
T.ZUCHOWSKI [TomZ] — Sun May 05, 1991 at 13:41 EDT

>MICOL.SYSTEM

I have a 40 col upper case only II+, and I ONLY use ProDOS...

Well, Ron, is that II+ the ONLY Apple computer that you have? If it is not the only one that you have, would you say that you do more than 50% of your computing on the II+? How do you accommodate lower case file names, programming, and text on your II+? I'd bet that at LEAST 75% of all public- domain ProDOS stuff uses lower-case text in one manner or another. And you actually PREFER that? How many drives do you have on the II+?

You completely missed the point of my post.

My point was that, for the "small" II+ system with only 40-col. UC text and one or two 5.25 drives, Diversi-DOS is a demonstrably superior system to use. OK, you don't agree with that. But I think that you have have no idea what it is like for that II+ to be your ONLY computer in a land of IIe's, c's, and GS's. And anyone who has a II+ as their ONLY Apple computer and LIKES ProDOS over DiversiDOS is almost certainly going to have 80-col. text or at least a 40-col LC chip.

As a matter of fact, I think that ProDOS is extremely nifty on my 128K enhanced IIe with 2 5.25's and one 3.5 drive, and I never use DOS 3.3 any more except when working on the DOS 3.3 Eamon library. But when I only had the II+ I found ProDOS to be all but unusable because of all the LC text everywhere. If you have a workaround for this that I can pass on to my membership, I'd be glad to learn of it.

The feedback from my Public-Domain outlets is that DOS 3.3 is very much alive and well. One tells me that he ships "thousands" of DOS 3.3 Eamon disks every month. This outlet doesn't carry ANY ProDOS stuff at all.

Tell me, if you had a choice between playing a 40-col UC Eamon on your II+ or playing an 80-col LC Eamon on one of your other computers, which would you pick. You know, I can't win. All I get from latecomer IIe and GS people is that they won't play Eamon because of the text. And then when I decide to pursue a two-track Eamon philosophy that gives the GSers what they want but still makes 40-col UC Eamon available, I get nailed by II+ people who think that I should be able to do it all in one program. Well, IT CAN'T BE DONE for any reasonable amount of effort. If you don't believe me, do the conversions yourself. Be sure to start out with one of the Eamons that completely fills a 5.25 disk and runs with 1K of free memory.

Meanwhile, there WILL be 206 UC DOS 3.3 Eamons, 90-odd UC ProDOS Eamons, and probably 100 mixed text 80-col Eamons. Get the kind that suits you and quit worrying that a 11-year-old public-domain system isn't as sophisticated as Shrinkit 3.23. I am no Andy Nicholas, and I draw the line at 10 hours to convert a single DOS 3.3 Eamon into 80-col ProDOS. I refuse to do a line-by- line rewrite, and that's all there is to it.

TomZ (below ground)

Message 26
—

Message 27
T.ZUCHOWSKI [TomZ] — Sun May 05, 1991 at 14:49 EDT

As I see it, here is a reasonable breakdown of different types of Apple II's, listed in order of highest numbers of users:

ProDOS:                              DOS 3.3:
 IIe/IIc with 40/80 col UC/LC         II/II+ with 40-col UC
 IIgs                                 II/II+ with 40-col UC/LC
 IIe with 40 col UC/LC                II/II+ with 40-col UC/80 col LC
 II/II+ with 40 col UC/80 col LC      IIe with 40-col UC/LC
 II/II+ with 40 col UC/LC             IIe/IIc with 40/80 col UC/LC
 II/II+ with 40 col UC                IIgs

And the IIc+ or other II that has no 5.25 drive and can only use ProDOS. This group won't include any members with UC-only Apples.

Of course, there will be individual exceptions to this like Ron and Jeff, and I know some IIe/IIc users who NEVER use ProDOS, but on the whole I don't see a lot of overlap between the machines used by ProDOS users and DOS 3.3 users. In that middle area of the lists I expect that the decision will be largely made on the basis of what disk drives they have, and I would bet that the vast majority of these people are comfortable with both systems. I am pretty happy with the 2-track Eamon idea because of this lack of overlap.

And let's not forget that the 40-col UC ProDOS Eamons will still be available, even if I have to go into business and sell 'em myself! *8-)

If it was up to me, I'd upload all three kinds to GEnie, but there are good reasons for not doing so.

TomZ

Message 28
T.ZUCHOWSKI [TomZ] — Sun May 05, 1991 at 15:03 EDT

>MICOL.SYSTEM

Ron, just out of curiosity, what in the world do you use your 40-col. UC II+ for that you actually prefer using ProDOS on it? I'll bet that you use DARNED little public-domain software on it! But if you do, tell me, how do you access a file that has LC text in the filename? A kid with a 1-drive II+ that he picked up for $35 as his first computer might have some difficulties with it.

TomZ

Message 29
NEBULA [Jeff B.] — Mon May 06, 1991 at 20:10 EDT

>>>T.ZUCHOWSKI [TomZ]

But if you do, tell me, how do access a file that has LC text in the filename?

Easy. ProDOS filenames NEVER have LC in the file name. Any LC you see in a ProDOS filename is FAKED using a bit map of which characters should or shouldn't be displayed as LC. This is how AppleWorks files and the GS/OS ProDOS FST both do it. The actual filename is always stored as UC and any filenames passed to ProDOS are converted to UC before being used. The Aux File Type bytes hold the bit map for AppleWorks files and the directory entry fields that used to be used for ProDOS version numbers (I think) are used for GS/OS' ProDOS FST. This keeps the file system compatible across all hardware platforms and different operating systems (ProDOS, ProDOS 16 and GS/OS).

DOS 3.3 did allow LC in file names and take it from a ][+ user: they're a real pain.

Jeff B.

Message 30
MICOL.SYSTEM [Ron L] — Fri May 10, 1991 at 20:52 EDT

what in the world do you use your 40-col UC II+ for

Well, today it runs a Proline BBS. I used to use it for all types of computing and telecommunication (Ascii Express, etc). I had an 80col card which I used with Plusworks to get Appleworks running on the II+. I found plenty of use for ProDOS based applications.

how do you access a file that has LC text in the filename?

ProDOS is NOT a case sensitive operating system.

Message 31
J.IMIG [Bit Picker] — Fri Aug 16, 1991 at 08:57 EDT

To all,

I've just scanned the messages here, but not read. them... But, I didnt see the HyperCard version mentioned. Has anyone looked at that ?

Back later....

Message 32
B.KIMBALL — Sat Nov 09, 1991 at 15:36 EST

Here's my vote for an IBM version of Eamon. I hope that doesn't sound like blasphemy. :) I had an Apple ][+ until it fried out of old age a couple of years ago. :( Eamon was one of the funnest games I have ever played, but I can't play it anymore. I never could get out of that cell in the beginning of one of the games though. (I can't remember what the name of it was) I would write the IBM version of Eamon, but I can't remember exactly how Eamon looked and played. So if anyone wants to give me some refresher info it would be great...

Thanks,
Ben Kimball [Kzinti] (I forgot to set my name) :)

Message 33
T.ZUCHOWSKI [TomZ] — Sun Nov 10, 1991 at 17:39 EST

Ben, IBM-Eamon exists already. John Nelson has done full conversions of all of his Eamons and wrote the tools for designing and editing IBM Eamons. It's all in QuickBasic, I believe. You can contact him at:

National Eamon User's Club
PO Box 30087
Des Moines, IA 50310

Note that this is an IBM-Eamon club. TomZ

Message 34
B.KIMBALL — Thu Nov 28, 1991 at 16:41 EST

Urrg, I was just there YESTERDAY!!! I should have checked back before now. I could have gotten a hold of him. Oh, well, I'll write to him, Thanks a lot anyway!! Now I can play again. (Really?!) :) :) :)

Message 35
J.MILLS11 [John_M] — Fri Mar 12, 1993 at 20:44 EST

About a GS-specific version...

• HyperCard -- this would be OK, but it requires you to HAVE HyperCard just to use the stack.
• HyperStudio -- this is like HyperCard, but it has a run-time module for stacks created by it.
• Desktop app -- would be the best (for me) esp. if the existing adventures were compiled into OMF load modules. Or better yet, small separate apps that are ran from the Main Desktop Eamon -- Main quits and passes execution to the adventure app. which passes execution BACK to Main when it's done.

Remember, if you're looking at a GS-specific version, you may as well take advantage of all GS extensions.

Message 36
A2.DEAN [A2 Leader] — Sat Mar 13, 1993 at 19:58 EST

One would think that Micol Advanced Basic GS would be the ideal environment to port Eamon to the IIgs environment. Moving to any of those other environments would be such a fundamental change that you'd probably be just as well off designing a whole new system. MAB is at least close to Applesoft and would allow you to preserve most of the games exactly as they were originally written.

Besides, Hypercard & HyperStudio's languages are much too slow, and a full- blown desktop application would make things way too tough for most people to write (who's going to program Eamon games in Orca/C or whatever?).

Dean Esmay

Message 37
J.MILLS11 [John_M] — Sat Mar 13, 1993 at 22:02 EST

Hi Dean! :)

Yea, but if the Main Hall was a Desktop app, it could be used as a shell for the modules. Compile the mods any way you want and treat 'em as generic load files (or simple shell exes).

Message 38
D.MILLER132 [m530 daily!] — Sun Mar 14, 1993 at 08:15 EST

>>> J.MILLS11 [John_M]

Yea, but if the Main Hall was a Desktop app, it could be used as a shell for the modules. Compile the mods any way you want and treat 'em as generic load files (or simple shell exes).

I may be mistaken, but isn't MAB a desktop language? I think you _can_ do that kind of stuff with MAB. It's basically 16-bit AppleSoft with a Toolbox interface as far as I know...
_
|_)ave |\/|iller

Message 39
SOFTDISK.INC [Zak] — Sun Mar 14, 1993 at 15:34 EST

I wouldn't even think about using MAB--it's just too darn quirky and limited. if only Micol had followed Apple's and Byte Works' lead and done things in a standard way, things would be cool.

I'd go with ORCA/Pascal for this. Pascal is enough like english that there wouldn't be that much trouble porting it from BASIC.

Bryan

Message 40
J.MILLS11 [John_M] — Mon Mar 15, 1993 at 20:54 EST

What about using Byteworks' Integer Basic compiler (is anyone working on an Applesoft Basic compiler which makes standard OFM modules)? John_M ----------

Message 41
PROPTOSIS [Eyeballs] — Sat Mar 20, 1993 at 11:48 EST

How about two sound librarys? A simple one for those without disk space, and a deluxe sound library for those with sufficient disk space? If all programs were to share a standard sound library, then each new adventure wouldn't have to ship with an extensive set of sounds. Only new and unique sounds would be packed with each new adventure.

Message 42
LUNATIC — Sun Apr 11, 1993 at 10:00 EDT

           _____
        /"  "  "\         _         _   ___   _          _   __    __   {{!}}
      /- - - - - -\      {{!}}_   /\   (_    {{!}}   {{!}}_  {{!}})     {{!}}_  /     /     {{!}}
     /^ ^ ^ ^ ^ ^ ^\     {{!}}_  /--\  __)   {{!}}   {{!}}_  {{!}}\     {{!}}_  \__{{!}}  \__{{!}}  o
    {{!}} ' ' ' ' ' ' ' {{!}}
   /  /  /  {{!}}  \  \  \
  {{!}}==================={{!}}
  {{!}}> <> <> <> <> <> <>{{!}}                 Remember this spot!
  {{!}}==================={{!}}
   \  \  \  {{!}}  /  /  /
     \  . . . . .  /
       - _______ -

Message 43
KEN.GAGNE — Tue Oct 05, 1993 at 20:54 EDT

So, was Eamon ever converted to the GS, or will it be?

Message 44
S.HEWES — Tue Oct 05, 1993 at 23:50 EDT

It has been a long time since I played an Eamon game. Has there ever been any of them that use graphics or are they all just text?

Steve Hewes

Message 45
T.ZUCHOWSKI [TomZ] — Tue Oct 12, 1993 at 10:33 EDT

>>>KEN.GAGNE

Ken, if you are asking if anyone has converted Eamon over to a different language than Applesoft so that it can be run under GSOS, the answer is no, no one has converted Eamon to the GS. I'm not aware of anyone who is working on such a conversion. In fact, the lion's share of Eamon activity remains in DOS 3.3, where it has always been. Go figure. *8-)

However, there are over 100 ProDOS Eamons in the A2 library that work fine from GS hard drives. About 40 of them have been fully converted to 80-column lower-case text.

>>>S.HEWES

Steve, the only Eamon that ever used graphics was one done by Little Green Software. It was a commercial product that never did well. I've seen pirated copies of it floating around. I spent some effort trying to track down Little Green to get permission to put it in the public domain, and was unable to find a good address.

Anyway, a public-domain graphics Eamon designing system wouldn't work. Hi- res is just too crude, and it takes a LOT of talent to design an attractive, good-playing graphics-based adventure game. People who have such talent are already doing such things in commercial products.

Both of you might want to take a look at Softdisk's Adventure Machine. SAM is a graphics-based GS adventure designing system that is very cool.

TomZ

Message 46
EDITOR.A2 [Doug Cuff] — Tue Oct 12, 1993 at 18:12 EDT

Both of you might want to take a look at Softdisk's Adventure Machine. SAM is a graphics-based GS adventure designing system that is very cool.

I'll break trail to Category 34 (Softdisk) if anyone cares to follow....

Doug Cuff
Editor, GEnieLamp A2

Message 47
SOFTDISK.INC [Bryan Zak] — Wed Oct 13, 1993 at 10:25 EDT

Yep,

Jay has a LOT of plans for the next incarnation of SAM (Softdisk Adventure Machine) and I'm sure he'd love to hear everyone's ideas!

(Plus we are currently running a contest for the best SAM adventure created using Skypter (the thingy used to create adventures). The contest pays real money! :)

- Bryan Pietrzak
Softdisk Publishing

Message 48
D.RAINES — Fri Oct 15, 1993 at 02:15 EDT

... no one has converted Eamon to the GS. I'm not aware of anyone who is >working on such a conversion. In fact, the lion's share of Eamon activity >remains in DOS 3.3, where it has always been. Go figure. *8-)

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]

Message 49
T.ZUCHOWSKI [TomZ] — Fri Oct 15, 1993 at 08:29 EDT

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

Message 50
J.KOHN [Joe] — Fri Oct 15, 1993 at 13:44 EDT

Despite the slowness of the HyperCard version of Eamon, I liked it a lot!

Joe Kohn

Message 51
D.BROWN109 [Dan] — Sun Oct 17, 1993 at 17:19 EDT

>>> T.ZUCHOWSKI [TomZ]

I just picked up a GS-specific adventure game authoring system off the Internet, and it seems like it would be able to handle any of the Eamons. It is, however, entirely text-based, and it requires some kind of shell (ORCA or GNO). I could upload it if you're interested.

--> Dan <via GEM 4.21 / PT3.1>

Message 52
T.ZUCHOWSKI [TomZ] — Mon Oct 18, 1993 at 08:43 EDT

>>>D.BROWN109

Dan, what makes you suspect that that GS gaming system can "handle any of the Eamons"? Does it say so in the description? If so, what does it claim to be able to do? What Eamon versions can it handle? There were four major database revisions over the years.

Don't be fooled by the fact that Eamon is "merely 8-bit". The database is quite complex. For example, envision an artifact that is a door that is hidden in a room that can only be opened if you have another artifact that is the key that is inside yet another artifact in a different room and that container is in the possesion of a monster in that room.

I'm a bit confused as to what advantage there would be in running an Applesoft program from within some kind of shell. If it can only handle the data, then it is largely useless for most of the best Eamons, which incorporate programming modifications. Even so, it's a pretty major accomplishment to be capable of handling the data.

If it's a system that uses the same database conventions as Eamon, then that might be a pretty cool thing to have.

TomZ

Message 53
EDITOR.A2 [Doug Cuff] — Mon Oct 18, 1993 at 09:12 EDT

>>> D.BROWN109 [Dan]

I could upload it if you're interested.

Oh yeah.

Colour me interested.

Doug Cuff Editor, GEnieLamp A2

Message 54
EDITOR.A2 [Doug Cuff] — Mon Oct 18, 1993 at 17:34 EDT

The ADVSYS system that Dan Crutcher spoke of looks really cool, so it just kills me that one can't run it without GNO/ME or the Orca shell

I tried it under ProSel-16's shell mode -- while the game compiler would work, the game interpreter wouldn't.

This just kills me -- I thought I'd a found a tool that'd allow me to distribute games widely. Oh well.

Looking at this system, however, I can't for the life of me see how it would handle Eamon adventures without serious re-coding. It's been a while since I looked at Eamon however (never seen a ProDOS one!), so maybe I shouldn't say that.

Doug Cuff
Editor, GEnieLamp A2

Message 55
D.RAINES — Tue Oct 19, 1993 at 02:03 EDT

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]

Message 56
D.RAINES — Tue Oct 19, 1993 at 02:04 EDT

I could upload it if you're interested.

Okay, I will bite. We are interested. Go ahead and upload the software.

Darrel Raines
[D.Raines]

Message 57
D.BROWN109 [Dan] — Thu Oct 21, 1993 at 00:38 EDT

>>> T.ZUCHOWSKI [TomZ]

Dan, what makes you suspect that that GS gaming system can "handle any of the Eamons"?

Um... I phrased that poorly. Based on a brief overview of the GS system, and a not-so-brief overview of Eamon, any of the Eamons could be rewritten to operate under AdvSys without any loss of features. This system offers the capability to add commands and define their effects, as well as rooms, artifacts, NPCs, and so forth. IOW, it's pretty flexible, and any of the Eamons could be replicated under it. It's also compiled, which speeds up game play greatly and reduces the chance to cheat by listing the relevant files.

--> Dan <via GEM 4.21 / PT3.1>

Message 58
D.BROWN109 [Dan] — Thu Oct 21, 1993 at 00:38 EDT

>>> EDITOR.A2 [Doug Cuff]

The ADVSYS system that Dan Crutcher spoke of looks really cool, so it just kills me that one can't run it without GNO/ME or the Orca shell

It's possible, I guess, that it could run under the ECP-16 shell, though I haven't tried it. It looks like you have it, so you don't need me to upload it, right?

--> Dan <via GEM 4.21 / PT3.1>

Message 59
EDITOR.A2 [Doug Cuff] — Thu Oct 21, 1993 at 18:10 EDT

>>> D.BROWN109 [Dan]

It looks like you have it, so you don't need me to upload it, right?

You could always upload it for others... <grin> I don't see getting time to do it myself before the beginning of next month.

Doug Cuff Editor, GEnieLamp A2

Message 60
D.RAINES — Tue Oct 26, 1993 at 02:02 EDT

All (and especially TomZ) --

It's done! I have completed the concept demo that I was working on for Eamon IIgs (my designation). This program is not so much a working demonstration as it is a "look and feel" presentation. I think that you will be able to see where I am going with the concept.

The file should be available soon in the A2 library. Please give me feedback about the demo. I am really interested in how many people want to see this software finished. E-mail is preferred, and I would also like to see some discussion here as a public forum.

Thanks, Darrel Raines
[D.Raines]

Message 61
EDITOR.A2 [Doug Cuff] — Tue Oct 26, 1993 at 17:49 EDT

>>> D.RAINES

The file should be available soon in the A2 library.

<waiting, pretending to be doing it patiently>  :)

Doug Cuff Editor, GEnieLamp A2

Message 62
D.BROWN109 [Dan] — Tue Oct 26, 1993 at 23:30 EDT

>>> EDITOR.A2 [Doug Cuff]

You could always upload it for others... <grin>

Done.

--> Dan <via GEM 4.21 / PT3.1>

Message 63
EDITOR.A2 [Doug Cuff] — Thu Oct 28, 1993 at 09:21 EDT

>>> D.BROWN109 [Dan]

You could always upload it for others... <grin>

Done.

So I noticed. An official GEnieLamp thank-you, Dan. If I tried to find time to upload it, there ain't no way I'd get this month's 'Lamp finished on time.

Doug Cuff Editor, GEnieLamp A2

Message 64
EDITOR.A2 [Doug Cuff] — Thu Oct 28, 1993 at 21:25 EDT

I've downloaded the Eamon GS "concept demo", and while I found it attractive, I find it difficult to comment on, since it doesn't have any functionality at this point.

Very very minor point -- the double title screen is a very nice touch, but there's not really enough time for the first version to register. Pause just a little more (and, of course, allow the user to end the pause with a keypress)?

The demo graphics are most impressive, even if borrowed from other sources.

If only we could count on artwork that finished all the time, eh?

The use of "textscreen" characters really appeals to me for some reason. One thing I'd worry about is whether players could choose what colours they want -- green on black, while deucedly attractive, might drive you blind after several hours of play. <grin>

I don't quite understand what the two squares at the top of the screen are supposed to represent, incidentally, but then, I don't play many RPGs.

It all looks very nice at this stage... what more can I say? What do other people think?

Doug Cuff Editor, GEnieLamp A2

P.S. I've always wanted to know -- "EEmon" or "AYmon"?

Message 65
D.RAINES — Thu Oct 28, 1993 at 22:53 EDT

>>> All

It's here, it's here! The concept demo that I have been telling you about has finally arrived in the libraries:

21574     EAMON2.GS.BXY  Concept Demo for Eamon IIgs
                   X    D.RAINES  Oct 26 93 42112

I would like any comments that you may have on this demo. I know that it does not show a lot of playability but it indicates what I have in mind for the final product look-and-feel. E-mail is preferred for all comments with a post here for further group discussion. Thank you in advance for trying out this short demo and giving me your feedback.

Darrel Raines
[D.Raines]

Message 66
KEN.GAGNE — Fri Oct 29, 1993 at 18:06 EDT

EEmon, of course!

Message 67
C.HARTLEY3 [Charlie] — Fri Oct 29, 1993 at 18:54 EDT

What Doug said.

Will your screen stay static ... that is, always graphics at the top, text beneath? Might want to vary it; say, half screen, left and right or each, or graphics expanding or contracting ... probably a bit much!

Also, you might want full-screen graphics with inserted text windows.

Just a thought ... I wonder how something like this would work with HyperStudio and the new logo programming?

Charlie

Message 68
T.ZUCHOWSKI [TomZ] — Sun Oct 31, 1993 at 09:48 EST

>>>D.RAINES

Darrell, I got a look at your "Eamon GS" demo at the UG meeting yesterday. I have to admit that it has a very nice look, though I do agree with an earlier comment that screen color selection would be a very nice feature.

Your demo didn't begin to give me a feel for what your adventure system will be capable of. Picking out a few nice graphics from your collection and then making up some purple prose to explain the pictures looked =really= pretty, but is otherwise useless as a demo.

What I want to know is: what data types will you support? What commands? What player-character capabilites and stats? What database interactions? What player-character encumbrance system? How will you present things like inventories, special events, weapon readiness, armor damage, containers, spells, ability development? What will be the preferred method(s) for developing and adding the graphics? How will timed and event-driven special events be handled? What combat situations? Will you permit hidden stuff that must be ferreted out? How? What varieties of short and verbose text presentation will you support? The demo tells me none of this.

What I want to see is a small adventure that was actually constructed from the Eamon GS developer tools and actually follows the protocols and structures that you have designed into your system. I want to be able to look over the author's manual. Having written the version 7.0 Eamon system, I know that getting the development toolkit right is a huge part of the undertaking, and toolkit testing and development will shape the final adventure capabilities as much as your original blueprint will.

Have you played Sam Ruby's "Storm Breaker" Eamon adventure? I consider the capabilites of this Eamon to be pretty close to the baseline capabilities that you should consider supporting.

You have said repeatedly that you aren't making any claims about this demo and you are merely looking for commentary on the "look and feel". OK. It's pretty, but it's presently just a short story. You didn't show me how actual play will look and feel.

I'm particularly concerned about the sparseness of character info on the screen. How did you plan to expand on that?

If the main purpose of generating a GS-only adventuring system is so that we can have small graphics a'la Wizardry, then I don't see what all the shouting has been about.

TomZ

Message 69
D.RAINES — Tue Nov 02, 1993 at 03:55 EST

>>> T.ZUCHOWSKI [TomZ] , et. al.

I read everyone's response so far. Thank you for posting here. I am very busy the last few days but will respond to your questions within the next few days. Please bear with me. I am stretched pretty thin right now.

Look for more soon, Darrel Raines
[D.Raines]

Message 70
D.RAINES — Wed Nov 03, 1993 at 00:27 EST

> EDITOR.A2 [Doug Cuff]

Thanks for your kind words. I will take your suggestion to heart on the title screen. That double-scroll idea is one of my favorite graphic tricks to date. By the way, I never claim to be an artist! In fact the closing screen asks for a collaborating artist. I know my limitations.

I had always planned on the text screen colors being adjustable. That just is not in the demo yet. The double square insignia in the top window is simply an indication that I can put text OR graphics in the windows. This feature could be used to draw graphs of the players health instead of using a word phrase.

> C.HARTLEY3 [Charlie]

Thank you for your comments. I intend for the screen window sizes to stay the same. I did quite a bit of planning to make sure that I maximized usage of the screen. On a IIgs computer, it is possible to plan for each horizantal scan line since there are "only" 200 of them.

I have my reasons for the display being broken down that way that it is. I wanted to have the following elements on each screen: 1) an optional graphic image, 2) a status area with a player's stat.'s shown at all times, 3) a one-line description of the "room" that the player is currently in, and 4) an area for text to describe the room in detail, actions by the player and actions by any "monsters".

By the way, HyperStudio or Logo would certainly work as a tool to write Eamon GS. However, I am bent on using ORCA/Pascal with some Assembly language, as needed. Since I am th one doing the code, I get to choose the tools.  :)

> T.ZUCHOWSKI [TomZ]

Picking out a few nice graphics from your collection and then making up some purple prose to explain the pictures looked =really= pretty, but is otherwise useless as a demo.

Now listen, I was using green for my prose not purple. Your monitor must be way out of adjustment!  :)

Seriously, I thank you for you comments. I am sorry that you did not feel that there was anything substatial behind the concept demo. In my mind, a number of things were accomplished by distributing a demonstration at this time: 1) I get some feedback on the interest in this type of software, 2) I force myself to develop some of the software tools that I will need to finish the final program, 3) I was able to show (as opposed to describing via text) what I have in my head for the user interface, and 4) I am able to show how much graphics and other IIgs capabilities can be exploited without changing the basic premise of the Eamon gaming system.

As an example of what you were able to glean from the demo, I will list a few facts that I am sure that you caught. The system is still mostly text based. The graphics can augment the verbage but does not replace it. The mixed text and graphics mode can be used to advantage for purposes of character statistics or similar information. The system is still a single character adventure with heavy interaction between the character and "monsters" within the scenario. I am sure that there are other things that are so much more clear with a demo in hand.

On the other hand, I never claimed that this was a working adventure system. I never even claimed that I was close. Quite the contrary, I have warned in a number of places that this is merely a concept demo that shows what I have in mind. I am still a long way from having a viable software package complete.

I know that a person as deeply involved with Eamon as you are will be most interested in the internal details of the gaming system. You want to know how small details of the adventure fit together and what algorithms I use to handle certain situations. I have quite a bit of this down on paper. I have been doing some game design for the past four months. I could certainly make some of this available to you and would even enjoy discussing it with you. However, at this stage I would agree that none of this information is in the demo. I never intended for it to be.

You state that you would like to see a small adventure that actually works (ie. runs). So would I! If I was that far along, I would be essentially finished with the first version of the program. I am just not that far along yet.

I can answer one specific question that you had about adventure developent tools. This system will be mostly database driven. I do not plan on having the average scenario designer get into the middle of the Pascal code. I have indicated in an earlier post why I need to do it this way. Therefore, the first set of scenarios will have to be developed with a text editor, a paint program and a few sparse creation tools. The current dungeon designer tools available for basic Eamon are well beyond what I will be able to provide for the initial release. However, based on the success of the Explorer series of adventures (found mostly on AOL), I think that this will probably suffice for a while.

You want to know how Eamon GS will play. My best answer would be, "As close to basic Eamon as possible for commands and command structure." I want to enhance the playing experience by adding graphics, sound (one day), mixed mode (text/graphics) display, and continual display of certain statistical information. Along with that, I want to produce a gaming environment that a non-programmer can use to create adventures. But I want that environment to be as flexible (almost) as the original Eamon system.

And really, I never _shouted_ about the merits of my demo or the potential final product. I just wanted some feedback and reactions.  :)

I thank you all, once again, for your comments. I solicit further feedback from these individuals or anyone else who has seen my demo. I get incentive from this type of discussion.

Demo on dudes,
Darrel Raines
[D.Raines]

Message 71
T.ZUCHOWSKI [TomZ] — Wed Nov 03, 1993 at 08:22 EST

Cool, Darrel. It sure sounds like you've got yourself organized on this GS Eamon project.

TomZ

Message 72
KEN.GAGNE — Wed Nov 03, 1993 at 18:57 EST

Have you written any other software that can be found in freeware/ shareware/PD libraries?

Message 73
D.RAINES — Thu Nov 04, 1993 at 04:20 EST

>>> KEN.GAGNE

Have you written any other software that can be found in freeware/shareware/PD libraries?

Yes. Look for D.Raines as the uploader and you will find three other items still available in the libraries: an 8-bit Blackjack game, an 8-bit dice game, and a graphics demo called Qix Circus. The only one of these that I believe to be bullet-proof and in a final product state is the Blackjack game. The others are okay and were completed in order that I might teach myself something about programming.

Qix Circus is my way of playing around with Super Hi-Res graphics. Greed (the dice game) is most interesting in that the computer opponent implements an artificial intelligence scheme based upon statistical analysis. Blackjack has a very unique way of handling the situation that evolves when you run out of money.

I have a few other programs that have been sold commercially. I also work as a professional in the aerospace industry. Some of my software is flying around in airplanes and/or simulators around the world.  :)

None of this necessarily qualifies me to write Eamon Gs; I just took the bull by the horns and have been riding along ever since.

Darrel Raines
[D.Raines]

Message 74
T.ZUCHOWSKI [TomZ] — Thu Nov 04, 1993 at 07:37 EST

I remember the Greed game. I got rather addicted to it for a while. Good game.

Like Darrel sort of said, all three of his programs are in the A2 library. A search on uploader D.RAINES turned them all up in seconds.

TomZ

Message 75
EDITOR.A2 [Doug Cuff] — Thu Nov 04, 1993 at 09:51 EST

>>> D.RAINES

By the way, I never claim to be an artist! In fact the closing screen asks for a collaborating artist.

I realize the former and noted the latter. What I was trying to say is that _finding_ a talented artist will, at least initially, make or break your system. (Well, okay, that's a little strong, but still, pretty pictures will make a big difference.)

Doug Cuff
Editor, GEnieLamp A2

Message 76
T.ZUCHOWSKI [TomZ] — Thu Nov 04, 1993 at 10:52 EST

still, pretty pictures will make a big difference

Yep. Precisely why I have never been a big enthusiast of adding graphics to Eamon. Among the 223 Eamon adventures you can count the truly talented Eamon authors on the fingers of one hand, and now we are looking for authors who are not only talented gamers and authors but artists as well.

To be sure, there's nothing wrong with this. But I think that Darrel would be well-advised to add a text-only mode to his system, or include a method to put up and leave an included "Eamon GS" graphic in the picture window.

TomZ

Message 77
KEN.GAGNE — Thu Nov 04, 1993 at 19:51 EST

Darrel, I wasn't trying to prove your credibility as an author of a new Eamon system. :) Read my Email...

-Ken

Message 78
D.RAINES — Fri Nov 05, 1993 at 02:51 EST

>>> T.ZUCHOWSKI [TomZ]

To be sure, there's nothing wrong with this. But I think that Darrel would be well-advised to add a text-only mode to his system, or include a method to put up and leave an included "Eamon GS" graphic in the picture window.

Good point, Tom. What I had in mind here was an option that turned off the graphics area and/or turned it into a graphical status area. I also want to have a set of canned graphics done by someone with some talent (ie. not me) that can be used by all future authors in their adventures. I admit that this might become redundant, but at least you don't _have_ to be an artist to get an adventure going.

I, too, realize the inherent danger in having an area for graphics. Now a person is required to put something in there. However, if it can be done with success, then the overall gaming experience can be enhanced a great deal.

One other idea I had was to use that area for auto-mapping. This could be done a-la Beyond Zork with a map font. I have not decided what I think about that option yet. What do you think?

Once again, thanks for the input.
Darrel Raines
[D.Raines]

Message 79
D.RAINES — Fri Nov 05, 1993 at 02:51 EST

>>> KEN.GAGNE

Darrel, I wasn't trying to prove your credibility as an author of a new Eamon system. :) Read my Email...

That's okay, I loved the chance to tell about my other releases. I also don't mind confessing to my limitations. One of my greatest limitations, at the moment, is time to work on this project. Therefore, I always try to indicate that it may be slow in developing.

(By the way, no E-mail yet.)

Darrel Raines
[D.Raines]

Message 80
T.ZUCHOWSKI [TomZ] — Fri Nov 05, 1993 at 07:58 EST

An auto-mapper would be way cool! But I have difficulty imagining how it would handle rooms that varied widely in size or room connections that were weird in some way like the infamous "twisty passages all alike" or magical portals. I've never seen a version of Zork that had the auto-mapper. How do they do this?

The way I personally map adventures is with a symbolic system that I developed that enables me to show any conceivable room connection, no matter how bizarre. However, my system doesn't remotely resemble a map.

TomZ

Message 81
EDITOR.A2 [Doug Cuff] — Fri Nov 05, 1993 at 11:22 EST

>>> T.ZUCHOWSKI [TomZ]

Precisely why I have never been a big enthusiast of adding graphics to Eamon.

You raise an important point here, Tom. Personally, I prefer text adventures. The point I was trying to make is "Anyone who slows down my screen with graphics had better make them worth my while."

Doug Cuff
Editor, GEnieLamp A2

Message 82
EDITOR.A2 [Doug Cuff] — Fri Nov 05, 1993 at 20:38 EST

never seen a version of Zork that had the auto-mapper. How do they do this?

I've never seen one either, but the easiest way _I_ can think of to "implement" auto-mapping for mazes is to put up a notice that the auto-mapping feature has been turned off, as you're now in a maze! <grin>

Doug Cuff
Editor, GEnieLamp A2
(who still hasn't finished Beyond Zork)

Message 83
D.RAINES — Wed Nov 10, 1993 at 00:12 EST

>>> T.ZUCHOWSKI [TomZ]

auto-mapper and "twisty passages all alike"...

The auto-mapping games that I have seen are all limited to two-dimensional maps. When you change levels (depths) the map starts over again. Beyond Zork used a font that had map symbols for characters. Therefore, the map was simply a text display with a fancy font!

In any case, I was really just saying that the auto-map capability would be one way of using graphics without having to depend upon someone (yourself?) to create nice looking artwork. I do not anticipate adding this feature to the original Eamon GS release specifications. It would be a nice add-on feature for a future version.

Another idea that I had for the graphics area, should you not want to provide artwork with your adventure would be to have bar-graphs of the various character statistics. Eamon GS will be a much more level game than the original as far as character development goes. In other words, there will not be any character development across adventures. Each individual adventure will have its own character maturity requirements, but this will not carry over between games. My rational here is that the characters have to have very high ability points to survive in most of the original adventures. Therefore, a novice character has barely any chance of getting anywhere without first bumping up his/her abilities. My alternative will be character development within the scenario and equalization between adventures.

(Please do not construe any remarks that I make here or in any of my other posts as a slam to the original Eamon series. I am extremely impressed with the quality of most of the adventures in the group. I do not consider my ideas to be inherently better than the ones used as a basis for the original gaming system. However, I obviously have ideas that I want to see implemented in Eamon GS. If I did not have my own ideas, then I would simply write a new game in the original system.)

Well, there I go blurting out information from my game design notes. I really do tease, do I not? My point here is that there will be a few attributes that would make sense to put in a bar-graph. That graph could be put in the picture area if a game designer does not want to provide his/her own graphics.

Finally, I want to provide a number of "canned" pictures that can be used by the intrepid adventure author. It will get boring if everyone uses the same graphics but at least you do not have to start completely from scratch. I still need a graphics collaborator to manage this last feat.

Keep the ideas coming,
Darrel Raines
[D.Raines]

Message 84
T.ZUCHOWSKI [TomZ] — Wed Nov 10, 1993 at 07:57 EST

Darrel, I'm not sure that you understand my question about auto-mapping. How does the auto-map graphic handle "impossible" room connections such as are often used in mazes and magic portals? For example, a set where Room 1 EAST goes to Room 2, and Room 2 EAST goes to Room 3, and Room 3 EAST goes to Room 1?

there will not be any character development across adventures. Each individual adventure will have its own character maturity

I have found that a significant fraction of Eamon players enjoy "building up" their characters. You might want to consider including a set of experience and expertise character stats that have little or no effect but do increase as the specific characteristic is used.

However, I applaud your decision not to have character maturity a part of the play. There are altogether too many Eamons that were written by guys who think that stats of 500% over max is a "normal" character, because that is what they play with. Consequently, otherwise ordinary Eamons sometimes require massively huge stats and weapons just to survive!

TomZ

Message 85
D.RAINES — Fri Nov 12, 1993 at 02:11 EST

>>> T.ZUCHOWSKI [TomZ]

I'm not sure that you understand my question about auto-mapping. How does the auto-map graphic handle "impossible" room connections ...

Oops, I understood your question but I got off on a tangent and never answered it. I think that I like Doug's suggestion. I could turn off the auto-map area and print a disclaimer like: "Now entering unmapable area".

You might want to consider including a set of experience and expertise character stats that have little or no effect but do increase as the specific characteristic is used.

Ah, this is one that I did anticipate. I know that some adventure players love to "build" character stats. Therefore, I have an Age attribute defined that will affect (to a very small degree) the Strength and Intelligence attributes of a character. This combined with an adventure completion award system should do the trick for most gamers.

In any case, keep those comments and suggestios coming,
Darrel Raines
[D.Raines]

Message 86
EDITOR.A2 [Doug Cuff] — Fri Nov 12, 1993 at 13:34 EST

I could turn off the auto-map area and print a disclaimer like: "Now entering unmapable area".

If you wanted to get fancy, you could make this part of the narrative. "Oops! You have dropped your special mapping pencil!" Okay, that's really lame, but you see what I mean?

Doug Cuff
Editor, GEnieLamp A2

Message 87
A2PRO.HELP [ Sloanie ] — Fri Nov 12, 1993 at 19:53 EST

Re: Auto-mapping

You guys are out-doing yourselves. Simply draw a line from the EAST side of Room 3 to Room 1.  :) it would look something like this:

 __________   __________   __________
 | Room 1 |___| Room 2 |___| Room 3 |___
 |________|   |________|   |________|  |
    +-------<------------<-------------+

(the <s mean one-way travel)

Something like this should be sufficient for most situations, I'd think.

Message 88
H.HISLOP [Harold] — Fri Nov 12, 1993 at 23:30 EST

Hmmm...

re: Entering an "unmapable" area...

"You vainly attempt to enscribe your last move on the parchment that you've spent years at making, lest you forget what it was, but as you fumble for your ink phial, you drop your quill and the point breaks. To make matters worse, you aren't carrying an extra quill at this time."

This alludes to the possible existence of a second (or more) quill(s) somewhere. The player could find one shortly after exiting the "unmapable area, and a later version of the game could, without disruption, simply dispense with this entire device and map the area, or keep the device but handle the mapping if the player was already carying a spare.

-Harold
(You're in a maze of twisty little passages, all alike)
(You're in a maze of little twisty passages, all alike)
(You hear a rustling sound from behind you...)
(You've just been bitten by the RPG bug!!!! :-)

Message 89
T.ZUCHOWSKI [TomZ] — Sat Nov 13, 1993 at 09:20 EST

Sloanie, you're over-simplifying your suggested mapping solution to a "weird" room connection. Imagine if you will an Eamon adventure that has, say, 100 rooms and perhaps 50 such non-mappable room connections. The classic adventure maze typically contains about a dozen or so rooms and about NINETY such weird connections. I've seen mazes with 30 rooms or more.

Even your three-room solution becomes difficult to implement if all three of those rooms have exits in all six directions.

TomZ