Defining Weapons

DaniJ

<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Beta 7, Engine, Games, jDoom, jHeretic, jHexen.</i>

Doomsday 1.9.0-beta6 sees the introduction of the beginnings of a new player inventory system that I've been working towards. This new system will cover everything that a player may collect/be given including weapons, powers and (in the case of Heretic and Hexen) store-able items for later use. The plan is that all the existing code for this stuff will be replaced with a new (common) extendible system.

For 1.9.0-beta7 I would like to continue this work and one of the tasks will be doing something with the currently hardcoded <tt>weaponinfo_t</tt> arrays (e.g., like those belonging to jDoom in <em>/plugins/jdoom/src/d_items.c</em>).

My current plan is to do something similar to the <tt>mobjinfo_t</tt> shared structures, editable via DED (would "Weapon" be a good name for these?).

Any thoughts?

skyjake

I like the notion of a common inventory system.

I would like to reduce the number of shared data structures between the engine and the games eventually down to none. So maybe the API for accessing the weapon info (and other item parameters) could be through the Def_* methods (or even Values?). Or via some other functions -- I would prefer not to add new shared data, though.

DaniJ

Perhaps what we actually need is a way for plugins to leverage the DED parser so that it can be used to read game-domain definitions. Naturally this would mean a complete rewrite of the DED file reader but that is long overdue anyway.

EDIT:
Thinking about this further, if a new text file parser was introduced with full control over tokens, syntax mnemonics (etc), this could then be used for all textual data which the engine and the games currently have separate parsers for, for example; jHexen's MAPINFO stuff.

Perhaps the code you've already written for Hawthorn's script parser could be used here?

skyjake

<blockquote>Naturally this would mean a complete rewrite of the DED file reader but that is long overdue anyway.</blockquote> I'll say.

This would be an opportune time to do the rewrite and rethink the definition system.

At least the Lex class would be helpful from Hawthorn, although what it does is very simple (reading characters and keeping track of which line the parsing is progressing). The other classes built on top of that assume the Haw script syntax (which is much like Python, actually). I would assume that we keep the basic DED syntax the same as currently, so they won't be of much help.

<blockquote>Perhaps what we actually need is a way for plugins to leverage the DED parser so that it can be used to read game-domain definitions.</blockquote> We should compile a list of things that the revised DED system should be able to do, a set of requirements basically. A wiki page?

DaniJ

Agreed. Beta7 does indeed seem like the right time to be rewriting the DED parser. A wiki page sounds like a good idea to me.

Top of my list of parser-level requirements would be; definable constants and expressions (which could be stored to constants). The idea here is that values for constants could be passed to Doomsday on the command line, which could then be referenced in DED files. This in turn would allow Snowberry .addons to feature custom controls for setting those constants via the GUI.

As for the syntax itself, I'm pretty happy with the current syntax but perhaps we could take this opportunity to revise that also, migrating to a Haw-like syntax? The existing DED parser could be moved into a plugin and then reserved for backward compatibility with existing addons.

This would allow us to introduce some new fundamental concepts aimed at resolving some of the current issues e.g., a rule system governing when a definition should be used (IWAD/PWAD etc...).

skyjake

<blockquote>This would allow us to introduce some new fundamental concepts aimed at resolving some of the current issues e.g., a rule system governing when a definition should be used (IWAD/PWAD etc?).</blockquote> This reminds me of the bias lights, where lights are defined for a particular map. I think we should generalize this and create a scoping mechanism that allows any set of definitions to have effect only when certain conditions are in effect (chiefly, the map, PWAD/IWAD, game mode, etc.). This needs syntax-level support, I think.

<blockquote>As for the syntax itself, I?m pretty happy with the current syntax but perhaps we could take this opportunity to revise that also, migrating to a Haw-like syntax?</blockquote>
I think that Haw isn't suitable for the declarative data that DEDs basically are. Instead we should focus on adding the expressions you mentioned, and give more power to the block-beginning statements, where currently "Copy" is the only modifier that is available. For instance, the scoping could be part of it.

DaniJ

<blockquote>Instead we should focus on adding the expressions you mentioned, and give more power to the block-beginning statements, where currently ?Copy? is the only modifier that is available. For instance, the scoping could be part of it.</blockquote>
Note that the new Material definitions are designed to work differently than other definition types in that definitions for a given Material identifier are cumulative, rather than later Material definitions overriding earlier ones completely, at block-level. This is so that the engine automatically generates materials from DOOM TEXTURE1/2 definitions, flats, etc..., which can then be patched using Material definitions in DEDs. The game plugins make use of this feature, patching the auto-generated materials to specify which should be skymasked, draw fully-bright etc, without needing an API specifically for that.

I'm thinking that in order to roll out similar functionality to all definition types that it should be done as a new block-beginning modifier, like Copy.

skyjake

I see. So maybe something like "Extend"? Also, for convenience, we could have the ID of the definition specified in the beginning statement:

<pre>Material "MYMAT" {
Thingy = 2
....
}

# A derivative definition.
Material "X-MYMAT" Extends "MYMAT" In doom2|map04 {
Thingy = SOME_CONST + 4;
}

# A patching definition.
Material Mods "MYMAT" In doom2|map04 {
Thingy = SOME_CONST + 4;
}
</pre>

The "In" would specify the scope where the definition applies. You might also have:

<pre>In doom2 {
Material "SOMEMATR" {
# Scoped to doom2
}
}</pre>

This would still allow using "Copy" as before, to duplicate the previous def.

DaniJ

That looks ideal to me.

Another feature of the current Materials stuff is namespacing where each material belongs to a namespace, with the ID as the key. This is needed so that two materials with the same name can co-exist as there are name overlaps in TEXTURE1/2, flats etc.

Currently this is handled as a field in the Material definition but might we want to introduce a more general namespacing scheme, as an extension of the scoping mechanism?

skyjake

I'll copy the DED parser discussion here to a proposal.