Re: Work on improving/expanding 'HLA Adventure'
From: rsood (c.sood_at_worldnet.att.net)
Date: 12/10/04
- Next message: dunric_at_yahoo.com: "Re: Work on improving/expanding 'HLA Adventure'"
- Previous message: Percival: "Re: The move to 64-bit computing"
- In reply to: dunric_at_yahoo.com: "Re: Work on improving/expanding 'HLA Adventure'"
- Next in thread: Frank Kotler: "Re: Work on improving/expanding 'HLA Adventure'"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 9 Dec 2004 19:45:15 -0800
It looks like my idea has become irrelavent in the time it took me to
type this up but I was just going to say:
Frank wrote:
>I *don't* know how to write/use dlls in HLA. But I *do* know, >or
>strongly suspect, that this approach would make it difficult >to run
on
>Linux. It *might* be possible to write code with HLA which >would
produce
>a ".dll" for Windows, and a ".so" for Linux, but it seems like >a
>stretch.
>Paul's current game will run on Windows *or* Linux. It >*ought* to be
>possible to assemble these two executables from the >*same* source
file.
>I really haven't looked at Paul's latest version, but I think it
>comes
>in two versions. If so, I suspect the difference is in >the "console"
>calls. It would be nice to "reconcile" the two sources (if I'm >right
>that there *are* two).
I recognize this problem and admit to knowing nothing about Linux, but
I find it hard to believe that the Linux OS doesn't support dynamic
linking. There is nothing in the DLL file I see that is Windows
specific, so it should be possible for Linux to load it and use it.
The problem is I only know the Windows specific way to load a DLL.
>> I've got some ideas for
>> scenario editing that involve putting the verb and room >handlers in
>> DLLs which could then be switched in different >scenarios. The game
>> would then start by loading a scn file that looks something >like
this:
>I'm not sure why this would require the use of dlls...
It has to be in some kind of library because it contains code that has
to be executed. A script language that can be contained in a data file
is probably a better idea, but I'm not one for coming up with new
languages (at least not at this stage in my programming). I wanted
DLLs because that way people can swap and play scenarios without
editing the main source. It'd be like plug and play.
>> Version // to allow more info (such as >possibly
// whether a noun
>> NumRooms // moves on its own) to be included in >more
// advanced scn
>Good point! It might make for a confusing game to have >nouns moving
>around on their own, but it might make for some interesting
>possibilities. Definitely some version info! Maybe even >some "magic"
>before that, to confirm that we *are* reading a >legitimate ".scn"
file
>before we try to "parse" it (even for version info).
>> MoveTable
>> RoomDLLNames
>> NumNouns
>> NounStrings
>> NounDescriptions
>> LocationsTable
>> NumVerbs
>> VerbStrings
>> VerbDLLNames
>> plus some quest information
>> This would allow different scenarios having different >rooms, nouns
and
>> verbs to be played using the same "engine" (if I >understand that
word
>> correctly).
>Yeah, that's how I understand it, at least...
>> It would also make the code more structured and easier >to
>> follow.
>That would be a step in the right direction! :)
>> The one drawback I can see is that all the DLL functions will
>> have to be passed the same general set of parameters, >because there
>> will be no way for the engine to tell "okay, this verb is 'fight'.
>It
>> needs [such and such information]."
>The "object oriented" approach that Randy proposed might >offer a way
to
>deal with that.
>> It also might make the project
> >hard to maintain, but I think it'd be worth it.
>Anything that makes any project "hard to maintain" had >better have
some
>*real* strong points in its favor!!!
>> I also think it would be cool if the monsters moved >through the
game as
>> the player did (hence my comment above).
>That's a good idea. I think it would be possible to do >without such a
>massive restructuring...
>I'm not sure if Paul is looking for help making the >current "HLA
>Adventure" more "robust and complete", or looking for >someone to
"adopt"
>it so he can move on to other things. What we're offering, >so far, is
a
>"whole different approach to writing a game". The proposals >for a
"game
>engine" - object-oriented, dll-oriented, or otherwise - are
>interesting,
>but may not be what Paul had in mind...
I guess it would be kind of a waste if Paul plans on moving on or
implenting some other idea, but I'll write up my version anyway and
send it to him and he can do what he wants with it. If he ever decides
to move on to another text based adventure, he could consider
implementing it as a scenario of this one. If nothing else, it will
give me some experience with DLLs.
RSood
- Next message: dunric_at_yahoo.com: "Re: Work on improving/expanding 'HLA Adventure'"
- Previous message: Percival: "Re: The move to 64-bit computing"
- In reply to: dunric_at_yahoo.com: "Re: Work on improving/expanding 'HLA Adventure'"
- Next in thread: Frank Kotler: "Re: Work on improving/expanding 'HLA Adventure'"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
