lmbailey@vela.acs.oakland.edu (Laurana Bailey) (06/10/91)
Hello all. I am trying to write my own Text Adventure game and was wondering if there were any others who have written such for the Amiga who would be willing to let a beginner study their source code for ideas and techniques. I don't have any delusions of going commercial with these things and I would give credit in the program for any code that I used from the original source. I would release it as a Shareware product if I thought it good enough, though I doubt my first attempt will be anything that great. Thanx much ahead of time to anyone willing to help me out. If anyone knows of any FTP sites that have TA source, that would help too. Laurana -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ |Just another lemming... | Yet another Amiga maniac set loose | | | on the world...and you thought things| |lmbailey@vela.acs.oakland.edu | couldn't get any worse. |
sheley@convex.com (John "Dumptruck" Sheley) (06/10/91)
In <6943@vela.acs.oakland.edu> lmbailey@vela.acs.oakland.edu (Laurana Bailey) writes: >Hello all. I am trying to write my own Text Adventure game and was >wondering if there were any others who have written such for the Amiga >who would be willing to let a beginner study their source code for >ideas and techniques. I don't have any delusions of going commercial >with these things and I would give credit in the program for any code >that I used from the original source. I would release it as a >Shareware product if I thought it good enough, though I doubt my first >attempt will be anything that great. > >Thanx much ahead of time to anyone willing to help me out. If anyone >knows of any FTP sites that have TA source, that would help too. My advice to you would be to use adl (adventure definition language). It will save you a lot of work, as it has: a fairly robust input parser, built-in code for handling swapping in/out text blocks, and all the database manipulation routines built into the language. Best of all, the source code builds on both unix systems and amigas, and your adl source is portable between either platform. Definitely a nice package. You can ftp it from abcfd20.larc.nasa.gov (128.155.23.64) - can't remember the exact directory, though. >Laurana >-- >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >|Just another lemming... | Yet another Amiga maniac set loose | >| | on the world...and you thought things| >|lmbailey@vela.acs.oakland.edu | couldn't get any worse. | John Sheley Convex Computer Corp. sheley@convex.com
ludde@cyklop.nada.kth.se (Erik Lundevall) (06/11/91)
To: In article <sheley.676564285@convex.convex.com> sheley@convex.com (John "Dumptruck" Sheley) writes: > My advice to you would be to use adl (adventure definition language). It > will save you a lot of work, as it has: a fairly robust input parser, built-in > code for handling swapping in/out text blocks, and all the database > manipulation routines built into the language. Best of all, the source code > builds on both unix systems and amigas, and your adl source is portable > between either platform. Definitely a nice package. > > You can ftp it from abcfd20.larc.nasa.gov (128.155.23.64) - can't remember > the exact directory, though. ADL is also available on a Fish disk, Fish 91, I believe. Definitely a nice package. > > John Sheley > Convex Computer Corp. > sheley@convex.com -- -Erik Lundevall "God is real, unless declared integer." ludde@nada.kth.se | uunet!cbmvax!cbmehq!cbmswe!adder!ludde
kskelm@happy.colorado.edu (06/11/91)
In article <LUDDE.91Jun10204709@cyklop.nada.kth.se>, ludde@cyklop.nada.kth.se (Erik Lundevall) writes: > To: > In article <sheley.676564285@convex.convex.com> sheley@convex.com (John "Dumptruck" Sheley) writes: > >> My advice to you would be to use adl (adventure definition language). It >> will save you a lot of work, as it has: a fairly robust input parser, >> code for handling swapping in/out text blocks, and all the database >> manipulation routines built into the language. Best of all, the source >> builds on both unix systems and amigas, and your adl source is portable >> between either platform. Definitely a nice package. >> Or if you're in a spending kinda mood, try using Visionary, soon to be released by Oxxi/Aegis. +------------------------------------------------------------+ | /// Kevin "Visionary will be done RSN" Kelm | | /// kskelm@happy.colorado.edu | | \\\/// "Reality is subjective-- if you can make your own, | | \XX/ then who's crazy? That's entertainment software!"-me | | C code run. Run, code, run--PLEASE! | +------------------------------------------------------------+
kuerten@Informatik.TU-Muenchen.DE (Kuerten) (06/11/91)
lmbailey@vela.acs.oakland.edu (Laurana Bailey) writes: >Hello all. I am trying to write my own Text Adventure game and was >wondering if there were any others who have written such for the Amiga >who would be willing to let a beginner study their source code for >ideas and techniques. I don't have any delusions of going commercial >with these things and I would give credit in the program for any code >that I used from the original source. I would release it as a >Shareware product if I thought it good enough, though I doubt my first >attempt will be anything that great. >Thanx much ahead of time to anyone willing to help me out. If anyone >knows of any FTP sites that have TA source, that would help too. Well u might check out Fish Disk 41 and 90/1/2 (don't know wich one of them) for the ADL (Adventure Definition Language) and the AmigaVenture or AdvSys, all of them are tools to create Text Adventures on an Amiga. Hope I could help, Michael
lmbailey@vela.acs.oakland.edu (Laurana Bailey) (06/12/91)
In article <sheley.676564285@convex.convex.com> sheley@convex.com (John "Dumptruck" Sheley) writes: | | | >Hello all. I am trying to write my own Text Adventure game and was | >wondering if there were any others who have written such for the Amiga | >who would be willing to let a beginner study their source code for | >ideas and techniques. I don't have any delusions of going commercial | >with these things and I would give credit in the program for any code | >that I used from the original source. I would release it as a | >Shareware product if I thought it good enough, though I doubt my first | >attempt will be anything that great. | > | >Thanx much ahead of time to anyone willing to help me out. If anyone | >knows of any FTP sites that have TA source, that would help too. | | My advice to you would be to use adl (adventure definition language). It | will save you a lot of work, as it has: a fairly robust input parser, built-in | code for handling swapping in/out text blocks, and all the database | manipulation routines built into the language. Best of all, the source code | builds on both unix systems and amigas, and your adl source is portable | between either platform. Definitely a nice package. | | You can ftp it from abcfd20.larc.nasa.gov (128.155.23.64) - can't remember | the exact directory, though. Thanx much for the help. I do appreciate it. On a slightly related note: Would someone mind explaining to me exactly when I should alloc memory and how I am supposed to know how much I will need? I took a C class at school and am applying the basics I learned to help me learn Amiga specific stuff. One thing we never had to worry about seeing as we were writing on a mainframe, was memory allocation. I could use a crash course in knowing when it is needed and how much to ask for. Thanx again. Laurana -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ |Just another lemming... | Yet another Amiga maniac set loose | | | on the world...and you thought things| |lmbailey@vela.acs.oakland.edu | couldn't get any worse. |
ttr1415@helios.TAMU.EDU (Thom Robertson) (06/14/91)
Welllll,,,
This is some code you might want IF your adventure was to be graphicall
(al la Ultima and Company).
This code was developed under 1.3 in Lattice C 5.04.
**********cut here************adventmap.c**************
/* These are the AdventMap functions.
incept 11/5/90 */
#include <exec/types.h>
#include <exec/memory.h>
#include <intuition/intuition.h>
#include <intuition/intuitionbase.h>
#include <graphics/gfx.h>
#include "advent_map.h"
/* This routine displays the visible area of the map on the screen,
together with the player and any objects on the screen.
*/
void display_map(world,game)
struct world *world;
struct game_data *game;
{
void display_buffer(),assemble_buffer();
assemble_buffer(world,game,game->you_x - world->win_w/2,
game->you_y - world->win_h/2);
display_buffer(world,0,0);
}
/*******************************************************************/
/* this routine displays the visible part of the map, and SCROLLS it in
the direction given at the speed given.
direction = 0-7, 0 is up (North)
1 is up and right
2 is right
3 is down and right
4 is down
5 is down and left
6 is left
7 is up and left
speed = 1 and up, actual speed is = speed X 1/6 sec.
RETURNS: 0 if successful, -1 if the player can't move there.
*/
int move_player(direction,speed)
int direction,speed;
{
return(0);
}
/*******************************************************************/
/* this routine allocates a bitmap and attaches it to the world
structure to be used as a temporary rendering area for the
previous routines.
Incidently, the world structure's tempras1 and tempras2 are
initialized, and tempras1->BitMap is pointed to the world->bm
RETURNS: 0 if OK, -1 if couldn't allocate buffer (CHIP RAM!)
*/
int alloc_world_buffer(world)
struct world *world;
{
int i,x,y,d;
struct Image *picture;
picture = (struct Image *) *(world->picture);
x = picture->Width * (world->win_w + 1);
y = picture->Height * (world->win_h + 1);
d = world->rp->BitMap->Depth;
world->bm.Planes[0] = (PLANEPTR) AllocMem(RASSIZE(x,y) * d,
MEMF_CHIP | MEMF_CLEAR);
if (world->bm.Planes[0] == NULL) {
return(1);
}
i = 1;
while (i < d) {
world->bm.Planes[i] = world->bm.Planes[i-1] + RASSIZE(x,y);
i++;
}
world->bm.BytesPerRow = RASSIZE(x,1);
world->bm.Rows = y;
world->bm.Flags = 0;
world->bm.pad = 0;
world->bm.Depth = d;
InitRastPort(&(world->tempras1));
InitRastPort(&(world->tempras2));
world->tempras1.BitMap = &(world->bm);
return(0);
}
/*******************************************************************/
/* this routine DE-allocates the bitmap attached to the world
structure.
This routine ASSUMES the bitmap was allocated as one big block!
*/
void dealloc_world_buffer(world)
struct world *world;
{
/*int i;*/
struct BitMap *bitmap;
bitmap = &(world->bm);
if (bitmap->Planes[0] != 0) {
FreeMem(bitmap->Planes[0],bitmap->BytesPerRow *
bitmap->Rows * bitmap->Depth);
world->bm.Planes[0] = 0;
}
}
/*******************************************************************/
/* This routine is used by the others to assemble the displayable picture
in the world structure's bitmap.
the x and y arguments are in map positions. They are for the upper
left of the display area, NOT the player's position.
*/
void assemble_buffer(world,game,x,y)
struct world *world;
struct game_data *game;
int x,y;
{
int i,j,w,h,space;
struct Image *picture;
extern struct Image mountain;
picture = (struct Image *) *(world->picture);
w = picture->Width ;
h = picture->Height;
printf("boo1");
printf("h = %d, tot. h = %d\n",world->bm.Rows,h*(world->win_h+1));
for(j = y;j<y+(world->win_h);j++) {
for(i = x;i<x+(world->win_w+1);i++) {
space = (int)world->map[j*world->map_x+i];
if (j<0 || i<0 || j>world->map_y || i>world->map_x)
space = (int)world->edge_char;
picture = (struct Image *) *(world->picture + space);
printf("x= %d,y= %d ",i-x,j-y);
DrawImage(&(world->tempras1),picture,w*(i-x),h*(j-y));
}
printf("\n");
}
printf("boo2");
}
/*******************************************************************/
/* This routine ClipBlits the world structure's bitmap to the display
window. Currently I will use a WaitTOF for this, as I don't think
anything more is neccessary.
the x and y arguments are in pixels. They are offsets from the
upper-left of the temporary bitmap.
*/
void display_buffer(world,x,y)
struct world *world;
int x,y;
{
int w,h;
struct Image *picture;
picture = (struct Image *) *(world->picture);
w = picture->Width * world->win_w;
h = picture->Height * world->win_h;
WaitTOF();
printf("boo3");
ClipBlit(&(world->tempras1),x,y,world->rp,world->win_x,
world->win_y,w,h,0xc0);
printf("boo4");
}
***********cut here****************adventmap.h************
/* this code is the include file for my adventure map creation and
display routines, collectively called "advent_map".
incept 11/5/90 */
struct world {
char *map; /* map is a 2-dimensional character array. each character
is a location the player can see (and maybe move through).
NOTE: this is actually just one dimensional, and should be
accessed like " map[y*y_size+x] ".
*/
int map_x,map_y; /* x and y size of map */
char edge_char; /* this is the character used when the display module
is showing a space that is off the edge of the world
(needles to say, the player can't go out there).
*/
char *move_map; /* this is a 1-dimensional array. each character
corresponds to the associated type of landscape. A
logical TRUE means the player can't move into this
type of space. */
struct RastPort *rp; /* this is a pointer to the rastport we will be
displaying the map on. */
int win_x,win_y,win_w,win_h;
/* these are the dimensions of the "window" used to display the
map on the screen. This is NOT a real Amiga window, but just the
area we're gonna use to display on. The x and y are in pixels
from the upper-left of the given RASTPORT. The w and h, however,
are in MAP SPACES. The size of each map space is gotten from the
first graphic picture in the list. */
APTR *picture;
/* This is a pointer to an array of pointers to graphics which are
the pictures we use to make the map display.
right now I'm using Images just to facilitate things, but I will
use BitMaps later because they are more flexible.
*/
struct RastPort tempras1,tempras2;
/* these are two rastport structures to be used in assembling
the picture. */
struct BitMap bm; /* this is a bitmap we will
use as a temporary graphic area. We assemble the
map here, and blit it all at once to the rastport.
This should be allocated one space bigger in both
directions, so we can do smooth scrolling. */
}; /* end of "struct world" */
struct game_object {
int x,y; /* these are coordinates of the object relative to the map,
not the player or the window. */
char thing; /* this is the reference to the image used to display the object
on the map. */
struct game_object *next_object;
};
struct game_data {
int you_x,you_y; /* where the player is on the map. */
struct Image *you; /* pointer to the image of the player to be placed
in the middle of map display*/
struct game_object *first_object;
/* this is a pointer to the first game_object in a linked list. */
struct Image *picture; /* this is a pointer to an array of images (just
like the "picture" variable in the world structure.
difference is, this array is for things that are
ON the map with the player (chests, monsters, etc.)
*/
}; /* end of "struct game_data" */
*****************cut here************************************
Anyone can use this code, as long as
1) You give me a little credit, and
2) You let me in on what you're using this code with. I love Adventure
games, or I wouldn't have written this, so let me help you if you want to
use it :)
Thom Robertson
ttr1415@helios.tamu.eduAlex_Topic@resbbs.UUCP (Alex Topic) (06/14/91)
This sounds real interesting, I'm also working on a TEXT type game. But it
will be a multiplayer one that works with the Dialog BBS software. Which
basically will work if my program stays within its own CLI window...
Hmmm the problem I'm haveing is the desigining aspect of the game. I
was thinking about haveing it like this..
Have a BIG games.library!!! and have User.modules for each phone
line..etc It will have alot of interprocess communication happening in
it, since I want it to be fully teractive.,.
Hmmm the game world will be on a grid type system.. A 2 dimensional
array.. 100x100=10000 sectors.. 58 bytes each.. but my demo version
will just have 10x10=100sectors.. and very simplfied!!
the question I ask to anyone on the USENET.. Is should I use a
library for all my game routines???
In my user modules I will simple allocate memory for players structure
to work with the RUN-TIME library... so no confusion is about.. then once
that is done.. I will jump right into the LIBRARY and the rest is the games
code...
Anyone have a good idea how to write a library in 'C'?? hmmm I'm
new to 'C'.... oh well later all!
A.t.lmbailey@vela.acs.oakland.edu (Laurana Bailey) (06/15/91)
Thanx for the routines, but I do not intend to do any graphics of any sort. I just want to do a simple (or so I thought) text adventure. I do appreciate the help and I have captured the routines for the rare possibility that I ever try to do a graphic adventure. I gotta hope I survive doing the text adventure first! Laurana -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ |Just another lemming... | Yet another Amiga maniac set loose | | | on the world...and you thought things| |lmbailey@vela.acs.oakland.edu | couldn't get any worse. |
davewt@NCoast.ORG (David Wright) (06/17/91)
In article <Alex_Topic.3432@resbbs.UUCP> Alex_Topic@resbbs.UUCP (Alex Topic) writes: > Have a BIG games.library!!! and have User.modules for each phone >line..etc It will have alot of interprocess communication happening in >it, since I want it to be fully teractive.,. This is the best way to do it. Having done a lot of work on Amiga Empire, writing my own new multi-player space game in SAS/C, I have found that writing the entire thing as a library is the best way all around. Your only other real choice is to make the user stuff one big program which is residentable, but this has a bad side effect. Should you wish to update the library (add new commands, fix bugs, etc.) every user program will have to be recompiled as well. You will also need to write many versions (all of which are again huge) for things like ARexx versions, serial port versions, etc. if you want it to run on BBS systems besides DLG. By writing all the game-specific code in one library, it only takes up space on disk (and in RAM) once, and the library can be upgraded without recompiling all your "client" programs. > In my user modules I will simple allocate memory for players structure >to work with the RUN-TIME library... so no confusion is about.. then once >that is done.. I will jump right into the LIBRARY and the rest is the games >code... Exactly. And in fact, you can even put a "allocate" function into your library so that client programs don't have to know how big the structure is. That way you can change it later and again not have to recompile programs. > Anyone have a good idea how to write a library in 'C'?? hmmm I'm >new to 'C'.... oh well later all! The game I am working on is tenatively called "Imperium" (all I have left to do is add the combat code) and is a multi-player space Empire-like exploration game. It makes use of all of the above things (plus all the "clients" are "pure" and can be made residentable, so you only spend about 32k per "client" after the first is loaded), and I would not even consider doing it as anything other than a shared library. You also might want to consider creating a "standard" linkable object which people can use to create "doors" for other BBS systems. In Imperium I made up a module called "ModImp" (for Modular Imperium) which contains all the code for opening the Imperium library, handling command-line args, etc. All that people have to provide is another "module" which contains the user I/O functions they wish to use, plus some utility functions used by ModImp that are "module" specific (such as the strings to print in the log, the title bar text for any console windows opened, etc.). Doing this allows the the "modules" created by users to know nothing about Imperium or the Imperium library. I am providing the source to the serial port client as an example of what a "module" should look like (the console client could also be written this way, but I didn't feel it was worth the extra indirection and most of the other features (such as command-line/WB arg parsing) would basically be duplicated). Dave
Alex_Topic@tvbbs.UUCP (Alex Topic) (06/20/91)
Nice to see someone like you reply, who knows what he is doing. Yep the
system which will run my game has 12lines right now. It also runs
Amiga.Empire, the only problem with that game is its not as interactive. But
now that I heard you plan to do that, that is really great!
Yeah I love interactive games, eventualy one day I want to make a
special term and program to send little packets of data.. Something like a
Game.Protocal! So imagine playing Starglider 2 in a real-time world! Now
thats the type of games I love..heh Look at Firepower! Now thats bearly
touching the surface..heh
Anyways I figured out that I will use a Library and those
UserModules. I really don`t plan on converting it to other BBS software. DLG
seems to be thee multiline bbs software of the Amiga. Actually I plan on
haveing 2 versions! 1 which will work with that SERial SERVER program, only
stuff to be changed from the DLG version.. Is the usermodule %43??thingy
flag! which tells which serialport or line that user is on. I plan on
makeing a program or system for that SERSERVER so it keeps track of where the
serial.person is! heh
Ohya I think I figured out how I will have a Command Parser! I plan
on useing some of the stuff which is in the CSHELL program.. Rawgets()! But I
will have to modifiy it abit to make it abit more powerfull or to suit my
needs. I have to do the stuff in RAW mode, so it can detect the ^C!!!
Hmmmm ohya when dialog sends ^C to the usermodule!! DO I wait
for...
wait(12bitset) something like that? hmmm is that what you do? hmmmm..
Ohya have you ever played MUDS? On the UNIXes.. now those are pretty
good multiplayer games..heh played afew on BERKELEY system..eh Ohya if you
want to see my game in the future, or my friends awesome
teleconference...call
Resonance 604-322-5100 12line DLG!! its pretty cool!..
A.t.