Are there scripts for masks and the rod of seasons?

Started by Oahron, July 13, 2018, 10:09:45 PM

Previous topic - Next topic
Has anyone been able to successfully implement masks or the rod of seasons like in the RPG Maker's Project Zelda Engine?

I don't know if anyone's done it already, but doing a rod of seasons using dynamic tiles and map:set_tileset() it should be relatively easy, compared to other main, game-wide mechanics at least. All the aesthetic changes would be done using matched tilesets, and then whatever dynamic elements you'd want on each map, you could define on a map-by-map basis. I don't think it'd be one script you could copy and paste though, so you'd definitely want some experience with the engine first.

For masks, I can see how you'd do a few of them fairly simply, the most labor intensive thing would be the graphics of your hero in each mask. The Solarus engine is a lot more flexible than project Zelda, but it requires more front-end investment in learning how to use the engine and writing scripts.

I agree that using a different tileset for each season is the natural way to do so. The rod itself is just a sprite, which is very easy to do. But changing the season, appart from changing the tileset, would probably require some custom event(s) on each map, which would do some extra stuff depending on the season and the map itself.

I suggest the syntax: "map:on_season_changed(season)". Then your rod item script should be charged of changing the tileset (if possible) and calling these custom events (when they are defined).
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."

And now we're just hijacking this thread to discuss how you'd hypothetically do this, but Oracle of Seasons is probably my favorite Zelda game, haha.

The rod item I think could easily change the tileset, wouldn't you just do
Local game = item:get_game()
game:set_tileset(game:get_value(current_season )+ 1)
If current_season == 3 then current season = 0
Where you have a game value for the season and your tilesets are named accordingly. Then you'd set a new value for current_season. It'd be easiest if your seasons were just numbered.

Most of the seasonal changes could be dynamic tiles that the map:on_season_changed() function could set enabled/disabled. Ice, leaves, vines, snow, that could all be done with dynamic tiles. Water getting shallow in summer could be the same, but honestly I'd have a special type of "summer shallow" water in the tilesets set to deep water in 3 of them and shallow water for the summer set, so it'd work automatically. Same with bushy trees you can only squeeze past in winter.

There's a few elements like those bouncy flowers that bloom in spring that'd need to be custom entities. But things like those rock mushrooms that are pickable in fall could be destructables, you'd just stack the pickable and the stuck on top of each other and set the pickable disabled 3 seasons and set it enabled in fall, reverse for the non-pickable version.

Then I'm sure there's plenty of ideas that Capcom didn't even think of. Difficult to traverse mud in spring, or slopes you couldn't climb because of mud, a river that floods in the spring and the nearby forest is in a floodplain, so it'd all be shallow water. Maybe fires might start during the summer, or maybe you'd need to bring autumn rains to put one out. A rainy season, especially if you had a particular area of the world that got spring or autumn rains so it wouldn't be global, but in that area there'd be mudslides, puddles, flooded rivers, fires would be put out, rapids would develop, plants would grow big.

Certain enemies could only appear in certain seasons, or be in different parts of their life cycles. Maybe there's a grub enemy that's easy to fight in spring, but by autumn it's matured into a dangerous beetle. Winter might kill off some enemies or cause them to hibernate. Maybe there's a bear like a Snorlax that won't wake up and get out of your path until spring. Maybe theres a forest full of wolves, but they're just a few here and there, but in winter they're only in their den and there's a bunch right together.

Then there's a ton of small environmental touches that Oracle of Seasons couldn't do because of the gameboy's processing power. Fireflies in the summer, falling leaves in the autumn, snow effects in the winter. A random weather system would pair well, and the probabilities of weather would change with each season, so it's unlikely to rain during the summer, but if it does it's a big thunderstorm.

I've thought a lot about this kind of system because Oracle of Seasons is probably my favorite Zelda game, but I've never acted much on it because I've been hesitant to just steal an idea so wholesale like that. But I also think Capcom could have gone much further- for example, why didn't they ever use the season mechanic in dungeons? The puzzle density and different player expectations for dungeons would have paired fantastically, I think.

There's some overall design decisions to make too- I think having the player explore much more of the overworld before they can change the seasons at all would be better, to develop seasonal mechanics and how they work before the player messes with them, so that way the player can form their own solutions based on previous experiences. So instead of, I can't cross this river, but I can cause either winter or summer so I'll see which helps, instead of that it'd be, I can't cross this river but I remember encountering a frozen river earlier, or I remember a dry stream bed from earlier, maybe I can make that happen. Give the player a reason to be more intentional with which season they choose- equipping each season independently would reinforce this, so they'd choose "I want to bring summer" instead of, "let's try a different season." This could be a setup like A Link to the Past, where you have to travel the majority of the world to go through a couple dungeons to even get the main mechanic.

Capcom was smart about only letting the player change the season at certain spots though, because that automatically prevents a lot of tricky situations where you'd suddenly be stuck in a snow bank, I would personally keep that.

Maybe I'll work on it someday. In the mean time, anyone who tries this system in their own game has my full support.

Quote from: Max on July 15, 2018, 04:52:26 AM
Most of the seasonal changes could be dynamic tiles that the map:on_season_changed() function could set enabled/disabled. Ice, leaves, vines, snow, that could all be done with dynamic tiles.

Using dynamic tiles would be okay if you're just talking about a small number of entities on the map here and there. If the majority of the tiles were dynamic tiles, then I think you'd be losing out on a number of optimizations that are made with static tiles.

An alternate idea would be to create a single seasonless map in the map editor, but then at run time use lua to dynamically output separate map.dat files, one for each season. The seasonless map could use custom entities for season-specific things, such as pile_of_leaves_fall, fireflies_summer.

I guess it would depend on how you set up your game, but Oracle really had very few of these per map, since each was just one screen. Even with larger maps, I don't imagine you'd be having more than a couple dozen per map tops. Especially if you did ice as a tileset thing like how I suggested water that dries up in summer. I mean, realistically, how many dynamic tiles do you need before any systems would start to struggle? 100?

Also, after further consideration, most dynamic tiles I was thinking could probably be normal tiles. Vines, for example, in the summer tileset you'd have vine tiles that were set as a ladder tile, and in the other tilesets you'd have a corrospondingly named tile that's just blank and empty. So the tile is still there (no errors when the tileset is switched), but it's just empty. Puddles could be done like this too, most aesthetic changes, you could have corrosponding empty tiles for snow banks, etc. Then there's even fewer dynamic tiles you'd need.

The reason I was thinking you wouldn't want multiple map.dat files is because wouldn't each season then he considered a new map, and therefore would respawn enemies, regrow cut bushes, reset pushed blocks, etc when the season changed?

Another important tool for this is the "custom properties" of Solarus 1.6. You can add a season property to some entities, and when that property is defined (not nil) and different from the current season, that entity would be destroyed when the map has been created. That together with the custom events are very flexible and powerful tools to work with.
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."

Thanks for the information, that definitely gives me some direction!  I'm excited to experiment with it.  Has anyone had any success creating transformation masks--- like how it worked in Majora's Mask?

No one has tried. But it is all perfectly doable. The only problem is to find enough free time to create the art and code it.
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."