Grimrock

About requiring items... perhaps we can do the same than RRR2. You have a lot of keys to open the path to the end and is not necessary to have all the keys to complete the mod. Some of them can be used on extra areas or to open treasure rooms.

With the new features available, it's not far fetched to simply add a dedicated plot-item inventory panel that fills up as these items are acquired, but does not require that they be equipped or even stowed in inventory. The Witcher did this, as I recall.

I think we have a few options when it comes to "what we're collecting". Without actually defining what the items are, I can think of 3 variants...

1. Assuming each area is 5 rooms. That could be 4 rooms and a final room (potential for boss fights if some designers want to do them). Then, within an area - each of the 4 rooms could hold a key to the 5th, and you need to get 3 of the 4 keys to open the final room. Completing the final room gets you one step closer to the black tower...

2. We could do similar to the main game / the ORRR2. You need X of Y items to get into the final area. Bonus items get you into treasure rooms.

3. Each room could give you one "bit" of a given crafting resource - which you can use in the main town to build the quest item(s) you need to proceed. Maybe you need "4 special items" to enter the black tower, but you actually get to craft them yourself. You could choose to craft a piece of armour for "4 bits" and a sword for "3 bits". And when you have crafted 4 of these items, you're able to go in to the tower.

I quite like number (3) myself. You get to craft some unique (useful) items and it feels novel compared to LOG2 and the ORRR2. It also means you only have 1 type of item in your inventory (crafting resource) until you craft weapons/armour.

How about this for a plot item setup: the player finds a talisman near the beginning, and throughout the rest of the game finds magical items to imbue the talisman with powers that allow them to pass certain obstacles. For example, maybe you could use the nine elemental essences for the items needed to imbue the talisman: the essence of air would allow the party to breathe safely in the mine filled with poisonous gas, and the essence of life would let them pass a "death spell" protecting the black tower. The essences could be made with power gems (found in each room) as usual or you could be more creative.
Alternatively, you could use gemstones: the talisman has a bunch of slots for different cut gemstones, and you find one gemstone in each room.

This would be a lot more flavourful than just using keys. And gemstones are really easy to model/texture

Optional: If you get all the items and fully imbue the talisman, it can banish the evil from the town at the end, getting the "good ending". Otherwise, the talisman isn't powerful enough and you get the bad ending.

edit: oops, started writing this before John's post.

Another thing that should be decided sooner rather than later is our targets for file size & resource usage. Steam's 100MB limit is damn restrictive for Grimrock, I know it was a problem for ORRR2. Maybe there could be a <100MB "lite" version that would be on Steam, with fewer custom textures/sounds, and a >100MB "full" version downloadable elsewhere. I would LOVE to compose extra ambient tracks for the mod, for example - I'm sick of hearing the default ones - but those use up significant space. If we designed with this goal in mind (have an easy mechanism to swap out sounds/models/textures so that patches don't need to be written twice), it wouldn't be too difficult to maintain.

Other considerations are performance and video RAM usage. In my opinion we should try to support the minimum system requirements. The nice thing about Grimrock 2 is that mods have some "graphics detail" resources they can use to adjust performance: for example, allowing the player to adjust the distance at which meshes change to their low-detail versions is very easy.

JohnWordsworth wrote:I think we have a few options when it comes to "what we're collecting". Without actually defining what the items are, I can think of 3 variants...

1. Assuming each area is 5 rooms. That could be 4 rooms and a final room (potential for boss fights if some designers want to do them). Then, within an area - each of the 4 rooms could hold a key to the 5th, and you need to get 3 of the 4 keys to open the final room. Completing the final room gets you one step closer to the black tower...

A fourth option is to design it so the 5th room completed is the final fight ~whichever the 5th room happens to be.
consider a situation like "Beauty and the Beast". Imagine that at sometime before that tale began, an intruder entered the beast's home, and was eventually confronted by him either when first discovered (in the last room), or at the point where the beast could not tolerate the intruder any longer; got too close to something.

In Grimrock, the player could (for instance) invade a mausoleum and disturb the crypts by looting, or even just entering the various rooms (perhaps breaking seals), and eventually the guardian appears in the last room visited.

minmay wrote:Another thing that should be decided sooner rather than later is our targets for file size & resource usage. Steam's 100MB limit is damn restrictive for Grimrock, I know it was a problem for ORRR2. Maybe there could be a <100MB "lite" version that would be on Steam, with fewer custom textures/sounds, and a >100MB "full" version downloadable elsewhere.

I don't have LoG2 for Steam; is it impossible to set the mod not to update, and manually swap or overwrite the mod's dat file with the one from the Nexus version? Or is there some limitation of the Steam wrapper preventing this?

Yay! I just voted for number 1... I think central town hub is a great idea, and it's totally not limiting. If you want a protal to a magic dimension you can do it in any possible setting, if you want underground you can put an elevator to a mine shaft 200m below ground, a magic tunnel from a hut up to a cloud world, I mean given that the story framework is relatively loose, it's easy to plug in any design you might have.

Having some specific themed-zones is nice in any case, as it directs creativity, but even within that it's easy to be original.

Remember that a big part of the ORRR fun is for the player to open a door an have NO IDEA of what's going to happen. Both the ORRR1 & 2 also allowed for humoristic rooms, which IMO was a big plus to the experience.

variety is the spice of life

Re: Quest Items. I like the idea of having a talisman. It kind of also fits with the requirement to craft the gems for it in town. You could find the talisman for free and then find "gem fragments" in the rooms and craft them into full gem stones in town. We might be able to make the upgrades "optional" (so you can pick what you want) or they could just be linearly assigned (eg. first gem = X, second gem = Y, third gem = "can pass the wall of death on the black tower").

Re: Mod size. Having a version that fits on Steam is a must I think. We would miss out on a large number of players if we don't aim for that. I will have a think about a "friendly" way we could offer an "HD" version without it being too much manual work. Preferably, we can almost automate it (put your HD assets in a special folder and a script copies them into mod_assets using a python script).

Re: Boss Fights. While I like the idea conceptually, I think a big part of boss fights is the arena in which you meet them, and I fear spawning the bosses in the last room of an area would (a) cause every room designer to have to think about "what if I get the boss" and (b) lessen the ability to make the boss fight unique.

@Diarmuid: Definitely agree! There is scope for all sorts of weird and wacky rooms in the confines of the mod. Areas like the Asylum and a mine spoiled by magic lend themselves particularly well to random weirdness too.

JohnWordsworth wrote:Re: Mod size. Having a version that fits on Steam is a must I think. We would miss out on a large number of players if we don't aim for that. I will have a think about a "friendly" way we could offer an "HD" version without it being too much manual work. Preferably, we can almost automate it (put your HD assets in a special folder and a script copies them into mod_assets using a python script).

Dungeon export will ignore files without certain extensions so you can simply have the script rename the unused assets.
Simple version: You could make the script swap out any files appended with HD (use "materials.lua" versus "materials.lua.HD"). Because Grimrock 2 supports external scripts, you could have a simple script entity that loads an external file "isHD.lua" versus "isHD.lua.HD". Then define an "HD" field in the HD version, and scripts across the game could use "if isHD.script.HD then" for mode-dependent behaviour. No manual file changes required to switch between the two. If we enforce that rooms keep all their files (object definitions etc) in their own folder, this would be quite simple to maintain.
Improved version: have the script set an "HD" variable in every Lua file that's loaded before script entities (except for dungeon.lua), then modders would get ifdef behaviour in their asset definitions (similar to how Config.getRenderingQuality() is used). This way you would only need one materials.lua and the file swapping would only be needed for actual binary assets.

EDIT: Here's a complete specification of what I have in mind:
- Two naming patterns for files would be used: "*.extension.HD", and "*.extension.LD". Obviously we don't have to use those specific acronyms or anything. The term "regular asset file" will heretofore refer to a file without a .HD or .LD extension.
- When you run the "make HD" script, it copies all *.lua.HD, *.model.HD, *.dds.HD, *.animation.HD, *.wav.HD, *.ogg.HD, *.ivf.HD files to the same filenames with the ".HD" suffix removed. "goat.model.HD" is copied to "goat.model". The original "goat.model.HD" still remains.
- The "make LD" script would behave the same way but with the LD naming pattern instead. In addition, if it finds a file with an HD version but no LD version, it deletes the regular asset file.
This works because dungeon export only exports filenames ending in .lua, .model, .dds, .animation, .wav, .ogg, and (as of recent patches) .ivf.
Asset files would then fall into one of 3 categories:
1. If your file is the same in both the LD and HD versions, you don't need to do anything; give it a regular filename. The script will ignore it completely.
2. If you have both an LD and HD version of an asset, make all changes to assetname.LD and assetname.HD and let the script overwrite the regular asset file.
3. If you have an asset that should only be present in the HD version, make all changes to assetname.HD and let the script overwrite the regular asset file (HD) or delete it (LD); don't make an assetname.LD.
Pretty simple to follow IMO. Remember that most files would be in category 1.

About the "ifdef-like" behaviour. I realized there's a ridiculously easy hack for that:
Step 1. Have a file called "stupidConfigHack.lua.HD" (or whatever) consisting of one line: Step 2. And a corresponding "stupidConfigHack.lua.LD" that's a completely empty file: Step 3. Have this at the top of your init.lua: Now every script in asset definition files AND ingame can use: Yes, it works with saving/loading the game!
Credit to JKos for being GODDAMNED INSANE enough to try adding fields to the global tables in the first place
The advantage of this is it doesn't require another level of automation - the script only has to do the file-moving - and plus it's really easy for scripters to type. The disadvantage is how dirty it feels.