Non-Named (More debugging)

[Filler]

Item menu thing. Not done.

[iyenal]

Well done. But I think that some colors can be changed.

[Filler]

Finalized item menu maybe? Each of the slots can hold 9 items each. Meaning there's 30 slots with 9 uses. (Ignore the typo of two Test 29 items)

[puggsoy]

There's also some issues on delaying encounters after running (this is mostly to prevent you from constantly getting raided by enemies the instant you run away).

This is a bit late but here's a fun fact about how Pokemon works: instead of randomly checking each step in long grass whether an encounter will occur, it instead sets a counter to a random number between an upper and lower bound after each encounter. Each step in long grass will then decrement the counter, and once it hits 0 a wild Pokemon will appear. This ensures that you will at least have to pass the lower bound number of steps before you encounter anything.

Not sure how you're doing encounters and from what I can see your movement is more continuous than discrete so you might need to do something else (e.g. pixels travelled?) but I'd suggest something like that rather than just delaying, might allow a bit more control.

[Filler]

Thanks for the suggestion.

That actually sounds easier to program than a timer based one, as I wouldn't have to focus on the timer staying put on menus being accessed and such.

[Filler]

Final item layout? Dunno. Haven't been feeling that happy in terms of mood, so I haven't been doing much.


Changed the design of the item quantity to look a bit easier on the eyes, as the options have been added:

• Use does what you'd expect.
  
• Hold lets a party member hold an item, which can be used as a form of storage that you can't use. Some items have special effects when held, too.
  
• Toss throws out 1 quantity of the item selected.
  

Some other stuff:

• Maximum was changed from 9 to 5, as I feel like you'd have way too much items.
  
• There's now a centre-line to make it easier on the eyes.
  

[iyenal]

Maybe a blue palette ? Or maybe custom color settings.
As you understand, I don't find this color very beautiful, but if you like it don't change.
And I think the right panel can be better centered horizontally.

[Filler]

I chose neutral colours so that they don't stand out too much compared to everything else.

Works fine on the GUIs in gameplay, but it looks sorta weird here. The whole menu is a sprite (so I can animate it), so I might allow colour changing.

[Filler]

Been brainstorming how enemies should attack, I decided the enemy behavior could have a list with each enemy that could be adjusted.

For example:

0. The Test Monster attack you! <HP/5>
1. The Test Monster stole some AP you! <AP/5>
2. The Test Monster rasied it's offense! <MATK/5>
3. The Test Monster rasied it's defense! <MATK/5>
4. The Test Monster raised it's speed <MSPD/5>
5. The Test Monster raised it's dodge <MDOG/5>
6. Test Monster raised it's HP <MHP/5>

For example, during the enemy's turn, it'll draw the text before "<" as the stat to reduce is determined by the text after "<", and before "/", and the amount affected is by after "/", and before ">"

I assume attack order will be another list that'll update, maybe organized by speed?

[puggsoy]

I'm assuming this is following the traditional RPG battle system in which case this is how I'd do it.

Enemy actions are decided semi-randomly each turn, different enemies have different weights for each action (e.g. some may only attack, some may increase defense very often, etc). Weights may change dynamically for some enemies as a form of AI, making some actions more or less likely depending on certain conditions (e.g. if the player is at low health, an enemy may be more likely to attack).

For attack order, you'd just have a list of all characters in the battle every round, and order them by speed stat. Once you've gone through the list a new round starts and the list might change order, since speed can change during battle.

[iyenal]

Weights may change dynamically for some enemies as a form of AI, making some actions more or less likely depending on certain conditions (e.g. if the player is at low health, an enemy may be more likely to attack).

The idea of AI is interesting, maybe make a diagram of events so you can schematize and clarify it clearly and after code.
Also bring sometimes random events to make unexpected things.

[Filler]

More brainstorming from a game design standpoint, been thinking of how this should work.

Attack list:
>Doing actions sets each party member action and attack to a list.
>After that, enemy stuff is set up
>Speed order bool sets after everything is set
> After that, the turn order is chosen via speed.
>Speed order bool shuts off afterwards, as attack order bool happens.
>Turn order stats, stats are deducted so, as animations and such are played.
>Returns to normal, as both bools are shut off.

Is this how it should work?

[puggsoy]

Not sure what the bools are for? Like I think I get their function but they shouldn't really be necessary, if I understand you correctly. Otherwise that seems about right though.

[Filler]

Bools set things to true or false. Can be used to do quick checks.

[puggsoy]

I know what booleans are lol I meant why are they there? I assume the process is done sequentially, why do you need a bool to keep track of whether you're ordering turns by speed (this should be a simple for loop at most), executing turns (this should run through a list), or neither?