Script or database?
The Sheep
There are at least two alternatives to handling external data files:
database-like and script-like
The database-like files are parsed and converted to actual in-memory objects
first, and then you can do any additional operations on them. The order they
come in, and some other things are irrelevant.
On the other hand, script-like files use some scripted commands to create the
objects in memory as they are parsed. The order, the actual environment and
other things are importatnt.
The problem I have now is: which to choose?
I don't want to use a scripting language as powerful as lua, to define game data.
The files should hold only the definitions of items, monsters, level themes, etc.
Any extensions to the game would be written in C and linked (statically, or
dynamically, as plugins) into game's engine.
Even if the data files would be `script-like', there would be no flow control
commands.
So, at first I wanted to make it just a database -- offcourse still human-readable.
But then, doing it as script allows me to control the process of game's initialization
better. I can, for exaple, load only the set of colors that would be used -- ignoring
all the other ones.
With database it's much easier to load and unload data -- there would be problems with
cancelling the effects of scripts when you want to unload them.
So, I'd like to discuss some pros and cons of these approaches.
--
Radomir `The Sheep' Dopieralski
To bee or not to bee -- this is the question!
Lucas Ackerman
interesting but often serve for managing art assets in modern games,
while scripting languages are about defining the proper problem domain
tools to make writing your game easier.
The Sheep <sh...@atos.wmid.amu.edu.pl> wrote in message news:<slrnbgaom2...@atos.wmid.amu.edu.pl>...
> There are at least two alternatives to handling external data files:
>
> database-like and script-like
>
> The database-like files are parsed and converted to actual in-memory objects
> first, and then you can do any additional operations on them. The order they
> come in, and some other things are irrelevant.
In this treatment, you're saying you want it to act like an extension
to the running game engine. That's fine, but this doesn't address
*how* it got to the running state, what the bootstrapping or creation
process for a new (or loaded) game is like. So it would seem you also
need an initilization subsystem or scripting language anyway.
> On the other hand, script-like files use some scripted commands to create the
> objects in memory as they are parsed. The order, the actual environment and
> other things are importatnt.
A smartly done scripting system would handle all the dependancies
without intervention, at a resonably fine granularity. There are lots
of ways to make module systems in Lua for example. Perhaps it's
better to think about what information you need to access, not what
goes on under the hood to prepare it for you. Game content code
shouldn't have to care.
> The problem I have now is: which to choose?
I think the problem is deciding what issues you really want it to
address.
> I don't want to use a scripting language as powerful as lua, to define game data.
Because your game development is moving along too quickly and easily,
so you want to make more work for yourself? Get real :) Lua is a
brilliant, tiny powerhouse.
I'm working on a game language in Lua, but that's neither here nor
there.
> The files should hold only the definitions of items, monsters, level themes, etc.
> Any extensions to the game would be written in C and linked (statically, or
> dynamically, as plugins) into game's engine.
>
> Even if the data files would be `script-like', there would be no flow control
> commands.
>
Bzzzzt. Thanks for playing.
What I think you mean to say, is that they're responsible for
providing access to representations of these game objects, while the
game code resides executable side. You obviously don't have to use
the scripting language for game code or extensions if you don't want,
but that's an independant issue.
What form the game objects are described in (as self-building objects,
lookup tables, or generating functions) is the real problem you need
to solve, and you should definitely leave it open-ended so you can use
the best tool for each job. Maybe monster stats should be tables, but
items should be clonable objects, and maps are configurable generation
procedures. However it works, you can always just provide the
resulting objects (monsters, items, maps) to your game code through
well defined interfaces, but leave the definitions very flexible.
There's no reason to artificially limit your options.
> So, at first I wanted to make it just a database -- offcourse still human-readable.
>
> But then, doing it as script allows me to control the process of game's initialization
> better. I can, for exaple, load only the set of colors that would be used -- ignoring
> all the other ones.
> With database it's much easier to load and unload data -- there would be problems with
> cancelling the effects of scripts when you want to unload them.
I think a database should be treated as transparent, the game code
should act as if it's all loaded all the time and proceed as usual,
but the DB can do all the real work lazily. That's kind of the point:
to not manage it manually.
Scripting language (like Lua) tend to be garbage-collecting, so you
can load whatever whenever and it will go away when it's no longer
needed. If a script just offers similar access to objects, it's
trivial to discard anything that's no longer needed, or persist
objects that aren't needed currently.
> So, I'd like to discuss some pros and cons of these approaches.
The DB is simpler, in that you'd be able to use popular DB software to
handle the real work. It lacks the power and flexibility of a
language like Lua however.
The scripting language takes more upfront work from a design
standpoint: deciding what your interfaces should be and how the system
is arranged. But given the basics, there's just so much more work it
can do for you.
The bottom line is that C code is much more brittle than DBs or
scripts are, so you want to change your interfaces and data structures
in C as little as possible. Whether you go with a DB or script
system, the key is to figure out what those interfaces need to do
first, then arrange to provide lots of resources and services to them
via the (DB or scripting) back-end. To roughly quote a software
engineering course I had once, "The primary problem in designing
software objects and interfaces is that of assigning
responsibilities."
-Lucas
The Sheep
> The Sheep <sh...@atos.wmid.amu.edu.pl> wrote in message news:<slrnbgaom2...@atos.wmid.amu.edu.pl>...
At beginning I want to apologize for not responding -- I was unable to connect
with internet for some time.
> In this treatment, you're saying you want it to act like an extension
> to the running game engine. That's fine, but this doesn't address
> *how* it got to the running state, what the bootstrapping or creation
> process for a new (or loaded) game is like. So it would seem you also
> need an initilization subsystem or scripting language anyway.
You apparently misunderstood me. I *don't* want to make possible to extend
the game engine by scripts. The external files are used *only* as data definition.
In particular, I don;t want to interpret any of the scripts while you're actually
playing the game.
The scripts I'm considering are to be only interpreted on startup and eventually on
loading/unloading of modules.
>> I don't want to use a scripting language as powerful as lua, to define game data.
> Because your game development is moving along too quickly and easily,
> so you want to make more work for yourself? Get real :) Lua is a
> brilliant, tiny powerhouse.
Maybe it is, but I want to write my game in C, not in Lua, with small, specialized
interpreter in C.
> What I think you mean to say, is that they're responsible for
> providing access to representations of these game objects, while the
> game code resides executable side. You obviously don't have to use
> the scripting language for game code or extensions if you don't want,
> but that's an independant issue.
The structures being defined are hardcoded -- the script should only `fill them in'.
> What form the game objects are described in (as self-building objects,
> lookup tables, or generating functions) is the real problem you need
> to solve, and you should definitely leave it open-ended so you can use
> the best tool for each job. Maybe monster stats should be tables, but
> items should be clonable objects, and maps are configurable generation
> procedures. However it works, you can always just provide the
> resulting objects (monsters, items, maps) to your game code through
> well defined interfaces, but leave the definitions very flexible.
> There's no reason to artificially limit your options.
Simplicity is the reason. All the objects are stored in tables of proper structures.
> The bottom line is that C code is much more brittle than DBs or
> scripts are, so you want to change your interfaces and data structures
> in C as little as possible.
Thanks for advices, I think I'll go back to database-like approach.
Jeff Lait
>
> The bottom line is that C code is much more brittle than DBs or
> scripts are, so you want to change your interfaces and data structures
> in C as little as possible.
I am rather unconvinced of that. It is a question of design - one can
as esily make a brittle DB as a brittle Script as a brittle C
implementation.
On my current roguelike, my platform is the Gameboy Advance. That
places a few restrictions on using SQL databases to store my data :>
Indeed, all my data, including graphics, is linked into the final
executable, so largely is converted to a C intermediary.
My initial implementation had the static initialized array of objects,
ie:
ITEM_DEF
glb_itemdefs[NUM_ITEMS] =
{
{
"knife",
ITEMFLAG1_ISSTACKABLE,
TILE_WEAPON,
MATERIAL_IRON,
2,
0,
ATTACK_KNIFE,
MINI_SWORD,
MAGICTYPE_NONE,
"\x00",
CURSECHANCE_NORMAL,
},
...
};
(These are not the actual objects, but the templates which the objects
are created from)
Now I suspect this is the sort of fragility you were talking about
with C code. If I wanted to add another flag, I'd have to add it to
every single one of my items, even if it had a default value for each
of those. One way to ameliorate this is to use multiple constructors
with default parameters. However, this remains unclear (what is that
2 referring to?) and not acceptable on the GBA as constructed data has
to be initialized at run time so consumes precious RAM (as opposed to
static tables which can be left in the near infinite ROM).
The way around this is similar to the approach taken with the art
assets: auto generate the required C code. I threw together a quick
parser, so I can instead:
DEFINE ITEM
{
CST name "unnamed item!"
ENM flag1 ITEMFLAG1 NONE
ENM tile TILE VOID
ENM material MATERIAL ETHEREAL
u8 weight 1
s8 ac 0
ENM attack ATTACK MISUSED
ENM minitile MINI NONE
ENM magictype MAGICTYPE NONE
ENMLIST intrinsic INTRINSIC NONE
ENM cursechance CURSECHANCE NORMAL
}
This defines the ITEM_DEF structure, along with default values to be
used when a full specification is not given.
ITEM KNIFE
{
name "knife"
tile WEAPON
material IRON
weight 2
attack KNIFE
minitile SWORD
flag1 ISSTACKABLE
}
And this defines a specific ITEM_DEF, the one mentioned above.
Now, in the code, I can access specific definitions using the
templates auto-generated enumeration (ITEM_KNIFE) and the relevant
field of the structure:
glb_itemdefs[ITEM_KNIFE].weight
My source code is thus independent of the layout of the structures -
if I add a new field, the old code only has to be recompiled, and if I
remove one, only the relevant code has to change.
- Jeff Lait
(POWDER: http://www.zincland.com/powder)
be...@sonic.net
>
> gli...@gweep.net (Lucas Ackerman) wrote in message news:<6d33ce44.03070...@posting.google.com>...
> >
> > The bottom line is that C code is much more brittle than DBs or
> > scripts are, so you want to change your interfaces and data structures
> > in C as little as possible.
>
> I am rather unconvinced of that. It is a question of design - one can
> as esily make a brittle DB as a brittle Script as a brittle C
> implementation.
> Now I suspect this is the sort of fragility you were talking about
> with C code. If I wanted to add another flag, I'd have to add it to
> every single one of my items, even if it had a default value for each
> of those.
I'm kind of still tackling items. I started making magic items a
few months ago, but I kept running into problems that, ultimately,
come back to not having the basics of items, effects, and inventory
properly handled. So I'm in the process of ripping out a bunch of
code and redesigning a chunk of the game.
:-(
I think I'm going to wind up extending a scripting language I've
already built for scriptable monsters to do item initialization
and construction too.
One reason is that it allows variants to be established recursively
and combinatorially. I'm not going to even attempt to deal with
database code; language code is a lot easier for me.
Bear
Paul Pekkarinen
> I am rather unconvinced of that. It is a question of design - one can
> as esily make a brittle DB as a brittle Script as a brittle C
> implementation.
One thing I recommend is replace source code and text based
approaches with a data/resource editor. Makes the life much easier.
The Sheep
I would disagree. It forces you to develop more programs at once --
the editor should `grow' together with the game.
I've seen effects of lost synchronization between the game itself
and it's editor.
Horrible.
Paul Pekkarinen
> > approaches with a data/resource editor. Makes the life much easier.
> I would disagree. It forces you to develop more programs at once --
> the editor should `grow' together with the game.
I have five editors for Kaduria and there is no need to
put them in the game itself. Making an editor for some task
might first seem nonsense, but when you work with lots of data
it will be much easier with a decent tool.
But either way an editor tool is better than maintaining for
example lists of random items by typing them in a text file or
source file.
Jeff Lait
I'm a big fan of editors. However, I'm a bigger fan of text files.
In my perfect world, you have the editors which can read/write text
files human readable text files. These text files can then be
processed appropriately into your raw format (.C code in my example).
You have:
Editor <-> Text File -> Binary -> Executable
A properly designed editor can avoid munging your text files, allowing
you to make quick patches of spelling errors without booting up your
data/resource editor. It also means that you are not reliant on the
resource editor for your build process - if your editor becomes
desynchronized, your development isn't frozen.
This also allows you to have many specialized editors/generators
rather than relying on a single system. This also allows you to start
populating the roguelike before you write the editor.
I've only got as far as the text file -> .C conversion, but as my .txt
file is only 2500 lines currently, it is still managable.
David Damerell
>But either way an editor tool is better than maintaining for
>example lists of random items by typing them in a text file or
>source file.
Sure, because I'd rather use a tool written by some random third-party
than Emacs.
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Rick C
news:jLf*hQ...@news.chiark.greenend.org.uk...
> Paul Pekkarinen <pau...@mbnet.fi> wrote:
> >But either way an editor tool is better than maintaining for
> >example lists of random items by typing them in a text file or
> >source file.
>
> Sure, because I'd rather use a tool written by some random third-party
> than Emacs.
I dunno about you but I'd rather edit Half-life levels in Worldcraft than in
Emacs. Actually, that goes for pretty much any commercial game for which
I've seen an editor, like the HOMM series and, say, Neverwinter Nights.
David Damerell
>"David Damerell" <dame...@chiark.greenend.org.uk> wrote in message
>>>But either way an editor tool is better than maintaining for
>>>example lists of random items by typing them in a text file or
>>>source file.
>>Sure, because I'd rather use a tool written by some random third-party
>>than Emacs.
>I dunno about you but I'd rather edit Half-life levels in Worldcraft than in
>Emacs.
But that is not the question here; the question is maintaining lists of
items or monster properties or whatever for a roguelike, a task for which
a powerful text editor is ideally suited.
I really don't see how you can imagine that the appropriate tool for what
is effectively 3D CAD is in any way relevant.
Paul Pekkarinen
> items or monster properties or whatever for a roguelike, a task for which
> a powerful text editor is ideally suited.
My simple graphical resource editor beats the most powerful
text editors in maintaining object lists. You can
a) see the objects in the list clearly
b) use the mouse to select an object and then place it in a list
Now, how much easier or faster any text editor can do that?
http://koti.mbnet.fi/paulkp/temp/urce.gif
Of course all RL's are not graphical, but I think you can make
same kind of tools for a text based RL too. Frames could be
letters and when you move mouse over, it will show the name
of the item.
David Damerell
>David Damerell <dame...@chiark.greenend.org.uk> wrote in message
>>But that is not the question here; the question is maintaining lists of
>>items or monster properties or whatever for a roguelike, a task for which
>>a powerful text editor is ideally suited.
>My simple graphical resource editor beats the most powerful
>text editors in maintaining object lists.
I see that you have not used Emacs properly.
>You can
>a) see the objects in the list clearly
There is no reason why recent Emacsen could not display these bitmaps.
>b) use the mouse to select an object and then place it in a list
Yeah, I really want to take my hands off the keyboard every time I want to
do something.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Paul Pekkarinen
> There is no reason why recent Emacsen could not display these bitmaps.
Good thing is that you have a hard head. It's good to have one
when you make roguelikes. I have never used Emacs and I didn't know
it can handle graphics as well. However we were talking about TEXT
editing vs. graphical resource editor. Well, whatever. I quit.
> Yeah, I really want to take my hands off the keyboard every time I want to
> do something.
(sarcastic voice) Yeah, why they ever invented mouse?
David Damerell
>David Damerell <dame...@chiark.greenend.org.uk> wrote in message
>>I see that you have not used Emacs properly.
>...
>>There is no reason why recent Emacsen could not display these bitmaps.
>Good thing is that you have a hard head. It's good to have one
>when you make roguelikes. I have never used Emacs and I didn't know
>it can handle graphics as well. However we were talking about TEXT
>editing vs. graphical resource editor.
Emacs _is_ a text editor. It's just an amazingly powerful one (in this
particular case, handling a peculiar character set that happens to be a
bunch of bitmaps for RL objects should not be beyond it.)
>>Yeah, I really want to take my hands off the keyboard every time I want to
>>do something.
>(sarcastic voice) Yeah, why they ever invented mouse?
Your sarcasm does not conceal your ignorance. HCI research regularly shows
that mouse operations are amazingly inefficient, especially when
interspersed with keyboard operations (hence requiring frequent hand
movement). There has to be some pressing reason why a pointing device is
ideal for the operation before this inefficiency is tolerable.
be...@sonic.net
>
> Your sarcasm does not conceal your ignorance. HCI research regularly shows
> that mouse operations are amazingly inefficient, especially when
> interspersed with keyboard operations (hence requiring frequent hand
> movement). There has to be some pressing reason why a pointing device is
> ideal for the operation before this inefficiency is tolerable.
Chill, guys. The keyboard is for people who use language to tell
the machine to do what they want.
But for people who haven't spent time learning the necessary
languages, the mouse is the point-and-grunt stage of communication
that lets someone order food whose name he doesn't know off a
menu in a language he hasn't learned by pointing at the pretty
picture and showing the waiter some money.
Clearly, language is more efficient if you're up the learning curve
and allows for a hell of a lot more subtlety (you can tell the waiter
how you want your food cooked or seasoned, for example). Just as
clearly, mousing, and not cluttering up the menu with subtleties
and tiny variations, is more efficient for beginners and newbies.
A good interface ought to fully support both: meaning, there's nothing
important that the application does that someone mousing around can't
discover, and there's nothing at all that the application does that
can't be invoked directly from the keyboard without touching the
mouse.
Emacs is an excellent editor for people who've learned it's language.
I love it, myself. But if you don't want to bother learning its
language, its mouse interface is horrible. So newbies always hate
it. Most of the people who love emacs were once newbies who were
*forced* to learn it...
Bear
R. Alan Monroe
>HCI research regularly shows
>that mouse operations are amazingly inefficient, especially when
>interspersed with keyboard operations (hence requiring frequent hand
>movement). There has to be some pressing reason why a pointing device is
>ideal for the operation before this inefficiency is tolerable.
The mouse is more suited to picking arbitrary cells from a 2d array
(much like the screenshot posted). Using keys, you'd have to resort to
right, right, right, right, down, down, down kind of stuff, in the
worst case. Even doing some kind of alt-columnletter, alt-rowletter
which cuts it down to 2 keystrokes would be awkward for a lot of
people. Maybe there are other methods I'm unaware of though.
Alan
The Sheep
> David Damerell wrote:
> Just as
> clearly, mousing, and not cluttering up the menu with subtleties
> and tiny variations, is more efficient for beginners and newbies.
I think an author should know the language he invented, so this is it
for mouse-driven resource editors... ^^)))
Jeff Lait
Depends on the data. For raw grid selection, you are correct.
However, that screenshot could also be facilitated through some
natural language equivalents to the icons (which there must exist).
Thus, to get to the sword I may type "/sword" rather than "r3c5".
This requires a bit more thinking than just mouse clicking, but makes
it easier to build more complicated commands to perform a lot of
processing simultaneously. This is why a text editor can often beat a
special built GUI - the text editor gets search & replace and a very
complicated macro language embedded for free. The special built GUI
requires rebuilding all those components.
It all comes down to familiarity & the target audiance. In a RL
design, chances are you yourself are the target audiance, so do
whatever you prefer :> For me, I use text files.
- Jeff Lait