It actually doesn't matter that much, because the game uses randomized values. Sometimes a character gains a few points more than the average and sometimes less, so you'll never get the exact values anyway, because they fluctuate. So defaulting to gaining a point less isn't a problem.

Unless the game would have used fixed point to begin with, it's impossible to get this to be completely fair. However, using this method is a lot more fair than it's now.
Why am I not surprised :D
Have you ever tried to come up with anything good?
Just because people have failed doesn't mean it's impossible ;)
I'm just saying it opens up possibilities. That such a feature is perhaps not so easy to use properly just means having to try harder. Good level design already isn't all that straightforward, and the more options you have, the harder it becomes when you actually want to use all those features.
Not me. I want to use computers for that.

Well, perhaps it's indeed not possible to be as fair as i wished. Now let's see how your motivation is, by the challenge below ;)

I think i've been clear enough when explaining it. Anyway, just reaching that door without opening it, is way too easy (especially because there are several ways to do so !).
It's the challenge, man.

What do you mean, that i always came up with everything bad ???

Sure, but it's starting to mean that it's perhaps not a smart thing to do.

And what if i'm just saying it opens up nothing at all ?
You're not even giving a single example where this can be useful !

Then use some paint program :D

No, it's not, but it's a lot more fair than the current system. Also, the current system can be exploited somewhat by saving just before a level up, and reloading if you gain bad bonuses (yes, some people do this). With non-random systems this is impossible.

As for the challenge, sure, I'll try :great
Yeah, didn't interpret it correct ;)
No, I mean have you tried to come up with some interesting 3D stuff?
But why is it not smart? If no one ever tried difficult things, we'd still be stuck in the stone age :p
To me, it couldn't hurt. It can at the very least enable the creation of more interesting environments.
No, I'm not. Thing is, I'd like to just jump in and try things. Come up with ideas as I'm using such features.

It's all about flexibility, and the more the better, but as said this can make it harder to make anything good... which I don't think is a bad thing.
:laughing

Yes, the save'n'reload exploit problem. Didn't think about it. Well, ok. But you still have to do the challenge ;)

Good. If successful, just gimme the saved game. Then, next release will contain non-random level gains !

I can't see any interesting 3D stuff. Anyway while designing levels, i'm not thinking "how could i use this feature" but "what features do i need".

For me it's not interesting. It's just graphical.

You may want to write an editor, then :p

I fail to see any added flexibility here.

Another thing...

I've seen that some custom dungeons (on dmweb.free.fr, for example) provide graphics.dat containing bag object, like DM2. But chest weight is 5 KG and custom graphics file cannot change this, so a bag weighting this much is a little bit too heavy, right ?
DM2's bag is 0.7 KG and DM2 supports both chest and bag. This is what i did for my DM. I now have another significant edge over Csbwin :)

But i noticed that DM2's chest is 5.6 KG, not 5.0 KG like DM1.
Unlike DM1, there aren't many chests in DM2. So i kept DM1's weight.
However i'm asking here : what would you do, facing that problem ?

Okay then, seems fair enough.
It can work both ways ;) Anyway, I'm not going to try and come up with an example, because I can't use 3D anyway, and your port doesn't need 3D. As I said, 3D is nice to add when you're writing an engine from scratch.
I don't know about that... I'm writing a new system frame, though. My old one sucked badly, and I'm doing this one with the aid of the RKRM (which showed me all kinds of things I didn't know and enables me to do everything properly). Shouldn't be too hard once finished (getting close).
It adds possibilities, especially when adding other features as well.
Either one is fine, but I'd go for 5.6 simply to give the player a (very) small disadvantage.

Well, end of story then.

Let's see what you can come up with :great

Please name some of these possibilities 'coz i don't see them...

Strange, i would go for 5.0 to give DM2 player a very small advantage...

It's not difficult to change anyway, but altering it could mess older saves up so i won't touch it for now.

Indeed :great Or...
The basis of the frame is almost complete, and I'm just ironing out loose ends and doing the necessary debugging. After that I'll add some more useful features and make a proper library out of it. Not really a lot of work left to do :) By the way, the RKRM is truly enlightening. I can't believe I wrote my previous frame without it :banghead That and not reading the autodocs more carefully :banghead
It allows you to make puzzles that require you having to look at the environment in a way that's not possible with 2D. It also allows for more interesting dungeon layouts as a whole (you may see where you have to go from several levels up/down, but how to get there?).
My reasoning is this: If you want to change something which can slightly change the balance in either the game's or the player's favor, then it's probably best to balance in the game's favor, just to be sure.

If the change causes a not so small balance change, then it's perhaps better not to change that particular thing.
Good reason, but why might it do this?

Coding with some docs is indeed easier :cheese

Looks like a different kind of game to me.

In short : better raise the difficulty level than lower it ?

Get a chest. You get 5.0 kg load. Save.
Reload with new version. You load is 5.0 (it's not recomputed).
Now remove the chest : 5.6 kg less - your load becomes negative.

Not only that, but coding without the complete docs is just downright dangerous.
Doesn't have to be. Think DM2 with more varied environments.
Yes, but only if it's a little bit, otherwise leave it unchanged or be prepared to do a lot of play testing.
Yeah, that's a bad one for sure. I wonder why it does this?

It's kinda "experimental" coding :D

DM2 isn't much more 3D than DM1, so what kind of environments there ?

I think i already have enough play testing to do...

I guess it was simpler & faster.

I have a problem with your nightmare dungeon, something that didn't happen before and I don't know what I did to cause it. The game generates the following message and then quits: type de timer inconnu. Any idea?

Perhaps, but it sucks when you think you're doing it right.
Yes, but environments can be enriched by 3D (some types of environment just aren't flat). In my opinion, Hired Guns does a reasonable job here (from what I've see so far). Anyway, it would be nice to have, but it's obviously not essential ;)
They could have just added a weight field to the chest data. There aren't that many chests, and each one would only need an extra byte. Couldn't be easier.

Apparently you're using old saved game with newer program.
Either use old program which made that save, or restart the game with new program.
Alternatively if these aren't satisfying for you, i can somehow convert your save (if you give it to me).

Frankly I found Hired Guns to have less playability than DM, and got bored after having finished it.

Couldn't be easier, but not much logical if different weighted chests have exact same gfx.

Okay, I'll use a previous version then. I think there were only some bug fixes that don't affect me (I'll check the thread to make sure).
Perhaps it does ;) I think that ultimately this 3D business is a matter of preference.
To me it's better to implement it in a more flexible way when it's easy and doesn't use up many resources (in this case the extra memory required is minuscule).

Problem solved then.

Anyway this is DM thread and DM's not designed like that.

Object descriptors aren't very big either. But the player would certainly not like having apparently identical chests, which only differ by their weight !
(at least as a player i certainly wouldn't like that)

Valid point, but it shouldn't be to hard to add a few different chests. Or better, have the bags from DM2 be a chest type. There could be a portable container descriptor specifying the container graphics, weight and the number of items that can fit inside the container.

The bags from DM2 ARE a chest type, like healing potions are a potion type.

About the container graphics, it's like other objects in inventory or 3d view, apart you have the interface in inventory to put the objects in/out of the chest. This one makes things much more complex due you have to keep coordinate list of these cells and the whole game is hardwired to have only 8 slots.

New release !

Changes this time :
- No longer any broken exit (but i will put bad stairs back if nobody plays :evilgrin).
- A few levels and puzzles added here and there.
- Dungeon #1 contains some new bones (will you find yours ?).
- Clicking on letters (when renaming champions) now works (an old one, that is).
- Game loads faster (check it).
- A few potential deadlocks removed.
- Some cleanup and minor cosmetic changes.
- Script added to make dungeon copying automatic (just run the "run-it.script" of the relevant directory).
- Dungeons have been given names.

As a recall, grab the thing there :
http://meynaf.free.fr/tmp/customdungeons.lzx
... and use option "x" of lzx to extract, not "e". ;)

As another recall, please don't mix files of different versions. I would care about compatibility if there were enough players, but...

@meynaf: I can't find this info anywhere, so I'm asking... Is your version working on plain 68000 Amigas? I have a Minimig with 4MB RAM and it doesn't work (goes back to the OS with an error).
Another thing I'd like to know is if your custom executable can be used with the original dungeon.dat and graphics.dat, to play the original dungeon.

No, it needs at least a 68020 and Kickstart 3.0.
Yes, it works with the original dungeon.dat file. I don't think the original graphics.dat file is needed, though (the new graphics.dat file should contain all the original data as well as some additions, but I'm not to sure about the details).