Re: Freenukum game data

Am 07.11.22 um 10:37 schrieb Simon McVittie:
> On Mon, 07 Nov 2022 at 08:43:25 +0100, Wolfgang Silbermayr wrote:
>> It also extracts all files in lowercase, haven't looked at what GDP does.
>> Currently, FreeNukum can only load these, although I intend to change that

[...]

> Teaching your engine to be able to load files case-insensitively would
> be nicer for people who have copied the data directory from a Windows
> installation without using a special tool, though.

That would be my preferred way, as it imposes less requirements on the input 
files, thus being more robust.

>> You pointing me to GDP got me thinking that I might want to find a different
>> solution for this, always just having the extracted original data on disk,
>> and not requiring it to be converted to the well-known formats already.

[...]

> It's fine to have converted versions on-disk *alongside* the originals
> as an optimization, or for the benefit of an engine that doesn't know
> how to load the originals - if necessary, g-d-p can run imperative code
> to convert or edit them, on a "write-only" basis.
> game_data_packager/games/lgeneral.py is an example of this.

That's an interesting feature, but I would only want to use it in case there 
are performance or memory problems that would require such a measure. The 
original data is very small (~1M for each original episode, graphics are not 
compressed). I'd rather teach the engine to load both the original as well as 
"modern" (as in current well-known formats) data.

>> I'm currently in the process of migrating FreeNukum to the Bevy engine. The
>> fact that files of different types have the same suffix (.dn1, .dn2 or .dn3,
>> but the same for graphics, sound and level data), caused some issues there,
>> as Bevy can only register one asset loader per suffix
> 
> g-d-p can rename files if necessary, and can look for source files under
> more than one name, although the syntax for that is relatively verbose
> so you wouldn't want to use it for more than a few files.

As mentioned above, I'd rather make the loading more robust instead of 
imposing requirements on the data, especially because that doesn't scale well 
over multiple distros and operating systems, just as you mention below.

> Again, if you can teach your engine to be able to load the original files
> without modification, that would make it easier for people who have copied
> a Windows installation without using a special tool.
> 
>> My long-term vision is to have free assets for FreeNukum as well, so that
>> the game can be played without requiring any proprietary data.
> 
> That game wouldn't be Duke Nukem, it would be a different game that
> happens to have Duke-Nukem-like gameplay and share an engine - similar
> to the relationship between Quake III Arena and OpenArena. The way we
> generally represent that is to have a free engine (packaged directly in
> main or contrib), a package representing the free game that depends on the
> engine (packaged directly in main or non-free depending on licensing),
> and a parallel g-d-p-generated package representing the original game
> that also depends on the engine (non-redistributable), so that you can
> install either or both of the two games.

To be fair, FreeNukum isn't Duke Nukem 1, and never has been, it has always 
been a different piece of software that is able to load the original files. 
The idea is to just have different asset loading functionality, all the rest 
(game mechanics etc) would be run by the same code.

I'd love to have FreeNukum packaged for Debian some day, but it's not ready 
yet. Having transitioned to Bevy, and being able to play the original game 
data start to end is imho the bare minimum for that, and right now the final 
enemy doesn't even appear in the game yet, so no possibility to finish. :-)