HDTenEightyP/NetNews huggingface dataset:
From: psalp@acad2.alaska.edu (Albert L. Perrien II)
Newsgroups: rec.games.programmer
Subject: Monster library part 1
Date: 27 Jul 92 20:33:34 GMT
Organization: University of Alaska


		Copyright (C) 1992,  Albert L. Perrien II

	This woork may be used freely to create computer games for private use, and for the education of individuals wishing to create computer games.  For use in creating commercial games, please contact the Author.  The Author is not responsible for any addictions that are created by thease games.

	Okay,  here's the sources for part of the game library.  Sorry I took so long, but I am attempting to get my sister through her first term paper.  The graphics section is not finished yet, but I'm still busy typing!
	There are four main sections in this library: The Player manager, the monster manager, the weapon manager, and the object manager. I will also be covering various editors for each section of the game later.
	I do apologize for the lack of sound, but none of the IBM's at my college lab have any sound cards, and that's where I'm writing this.  Perhaps someone ouyt there could explain how to use the sound blaster card in C or Paascal? I'm still a lot rough in IBM assembly.


	Okay, on to the buisness at hand...

=============================================================

Create_Monster 

	Create_Monster is passed a monster spec from another source,  i.e. 
levelmap, Major monster,  etc.  It finds an empty slot in the monster array,
loads in the monster spec, and sets the Status of the monster to Alive.


Procedure Create_Monster (var Monster: Monstertype);

var
i:integer;

Begin
	Repeat i:=i+1 until Mlist(i).Status:= dead;
	Mlist(i):=Monster;
	Mlist(i).Status:=Alive;
end;

Do_Monster

	This routine is a driver program that routes information to the 
various monsters in the game. It is used in conjunction with the Create_Monster
and Kill_Monster routines (explained later) to manage the subroutines for each
individual monster.
	
Procedure Do_Monsters


Begin 
	repeat
		i:=i+1;
		Monster:=Mlist(i);
		With Mlist(i) do 
			Begin

				Case Monstertype of 
	1:BounceMonster(Monster);
	end;
	2:CrawlMonster(Monster);
	end;
	3:DartMonster(Monster);
	end;
	4:BirdMonster(Monster);
	end;
				end;
			end;
		end;
	end;
end;

Kill_Monster


	The Kill_Monster routine removes a monster with the identity k from 
the list. This routine omits a call to an explosion manager which would manage
the explosions of all the monsters, However, I do not think that this would be
too hard to write. A monster is killed whenever it moves too far away from the 
player in either an x or y direction, or if it's energy is expired.

procedure Kill_Monster(k:integer);

Begin
	Mlist[k].Status:=dead;
end;
Newsgroups: rec.games.programmer
From: bpeal@eng.clemson.edu (brian (malibu) peal)
Subject: New Computer Game System
Summary: Looking for the following to assist in designing computer game system:
		Programer
		Game Coordinator
		Graphic artist
		Graphic programmer
		Network hardware man
		Network programmer
Reply-To: bpeal@eng.clemson.edu
Organization: College of Engineering, Clemson Univ.
Date: Mon, 27 Jul 1992 19:53:00 GMT

I plan to build an system to be used at GenCon, copyrighted of course.  Send all replies to 
			
			Malibu S. Peal @

			bpeal@eng.clemson.edu

Computer Engineering
Clemson University
Keywords: 



Newsgroups: rec.games.programmer
From: dmb@wam.umd.edu (David M. Baggett)
Subject: Re: Bitmap 3-d graphics systems
Organization: University of Maryland, College Park
Date: Tue, 28 Jul 1992 17:08:39 GMT

bp092@cleveland.Freenet.Edu (Mike Ogrinz) writes:
>
>I'd say most of us have seen Origin's bitmap 3-d space system in WC and
>WC II (and other stuff) and maybe in Star Trek 25th Anniversary.
>
>First off, let me say that WC (1&2) do not map textures over polygons->
>It seems that they must capture a bunch of bitmaps for each object,
>and they just display the correct one probably according to some
>'direction facing' vector in each data structure. I'd bet there's
>also a velocity vector. When used with the 'direction facing' vector
>that would produce stuff like the debris and asteroids which spin
>in one direction and move in another.

This is an incredibly memory-intensive way to do things, but it's also
incredibly simple (and therefore fast).  It also has has the virtue
that you can make the rotated images look "perfect;" i.e., you can pay
your artist to draw each view by hand (or, more realistically perhaps,
to touch up texture-mapped solids you've already rotated with
Autodesk).

For static (i.e., non-animating) objects, you just need to store a
three-dimensional array of images: as the viewpoint moves left and
right, you move your frame pointer through the array along x; as the
viewpoint moves up and down, you move along y; similarly with
closer/nearer and z.

Note that this only encodes a single frame, but it enocdes that frame
from every possible viewing angle.  If you want to add animation, you
need to add a fourth dimension (time).  If you want multiple animations
(for example, rock spinining one way vs. rock spinning another), you
need to either add a fifth dimension.

You can eliminate a dimension with real-time scaling.  You can
eliminate another dimension in special cases with real-time rotation
(e.g., to get a rock spinning clockwise, just hflip the rock spinning
counterclockwise in real time).

A further space saver might be to disallow certain coordinates; e.g.,
in a head-on space dogfight you might never allow the player to look
straight down on top of a particular object (or even come close).

Probably the biggest space-saver would be to only store deltas between
frames.  I.e., you'd only store the changes from one view to the next.
This would restrict you to changing the view incrementally since to
"teleport" to a particular view from any current view would require you
to take the starting frame (0, 0, 0) -- the only fully-specified one --
and step through to your destination, applying deltas as you went.
This restriction would probably be fine for a space game.

There are probably many other possible optimizations as well.

Dave Baggett
dmb@wam.umd.edu
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: rec.games.programmer
Date: Tue, 21 Jul 1992 21:12:45 -0400 
From: James T Graves <jg4o+@andrew.cmu.edu>
Subject: Re: Formal programming education

Excerpts from netnews.rec.games.programmer: 21-Jul-92 Re: Formal
programming educ.. by Matthew A Kudzin@engws5. 
> One thing that has not been mentioned yet in this thead (at least not so far 
> as I've seen) is that if you want to be a programmer, you should have a 
> degree, but not necessarily a CS degree.  I am currently a Math/Physics major
> and I routinely (about five or six per year) get job offers looking for 
> programmers.  This includes offers from game companies.  Apparently, a lot of
> companies are looking for more than just CS majors.
>  

Conversely, a lot of CS majors are looking for more in their jobs than
just programming.  ;)

Jim
 
---------------------------------------------------
James T. Graves   
Carnegie Mellon University
internet: jg4o+@andrew.cmu.edu  
---------------------------------------------------
300,000 kilometers per second -- it's not just a good idea, it's the law.

Newsgroups: rec.games.programmer,alt.msdos.programmer,comp.os.msdos.programmer
From: njoddson@undergrad.math.waterloo.edu (Nick Oddson)
Subject: Mode Y
Keywords: MODEY DDJ GRAPHICS CODE
Organization: University of Waterloo
Date: Mon, 27 Jul 1992 04:03:42 GMT

How do you setup Mode Y...  I've got code (and understand) how to initialize
Mode X, but I have several routines which I can only implement in Mode Y...
so, could someone send me code or tell me the modifications which I have to
make so initialize mode Y (I suppose I could figure it out myself, but I'm 
lazy)...

Thanks in advance,
                    Nick

--
"This sentence no verb" -- Jargon File 2.90, July/92
Newsgroups: rec.games.programmer
Subject: Re: TP or C ?
From: stuartw@ccu1.aukuni.ac.nz (Stuart Woolford)
Date: Mon, 27 Jul 1992 23:25:14 GMT
Organization: University of Auckland, New Zealand.

johnf@apollo.hp.com (John Francis) writes:

>bruce@inmos.co.uk (Bruce Stenning) writes:
>>Can you imagine writing something like UNIX in Pascal?  It would be an
>>absolute nightmare.

>I don't have to imagine it - I've seen it.  In fact I wrote some of it.
>Domain/OS (the operating system for Apollo workstations) is written in Pascal.
>It's no more or less of a nightmare than real UN*X(tm).

>Now can we please all stop the "my language is better than your language"
>wars?  Without knowing all the constraints, it is impossible to make any
>meaningful comparisons.  for example:

>If portability is the major concern, then obvously you should choose C.
>If the code is only going to run on your computer, use whatever you like.
>TP has a (much) faster compile-load-run cyle, so using that instead of
>a C compiler can be a big win, especially on a slower machine like a 286.

not really.. try using the windows version to TP and QC/Windows, the
first is a dog on anything less than a fast 386/lots of mem..whereas QC
is quite useable..

also..by the time you include the linking, I find QC 2.0 ( for dos ) has
a MUCH faster develop time than TP ( sould be linked to RamDisk.. ).
also: I find the best part of QC 2.0 is the GREAT online help, which
has a much larger effect on my develop time than compiler speed, let along
having access to CodeView ( a GREAT debugger.. MUCH more powerfull/solid
than TD in my experience.. )

>As for the two languages:  any half-way competent programmer can work
>equally well in either language.  Obviously each language has its own
>set of features you will miss when programming in the other: in my case
>I like Pascal variant records, and C conditional expressions.

no.. TP people I know seem to spend most of their time writing core routines
which QC has as standard.

-------------------------------------------------------------------------------
stuartw@ccu1.aukuni.ac.nz

			>>>>In VI Where Available<<<<
-------------------------------------------------------------------------------
From: greg@Quotron.COM (Greg "Maddog" Knauss)
Newsgroups: rec.games.programmer
Subject: Dave 'n' Josh
Date: 30 Jul 92 17:09:28 GMT
Organization: Quotron System, Inc.

What this discussion seems to come down to, to me, is a question of
credibility.  Josh has made some pretty impressive claims, Dave has
doubted those cliams.  Period.
	Now, there are ways to settle this.  I, personally, know that
Dave can both program and design complex systems.  I've played his
games and used Game Workbench.  I know he's more technically competent
than me, and -- given a known and an unknown -- I'd be more inclined
to trust his judgement.  That doesn't mean that Josh is wrong, though.
	Could a complete (but not necessacarily TADS-like) adventure
system be created in three weeks?  I suppose, depending on how much
experience and code you had lying around to use.  I, personally, have
spent over a year on mine, but if I were to start over I could re-
produce what I have now in, say, a month of part-time work.  Given that,
I'd be willing to believe that a system could be put together in three
weeks.  In 18K?  I'd have to see it to believe it.  So, apparently,
does Dave.
	I believe that a flat-surface texture mapping routine could
be written with Bresenham.  Would it be fast enough to be real-time?
I'd like to see it.  So, apparently, would Dave.
	So all that's required is posting the code.  If you don't
want to post the source (which is understandable, I'm sure Dave wouldn't
want to have to prove that he can program by posting Game Workbench
source), uuencode an executable.
	And as for interest:  I'm incredibly interested.  An 18K
adventure system could revolutionize what I'm doing.  I'm sure there
are dozens of people here and in rec.arts.int-fiction that could
really, really use something like that.  A real-time flat-surface
texture mapper would generate equal excitement.
	I firmly believe that a 16-year-old can be a programming god.
I also believe that nobody is going to believe him until he proves
himself.  Which Josh can with one post.
--
 ------------------------------------------------------------------------------
 Greg "Maddog" Knauss                      My boss doesn't know I'm doing this,
 greg@duke.quotron.com                           so I doubt he'd agree with me.
 ------------------------------------------------------------------------------
From: cg@ami-cg.UUCP (Chris Gray)
Newsgroups: rec.games.programmer
Subject: Re:  TP or C ?
Distribution: world
Date: 22 Jul 92 21:01:46 MST
Organization: Not an Organization

In article <1992Jul22.000454.24871@ccu1.aukuni.ac.nz> stuartw@ccu1.aukuni.ac.nz
writes:
>	base_ptr[offset]=value;
>
>	or
>
>	*base_ptr+offset=value;

He he! I just love it when someone saying how great C is messes up with a
common C error! The above two are of course not equivalent - extra parentheses
are needed around the 'base_ptr+offset' in the second form.

I've been skipping through these articles on 'TP or C', not realizing I've
been missing the glorious fun of putting C down!

C is one of the unfriendliest languages I've come in contact with, especially
in the ways it is used by far too many people.

Folks! Use full prototypes. Turn on all possible warning flags. Make your
code compile clean. Use some fairly standard programming style. Make your
file global variables instantly distinguishable from your local ones. Avoid
inter-file globals (externs) like the plague. Don't overuse macros. Make
ALL macro names in all upper case (except perhaps true/false).

Anyone (including yourself after a few years) who has to work with your code
will greatly thank you.

My relevant experience: I've written an ANSI C compiler at work. I use
ANSI C at work almost exclusively. I've written other compilers, including
the one I use here at home. I've probably written over half a million lines
of high-level-language code over the years, so I've learned a LITTLE about
how to do it in a maintainable way, usually without sacrificing efficiency.

--
Chris Gray   alberta!ami-cg!cg	 or   cg%ami-cg@CS.UAlberta.CA
Newsgroups: rec.games.programmer
From: tmkk@uiuc.edu (Khan)
Subject: Re: On-Line Game Design Question
Organization: University of Illinois at Urbana
Date: Thu, 23 Jul 1992 21:00:44 GMT


In article <1992Jul23.134357.7464@cbnews.cb.att.com> nak@cbnews.cb.att.com (neil.a.kirby) writes:
>In article <1992Jul15.201804.12142@cactus.org> vlaurent@cactus.org (Vince Laurent) writes:
>>I am just about ready to put out an on-line game.  I have tested it
>>locally but would like to get feedback and suggestions from others
>>first.  Having never done anything like this, what is the best way
>>to go about it to get the testing and feedback BUT NOT to get the
>>game distributed?  Should I put out just a local version of the game
>>initially? This is what I am thinking of doing for a first phase.
>
>[more similar questions deleted]
>
>THis is a fragile point for your game.  You need a playtest group that you
>can trust.  You want them to sign non-disclosure agreements.

This is also an excellent situation for "expiring" software. Having beta
tested some recent Microsoft products, I can report firsthand that
commercial software developers put expiration timers into their beta
releases. After a certain period of time, the beta no longer runs, and
prints a message asking you to get a later version of the beta. That
also prevents beta versions of the game from "leaking" out and being
distributed up the ying yang - few people are going to distribute a game
which only works if you set the system date back to 6/30/92, although
they might try their hands at hacking it to get rid of the expiration
check so best hide it well.

Newsgroups: rec.games.programmer
From: dfs@doe.carleton.ca (David F. Skoll)
Subject: Re: Pascal and C
Organization: Dept. of Electronics, Carleton University
Distribution: usa
Date: Wed, 22 Jul 1992 17:11:55 GMT

In <1992Jul22.152218.10624@esds.mdc.com> bonney@esds.mdc.com (Greg
Bonney) writes:

>Mike Kienenberger SXMLK@ALASKA, SXMLK@acad3.alaska.edu writes:

>>C++ is an entirely different language.

>Entirely?  I think not.  Any ANSI C program will still work in C++.

I don't think so.  C++ is not a direct superset of ANSI C - there are
a number of small incompatibilities.

Here's a fragment from an ANSI C program which won't work in C++:

typedef struct buddy {
   struct buddy *next;
   int age;
} friend;

typedef struct room {
   struct room *next;
   int chairs;
} class;

:-)

--
David F. Skoll
From: Zarniwoop.Woop@f99.n121.z1.FidoNet.Org (Zarniwoop Woop)
Sender: FredGate@p0.f99.n121.z1.FidoNet.Org
Newsgroups: rec.games.programmer
Subject: Re: Formal programming education
Date: 23 Jul 92  20:52:01 EST

  1) LEARN TURBO PASCAL!!! The old school structure programing will

     help so much!! I sware. I'm learning C right now, and trying to 
learn assmebler.

 

  From what I've heard, its gonna be great for programmers!

  The future can only get better, everything around us is computers

  so you tell me.  I hope to go to college too, and code for a game comp 
so i dunno, guess thats the flavor of the day


 * Origin: NineJackNine / 608-256-5697 / Madison WI / (1:121/99.0)

Newsgroups: rec.games.programmer
From: angelrat@next06pg2.wam.umd.edu (RaT)
Subject: tpascal game library $120!!
Keywords: game, pascal
Organization: Workstations at Maryland, University of Maryland, College Park
Date: Thu, 23 Jul 1992 15:57:49 GMT

.has anyone hear heard of this sprite-editor / TPU for tpascal 6
called FastSprite!.....from White Obsidian Software.....
the  demo / evaluation copy is kinda lame...but it looks interesting..
.but no way in @#$ ican afford to shell out $120 for it.....
...i am writing this gameobjec mini-system in TP6 but as far as graphics  
go......i'm stuck with BGI..
From: gmt@reef.cis.ufl.edu (GMM)
Newsgroups: rec.games.programmer
Subject: Here's a source for "Zen. . . "
Date: 30 Jul 92 00:03:02 GMT
Organization: Univ. of Florida CIS Dept.

Someone had expressed an interest in getting Abrash's Assembly book.  The
easiest way to get it to pick up an issue of "PC Techniques" magazine
and order it through them.  I think they do their own publishing and have
Abrash on staff etc. . .    Anyway, they definitely will send you the
book.

Gary
From: gmt@reef.cis.ufl.edu (GMM)
Newsgroups: rec.games.programmer
Subject: Re: Game libraries...
Date: 29 Jul 92 15:43:13 GMT
Organization: Univ. of Florida CIS Dept.

I've got the Abrash book.  I'm not sure where to get more, but if you need
anything out if it, give me a buzz and I'll see what I can do.

Gary
Newsgroups: rec.games.programmer
From: brett@visix.com (Brett Bourbin)
Subject: Re: Game library...
Reply-To: brett@visix.com
Organization: Visix Software Inc., Reston, VA
Date: Mon, 27 Jul 92 14:58:03 GMT

In article <1992Jul22.131418.19638@wam.umd.edu> dmb@wam.umd.edu (David M.  
Baggett) writes:
> What I see missing from most demos (on the Atari at least) is polish.

or what Chris Crawford called the "icing". His point was that the whole  
idea of writing a game was to create a interesting, fun piece of software  
(that followed a "mission statement"... 8^) ), but producers and  
publishing house like (and need) the "icing". They need that flashy  
graphics and things that make this game boil to the top of pot.

I think everyone does know that demos are not games, but they do make good  
"icing" to combine with a good game design.
--                          _  _    _      _
Brett Bourbin              (_ |_ | /__ | |(_  4431 Lehigh Road, Suite 151
  ..!uupsi!visix.com!brett __)|_ |_\_/ \_/__) College Park, Maryland 20740
  brett@visix.com                LIMITED      703.758.2733
Newsgroups: rec.games.programmer,alt.msdos.programmer,comp.os.msdos.programmer
From: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng)
Subject: Re: Mode Y"{
Organization: University of Waterloo
Date: Mon, 27 Jul 1992 23:25:11 GMT

I suggest you get the polyblit (256 color) code from sunee.uwaterloo.ca and
look at the set_vmode code in the gxsppt.asm file.  This shows how to do
it.


--------------------------------------------------------------------------
| My life is Hardware,                    |                              | 
| my destiny is Software,                 |         Dave Stampe          |
| my CPU is Wetware...                    |                              | 
| Anybody got a SDB I can borrow?         | dstamp@watserv1.uwaterloo.ca |
__________________________________________________________________________
From: ron@zooid.guild.org (Secret Mud)
Newsgroups: rec.games.programmer
Subject: Re: Game Library? Fact or Fiction.
Date: 21 Jul 92 12:35:15 GMT

From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz)
>
>You also hit on an interesting point, which I've already addressed...
>Today, we have seen 5+ years of run-punch-kick-beatupwomenwithchains
>video games coming from the coin-op industry - the traditional leaders
>of the gaming industry (IMO).  Those guys get the best hardware (custom,
>just to make the game exactly as they want) and have great artists
>and other resources.  Back in the old days, you'd get a Centipede,
>a Q-Bert, an Asteroids, a Defender, a Robotron, a Qix, a Tempest, a
>pacman...  Games that are all very distinct, creative, have soul,
>and were highly entertaining.  Marketroids will tell you today,
>though, that those kinds of games (abstract, new edge) are not
>what sells anymore.  Just games like Double Dragon or Sports
>games...
>
>Author of Amiga GRn, MailMinder, Budokan, Beyond Dark Castle, Dark Castle,
>and Genesis Dick Tracy and Marble Madness.
>Mike Schwartz  (ames!zorch!amiga0!mykes or mykes@amiga0.sf-bay.org)
>1124 Fremont Ave.
>Los Altos, CA 94024
>

Possibly it might have something to do with the lack of any North American
designers of coin-op games.  (There must be one or two left, but I can't think
of them at the moment.)  Just Far East knockoff shops.
Newsgroups: rec.games.programmer
From: boutell@cshl.org (Tom Boutell)
Subject: Re: Game languages: not a
Organization: Cold Spring Harbor Laboratory
Date: Sun, 26 Jul 92 16:57:49 GMT

I wasn't aware you envisioned your game language as a preprocessor
for C++. That opens up some serious possibilities, since it really
could add new usefulness without reinventing the wheel. Perhaps,
since you're sick of the flamewar on this topic, you could email
me more details? I'm genuinely interested.

-T


-- 
My return address now works!
Believe it or not there is life after college. At least if you live
near NYC.
From: sl8nl@cc.usu.edu
Newsgroups: rec.games.programmer
Subject: Re: TP or C ?
Date: 23 Jul 92 23:53:51 MDT
Organization: Utah State University

In article <1992Jul24.044750.25177@ccu1.aukuni.ac.nz>, stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:
> sl8nl@cc.usu.edu writes:
> 
>>> what I want added to C:
>>> add scope control with '.' ie:
>>> int a;
>>> blort()
>>> 	{
>>> 	int a;
>>> 	a=1;	/* set LOCAL A=1 */
>>> 	.a=1;	/* set GLOBAL A=1 */
>>> 	}
>>> 
> 
>>Turbo Pascal already has that feature <sneer :)>  It deals with the one and
>>only reason I've found to use a program header (and it works with unit headers
>>too!)
> 
>>program Global;
> 
>>var a : Integer;
> 
>>procedure blort;
>>var a : Integer;
>>begin
>>  a := 1;    (* set LOCAL A=1 *)
>>  Global.a := 1;  (* set GLOBAL A=1*)
>>end;
> 
>>> B-)
> 
> cute feature B-)
> (just goes to show how unreadable pascal is B-)


I didn't come up with the smiley faces... :)
Newsgroups: rec.games.programmer
From: u882453@bruny.cc.utas.edu.au (Andrew King)
Subject: Re: TP game library
Organization: University of Tasmania, Australia.
Date: Wed, 22 Jul 1992 03:02:42 GMT

psalp@acad2.alaska.edu writes:


>	There's a lot of talk of game librarys on this group. Anybody mind if I
>post one I and a friend are writing to create nintendo type gamefiles? 

Yes.. please do...

>	P.S. By the way, try PC intern. It's a great source for info on
>scrolling and sprites. 
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>	I believe five impossible things before breakfast...
>	Six is one too many...
>		Albert L. Perrien II 
>			psalp@acad2.alaska.edu