averagemoe
Level: Smiter

Rank Points: 487
Registered: 03-22-2012
IP: Logged

In a fit of inspiration, I just typed up a synopsis for what could be the second story arc of DROD. Possibly three major releases worth of story material, and it's just a rough outline.

I'm not going to give spoilers for what I've come up with, because I wanted the chance to properly propose it to Caravel. Might PM the document to Mike if he's interested, but let's hear from the uninformed public.

____________________________
There are two types of sheep in the world. Those who jump off a bridge when told to, and those who jump off a bridge when told not to. Don't be either.

surrealcanine
Level: Master Delver

Rank Points: 139
Registered: 08-15-2018
IP: Logged

From a narrative standpoint, I would love to see a second story arc. But from the perspective of a player, I just wonder if it'll come off as a mission-pack sequel to TSS that doesn't do much of anything new. The thing most needed would be some new mechanics for 6.0+ and I'm not really sure what could be added to improve on 5.1.

____________________________
136th Skywatcher
surrealcanine plays All the DRODs

Dischorran
Level: Smitemaster

Rank Points: 3408
Registered: 09-10-2005
IP: Logged

*A* second story arc, or *your* second story arc? Because there's nothing keeping you from making your own holds, or even your own fanfic.

____________________________

Kalin
Level: Master Delver

Rank Points: 185
Registered: 01-25-2016
IP: Logged

After a couple weeks of watching some very exciting debates over the meanings of "bug" and "intuitive", how about this for NewDROD:

Game mechanics that are more consistent and intuitive and don't care if they break thousands of ClassicDROD rooms because this is a new game engine.

Things like what happens when you push something into/onto something else, brained behaviors, timing of stabs and double placement, etc.

We could even change things like map layers or even map shapes (hex grid? diamond grid? triangle grid? change between levels/rooms?).

When I first looked at the source code, I was immediately struck by how every monster has its own file of code (two files, actually). Instead, I'd like to set up different behaviors, and then have a monster database that assigns different combinations to each monster. Like this feature request extended to cover everything builtin entities can do.

Someone Else
Level: Smitemaster

Rank Points: 1300
Registered: 06-14-2005
IP: Logged

Kalin wrote:
When I first looked at the source code, I was immediately struck by how every monster has its own file of code (two files, actually).

This is normal for C++. There's nothing wrong with that, and it's actually really good practice (discussions about the value of header files aside). Unless you're aiming to have mainly non-standard monsters, you probably shouldn't aim for full generality, especially since all monsters act at least slightly differently. (That would make more sense in RPG, as most monsters act the same aside from stats)

Just as an example: you currently don't have to worry about what happens if a door opens in the middle of a serpent, because there aren't any wall serpents. If one was added, there would be one place to change things: the wall serpent code. If everything was a behaviour, there are two places to change things: the "go through walls" behaviour and the "be a serpent" behaviour, and it means that you're checking one or the other every time that code is called. A regular serpent doesn't need that code, and now it's harder to parse its code.

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

Class based monster code waa great option for back when DROD was being made.

With all the added complexity of new engines a behavior driven code would work much better. I want a flying gentryii shooting Aumtlich beams out of its chains and you can't convince me it's a bad idea!

But seriously, we wouldn't have many classes of bugs and inconsistencies if we had one monster class and the rest was controlled by behavior configuration.

____________________________
My website | Facebook | Twitter

Illusionist
Level: Master Delver

Rank Points: 165
Registered: 05-27-2020
IP: Logged

Of course I wouldn't mind moar, alas the question, if someone makes an unofficial sequel, is
Should it be harder than TSS (and that's kinda a slippery route, because TSS was very very hard, and at some point it kinda loses the point, because in TSS I knew the lynchpin, I just had to experiment how to get there, so it was more about exploiting the quirks of the engine, than figuring out the puzzle)

or more story driven (which might not be as satisfying as there are limitations to the engine)

personally, I would go with the latter, considering that there are plenty of RPG Game Maker games that people love, despite the limitations that grab the players by the heart (Doki Doki Literature Club anyone?). So I would say, more focus on the story, AND the implications from it.

One thing that wasn't explored much is that the dialogue choice doesn't affect anything - that would probably require some reworking in regard to saves.

But imagine chosing one path that opens rooms for new worlds, but at the same time closes the access to other rooms?

OR just like mind-breaking was adding the weapons, now adding new characters to play with different characteristics, like starting the game and having to chose the player and having unique characteristics, like not being attacked by monster instantly, or being invulnerable to hot plates, or having double speed, and once you chose them, you have to play as them for the rest of the game, a little like in The Choice. That would open the possibilites, because certain rooms would be easier with having immunity to monsters attacking, while the same room would play out differently if you could stay on hotplate and not get killed.

The only limit is our imagination to be honest

There are many ways to go from there, but frankly I won't mind just a new SMS, with story, as long as they are being released

---

[Last edited by Illusionist at 10-25-2020 06:21 AM]

Illusionist
Level: Master Delver

Rank Points: 165
Registered: 05-27-2020
IP: Logged

skell wrote:
Class based monster code waa great option for back when DROD was being made.

With all the added complexity of new engines a behavior driven code would work much better. I want a flying gentryii shooting Aumtlich beams out of its chains and you can't convince me it's a bad idea!

But seriously, we wouldn't have many classes of bugs and inconsistencies if we had one monster class and the rest was controlled by behavior configuration.

Okay I retract my words about imaginations being our limits
Maybe it's okay to limit ourselves

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

I prefer some general behavior utility functions, but leave each monster class full freedom of its own behavior.

You could say that whatever behavior you want for a monster can just be a generalized attribute. That can work, but also lead to unneeded difficulty in maintaining the code.

For example, an Evil Eye is the only creature that wakes up when Beethro enters its line of sight. So with the configurable behavior scheme, you'd add a "WakesForLineOfSight" property and set it to true. And the code for it goes into some general behavior source file, and you write it to work for every conceivable monster.

But since it's truly behavior that is coupled to a single monster, I'd argue you're better off putting it in a source file dedicated to that monster, the Evil Eye. This doesn't stop you from refactoring to a general purpose function later if more monster types end up using it.

After typing the above, I went and looked at the actual eye source code - https://github.com/CaravelGames/drod/blob/master/DRODLib/EvilEye.cpp

It basically does the same thing I described. And there are some general utility functions like GetTarget(), GetDirectMovement() that show good refactoring. It's also straightforward to understand how the EvilEye will work by looking at a single file. I don't think it's badly set up at all.

The one part of the code that looks annoying to maintain due to lack of refactoring/generalization is GetNextGaze() which must be updated for different occupants of O-square and T-square. If some general property like "blocksLineOfSight" could be a property of all T/O-square things, then that would probably be easier to maintain, and maybe could be reused for other non-eyeball things, e.g. Aumtlich gaze.

Not saying anybody should do that refactoring. Just using that source as a concrete example of how to follow a middle way of handling generality that comes short of indicating all behavior with general attributes.

I'm using the unique-classes-with-general-util-functions approach on my new game. I've generalized more than I did with DROD.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

I don't disagree that it's easier to write monster logic using polymorphism, but I disagree it's harder to maintain. There are two reason why I said what I said.

We have 61 places where we cast a generic monster to Character. 7 for Temporal Clone. Likely a lot more than hundred of places in the code where we need to do the conversion to handle special logic. We have a lot of places with a big (sometimes smaller) switch statement checking on monster's type. Like handling puff damage, processing aumtlich gaze, checking if player square contains obastacle, killing monster, processing monsters on half turns or processing reaction to their movement.

Many of those places require changes whenever a new element or script command is added and it's easy to miss them, forget about them or not even know they exist in the first place.

Then there is also the fact that scripting capabilities have exploded since they were introduced and that causes a lot of code and logic duplication. If Halph's critical hero logic was a togglable behavior in the first place, we wouldn't have to have this code or that code. And that's really only one example out of many many many others.

And that has caused a lot of bugs so far ! Even more if we include 5.1.1 (and that excludes inconsistent behavior that is too embedded into the rules to change or things from before I worked on 5.1.0, each word is a link)

Not trying to bash the way the game is written (Especially given the age of the game I think the codebase is for the most part brilliant and easy to follow), just trying to give my point some additional weight. And of course I realize that if it was written differently we'd have different problems. I just think doing it this way would remove whole classes of problems and would make extending scripting less of a hack job. Also behaviors would be quite similar entity-component-system pattern which is a popular (for good reasons) pattern in gamedev.

Do note that moving a lot of the logic from the calling classes to the monster classes themselves would fix a lot of the problems I am talking about, though it wouldn't allow easily implementing cool features like putting monsters on a chain.

____________________________
My website | Facebook | Twitter

---

[Last edited by skell at 10-25-2020 06:25 PM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Yeah, the switch...case-on-monster code in one of your example links is a code smell that points to polymorphism as a potential fix.

I like and use this approach. I merely point out that it can be usefully combined with per-monster classes that handle things truly unique to a monster.

And I'm not sure if anyone was considering the logical extreme of Baba is You style, purely declarative behavior. This would mean that any monster (or game element) behavior would require coding as a general behavior. Considering this pure approach, I see the following trade-offs:

PRO - forces early consideration of generalizing behavior to all elements. E.g. would it work to apply wakes-on-line-of-sight to a serpent or a brain?
PRO - promotes quick creation of new game elements that are just different combinations of behavior properties. In other words, you can create monsters by being declarative with trusted code.
CON - Extra work to generalize early before game elements have a true need for it.
CON - Can be a bit harder to understand the interactions of various behavior properties spread over multiple locations when they don't readily correspond to simple contracts. E.g. CanWalkOnWater() is simple. OrthoganalSightLineInWater() is not. If you force *everything* to properties, you will need weirdly named, unintuitive functions like that.
CON - The difficulties of making new behavior that must be immediately generalized can have a chilling effect on large departures from current functionality. The game becomes more about incremental conceptual updates, e.g. a serpent that wakes up when player is in sight line.

On that last point, I see parallels between disruptive startups and large stable companies. DROD is a complicated, mature codebase. It's hard to do wildly new things inside of it without burning bridges that leave old, working behavior behind. I say this with all respect. It is an accomplishment to have a multi-release game engine, backward compatible over decades. Few game companies achieve this.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

skell
Level: Legendary Smitemaster

Rank Points: 3734
Registered: 12-28-2004
IP: Logged

I think we may be talking about two different approaches, because I don't think the way I am thinking about this requires doing small incremental changes.

I think it all boils down to inheritance vs composition (but I am so bad with terminology don't take my word for it). The way I see it could be developed differently would be for each entity to have:

1. A set of customizable properties (which cover things from movement type, to handling different obstacles, to vulnerabilities, to how it reacts to pushing, etc) and the code being generic enough to read those properties instead of doing all the switch-cases, or having to override virtual methods with custom tweaks. Frankly this is easily accomplishable with current codebase, but we'd need a better test-case coverage to make sure stuff doesn't break (running spider with demos is great but spider takes days to go through all of the demos).
2. Have the behavior of the monster being a property of the monster, rather than class extension. For example EvilEye would have CEvilEyeBehavior() attached to it (which in turn could internally have CRoachBehavior(), which runs when it's awoken).

This would easily support revolutionary developments.

Of course keep in mind that's a solution I came up with mostly on the spot, without very much thinking so there are obvious issues (how would Serpents, Rock Giants or Gentryii fit into the picture? I can think of a few solutions but that would be way beyond the scope of this post).

And I agree it's amazing how DROD managed to stay almost completely backwards compatible. I am not the biggest fan of this, but I can certainly be amazed by it .

____________________________
My website | Facebook | Twitter

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

I always have to be careful not to talk past people in engineering conversations. I can also get a little sloppy in my descriptions.

I see you're not trying to implement everything with the properties approach in your point 1 above. Your point 2 is a form of the pressure relief I was advocating.

People could argue further about inheritance vs decomposition. I've got no appetite for that argument though. It doesn't seem like a critical choice.

For my creatures in The Godkiller, I use a bunch of general properties like is stackable(), isPushable(), hasDeathTouch(). And the individual controllers of creature classes use composition and calls to general utility functions like Walk(), Push(), Get beeline movement().


-Erik



____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

averagemoe
Level: Smiter

Rank Points: 487
Registered: 03-22-2012
IP: Logged

So, I'm not hearing a definite "no" here. Should I PM my story pitch or what?

____________________________
There are two types of sheep in the world. Those who jump off a bridge when told to, and those who jump off a bridge when told not to. Don't be either.