My game starts lagging if the map is too large

[toto8080]

Sorry if I'm posting my thread in a wrong topic, but since Im still new I still need some time to adapt the structure of the site.

I have a huge project, where I make a pathfinder in RGSS3. So my problem is, if my dungeon is big ( for example 100x50 tiles), and the pathfinder event is far enough (ca. 50 tiles), it starts lagging, since the script is running as a paralell, repeat process, and the lagging occurs because it has to compute all the neighnour and parent tiles, so it has a lot to do, which needs time of course.

I found basic AStar pseudos around the internet, and I implemented one in RGSS3, so my script should be full and functional, with all the necessarily functions in it.

Is there a way to make the game smooth, without changing all my dungeons size?

 

[Poryg]

Alright, let me explain what the lag is.
Lag is, simply put, when the CPU core doesn't have enough time to handle all stacked functions, because it's already handling a different function for too long due to its complexity or due to, if they're multiple, their complexity.
So the only way to prevent that function from making your game lag is to reduce its complexity... Or pass it to another thread via multithreading, so it doesn't interfere with the main thread. Here it depends on one or two things:
1. Ruby itself can do multithreading. But can VXAce's RGSS3 do multithreading? That is a question I don't know the answer to.
2. If RGSS3 can do multithreading, are you capable of using it properly?

 

[Shaz]

Pathfinding scripts lag when you have them on large maps. If you have yours as a parallel process, continually pathfinding, you're causing incredible lag. It's just a bad idea all round imo.

 

[toto8080]

Pathfinding scripts lag when you have them on large maps. If you have yours as a parallel process, continually pathfinding, you're causing incredible lag. It's just a bad idea all round imo.

The point of my game is, that the enemy continiusly calculates the optimal path toward the player's character. The script has to be paralell, since the player can move and therefore its position changes.

Do you know any solution, where the game doesnt lag in that case?

 

[TheoAllen]

I found basic AStar pseudos around the internet, and I implemented one in RGSS3, so my script should be full and functional, with all the necessarily functions in it.

Assume you could script, why not 'stop' the script after like 10-50 nodes of search and let the game update it first, the continue the search?
Real-time searching is different with simply A* implementation which works better in turn based game

 

[Shaz]

Do you know any solution, where the game doesnt lag in that case?

No, I don't know a solution, which is why I never implemented it in my Ace mouse script despite many requests from people who didn't realise the issues it would cause.

 

[bgillisp]

The problem is, pathfinding is just too complex for even today's systems. Ever play Dragon's Age (any of them)? The game will often hang 1 - 2 seconds when you select a new location as it is calculating the path for the party. So if it is trying to calculate this for each enemy every second, it will lag, even with today's computers.

The better solution might be to have your parallel process invoke a 60 second wait. The player isn't going to move enough in 60 seconds to affect it too much. Then have it update. That should go a long ways to reducing the lag.

 

[Shaz]

60 seconds, or 60 frames?

 

[bgillisp]

Good catch. I meant 60 frames. Though 60 seconds would probably also reduce the lag

 

[toto8080]

Sadly, none of the suggested methods are working.

Assume you could script, why not 'stop' the script after like 10-50 nodes of search and let the game update it first, the continue the search?

Because the player is - probably - always moving, the distance is between him and the chasing event is not changing, therefore the big 'calculations', where the script stores the current tiles and parents is always the same size, if not bigger. If I'm not mistaken, this wont help reduce the lag.

The better solution might be to have your parallel process invoke a 60 second wait. The player isn't going to move enough in 60 seconds to affect it too much. Then have it update. That should go a long ways to reducing the lag.

The problem is same as the previous one. Its the same, if the event have to do the 'big work' now, or 60 sec later, the lag is still there.

Guess the only option I left with that I have to reduce my dungeons from 100x50 to 50x50 and hope for the best.