I’m working on a turn-based battle system, building upon what tricxta made. I had to write the character selection thing 4 times now and I still can’t get it right.
This version produces a growing area and checks if something’s in it every time it gets bigger, getting the closest npc if multiple are found. The preceding version checked whether if something was in the direction that was pressed and if nothing was, it would check for the closest npc in the direction that was pressed.
I still run in the same problem, sometimes the npcs will be placed in a way that makes them impossible to select. For example, if I place 5 NPCs in a x, the middle one is impossible to select.
Still looking for solutions but I’m running out of ideas. Any?
Here it is with the debugging polygon and proper looping.
You can see it is suboptimal. Sometimes it doesn’t select what I would expect if I was playing a game.
Hah, that’s a cool idea. I would’ve just put all the npc indexes I needed to select inside an array and then you switch between them by pressing either left or right. Otherwise I couldn’t think of a theory to prove that you could select every single npc.
When you work with a square, if two NPCs or more are placed within the same “distance” of the selection square, there’s a scenario where only one can be selected. In a perfect X shape, there is always going to be this decision. This can apply to an isosceles triangle, as well. This is probably the reason why you are running into this problem.
I’m not so great at solutions, since I don’t know what a “successful” model of this looks like.
The other part of this is how the brain reacts to this shape. If I am not aware the distance to one NPC is only one pixel longer than the next NPC, I could be taken by surprise when it selects the closer one. If we couple this with the wonky hitboxes on the NPCs in Graal, the effect is amplified.
I think maybe a solution could be setting two of the selection boxes (directions) to be misaligned 1 pixel clockwise, and the other two directions misaligned 1 pixel counterclockwise. This could create a staggered bias that would allow for up-down movement to be preferred before moving farther left-right. It’s 4AM though so either I’m being a brainlet or a genius, there’s really no inbetween. xd
I’ve also tried with rectangles… doesn’t work either.
I didn’t understand but this gave me the idea of making my rectangles wider instead of taller, it’s going to work!
Dunno, [USER=“12792”]Zazenora[/USER] sent this to me.
I’ve also considered putting the characters in an array but characters can move during the fight, so I needed something more like Chrono Trigger.
I’ve just finished coding all that affects stats (Hp, Mp, def, dex…) plus or minus. I’m kind of proud of my idea, makes the whole thing very short. Right now I’m preparing a quick to do list to figure out what to do next.
[USER=“5637”]tricxta[/USER] I found it on the nekoroy website in the UltimateNPCpack1/graaldropboxdump/rpg project
There’s quite a few npc’s with your name on it in that pack
I broke a few things in the process of moving things around and updating tricxta’s code to fit the newer code I wrote but I’m done for tonight.
At least now the arrow moves and we have an idea of by how much the NPCs are affected (oops, I healed an enemy).
By the way, if someone could find or make a good, easy to see (fat?) numbers chart I’d be thankful… this one I found on opengameart.org isn’t very visible…
I think you’ve misunderstood. Say you were to store the npc indexes for the characters you need to select. You would would then simply reference that npc’s position using
setfocus(npcs[index].x,npcs[index].y;
You would then adjust your index variable appropriately based on which npc you wanted to focus on and this wouldn’t change one bit, were the npcs to move around.
Divide the screen into a coordinate system based off the size of a character/badguy. Iterate over it to find currently occupied positions. Build an new array on each turn/or position update and with the index of the occupied spaces. Allow iteration over that array that reverses the index into coordinates. Do things with character at that position.
3AM so it might be completely not possible and stupid on my behalf…
Were the rectangles longer in the direction they were being shot from? I’m not really sure I understand the problem. When looking at the animation with the projected square, it hits what I would expect to be the first thing. From what it sounds like, you’re expecting a different result? This could be hitbox related. If this is still on the topic of the middle of an X being unselectable, this would only theoretically happen in a perfectly aligned X because in any direction you press, the program would have to make a decision on which NPC to select as it has found two NPCs. Is this the problem?
No, the program has no decision to make… it touches the top NPC first for some reason, as I made the program to decide on the closest NPC if multiple are touched. Which would be the one in the middle of the X.
With Wider rectangles, I’ll touch the NPC in the middle first. And yeah, the rectangles, when I tried rectangles, were longer in the direction they were being shot from.
Well if you really cared about that, you would reorder them each time they moved based on some rule. Say for example, you might sort based on who has the smallest y position. I’m somewhat getting frustrated, so this is last thing I’m saying regarding this.
Instead of doing it with level NPCs, do it with system wNPCs. You can handle indexing internally instead of relying on the client. You can use showani similarly to showimg to place the characters. This is how I think most people would handle it, and how most of Beholder’s projects worked.
Wouldn’t that make the actual overall code a lot bigger and messier. With the NPC solution you can call triggeractions on them and store information like hp, level, etc on them with saves[].
I definitely think the sorting their indexes by highest/lowest y index is a good solution.
Unfortunately this may not be viable. The issue with showani is that any ganis referencing attributes when called from a wNPC will user the player’s attributes so unless you’re fine with everyone looking the same orrr having a custom gani for each type of character (which could be considered quite ambitious…), then I’d stay with level NPCs.
Also, that would keep the enemies from being interchangeable without adding them to the main code and topping the 64k limit. Unless I’m being noobish again.
