Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Programming & batch files
#1
PROGRAMSMsg # 1 of 44                    Date: Sat 23/08/1997,  3:23 pm

From: GURU                       Read: 23 times

     To: All
Subject: PRELUDE

Umm, this is kinda long, so if you can't be bothered, then just skip over it
Smile  This is basically a description of the adventure system I'm working on,
incase anyone is vaguely interested and incase anyone feels like giving
their opinion. Would you use it? If so, what would you rather were changed?

  Here is a description of my work and ideas for PRELUDE. The project is
currently working in a PASCAL implementation, and I am porting it (slowly Smile
to C. If you have the time, please read through this and give me your opinio
of this system. Appologies in advance for any parts I don't explain too well
- I'm trying to condense the results of several years' thought about this
into a quick overview. Also, there are several areas that are a bit vague -
the whole point of writing PRELUDE is to sort out some of these ideas.
  
  In this text, I use the word 'adventure' to mean a work of computer-bassed
interactive fiction. In general, I am refering to a 'text adventure' - that
is, a game where the player types commands such as "eat food" or "throw the
rope across the canyon", and the computer responds via. some set of rules
laid out by the author of the adventure. However, I do not intend to limit
the final system to only handling games of this type.


  PRELUDE is/will be the test version of a much bigger adventure game system
which I plan to develop sometime in the future. The purpose of writing
PRELUDE is to examine some of the strategies available for use in the
future system.

  Essentially, the adventure system will be a set of control routines, which
will be modifiable by the user of a system to conform to his or her
requirements. An adventure created by the author will consist of a set of
these routines, plus game data stored in the form of lists.

  Therefore, the 'adventure' will be created out of a number of layers:-

* GAME DATA - this is a set of lists, describing objects, places, etc. These
        are given the generic name 'frame' (name taken from AI work);
* CONTROL ROUTINES - a set of ANSI C routines + a main program that will
        use the data and control the adventure game.


  A standard 'library' of control routines will be provided:

   * LST - interfaces to the game data lists
   * FRAME - a frame is a 'thing' (object, place, person, etc.). The routine
                in this library handle movement of frames, etc.
   * CMD - routines to handle user commands, such as "get", "go", etc. These
                routines interface between FRAME and PARSER.
   * CMDLST - matches verbs with appropriate routine from CMD
   * PARSER - handles user input, uses CMDLST to exectue appropriate CMD
                actions. PARSER and CMDLST interface between CMD and
                user input.
   * GAME - gets input from user, then runs PARSER.


  For example, the standard CMD library would contain routines for verbs suc
as "get", "go", "drop", "eat", "look", "examine", "put", etc.

  If the author required non-standard commands (eg. "teleport", or
"levitate"), then these could be added to CMD and CMDLST. The code for these
commands could be built from the 'building blocks' provided by FRAME.

  If the author required a subtle change in the way a large number of
commands operate, the appropriate building blocks in FRAME could be
modified.

  
  The exact implementation of the GAME DATA lists is not important - the
LST library interfaces to these lists - changing implementation just means
changing the LST library.

  The LST library will provide simple 'building blocks' from which FRAME
commands can be built - for example displaying a set of text stored in part
of the list (an object description perhaps), adding and removing 'tags'
(eg. flags for on/off, visible/invisible, etc.), maps (eg. where to look if
the user wants to "go north"), etc...

  As well as the standard control routine library, the system will provide
a program to create GAME DATA lists ('frames'), allowing the author to
specify every component of the frame for his or her adventure.


  This system gives the author _complete_control_ over how his or her
adventure is going to work. I have chosen C since it is powerful, can be
ported easily to other platforms, and is known by many people. Obviously
creating any adventure that requires more than what is provided in the
standard library will require programming, but so do other adventure-
authoring systems.


  I indend for the system to be PUBLIC DOMAIN - meaning that anyone can
change the standard library to suit his/her purposes. It would of course
be possible to build several 'standard libraries' - eg. one containing
commands used in 'fantasy' adventures ("cast spell", etc.), another for
'modern' adventures ("drive", "switch on", etc.)...


  The working version I have is currently a reduced version - understood
commands are "go", "look", "examine", and "put ... in ...". Using the
building blocks from LST, it was easy to implement multiple descriptions
(eg. a description for when you first enter a room, and a shorter descriptio
every time after that), adjectives (eg. the "big blue metal box"), and
inheritance via. type and adjective (eg. all big things can contain small
things, all boxes can contain things whereas balls can't, all balls are
spherical, etc.).

  IMHO this system provides a powerful, portable, and easy(ish) way of
authoring adventure games. But, of course, my opinion is probably biassed.
Thanks for reading all this - please give me _your_ opinion on this system.

--------------------------------------------------------------
PROGRAMSMsg # 2 of 44                    Date: Sat  6/09/1997, 11:27 am
From: GURU                       Read: 19 times

     To: XLNC
Subject: File parameters

Dunno if you read the PASCAL subby, thats why this is here.

Program for Turbo Pascal/TMTPL to write parameters to a file that you can
use from QBASIC or whatever. It'll output a text file - first line of text
file is a number (number of parameters), then following lines are
parameters.


GETPARAM.PAS:
----------------------snip-------------------
PROGRAM GetParam;

USES CRT, DOS;

VAR OutFile : TEXT;
    i : INTEGER;

BEGIN
ASSIGN (OutFile, 'PARAMS.TXT');
REWRITE (OutFile);
WRITELN (OutFile, ParamCount);
FOR i := 1 TO ParamCount DO
  WRITELN (OutFile, ParamStr (i));
END.
----------------------snip-------------------

Change the 'PARAMS.TXT' to any filename you like (eg.
'C:\DATA\PARAMETE.RS')

--------------------------------------------------------------
PROGRAMSMsg # 3 of 44                    Date: Sun 14/09/1997,  2:25 am
From: RASPUTIN                   Read: 16 times

     To: XLNC
Subject: Re: OLMR

>>>No No No...When u use the SL colour codes... it takes up 3 chr spaces.
>>>so an inverse color thing Blinking etc takes 6-9 spaces of the 80 you can
>>>have on each line.
>
>>Ooooooh, thats what you mean...    <look of enlightenment>
>>OK. Talk to Ras on that one - he's the one that did that WriteX thingi kind
>>like that  Smile
>
>Hinterestin.. Ras.. Wotz WriteX thing?

A procedure I wrote in Pascal that writes strings in inline colours...
Eg, To write Yellow Text, just do: WriteX('<tYe>Yellow Text.');
Yellow on Blue:   WriteX('<tYe>Yellow...<bBl>On Blue.');
or Light Magenta on Black: WriteX('<tLm><bBk>Ras was here.');

The first letter (case IN-sensitive) specifies textcolour or Background...
Then the remaining two match the searchlight colour labels.

There are of course better formats to use for frequent colour changes...

--------------------------------------------------------------
PROGRAMSMsg # 4 of 44                    Date: Wed 22/10/1997, 10:58 am
From: GURU                       Read: 12 times  [1 Reply]

     To: All
Subject: C++

Hey y'all. I've discovered (on 42 BBS) a wonderfull thing called DJGPP.
Its a C/C++ compiler, its really easy to use (comes with an editor called
RHIDE which makes the whole thing work just like Turbo Pascal, including
online help), and best of all, its FREE!

  Anyway, its about 8 megs or so ZIPped, so I won't upload it right now. If
anyone is interested, leave a message and I'll stick it in the
TRANSFER area.

chow

___ Blue Wave/386 v2.30 [NR]

--------------------------------------------------------------

PROGRAMSMsg # 5 of 44                    Date: Thu 23/10/1997, 12:52 am
From: XLNC                       Read: 13 times  [1 Reply]

     To: GURU
Subject: Re: C++

>Hey y'all. I've discovered (on 42 BBS) a wonderfull thing called DJGPP.
>Its a C/C++ compiler, its really easy to use (comes with an editor called
>RHIDE which makes the whole thing work just like Turbo Pascal, including
>online help), and best of all, its FREE!

U mean its a complete standalone C++ clone or do we need C.?

--------------------------------------------------------------

PROGRAMSMsg # 6 of 44                    Date: Thu 23/10/1997,  4:51 pm
From: GURU                       Read: 14 times

     To: XLNC
Subject: C++

 >Hey y'all. I've discovered (on 42 BBS) a wonderfull thing called DJGPP.
 >Its a C/C++ compiler, its really easy to use (comes with an editor called
 >RHIDE which makes the whole thing work just like Turbo Pascal, including
 >online help), and best of all, its FREE!

 Xl> U mean its a complete standalone C++ clone or do we need C.?

Its a complete port of the UNIX 'GNU C++', so it is a complete standalone
compiler for either C or C++ (depending on what you want to write your
programs in Smile
  Oh, and it runs in protected mode (so you can use all 8/16/32 megs of
memory, insead of just the usual 640k), and handles virtual memory for you
(so you could make 4-gig variables if your HDD was that big Smile

___ Blue Wave/386 v2.30 [NR]

--------------------------------------------------------------

PROGRAMSMsg # 7 of 44                    Date: Wed 23/07/1997,  9:58 pm
From: JOKO                       Read: 22 times

     To: GURU                    Fwd From: :   No, not the confectionary treat
Subject: Re: RIPterm

> Jo> Doesn't work in ripterm. But if it did would it be:
> Jo> ,,,,,,,,,,,,,
> Jo> Aimeeeeeeeeeeeeee...!  ?
>
>Smile   Try Pressing ALT-=, _then_ do it
Aim‚e...
WOW it does work!
Aim‚e Aim‚e Bo Ba N‚n‚ Rama Bana Bo Banana, Aim‚e!
Guru Guru Bo Ba Gunu Nana Rama Bo Banana, Guru!
Joko Joko Bo Ba Hoko Tana Lana Bo Banana, Joko!
Raspy Raspy Bo Ba Baspy Gana Fana Bo Banana, Raspy!

I think thats how the song goes. Tell me if I'm wrong.

----------------------------------------------------------------
THE PROGRAMMER'S QUICK GUIDE TO THE LANGUAGES
----------------------------------------------------------------

The proliferation of modern programming languages (all of which seem to
have stolen countless features from one another) sometimes makes it
difficult to remember what language you're currently using. This handy
reference is offered as a public service to help programmers who find
themselves in such a dilemma.


                TASK: Shoot yourself in the foot.


C: You shoot yourself in the foot.

C++: You accidentally create a dozen instances of yourself and shoot
them all in the foot. Providing emergency medical assistance is
impossible since you can't tell which are bitwise copies and which are
just pointing at others and saying, "That's me, over there."

FORTRAN: You shoot yourself in each toe, iteratively, until you run out
of toes, then you read in the next foot and repeat. If you run out of
bullets, you continue with the attempts to shoot yourself anyways
because you have no exception-handling capability.

Pascal: The compiler won't let you shoot yourself in the foot.

Ada: After correctly packing your foot, you attempt to concurrently load
the gun, pull the trigger, scream, and shoot yourself in the foot. When
you try, however, you discover you can't because your foot is of the
wrong type.

COBOL: Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place
ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN
return HANDGUN to HOLSTER. CHECK whether shoelace needs to be re-tied.

LISP: You shoot yourself in the appendage which holds the gun with which
you shoot yourself in the appendage which holds the gun with which you
shoot yourself in the appendage which holds the gun with which you shoot
yourself in the appendage which holds the gun with which you shoot
yourself in the appendage which holds the gun with which you shoot
yourself in the appendage which holds...

FORTH: Foot in yourself shoot.

Prolog: You tell your program that you want to be shot in the foot. The
program figures out how to do it, but the syntax doesn't permit it to
explain it to you.

BASIC: Shoot yourself in the foot with a water pistol. On large systems,
continue until entire lower body is waterlogged.

Visual Basic: You'll really only _appear_ to have shot yourself in the
foot, but you'll have had so much fun doing it that you won't care.

HyperTalk: Put the first bullet of gun into foot left of leg of you.
Answer the result.

Motif: You spend days writing a UIL description of your foot, the
bullet, its trajectory, and the intricate scrollwork on the ivory handles of
the gun. When you finally get around to pulling the trigger, the gun jams.

APL: You shoot yourself in the foot, then spend all day figuring out how
to do it in fewer characters.

SNOBOL: If you succeed, shoot yourself in the left foot. If you fail,
shoot yourself in the right foot.

Unix:
% ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o
rm:.o no such file or directory
% ls
%

Concurrent Euclid: You shoot yourself in somebody else's foot.

370 JCL: You send your foot down to MIS and include a 400-page document
explaining exactly how you want it to be shot. Three years later, your
foot comes back deep-fried.

Paradox: Not only can you shoot yourself in the foot, your users can,
too.

Access: You try to point the gun at your foot, but it shoots holes in
all your Borland distribution diskettes instead.

Revelation: You're sure you're going to be able to shoot yourself
in the foot, just as soon as you figure out what all these nifty
little bullet-thingies are for.

Assembler: You try to shoot yourself in the foot, only to discover you
must first invent the gun, the bullet, the trigger, and your foot.

Modula2: After realizing that you can't actually accomplish anything in
this language, you shoot yourself in the head.

Enjoy


--------------------------------------------------------------
PROGRAMSMsg # 8 of 44                    Date: Thu 24/07/1997, 11:33 pm
From: XLNC                       Read: 31 times

     To: JOKO                    Fwd From: :   No, not the confectionary treat
Subject: Re: RIPterm

>----------------------------------------------------------------
>THE PROGRAMMER'S QUICK GUIDE TO THE LANGUAGES
>----------------------------------------------------------------
>C: You shoot yourself in the foot.
>FORTH: Foot in yourself shoot.
>Visual Basic: You'll really only _appear_ to have shot yourself in the
>foot, but you'll have had so much fun doing it that you won't care.
Etc...
Machine coad- You discover the way to do it is to move your foot Micron
by micron thru the bullet, but have to write a complete alter reality to be
able to see the event happen.

DOS - You search all the Util disks you can find for that utility you saw
once written just for this purpose but u deleted it because you though you
would never Ever use it.

COBOL (Part 2) You miss a full stop in the first line and the program shoots
holes in EVERYTHING.
QuickBasic You never get around to Shooting yourself in the foot, but you
discovered part of the solution to world piece, and a cursor controll system

WINDOWS You forget about shooting yourself in the foot after finding the
games folder.

WINDOWS 95 Where the hell did you put your foot again. Theres the bullets
but this gun can only move the bullets to another Clip.

VIRTUAL ENVIRONMENTS- You see yourself shooting yourself in the foot
Meanwhile your actually scaring the cat with your index finger.

THE INTERNET- What you thought was your foot turned out to be a foregn army
installation and somone else now wants to shoot you in the foot.
                ---=== X.L.N.C wuz here ===---

-
Reply


Messages In This Thread
Programming & batch files - Aimée - 08-02-2015, 05:12 PM
RE: Programming & batch files - Aimée - 08-02-2015, 05:12 PM
RE: Programming & batch files - Aimée - 08-02-2015, 05:13 PM
RE: Programming & batch files - Aimée - 08-02-2015, 05:13 PM
RE: Programming & batch files - Aimée - 08-02-2015, 05:13 PM

Forum Jump:


Users browsing this thread: 1 Guest(s)