Getting into a groove again
Tentacular Circus from Splatoon
Hi all. Things have settled down a fair bit for me. I've accustomed to a more ordinary, early wake-up-and-go schedule, and I've gotten the anime binge-watching situation under control by setting a three-episode-per-day-max house rule. ;)
This month has been a HUGE surge forward in productivity for Forgotten Gates. :D Mainly this is because my new job has been plagued by a lack of proper objectives and direction on using the archaic system from our client, so...a lot of the time during which my team and I were waiting on various clarifications, I spent working on FG. n.n; I feel a little slimy for doing stuff like that on company hours, but there isn't much of value to the company I could've done otherwise. I would prefer that such a wasteful situation didn't happen at all, but as long as it is, I guess I'm a relatively good person to have in it. c.c
I completed the DynBattleChoices plugin, which records data about the actions taken by battlers -- what type of action was chosen, the ID of the skill or item used if any, the target, etc. In FG, this means I'll be able to replace the clunky "choose a number"-based targeting system with RM2K3's built-in targeting. That does have a few unfortunate ramifications. Every ability that involves letting the player choose a target will need to be implemented as a "skill" in the RM2K3 system, although I'll be using those skills simply as triggers to feed into my battle plugin. This means, for example, that the basic Fight ability, which most games would give its own command, will have to be a skill that costs 0 MP. Not a huge deal, but it could throw players off for a bit. I won't be able to get more than one target input from the player per turn, and it has to happen before any scripting, so things like choosing two different targets for a dual-wielding hero goes out the window. It also means that the random-target-becomes-chosen aspect of Noab's Tactics ability isn't going to work. Still, I think having a clean targeting system is well worth those limitations.
After completing DynBattleChoices, I got to work on updating the scripting of my project in RM2K3 to interface with the battle plugin I've been making. The hardest part of this was overcoming the instinct to work around the existing scripting, which had huuuuuge monster group event pages covering all possible animations against each possible target, calling a common event every so often to shift values from holding variables into working ones. I already knew DynParams would eliminate the combinatorial explosion of animations and targets for me, but there was more simplification to be done. The existing scripting took on too much of a logic burden, with things like "if the damage multiplier is below 0 display a negative damage reaction animation, otherwise check if it's below a certain threshold and if so display a low damage animation, etc..." As I rewrote this system, I decided to move all of that burden to the plugin, and have the RM2K3 scripting simply say, "Check this variable for the damage reaction animation number, if it's anything besides 0, show that animation." The difference in complexity from before to after is phenomenal.
In making these changes, I'm having to essentially gut the old combat system, including all the common events which used to calculate the results of actions and feed them to the monster group event scripting. That probably represents the first year or two of scripting work I did on the project, wiped from existence. X) Not totally of course, the general logic of it lives on in the battle plugin, but still. I'm having to be very careful about that too, because "deleting" a variable or switch in RM2K3 doesn't really mean it's gone like in most programming languages. It just means that a certain index in the huge array no longer has an explicit name. There are variables I chose for the combat system which I also used in other systems, since they wouldn't be running at the same time. Bad programming practice, but I thought at the time that it was a smart optimization considering RM2K3's limited storage and the ambitious nature of the project. Bottom line is, if I "delete" a variable or switch and change it to something else, but an existing system I'd forgotten about is still using it, it could cause problems...problems that are very difficult to trace back to the source. :P
On NMR, I ran a chuunin exam scene -- not the usual big event with a lot of competing chars, just a couple genin sent on a contrived mission to test them -- as Cherii. The genin were sent to collect a rare crystal lily deep in the woods, with a scroll guiding them to the spot and describing the flower...only the innermost part of the scroll was smudged. The flower turned out to grow on top of a monster that looked at first like just a bundle of tree roots. The genin had to contend with tentacle-like roots while trying to clip the flower and make off with it while avoiding damage to it. When they got back, Cherii cheerfully took the flower, which was made mostly of crystallized sugars, and used it to top a cake celebrating the appointment of the new Tsuchikage. n.n
I also did a scene for the What If? Pokemon challenge with Mushi. Aburei was a minccino, Mushi was an espeon, and both of them were still medics in the what-if scenario. An absol, which are well-known for predicting disasters, showed up in a town shouting about an impending mud-slide, so they evacuated the town...only Aburei went back at the last minute to get a kecleon that was sleeping under sedative treatment. Mushi went to check on Aburei when he didn't catch up with the others, and found that the absol had caused the panic simply so that he and his gang could loot the village while everyone was away. Fighting ensued, baddies were blasted, the usual good time. ;)
Super Mario Maker:
Yay more Mario! X) And this time it's from Nintendo's official editing application. Super Mario Maker is an interesting offering. It doesn't come with a great deal of Nintendo-made stages, and the ones it does have are mostly short, single-idea things meant to demonstrate a building concept. I guess they didn't want polished in-house designs overshadowing the offerings of the playerbase.
The obvious downside is, a lot of the levels you'll play through in this game are uninspired. There are gems to be sure, and if you like you can filter the stages according to certain tags (puzzle, music, automatic, etc.) and the ratings of other players. But Nintendo implemented a clever system for encouraging players to take what they're fed, to a degree. It's called the 100-Mario Challenge, and it might be said to be the main game mode. You start with 100 lives, and you have to clear a certain number of randomly-chosen stages within your selected difficulty level. You're rewarded for completing this challenge with a costume, which widens the appearances you might end up with when collecting a mystery mushroom (gameplay-wise, it functions like being Super Mario without being taller). There are over 100 costumes to collect, so if you care about completion, you'll be hopping your way through quite a lot of community-made stages.
To maintain a degree of fairness, you can skip any stage you please without penalty (aside from whatever lives you've already lost attempting it). This is crucial at the higher difficulty levels; to survive all the way through, you have to learn to recognize when a stage is not just hard, but unfair, and cut your losses. Another clever rule they made to maintain challenge is that you can earn at most three lives per stage, and they don't take effect until you complete the stage. That way you can't redo a stage with lots of 1-UPs available just to stock up, and more importantly, you can't blame your failure on not running into enough such stages if you lose.
So how about the stage-making aspect? I have to confess I haven't really gotten into it, as poorly as that might reflect on me as a designer. X) I will say that they came up with some clever ways around the limitations of having only a touch-screen for the interface. To switch "modes" of certain objects -- for example, to turn a green koopa into a red one, or other options -- you take that object and shake it, until *POOF* it transforms. Also, rather than having some sort of checkbox for deciding options like "this enemy has wings", they make that an object you can drag from the bin onto the thing you want...and they make it applicable to nearly EVERYTHING. XD You can see Bowser with wings, and goombas swimming in the water, and all sorts of bizarre things. It really adds to the "play" nature of the editor.
Bottom line? It's not the polished experience you typically get from a Mario game, but that's not really the point. Get it if you like community-made stuff, or always wanted to make your own Mario stages.
Click to viewHi all. Things have settled down a fair bit for me. I've accustomed to a more ordinary, early wake-up-and-go schedule, and I've gotten the anime binge-watching situation under control by setting a three-episode-per-day-max house rule. ;)
This month has been a HUGE surge forward in productivity for Forgotten Gates. :D Mainly this is because my new job has been plagued by a lack of proper objectives and direction on using the archaic system from our client, so...a lot of the time during which my team and I were waiting on various clarifications, I spent working on FG. n.n; I feel a little slimy for doing stuff like that on company hours, but there isn't much of value to the company I could've done otherwise. I would prefer that such a wasteful situation didn't happen at all, but as long as it is, I guess I'm a relatively good person to have in it. c.c
I completed the DynBattleChoices plugin, which records data about the actions taken by battlers -- what type of action was chosen, the ID of the skill or item used if any, the target, etc. In FG, this means I'll be able to replace the clunky "choose a number"-based targeting system with RM2K3's built-in targeting. That does have a few unfortunate ramifications. Every ability that involves letting the player choose a target will need to be implemented as a "skill" in the RM2K3 system, although I'll be using those skills simply as triggers to feed into my battle plugin. This means, for example, that the basic Fight ability, which most games would give its own command, will have to be a skill that costs 0 MP. Not a huge deal, but it could throw players off for a bit. I won't be able to get more than one target input from the player per turn, and it has to happen before any scripting, so things like choosing two different targets for a dual-wielding hero goes out the window. It also means that the random-target-becomes-chosen aspect of Noab's Tactics ability isn't going to work. Still, I think having a clean targeting system is well worth those limitations.
After completing DynBattleChoices, I got to work on updating the scripting of my project in RM2K3 to interface with the battle plugin I've been making. The hardest part of this was overcoming the instinct to work around the existing scripting, which had huuuuuge monster group event pages covering all possible animations against each possible target, calling a common event every so often to shift values from holding variables into working ones. I already knew DynParams would eliminate the combinatorial explosion of animations and targets for me, but there was more simplification to be done. The existing scripting took on too much of a logic burden, with things like "if the damage multiplier is below 0 display a negative damage reaction animation, otherwise check if it's below a certain threshold and if so display a low damage animation, etc..." As I rewrote this system, I decided to move all of that burden to the plugin, and have the RM2K3 scripting simply say, "Check this variable for the damage reaction animation number, if it's anything besides 0, show that animation." The difference in complexity from before to after is phenomenal.
In making these changes, I'm having to essentially gut the old combat system, including all the common events which used to calculate the results of actions and feed them to the monster group event scripting. That probably represents the first year or two of scripting work I did on the project, wiped from existence. X) Not totally of course, the general logic of it lives on in the battle plugin, but still. I'm having to be very careful about that too, because "deleting" a variable or switch in RM2K3 doesn't really mean it's gone like in most programming languages. It just means that a certain index in the huge array no longer has an explicit name. There are variables I chose for the combat system which I also used in other systems, since they wouldn't be running at the same time. Bad programming practice, but I thought at the time that it was a smart optimization considering RM2K3's limited storage and the ambitious nature of the project. Bottom line is, if I "delete" a variable or switch and change it to something else, but an existing system I'd forgotten about is still using it, it could cause problems...problems that are very difficult to trace back to the source. :P
On NMR, I ran a chuunin exam scene -- not the usual big event with a lot of competing chars, just a couple genin sent on a contrived mission to test them -- as Cherii. The genin were sent to collect a rare crystal lily deep in the woods, with a scroll guiding them to the spot and describing the flower...only the innermost part of the scroll was smudged. The flower turned out to grow on top of a monster that looked at first like just a bundle of tree roots. The genin had to contend with tentacle-like roots while trying to clip the flower and make off with it while avoiding damage to it. When they got back, Cherii cheerfully took the flower, which was made mostly of crystallized sugars, and used it to top a cake celebrating the appointment of the new Tsuchikage. n.n
I also did a scene for the What If? Pokemon challenge with Mushi. Aburei was a minccino, Mushi was an espeon, and both of them were still medics in the what-if scenario. An absol, which are well-known for predicting disasters, showed up in a town shouting about an impending mud-slide, so they evacuated the town...only Aburei went back at the last minute to get a kecleon that was sleeping under sedative treatment. Mushi went to check on Aburei when he didn't catch up with the others, and found that the absol had caused the panic simply so that he and his gang could loot the village while everyone was away. Fighting ensued, baddies were blasted, the usual good time. ;)
Super Mario Maker:
Yay more Mario! X) And this time it's from Nintendo's official editing application. Super Mario Maker is an interesting offering. It doesn't come with a great deal of Nintendo-made stages, and the ones it does have are mostly short, single-idea things meant to demonstrate a building concept. I guess they didn't want polished in-house designs overshadowing the offerings of the playerbase.
The obvious downside is, a lot of the levels you'll play through in this game are uninspired. There are gems to be sure, and if you like you can filter the stages according to certain tags (puzzle, music, automatic, etc.) and the ratings of other players. But Nintendo implemented a clever system for encouraging players to take what they're fed, to a degree. It's called the 100-Mario Challenge, and it might be said to be the main game mode. You start with 100 lives, and you have to clear a certain number of randomly-chosen stages within your selected difficulty level. You're rewarded for completing this challenge with a costume, which widens the appearances you might end up with when collecting a mystery mushroom (gameplay-wise, it functions like being Super Mario without being taller). There are over 100 costumes to collect, so if you care about completion, you'll be hopping your way through quite a lot of community-made stages.
To maintain a degree of fairness, you can skip any stage you please without penalty (aside from whatever lives you've already lost attempting it). This is crucial at the higher difficulty levels; to survive all the way through, you have to learn to recognize when a stage is not just hard, but unfair, and cut your losses. Another clever rule they made to maintain challenge is that you can earn at most three lives per stage, and they don't take effect until you complete the stage. That way you can't redo a stage with lots of 1-UPs available just to stock up, and more importantly, you can't blame your failure on not running into enough such stages if you lose.
So how about the stage-making aspect? I have to confess I haven't really gotten into it, as poorly as that might reflect on me as a designer. X) I will say that they came up with some clever ways around the limitations of having only a touch-screen for the interface. To switch "modes" of certain objects -- for example, to turn a green koopa into a red one, or other options -- you take that object and shake it, until *POOF* it transforms. Also, rather than having some sort of checkbox for deciding options like "this enemy has wings", they make that an object you can drag from the bin onto the thing you want...and they make it applicable to nearly EVERYTHING. XD You can see Bowser with wings, and goombas swimming in the water, and all sorts of bizarre things. It really adds to the "play" nature of the editor.
Bottom line? It's not the polished experience you typically get from a Mario game, but that's not really the point. Get it if you like community-made stuff, or always wanted to make your own Mario stages.