Use "replace" areas to change the Map Objects groups

[Zukero]

Hello,

Coding spree striked again. I have almost completed initial coding (no code executed yet) of the handling of Map Objects groups by the replace objects. So here is how it works : it's exactly the same as the graphics layers ......
..... except the game engine currently doesn't care about the MapObject groups ! (You know, the little folder in Tiled, where you place your MapObjects). Need a proof ? The current "debugmap" used for debugging only uses NONE. All objects of all types (rest, mapchange, key, sign and mapchange) are in the same group "Object Layer 1". Only the spawnarea are separate, but even then, the map parser really doesn't mind about it. So, here is what I did :
- All Map Objects now hold a reference to the group they belong to in Tiled (String variable conatining the group's name).
- All Map Objects include a "isActive" boolean variable, initially set to true for all.
- When a replace area references a Map Object Group, as the "new" group after replacement, all members of that group are initially disabled (isActive = false).
- When the condition of the replace is met, all the Map Objects belonging to the source groups that are FULLY INCLUDED in the replace area are disabled, and the Map Objects belonging to the target (new) groups that are FULLY INCLUDED in the replace area are enabled. ATM, the replace condition is the usual Quest Progress, for those expecting the broader requirements referenced in this topic, it will be done when I will merge my two branches, but I wanted to keep the features separate.

The Spawn areas are concerned too, but ATM I don't know how to deal with the spawning of the new vs disappearing of the old.... what I did is let the old monster live, but not respawn, and do not auto spawn the new ones, but let them random-spawn. Everything is as expected after a full reset of the map (the 3 minute counter).
WHAT IS YOU OPINION :
- #1 Clean up everything. Make the old monster vanish, and the new ones appear as soon as the map replace is activated !
- #2 Leave the old, spawn the new.
- #3 Leave the old, don't spawn the new. Wait until the 3 minute counter, just as it currently is.
- #4 All of the above, depending on a property of the "replace" object. Power to the map makers ! (Those who will NOT select this option deserve a free hug ! )

Oh, and note that for extra-juicy feature feast (and mapmaking & debugging headaches), those replace areas can also be replaced by other replace areas ! Change your map completely (including map size, using neat tricks with "walkable") at every quest stage ! (After the merge), add rainbow bunnies everywhere for those who carry two RoLS and two RoL !

After implementation of your favorite behavior (#1, #2, #3, or #4) and some testing, I'll send the pull request to Oskar and start merging the two features in a single branch, so that if Oskar hasn't yet merged any when I'm done, and if he likes both, he will only have one commit to merge !

[Ian]

Wow, this just sounds great! You're the man!
It's awesome that we could even replace the replace area!

I chose of course #4 cause I'm a mapmaker. It would be great could code this.
So would the first option make it possible to spawn a new spawnarea where nothing was before (ambush)?

[fiernaq]

Very awesome features! Not entirely sure I understand how the replace areas bit works but if option #4 isn't that difficult to code then it certainly sounds like it would provide the most options to map makers which is what they need to make better maps.

[Zukero]

Ask ! And Thou shalt be served !
Option #4 was implemented and tested today !

Ian, you can create and/or remove any type of area as you please. To create something out of the blue, just use a non-existing group name as source (what to replace). Similarly, to remove something, use a non-existing group name as target.

Actually, you cannot replace the replace area, BUT, you can use several of them using different conditions, and make one remove the object areas introduced by the previous replace area....
For example :
- Before starting quest "testquest", no spawn area, one area locked by a "key" area
- At stage "testquest:10", 3 zones full of "bad_guy", no more key area
- At stage "testquest:20", all the "bad_guy" turned into "bad_zombie", what's more, the key area came back, locking you up with the zombies !
- At stage "testquest:30", the "necromancer" summoning the zombies appeared, cause you killed too many zombies (the ones still alive are still there though)... still locked
- At stage "testquest:40", you defeated the necromancer, the place is unlocked, but some new "bad_guy" came in.

Replacing the replace areas would be easy code-wise, but wouldn't make any sense functionally... re-replacing is way easier.

Now, imagine the crazy possibilities, and imagine using more than just quest stage required as conditions ! I'm just having concerns about the items-related conditions. Replacing an area based on worn or carried item induce the following problems :
- Map replacement is not persisted, but reinterpreted at load-time. A user can enter an area with two RoLS and see the replacement, remove the RoLS and still see the replacement until he quits and reloads the game where he would see the previous step...
- To prevent inconsistencies, I would have to code an "undo" for the replace, which may be complicated when several layers of replacement are used...
- Even with the undo, what would be the spawning strategy (#1, #2, or #3) depending on the intended strategy...
IMHO, after merging of the "Requirements" feature in the replace, I'll have to restrict the allowed Requirement types to persisting ones (quest, skill, monster killed, or the upcoming "inspired-by-Pyrizzle" consumed quantity of given item).

Do you see a point in having "replace" areas triggered solely by item possessed or equipped ?

[Zukero]

If you wanna try it out for yourself, the code is available (with test data) on my github, as branch replace_map_objects.
Here is a direct link
You need an AT build environment though

Pull request : sent !

[Pyrizzle]

#4 for sure! It would add new dept to the game!

Great work Z!

[Zukero]

Great work Z!

I don't like it when you call me "Z"
Call me "Zuk" if you want it short mkay ?

Back on topic : I'm facing a design choice and need your opinion (especially Ian's and other Tiled users).

Graphics layer replacement and Map Objects replacement are handled very differently in the code, and I had to include special checks in the parsers to avoid having too many warning about Map Object parser not recognizing the Graphics layers as Map Object groups and vice-versa.
Code-wise, it would make sense to use another type of area, like "replace_objects" to define the changing nature of map objects, and keep the "replace" areas as they were (graphics only). Code would be cleaner, and (very) slightly more efficient (a few CPU cycles saved, and a few bytes of RAM saved).
But, IMHO, from a map making point of view, they are the same conceptually, and sometimes, you'll want a single area to define both graphics AND objects changes. Having to define both would simply be boring (and confusing in case of large number of replacement layers).

There are pros and cons for both solutions. I think one favors the map makers & testers, while the other favors coders and, to a very very small scale, players.

Your arguments ladies & gentlemen ?

[cccd3cpt]

Not really related directly to this, but I keep up to date with the github repos and see that you are doing some awesome work.
Kudos Zukero! You've contributed so much in such little time on there.
Haha, love reading your and Oskar's comments, lots to learn from them!
Nice to have another hardcore dev! Keep up the good work!

Lol and I will read this and provide some actually useful input

[PK17]

Whatever saves the most storage space and development time is usually the safe road to bet on. Although I feel like keeping the clutter away from 'the layers' would do a lot of good, especially if you are in essence repeating layers. I think both options are very reasonable and it is hard to favor one or the other, depending on what someone's personal forte of development is, is going to reflect what side they are on. I feel asking Oskar is the best choice (as is in most scenarios), because of the mixed answers.

But then again, I do not go near the coding aspect of the game, unfortunatley, that is a concept that eludes the grasp of my mind to this day.

[Zukero]

Not really related directly to this, but I keep up to date with the github repos and see that you are doing some awesome work.
Kudos Zukero! You've contributed so much in such little time on there.
Haha, love reading your and Oskar's comments, lots to learn from them!
Nice to have another hardcore dev! Keep up the good work!

Thanks ! That's very pleasing to read, especially from someone WHO PORTED AT TO BB ALONE !
I'm sure you're referencing the types of technical & conceptual comments, like MVC vs SOLID. Discussing SW design can be very fun and intersting, but at some point, it's better to stop and just code... otherwise nothing gets done.
However, I hope Oskar will end up agreeing with me. I'd love the AT code to be more fit with OOP philosophy. Way easier to maintain. Then, maybe we're just not agreeing on what OOP philosophy is at all I'll keep contributing anyways, and will respect his vision of the AT coding style.

Whatever saves the most storage space and development time is usually the safe road to bet on. Although I feel like keeping the clutter away from 'the layers' would do a lot of good, especially if you are in essence repeating layers. I think both options are very reasonable and it is hard to favor one or the other, depending on what someone's personal forte of development is, is going to reflect what side they are on. I feel asking Oskar is the best choice (as is in most scenarios), because of the mixed answers.

Well, the current code uses a single replace area for both. I believe short term dev time, and less cluter in tiled are in favor of the actual code.
The optimization given by the other option are almost negligible, but would make the code really cleaner (less long term dev time). The only downside (which is pretty major for me) is the hassle for map makers.

Oskar raised this point in the GitHub comments, and I responded by directing him here. I'll change to option 2 if (and only if) Oskar and/or the majority of the community tells me to.