• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Forum moderator applications are now open! Click here for details.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

Development: New Battle System

794
Posts
10
Years
To current date, people have offered to contribute, even asked for details, but I've yet to receive any dev. help as of yet.

That's about to change! Here are 200 moves that alongside with BluRose's ones create a full table of moves from genI to gen IV.
Spoiler:


Things to note:
Spoiler:


By the way, I looked at your damage calculator code and (I think) I spotted some minor errors.
Spoiler:
 

Blah

Free supporter
1,924
Posts
11
Years
Okay, this seems a lot more complicated then what I thought you wanted people to do. No wonder I was getting confused.

Wish I could help, but learning C# on Youtube means info goes in one ear and out the other.
Except this is in C, not C# :D

Oh, really? I'll try to edit less, then...
*never uses programming jargon again*
Okay, then...
Either way, the big block of 51 moves should be good, even if I use the wrong terminology to describe it.

Just like vanilla, no? In which a script ID of 0 just makes it use a move that calculates the damage and then applies it to the opponent, and then everything else has a different effect. Do we want to rewrite the AI or do we want to keep to the original move script table?

I have no idea how it works in vanilla. I'm just going to implement it this way since it seems the most logical. I will write the AI indeed, the current AI is very easy to beat and even on highest difficulty, it's not difficult. People try obnoxious things like giving your AI opponent Full restores and high stat Pokemon, but gone shall be those days! (Now you can have a smart AI AND full restores. What can go wrong?).

The thing then comes to mind would then be if you are going to make programming exceptions due to the accuracy above 100--for example, would it display in the Summary as, say 255 Accuracy instead of the hyphen that is usually present? And, eventually, would it be able to miss due to enough Sand-Attacks (.25 modifier (I believe 6 Sand-Attacks) makes a base of 255% accuracy down to 63.75% accuracy, less reliable than Focus Blast)?

I'm so sorry for these questions, by the way, and thanks for answering all of them thus far...

Nope, I'd just skip the accuracy check if it's over 100 accuracy.


Now, I'm going to end up making two script effect tables. The way he told me to make them would be the same way that Vanilla does: With a pointer leading to a Battle Script signifying each. However, if what FBI said about RAM allocations being different is really true and most of the Battle Scripts are useless under this system, how are we to do this, then?
Should we have a whole new effects possible table?

So the move effect table is being scrapped entirely. Move effects will be left to the move script entirely. Instead functions will be allocated for applying effects, and in the move script you simply call those functions. And yes, all the move scripts in vanilla will not be compatible unfortunately :/

Things to note:
- Move spikes doesn't have 0x40 in target field as FBI wanted. I gave it value of 0.
- Feint Attack and Swift have accuracy set to 255. This means that value is going to show in the box with move info while playing. I'd advice switching it to 0.
- Priority values are taken from Bulbapedia's Priority article
- There may be some errors.

Good catch. Lets use accuracy 0 instead of 255 then. I don't really want to make an unneeded hook to fix the issue :x

By the way, I looked at your damage calculator code and (I think) I spotted some minor errors.
Spoiler:
Spoiler:
 

GOLDstandard

Eclectic
51
Posts
10
Years
I tried to post this on Github a while ago but I see that it's not changed so maybe I didn't post it correctly.
So here are all the forms and megas with the POKE_ prefix
Spoiler:

I used certain forms as standard:
Spoiler:
 
Last edited:

ShyRayq

Unprofessional Unprofessional
1,856
Posts
16
Years
  • Seen Mar 26, 2024
I tried to post this on Github a while ago but I see that it's not changed so maybe I didn't post it correctly.
So here are all the forms and megas with the POKE_ prefix
Spoiler:

And the same list without the prefix.
Spoiler:

Just posting to say you forgot Unown ! And ?.
Also, if you're going to assume natural forms for Pokemon, shouldn't you do the same for Unown, Burmy, Wormadam, Cherrim, Shellos, Gastrodon and Basculin?
 

GOLDstandard

Eclectic
51
Posts
10
Years
Just posting to say you forgot Unown ! And ?.
Also, if you're going to assume natural forms for Pokemon, shouldn't you do the same for Unown, Burmy, Wormadam, Cherrim, Shellos, Gastrodon and Basculin?

An oversight on my part, will edit now. Thanks for noticing.

I did have some questions for FBI though. As far as graphics go, I take it we're going to use 64x64 sprites correct? In terms of other sprites like sprites for items, are we going to keep sizing consistent with cannon firered (24x24 iirc).

Also, depending on difficulty, it might be a cool feature to toggle in battle animations for Pokemon like in Emerald. I fear that may be too hard though.

Last question is about attack animations and battle backgrounds. Do you plan to rip the anims directly from the ROM or write a custom animation script that makes it easier to write new ones in the future?

Thanks, and keep it up!
 
Last edited:
794
Posts
10
Years
I tried to post this on Github a while ago but I see that it's not changed so maybe I didn't post it correctly.
So here are all the forms and megas with the POKE_ prefix
Spoiler:

I used certain forms as standard:
Spoiler:

I think Unown should have deafault indices as they are already in game between 0x19D and 0x1B7. I'm also not
sure if making Deoxys and Castform was necessary.
 

GOLDstandard

Eclectic
51
Posts
10
Years
I think Unown should have deafault indices as they are already in game between 0x19D and 0x1B7. I'm also not
sure if making Deoxys and Castform was necessary.

Why wouldn't Deoxys and Castform be necessary? Also, I know that Unown have default indices in the game, but that doesn't mean that we have to structure this engine in the same way. IMO it makes more sense to keep all forms that are not a change in Pokedex number to be in the forms/megas section.
 

BLAx501!

Pokemon Flux
80
Posts
10
Years
How is the developement of this project going?

I'm going to have more time next week since I have just two more exams at university, then I can help with anything needed ;)

EDIT: I've seen the Git and no commits have been done from over a month :'(
 
Last edited:

Blah

Free supporter
1,924
Posts
11
Years
So I took a small break during the Christmas Holidays to slack off deal with some family matters. Now I'm back, and I've started working again!

Thanks to everyone who has contributed a table file for the project!

--
Well, I've run into a somewhat unfortunate problem. For triple battles, there isn't enough room on the screen to keep the current positions of the battle platforms/HP bars. So we need to make a new kind of graphic for triple battles so the HP bars of your opponent, your own Pkmn as well as everyone's sprites are all displayed at the same time.

I've been considering using custom HP bars, since 64x128 per HP bar is ridiculously huge (the size FR uses by default). When I tried mapping things in their places we get this clustered image
uCwUuIx.png

The black boxes are Pokemon and the red boxes are supposed to be HP bars. As you can see it's a cluttered mess and you can barely make out the battle background.

So here is my request. Someone make some suitable custom HP bars, but they must have the following features:
1) One version for opponent, and another version for player
2) Player's version must display, lvl, exp bar, hp bar, pkmn gender, name
3) Opponent's version must display lvl, hp bar, pkmn gender, name, and the Pokedex "caught" icon
4) Try to squeeze it into 128 pixels long but maybe 32 pixels high?
5) can't look like crap :3

Once the HP bar is made, if you can make a little diagram of how you see it's placement in triples, I'd greatly appreciate that :D

More updates in the coming weeks.
 
So here is my request. Someone make some suitable custom HP bars, but they must have the following features:
1) One version for opponent, and another version for player
2) Player's version must display, lvl, exp bar, hp bar, pkmn gender, name
3) Opponent's version must display lvl, hp bar, pkmn gender, name, and the Pokedex "caught" icon
4) Try to squeeze it into 128 pixels long but maybe 32 pixels high?
5) can't look like crap :3

Once the HP bar is made, if you can make a little diagram of how you see it's placement in triples, I'd greatly appreciate that :D

More updates in the coming weeks.

There will need to be room for status condition indicators as well. Maybe while move animations are going, the health bars of everyone but the target could be hidden? Or everyone but the target and attacker for moves like Pain Split or something? It would go a long way into not making that battle screen a fustercluck.
 

MrDollSteak

Formerly known as 11bayerf1
858
Posts
15
Years
So I took a small break during the Christmas Holidays to slack off deal with some family matters. Now I'm back, and I've started working again!

Thanks to everyone who has contributed a table file for the project!

--
Well, I've run into a somewhat unfortunate problem. For triple battles, there isn't enough room on the screen to keep the current positions of the battle platforms/HP bars. So we need to make a new kind of graphic for triple battles so the HP bars of your opponent, your own Pkmn as well as everyone's sprites are all displayed at the same time.

I've been considering using custom HP bars, since 64x128 per HP bar is ridiculously huge (the size FR uses by default). When I tried mapping things in their places we get this clustered image
uCwUuIx.png

The black boxes are Pokemon and the red boxes are supposed to be HP bars. As you can see it's a cluttered mess and you can barely make out the battle background.

So here is my request. Someone make some suitable custom HP bars, but they must have the following features:
1) One version for opponent, and another version for player
2) Player's version must display, lvl, exp bar, hp bar, pkmn gender, name
3) Opponent's version must display lvl, hp bar, pkmn gender, name, and the Pokedex "caught" icon
4) Try to squeeze it into 128 pixels long but maybe 32 pixels high?
5) can't look like crap :3

Once the HP bar is made, if you can make a little diagram of how you see it's placement in triples, I'd greatly appreciate that :D

More updates in the coming weeks.

Actually FBI the existing HP bars for double battles use the same size for the player and the opponent, only displaying, Name, Gender, Level, Status and HP. They're 32 x 128 for both. But realistically they're more like 32 x 104 with how they're presented on screen.

Also I have no problem trying to work out how to align them on the screen, my only question is are you doing this in the Fire Red style? Otherwise I can probably dummy up a set of HP bars to use in the Platinum or HGSS style. I assume the insertion process will be the same as in Fire Red, ie. not rewriting the HP bar generation system. If you are there's probably a bit more freedom.

That being said, I really don't see how you can show 6 64x64 sprites and then 6 32x128 HP bars on the screen without severely blocking things. Maybe Deokishu's suggestion could work, perhaps being able to cycle through the HP bars before a move has been selected, maybe only having two on screen, and only making one HP bar pop up when a specific pokemon takes damage.
 
Last edited:
534
Posts
11
Years
  • Age 26
  • Seen Jul 24, 2023
Well, I kinda imagined triple battles to be somewhat like this (status indicators became colored dots; notice the purple dot indicates PSN status) :
svqNiLa
uehY4ak.png

And along with a mockup of how the Pokemon sprites should be aligned:
svqNiLa
svqNiLa.png

Transparent version (a little harder to read but looks more modern-styled) :
xM093IC
xM093IC.png

noAN36b.png


P.S. Tell me if you need the doubles and singles battle versions. I just posted this so you can see my concept of it.
 
Last edited:
91
Posts
14
Years
  • Seen Feb 22, 2023
To me those look kinda squashed, the gba screen is just really small. What probably could be done is the following: Do not show every single pokémon on screen at the same time, but instead make it so you can scroll through them when targetting. That would probably easier.

Also FBI: I think we are missing each other in IRC again :D

~SBird
 

Blah

Free supporter
1,924
Posts
11
Years
Actually FBI the existing HP bars for double battles use the same size for the player and the opponent, only displaying, Name, Gender, Level, Status and HP. They're 32 x 128 for both. But realistically they're more like 32 x 104 with how they're presented on screen.

Also I have no problem trying to work out how to align them on the screen, my only question is are you doing this in the Fire Red style? Otherwise I can probably dummy up a set of HP bars to use in the Platinum or HGSS style. I assume the insertion process will be the same as in Fire Red, ie. not rewriting the HP bar generation system. If you are there's probably a bit more freedom.

That being said, I really don't see how you can show 6 64x64 sprites and then 6 32x128 HP bars on the screen without severely blocking things. Maybe Deokishu's suggestion could work, perhaps being able to cycle through the HP bars before a move has been selected, maybe only having two on screen, and only making one HP bar pop up when a specific pokemon takes damage.

Style doesn't matter too much to me as long as it looks good and organised. I'm trying to avoid a cluttered screen and I want this to have a nice and clean look to it. If you can make some HGSS or plat style look great, then I'm all for it :D


Well, I kinda imagined triple battles to be somewhat like this (status indicators became colored dots; notice the purple dot indicates PSN status) :
svqNiLa
uehY4ak.png

And along with a mockup of how the Pokemon sprites should be aligned:
svqNiLa
svqNiLa.png

Transparent version (a little harder to read but looks more modern-styled) :
xM093IC
xM093IC.png

noAN36b.png


P.S. Tell me if you need the doubles and singles battle versions. I just posted this so you can see my concept of it.

Hmm not exactly what I'm looking for. Imo it's a little too hard to read the fonts, also consider a large portion of the community is also color blind.

To me those look kinda squashed, the gba screen is just really small. What probably could be done is the following: Do not show every single pokémon on screen at the same time, but instead make it so you can scroll through them when targetting. That would probably easier.

Also FBI: I think we are missing each other in IRC again :D

~SBird

I'm still kind of wanting a new revamp for doubles battles and such so I'll let the people who want to make something make something.


For now I'll start working on the cycling thing, I also haven't pushed anything to git yet guys (sorry I'm just working on a lot of things at once and not all of it compiles immediately!). Currently trying to make stuff for text and battle start sequences :D
 

BLAx501!

Pokemon Flux
80
Posts
10
Years
I'm just wondering about the attacks. How are they going to work now?

Are they going to be the same as now with the BSP and ASM routines or are you going to re-write them too in order to work different with the new system?
 

MrDollSteak

Formerly known as 11bayerf1
858
Posts
15
Years
i think something like this would be really cool!
GqmYZnO.png


for the font, if you would style it like this one so it would still be of the same size and attach it to the hp bar background, it would look just fine!!!
YNPvNEZ.png

Yeah I think something like this is probably the best bet to getting it to work! You'll need to move the status bar 1 pixel to the right. Also it could only be the 104x16 one in the middle tht would realistically work on screen.
 
34
Posts
8
Years
  • Age 22
  • OHIO
  • Seen Apr 17, 2016
First post ~

I'm a bit new to any kind of higher level coding, so a lot of that still hurts my head right now. lol

I've been attempting projects for a little over a year and constantly failed, but I think I've finally acquired enough knowledge to make a hack.

So will this be something I'll have to implement at the start of my hack? Or am I able to begin right now? If so, is there anything that I should avoid messing with and editing?

Thank you :)
 
Back
Top