Jump to content
The Dark Mod Forums

Difficulty


mike mayday

Recommended Posts

I don't know about others, but having root randomized gives me exactly zero incentive to replay. same for randomly spawning guards. What makes a map good to play, and thus invite to replay it, is not the placement of guards, or the particular type of loot, but the overal concept of the map.

 

The point is not to make totally-random maps so you always feel "heh this is totally new. And totally random. And totally crap" as seen in many other games.

 

The point is to make the replay of an already great mission even more interesting.

 

But feel free to not play my mission :)

 

(On the same reasoning you could also argue against random patrols of the AI. I think they add greatly to the game play)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Yes, yes there is. For example, it would be trivial to expose something like rand() from stdlib.h to scripts. Is there already something like rand() exposed to D3's scripts?

 

I think having just a random number generator isn't that useful (because complicated to use for the mapper). Like for instance we have a random delay trigger (at least I think so, if we don't, we should have), so we could have a random-spawn trigger (give it a list of possible spawn entities along with a list of probabilities for the spawn), and this trigger could then be used for almost anything (random placement, random entity etc).

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

But feel free to not play my mission

 

Does that mean you're volunteering to code the loot randomizer?

 

I agree with the others, personally. Loot hunting is always my least favourite part of the game, and randomizing loot just seems more likely to cause frustration and immersion-breaking scenarios than anything else. But if you're willing to code it, I'm sure someone will find a use for it.

Link to comment
Share on other sites

So are you volunteering to code the loot randomizer?

 

Sure, I need to look at that stuff anyway to make the moss arrows work better with water. Greebo agreed to help me getting my feet wet, so this sounds like a good objective.

 

(I already wrote some game inventory systems and randomizers-for-game-maps in a few years ago, so obviously I already though a lot of what works in a game, and what doesn't :)

 

I agree with the others, personally. Loot hunting is always my least favourite part of the game, and randomizing loot just seems more likely to cause frustration and immersion-breaking scenarios than anything else. But if you're willing to code it, I'm sure someone will find a use for it.

 

I think many here mis-understand. You obviously can't really randomize the loot count (that would lead to mission failure if the player can't get the needed amount), or the loot places for important stuff (as the loot-hunt starts then).

 

But on the other end of the spectrum, there is no reason that the stack of coins on the fireplace can't be a ruby the next time you play :)

 

Likewise, if the readable says "I hid the key in the second barrel on the left", there is no reason it can't say "I hid the key in the third barrel on the right" tomorrow :)

 

All within reason, of course.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

It seems to me that you'd be constantly running the risk of either size problems (what if a small stack of coins in a box is replaced by a vase that doesn't fit?) or immersion problems (a silver spoon next to a bowl is replaced by a stack of coins). The only way to avoid these issues (without tremendous work) would be to reduce the randomizing factors to the point that they'd be nearly pointless--does it really make much difference if a stack of coins is replaced by a gold ring the next time you play?

 

If little details like that really matter, then why not just randomize the skins on paintings, so that they're all different the next time you load the map? It has about the same value as far as I can see, but avoids all the potential pitfalls of size, value, and appropriateness.

Link to comment
Share on other sites

In Dromed I resorted to random patrols of frogs, who then hit bounds triggers linked to other things!

Random patrol paths are already there: Instead of

AI >> path_corner_1 >> path_corner_2 >> path_corner >> 3

you can also target multiple path entities for each AI and for each path entity - you can have setups like this:

AI ->> path_corner_1 OR 2 OR 3 >> path_corner_4 >> path_corner_2 OR 3 OR 5

 

Basically: When a path entity or AI is targetting multiple path entities, one of them is chosen randomly. This way you can create entire trees of patrol routes without touching a single script line.

 

As for randomising mission-related stuff, I also agree with most of the others. This looks like more freedom, but it will quickly result in even more work for the mission creators and especially the beta testers.

Link to comment
Share on other sites

It seems to me that you'd be constantly running the risk of either size problems (what if a small stack of coins in a box is replaced by a vase that doesn't fit?) or immersion problems (a silver spoon next to a bowl is replaced by a stack of coins). The only way to avoid these issues (without tremendous work) would be to reduce the randomizing factors to the point that they'd be nearly pointless--does it really make much difference if a stack of coins is replaced by a gold ring the next time you play?

 

If little details like that really matter, then why not just randomize the skins on paintings, so that they're all different the next time you load the map? It has about the same value as far as I can see, but avoids all the potential pitfalls of size, value, and appropriateness.

 

The randomizing system should be generic - you can make it do whatever you want. Swap a coin for three coins, swap a painting, enable a torch, or not, spawn entitiy, or not, whatever the mapper wants.

 

Discussing whether details of usage for a not-yet-existing system will make sense or not is a bit pointless IMHO :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

No wonder why I've been having so much trouble; I've been going about this the wrong way! You're going and trying to get your feet wet, and here I've been wearing me Wellies the whole time!

I can only repeat what I offered multiple times now: I'd be happy to get new coders started and introduce them into smaller tasks, I'd even take a complete newbie by the hand and get him/her into coding, but strangely enough nobody took me up on my offer so far. :mellow:

Link to comment
Share on other sites

Discussing whether details of usage for a not-yet-existing system will make sense or not is a bit pointless IMHO :)

Yes, and in my grumpy state of mind, I have to say that discussing new features a year after feature freeze is not exactly what brings us forward.

Link to comment
Share on other sites

Yes, and in my grumpy state of mind, I have to say that discussing new features a year after feature freeze is not exactly what brings us forward.

 

True. I forgot once again. :blush:

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I can only repeat what I offered multiple times now: I'd be happy to get new coders started and introduce them into smaller tasks, I'd even take a complete newbie by the hand and get him/her into coding, but strangely enough nobody took me up on my offer so far. :mellow:

 

Sorry, I am seriously lagging behind (mapping soaked up all my time :blush: reading that tutorial you gave me, asking about the moss arrows etc. is on my do-it-real-soon-now list.....

 

(Setting up my laptop to compile DR as I write this)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I can only repeat what I offered multiple times now: I'd be happy to get new coders started and introduce them into smaller tasks, I'd even take a complete newbie by the hand and get him/her into coding, but strangely enough nobody took me up on my offer so far. :mellow:

Joke, mate. ;) But in all seriousness, I was planning to take a serious look writing the vine arrow script very soon, preferably immediately after my concert tonight. I'd start now, but I stayed up until 06:00 trying to figure out why my list was segfaulting on a double free. As it turns out, I had correctly written my library, but due to a requirement of the assignment, I was mallocing my nodes outside of the list. As an optimization, I was attempting to malloc all the nodes I needed at once. When I would free the head, it would free the entire block, so the next time I removed the head, it would result in a double free. I spent five hours banging my head against the wall in Valgrind until I realized my error. :(

 

I know it's possible to allocate more than one block at a time and have it work correctly. Could anyone explain to me the right way doing it?

Link to comment
Share on other sites

Joke, mate. ;) But in all seriousness, I was planning to take a serious look writing the vine arrow script very soon, preferably immediately after my concert tonight. I'd start now, but I stayed up until 06:00 trying to figure out why my list was segfaulting on a double free. As it turns out, I had correctly written my library, but due to a requirement of the assignment, I was mallocing my nodes outside of the list. As an optimization, I was attempting to malloc all the nodes I needed at once. When I would free the head, it would free the entire block, so the next time I removed the head, it would result in a double free. I spent five hours banging my head against the wall in Valgrind until I realized my error. :(

 

I know it's possible to allocate more than one block at a time and have it work correctly. Could anyone explain to me the right way doing it?

 

You need to allocate one block with malloc (this block is often called "a slab", "an arena" or "a bag"), then manage it yourself by keeping pointers into this block. Usually this only works good if all nodes have the same size, tho.

 

Otherwise (nodes with different sizes) it get's quite easily complicated, and you are best using malloc for each single node. You probably will not be able to beat malloc and the optimization is not worth your coder time.

 

Once you have your block allocated, you need to keep track of which bits of it are used and which not, which means you need at least one bit per node. Either stuff this bit into the node itself, or keep a bitvector somewhere else that tells you which bits of your block are in use and what not.

 

But as I said, this can get complicated quite easily, so you probably not worry about using malloc for each node.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

This was in C. How would I have nodes of different sizes? Unions are always the size of the biggest member struct. AFAIK, you can only have variable types/sizes of data in your struct through the use of void pointers. And how the hell do you "beat malloc" in a single-threaded process?

 

In retrospect, I think what caused it was some unwise variable reuse. I can't really check until I get my work back off the school computers, though, and I can't be assed to do that just yet.

Link to comment
Share on other sites

This was in C. How would I have nodes of different sizes?

 

Well, maybe if you have two different types of nodes/unions :-) (You said something about a linked list, guess that means you have only one union/struct for each node? That would certainly simplify things - good for you :)

 

Unions are always the size of the biggest member struct. AFAIK, you can only have variable types/sizes of data in your struct through the use of void pointers.

 

I don't quite understand this sentence. Certainly, in a linked list you can have variable sized nodes as long as the start of each node contains a flag or size field which tells you how big this node is.

 

Of course, this needless complicates matters unless you really need to save memory.

 

Usually, what you do is you have a inked list of _equally sized_ nodes, and each node contains a pointer to extra data that is then of different sizes. Pulling in this data into each node is really only when you want to save that one extra pointer.

 

Hope I explained that well enough?

 

And how the hell do you "beat malloc" in a single-threaded process?

 

malloc has an overhead in terms of memory per allocated block. Likewise, if you need to manage a few hundred/thousand/million little blocks, even if they are all of the same size, you might get fragmentation of your memory.

 

E.g. if you have one million nodes allocated, free 2 of them, then want to allocated 2 more, your malloc/memory manager/whatever, needs to find out *which* of the million little blocks are free - which can be either some lookup, or walking throught the chain of memory blocks etc.

 

Your idea of "allocating one large block and managing by yourself" is exactly how you can beat malloc, but as I said, it can be getting complicated :)

 

In retrospect, I think what caused it was some unwise variable reuse. I can't really check until I get my work back off the school computers, though, and I can't be assed to do that just yet.

 

:)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Well, maybe if you have two different types of nodes/unions :-) (You said something about a linked list, guess that means you have only one union/struct for each node? That would certainly simplify things - good for you :)

No, a union of two structs will simply be the size of the larger struct. Pointers allow you to have variable amounts of data (through void pointers or possibly union pointers), but then, that data won't actually be in the node struct.

 

I don't quite understand this sentence. Certainly, in a linked list you can have variable sized nodes as long as the start of each node contains a flag or size field which tells you how big this node is.

 

Of course, this needless complicates matters unless you really need to save memory.

This idea intrigues me, and I would like to learn more.

 

malloc has an overhead in terms of memory per allocated block. Likewise, if you need to manage a few hundred/thousand/million little blocks, even if they are all of the same size, you might get fragmentation of your memory.

 

E.g. if you have one million nodes allocated, free 2 of them, then want to allocated 2 more, your malloc/memory manager/whatever, needs to find out *which* of the million little blocks are free - which can be either some lookup, or walking throught the chain of memory blocks etc.

 

Your idea of "allocating one large block and managing by yourself" is exactly how you can beat malloc, but as I said, it can be getting complicated :)

Ah. I thought you had been talking about some sort of race condition or something, not improving cache locality/page utilization over standard, fragmentation-happy malloc.

 

Edit: Hurray for programmer thread-hijacking!

Link to comment
Share on other sites

Edit: Hurray for programmer thread-hijacking!

 

Oops, sent you a PM :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

There is already a randomizer linked to the script. It is the one from Id's math library, so if someone feels they have a better one in mind we can always link that in too.

 

I think all of this random loot and AI stuff is pretty trivial to code / put in the map script. People could do it easily now with scripting, maybe there are more elegant ways to make it easier on the user with some SDK mods. I think it would only take an hour or two at most.

Link to comment
Share on other sites

No SDK mods would be required to package a random entity placer in a user-friendly form, since it would be trivial to implement with an entitydef and a script. (eg, the distance-portals that shut off when you're far away are implemented in terms of an entitydef and script, without SDK support)

 

The only major roadblock is that in D3, random numbers always use the same seed from map start, so a "randomized" map will always load the same way (perhaps they did that to help with testing). But that wouldn't be hard to change in the SDK.

 

Also, though I'm not 100% sure (I don't have access to D3 at the moment ... my computer's motherboard is fried), I don't think you even need to use scripts to do this. There are triggers that automatically fire on map start, and I think there are trigger relays that randomly fire one of their targets and there are entity-spawners. Just hook all three together and you have random entity placement.

Link to comment
Share on other sites

The point is to make the replay of an already great mission even more interesting.

 

As I already said, a random element doesn't make a mission more intersting to replay. Either the mission is interesting or it is not. If you think that radnomness improves a boring mission we can also create a level generator.

 

(On the same reasoning you could also argue against random patrols of the AI. I think they add greatly to the game play)

 

Yes, I know. A lot of people believe that all kind of stuff they may think up "adds to the gameplay". Until they actually get it and start to complain about it. <_<

Gerhard

Link to comment
Share on other sites

But on the other end of the spectrum, there is no reason that the stack of coins on the fireplace can't be a ruby the next time you play :)

 

WOW! NOW that would REALLY be an excitment! It would add soooo much to the gameplay if the stack of coin is replaced by a ruby. I can't wait to see this features as it adds so much immersion...

 

Likewise, if the readable says "I hid the key in the second barrel on the left", there is no reason it can't say "I hid the key in the third barrel on the right" tomorrow :)

 

Yes, yes! That's a TOOOOTALLY MUST HAVE! I can't wait to see it. I think maps will get SOOOO much better because of this.

Gerhard

Link to comment
Share on other sites

How about a script for randomized readables aligning words to senseless sentences? ;) No seriously, better concentrate on your beautifull map than on meaningless stuff like randomising. After all, randomising has never been important in informatics, or has it? ;D

Edited by STiFU
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...