Valone
|
  |
| Joined: 08 Feb 2012 |
| Total Posts: 4371 |
|
|
| 22 Feb 2013 05:58 AM |
I'm creating a massive RPG, in your opinion, which method keeps the game running best.
1. Classic each monster has a script but using a touched brick welded underneath them rather than magnitude to keep it faster.
2. Every monster is run on one script and the one script checks the closest monster to the players and attacks them if they are close enough.
3. One script checks when players are close to monsters, monsters are inactive until players get near, a local script in the player then runs the monster with a maximum of 3 monsters at a time.
What do you think? |
|
|
| Report Abuse |
|
|
zac4545
|
  |
| Joined: 19 Aug 2009 |
| Total Posts: 2324 |
|
|
| 22 Feb 2013 06:00 AM |
2.
Anything's better than using multiple scripts, because too much can cause server latency.
3 is a maybe, but I would still go with 2. |
|
|
| Report Abuse |
|
|
Aerideyn
|
  |
| Joined: 16 Jan 2010 |
| Total Posts: 1882 |
|
|
| 22 Feb 2013 07:28 AM |
can cause server latency? I'm sorry but i don't think you are entitled to an opinion with that level of comprehension.
Anyway- I have heard hothoth say before that by far the biggest problem in an RPG is the humanoid object - apparently you can run an enormous number of npc's if you create your own solution instead (animate arms, handle movement yourself)
Beyond that have a master script disable and enable your npc's scripts when the player is beyond a certain distance and you should be able to support a couple hundred quite comfortably - apocalypse rising often has 80 npc's on field at once and i'm fairly sure they are using humanoids!
I really wouldn't recommend having all your npc's running off 1 script - it sounds like the beginnings of a big mess to me. Get it going first and then start thinking about optimisations if it isn't running fast enough for you. I actually don get the reasoning behind combining scripts anyway - either do the work here or do it there.. it's all the same. At least on separate scripts they run on seperate threads which opens the door to utilising multiple cpu cores (though i have no idea where roblox stands on that) |
|
|
| Report Abuse |
|
|
|
| 22 Feb 2013 07:48 AM |
I just read an abstract of a paper having something to do with this, so I feel entitled to an opinion.
Here's a solution: Partitioning.
Essentially, split up the world into pieces, and limit how the players can interact with pieces they're not in, so that you can save resources. You can't be chased by monsters 1000 studs away, so why bother checking if you're in range to be chased every frame? Be careful when using this approach though. You want to make sure that players don't notice the borders between pieces. |
|
|
| Report Abuse |
|
|
| |
|
Valone
|
  |
| Joined: 08 Feb 2012 |
| Total Posts: 4371 |
|
|
| 22 Feb 2013 11:09 AM |
I'm talking in the region of 1000's of NPCs. How about taking the partitioning idea.
Loading the area the player is in, and loading the areas next to it without scripts. Then as a player traverses into a new area it's already loaded meaning no border issues.
So, don't use humanoids. Got it, that should work greatly. How about treating NPCs as positions. So a script changes the position, and a players script moves the NPC around.
Using step 3 may be best in my opinion. |
|
|
| Report Abuse |
|
|
|
| 22 Feb 2013 11:21 AM |
In my upcoming zombie game, I'm going to have every zombie represented servers-side by a cframe value that shows position, a number value that shows what time the zombie needs to be at the position, and a string value with additional info. This way I can completely dedicate the server's resources to pathfinding and I'll force the client to handle animating, health, noises, etc.. At least, that's how it is until the zombie gets within 50 studs of the client. When the zombie gets that close, the server hands control over to the to client. This way, the nearby clent will see almost no latency and the server will be free to control hundreds of zombies at once.
Of course, my idea is probably way too complicated and far unnecessary for your game, but I do think it's easily the most efficient. |
|
|
| Report Abuse |
|
|
HotThoth
|
  |
 |
| Joined: 24 Aug 2010 |
| Total Posts: 1176 |
|
|
| 22 Feb 2013 01:43 PM |
Wellp, as with almost everything else, anything you can push to the client from the server will make the project scale better, so if you're worried about distance checks (not all that costly; scale linearly with number of monsters * number of players), you can instead use LocalScripts for the distance checks (so each player does their own-- now cost scales linearly with number of monsters). Furthermore, if you have a space-partitioning scheme (any sort of bucketing based on region), then it will no longer scale linearly with number of monsters, but will be expected constant run time with increased number of monsters. In any event though, as long as polls are not run too frequently, this is usually not a bottleneck, so I'd worry more about other things first in an RPG :).
- HotThoth
~ Think happy Thoths ~ |
|
|
| Report Abuse |
|
|
SN0X
|
  |
| Joined: 24 Oct 2011 |
| Total Posts: 7277 |
|
|
| 22 Feb 2013 03:05 PM |
Use #2 but share the NPCs between a few threads using spawn(). Not one thread/monster. About 1 thread for 10 monsters? You don't want a single thread supporting 200 NPCs that don't use humanoid to move, only CFrame and your own stuff.
Don't use coroutines they're not real threads. Apparently spawn(function) makes a real thread. |
|
|
| Report Abuse |
|
|
|
| 22 Feb 2013 05:55 PM |
valone why did you stop foruming here?
- Danster5oo's secondary alternative account |
|
|
| Report Abuse |
|
|
HotThoth
|
  |
 |
| Joined: 24 Aug 2010 |
| Total Posts: 1176 |
|
|
| 22 Feb 2013 06:20 PM |
@Sn0x: those are not "real" threads either :P.
- HotThoth
~ I Thoth so ~ |
|
|
| Report Abuse |
|
|
jrf2112
|
  |
| Joined: 29 Jun 2008 |
| Total Posts: 3354 |
|
|
| 22 Feb 2013 11:18 PM |
| I'm currently making a script to split maps into chunks of any size you want. Coming along rather nicely. |
|
|
| Report Abuse |
|
|
8SunTzu8
|
  |
| Joined: 30 Sep 2011 |
| Total Posts: 8199 |
|
|
| 22 Feb 2013 11:28 PM |
Wait, wait, wait...
What's the difference between a real thread and a "not real" thread?
Are you emulating a thread with coroutines or spawn()? And does that mean you're still running on one thread? I see that as unlikely, considering how computers run instructions in a logical order, so in order to run two things at once, wouldn't you need two threads at once?
Hmm... that just sounded strange to me, and I feel like it's important to know.
"Consider, friend, as you pass by, as you are now, so once was I. As I am now, you too shall be. Prepare, therefore, to follow me." -Scottish Tombstone Epitaph |
|
|
| Report Abuse |
|
|