Grimrock

petri wrote:Creating a patcher that does simple string replace operation on existing levels is probably safe and doable. But then again, this requires changes to the grimrock.dat file (direct patch to dat file or for the loose file hack to work), so the patch would be gone when the game is updated. How about unintalling the patch then - would you supply an unpatcher for each patch?

Why wouldnt this work:
- extract data from .dat
- patch data
- let game load the extracted data

Don't forget to let it backup up that dat.

Crashbanito wrote:Don't forget to let it backup up that dat.

That's a bit hdd space heavy solution, and unnecessary if the engine already knows how to load stuff off disk instead of from the dat file if a file exists..

Sol_HSA wrote:

Crashbanito wrote:Don't forget to let it backup up that dat.

That's a bit hdd space heavy solution, and unnecessary if the engine already knows how to load stuff off disk instead of from the dat file if a file exists..

The problem is that you do need to modify the .dat to load stuff off disk.

Crashbanito wrote:

Sol_HSA wrote:

Crashbanito wrote:Don't forget to let it backup up that dat.

That's a bit hdd space heavy solution, and unnecessary if the engine already knows how to load stuff off disk instead of from the dat file if a file exists..

The problem is that you do need to modify the .dat to load stuff off disk.

Ah. Well, I hope the devs will help with that bit.. =)

Sol_HSA wrote: Why wouldnt this work:
- extract data from .dat
- patch data
- let game load the extracted data

So, ok, you're saying that we should allow overriding any file if it's placed in the correct subdirectory under grimrock. We could consider this but why not then add an extra step:
- repackage the modified files into a new dat file that's loaded by the game

This way it would be easy for the user of a mod to uninstall the mod simply removing a single file created by the patcher. Multiple mods operating on loose files gets very messy very fast.

I'm still thinking that all this trickery is a pretty silly way to circumvent the "you are not allowed to distribute the original assets" rule I think we're going backwards into all this. Why not first create mods that add new dungeons, monsters, items and puzzles and then worry about advanced/hacky stuff later?

The easier you make the process of creating a new dungeon the more user created content you will see. In my opinion I would urge you to provide easy tools for creating dungeons and setting up puzzles, with the mechanics that already exist in game, while then leaving completely new puzzle mechanics for something you can provide through expansions or DLC if you decide to make any.

Realistically speaking most people would probably want to create dungeons by recycling the assets (and mechanics) that you have already made, after all there are probably more people that are interested in creating dungeons than there are people capable of really coding in lua or doing things like creating whole new models for monsters (more likely people would prefer to be able to re-texture the existing models).

That said scripting opens many possibilities. Regarding mods that affect the core game, wouldn't the easiest approach be to provide addons with "hooks", preset expansion points which a script can catch and execute code on, then provide a set of functions for scripts to call back to the engine in order to set or trigger something to happen.

That way you will be able to keep a certain degree of control with what the scripts may do, and lessen the number of situations where poorly written addon may put the game engine in an invalid state. Also I noticed you use LuaJIT as part of the game engine, though it does not state what version so I don't know if the more interesting features such as FFI (Foreign Function Interface) are available. But I will say this; I would prefer not to have a script in a mod be able to execute machine code, which is something you can do with FFI, or load a arbitary dll or even lua module that could do who knows what.

However, at the same time... creating an addon that would allow for example network co-op would in theory be kinda neat and open new possibilities for puzzles that need two parties acting together. The only problem with that is that without some extensive work (unrealistic for a mod) you couldn't allow these two parties to ever meet face to face.

Very good points, Crise! Thanks for the feedback!

petri wrote:So, ok, you're saying that we should allow overriding any file if it's placed in the correct subdirectory under grimrock. We could consider this but why not then add an extra step:
- repackage the modified files into a new dat file that's loaded by the game

This way it would be easy for the user of a mod to uninstall the mod simply removing a single file created by the patcher. Multiple mods operating on loose files gets very messy very fast.

I'm still thinking that all this trickery is a pretty silly way to circumvent the "you are not allowed to distribute the original assets" rule I think we're going backwards into all this. Why not first create mods that add new dungeons, monsters, items and puzzles and then worry about advanced/hacky stuff later?

I think the best way to do things is to have the game accept packaged archive files - .zip format for example - and have it use those to override existing content if there's a clash. On top of that have it load them in a prescribed order, in a text file or the like. Loose files sounds like an absolute nightmare. I think it's pretty obvious though, and I think you've already come to that conclusion So you've got a mods directory and normally you don't need to worry about anything, you just fire a .zip file in there with a pack of stuff in it and nothing is likely to override since most of the stuff will be new content like dungeons or mobs.

In the future versions of your modding tools, will you allow people to fiddle with existing assets, like in Bethesda's games?