Re: cementing relations (and RPG making)
>G'day from snowy Canada, Roderick!
>
>Thought I'd drop you a line, considering that your topic
on the Euphoria list about RPG making interested me. I had
actually been thinking of a similar project for the last little
while, and have been working on drafting (on paper) my plans
for it. Basically, here's what I've got planned, if you're interested.
Oh believe me, I'm interested! Hmm, I'll share my thoughts as I go =
through this...
>* everything is driven by two things -- maps and objects. Both
can be user-defined using beautiful (Euphoria) code to give
the user more flexibility over game control
Sounds good so far. Although it raises a question I'll bring up further =
down.
>* everything that objects do is defined by object code. There
are built-in variables to test the object's state (i.e. touched,
trapped, hit, etc.)
Again, this sounds good and makes since. I had been working on some =
foundational object classes for an RPG using my Quartz routines (I'll be =
zipping them with documentation as soon as I get around to it...) =
Object-oriented programming seems ideally suited for handling an RPG. =
However, I hadn't gotten as far as thinking how to adapt it to generic =
RPG-making.
>* maps themselves can contain object code in their headers
Hmm, I would suggest that perhaps maps could themselves be objects, but =
apparently you're thinking of doing this in a much different way than I =
was.
>* all object code libraries are standard .e code, making for easy
addition of new functions / features
Yep. Makes sense.
>* and, for the grand finale, _it's all text-driven_. Maps are
sequences, object code is text, and the final product is a 'script'
to the game with accompanying graphics/sound which is run by an
engine. A text-based approach allows the following:
I think I like the idea. 
Seems to fit well.
> 1) more than one interpreter can run the same code (possible
portability, if others wanted to run it in other langs)
And would allow future versions of the interpreter to handle new, more =
complex .rpg files (or whatever they'll be called--I'll refer to them as =
this for now) as well as the old ones. A plus.
> 2) more flexibility and control for the end-user/creator by
allowing them to fully command the object code
=20
True.
> 3) editors can be made to graphically edit maps, object code,
etc. If you _only_ have a graphical editor, code editing
and detailed changed get very hard very quickly.
>
>Anyway, I've been incredibly busy with school lately (working on
Computer Science projects [unfortunately in QBasic, which we've been
running sans help-menu because either our teacher doesn't want to
install it or doesn't know how. I'm hoping it's the former.]) and
have kept it in the planning stages. Hope this at least gives you
some good ideas, and if others are interested, drop me a line.
Well, it all looks well thought-out. But I have that question: were you =
intending the objects of the .rpg files to be written in literal =
Euphoria text? Or just a simple "scripting" lingo yet-to-be-developed?
Let me detail what I'm currently working on, so you can see if there's =
any ideas you'd like to incorporate. My original plan was just to make a =
RPG, in Euphoria, with a superhero theme (everything else seems =
overdone). After determining it might be nice to allow the skill set and =
powers to be more open-ended, I whipped together Quartz (which is a =
subset of a larger project) to help with the object-oriented aspect.
I had intended on making EVERYTHING in the game an object, including the =
display areas, characters, etc. I had also planned a bit of detail to =
allow some nice effects; for example, the composition of all physical =
objects would be an object (one of the constants ICE_COMPOSITION, =
FLESH_COMPOSITION, METAL_COMPOSITION, etc.) Attacks would be objects, =
and would either be deemed physical or based on one of a few basic types =
of energy. This allows effects such as having all physical objects =
composed of ice take much greater damage from a heat-based attack than a =
cold-based attack.
Currently, I've finished the composition class (which also allows =
morphing into different states--solid. liquid, etc.--based on object =
temperature), and am finishing up the attribute-set class and the =
skill-set class, all of which I'm building the character class around.
Now, I plan to continue development on *this* setup regardless, but =
perhaps the structure could be scaled down and simplified for use with =
your ideas? The RPG engine objects could just be simplified versions of =
these objects--i.e., a character would be a sequence: {"Superman", 10, =
10, 10, 10, "Superman is very powerful, and all of his attributes rank =
at level 10."}. A description of a room might be: {"Fortress of =
Solitude", "Entrance", LARGE_SIZE, GRAPHICAL_LAYOUT_0098, =
ROOM_DESCRIPTION_TEXT_0098, NORMAL_VISIBILITY, EXIT_LIST}. One of my =
design goals was that characters saved to disk from one game could be =
used in a future one, possibly of a different theme. That would be even =
easier to implement in an RPG engine if the character objects were =
simplified.
The actual code (methods) for the objects could be included as class =
descriptions within the engine, simplifying things there. This way, all =
possible actions for ALL objects would be contained in the engine--how =
attacks are made, how to display objects, and such--but the details of =
the *constant* objects (the specs of each available power/skill, =
TEXT_BLOCK_0001 through TEXT_BLOCK_9999 for conversations, all built-in =
creatures and items, etc.) would be stored in the .rpg file.
Granted, this seems to make the .rpg files very flexible, but would also =
make it somewhat harder for others to write interpreters for the files, =
as opposed to designing a scripting language and detailing exactly how a =
power or skill works in the .rpg file, with the interpreter just =
following the script. In any case, I'm not stuck on any one method =
(other than SOMEHOW being object-based); let me know what you think.
Rod Jackson
|
Not Categorized, Please Help
|
|
