I took a look at the RBY battle engine at one point and it seemed like a mess. The 2gen engine is also a bit awkward, but mostly because it has a tendency to duplicate a lot of the logic. You seem to be of the opposite opinion. What is it that makes the RBY battle engine easier to work with?
It's hard to explain, and I guess it can be labeled as a personal preference. Gen 2 is clearly much better written than Gen 1 and far more robust. It even feels like a higher level language at times. In particular the Gen 1 battle engine feels easier to pick up and dissect; in Gen 2 it feels that you'd have to go through and recode at least twice as many things to remodel the battle engine the way I'm doing. I also always had this idea in mind of reconsidering the functionality of every part of the game at some point, so Gen 1 obviously felt a lot more accessible. The amount of code in Gen 2 is just overwhelming and never ending.
So yeah, maybe I should've started with Gen 2 as a base, or at least consider it more carefully before starting. After all, you could argue that at least one third of the things I'm aiming to implement already exist. But for the remaining parts, reverse-engineering and rewriting the GSC code can be a lot scarier, at least at first glance.
This is an incredibly innovative hack. Some thoughts:
- Showing moves being evaded or failing is neat. I never liked the lack of animation in the official games.
- When Pokémon are swapped in double battles, how about moving them up/down instead of right/left to distinguish it from evasion?
- Bulbasaur was poisoned; do you plan to make Poison types immune to poisoning (and Fire to burning, Electric to paralysis, and Ice to freezing)?
- Bag pockets are very convenient.
- The mobile PC system is interesting. It seems like you could effectively enter a dungeon (I'm thinking of Silph Co.) with a team of 6+20 Pokémon. Will the overall difficulty assume that players do this, or do you have a counter in mind?
- Menus in the overworld are gray, not the sharp black and white of submenus like the party list. Was this unavoidable due to palette space?
2. It would feel less realist imo. I think that the horizontal animation comes closer to suggest that rather than the Pokemon moving, the camera angle or your eye sight is changing its direction. The move animation and feedback text should be enough to let the player know whether an attack is being evaded or a Pokemon is being scrolled in. You know, ideally all 4 pokemon would be displayed, but due to screen space and other hardware limitations it's not feasible unless you make the sprites extremely small and make everything look excesively congested.
3. There are many minor things like these that are not implemented but it's not a big deal. Nothing relevant to read from that. I have a very big data sheet and progress document where different minor mechanics like these are also contemplated.
5. Yeah, you know, the feature itself suggests what it could be useful for. I have studied how I'm willing to have this feature play out and what it is going to offer more carefully, but the overall goal can more or less be guessed.
6. It's something that I haven't really taken care of yet. It's a leftover from the color hack this game is based off, and other than fixing a couple of minor bugs here and there I haven't done anything about it. But as with everything else, I expect to go through these kind of things eventually.
