Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Opinion on multiplayer game with spell duelling

Hey guys. Just wanted to get some opinion from more skilled people regarding a game I'm trying to make. It's supposed to be a multiplayer action game and it has a feature where spell projectiles that collide initiates some sort of duel between the two involved players.

I can't seem to come up with a way on how to initiate the duel on collision. As it is multiplayer, multiple duels can happen at the same time. I was thinking maybe I would make another Actor blueprint which would have an event that will be called by the Projectile blueprint if it collides with another projectile. I think it'll work on single player but when more people are initiating duels at the same time that's where things start to fall apart.

Any help would be appreciated.

Product Version: Not Selected
more ▼

asked Dec 11 '14 at 09:09 PM in Blueprint Scripting

avatar image

13 2 5 10

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

projectiles usually have an instigator reference when handling collision.

you can check if either of the instigators are already fighting by checking a bool bIsFighting.

on overlap, flag a bool in playerState for each of the instigators like bIsFighting = true.

if they are already fighting, ignore the overlap event.

handle these overlap events only on the server, by using a SwitchHasAuthority node.

more ▼

answered Dec 11 '14 at 11:22 PM

avatar image

9.6k 320 205 450

avatar image Bluarchon Dec 11 '14 at 11:53 PM

That's a good idea. Thanks. Regarding the PlayerState, would you recommend placing all of the attributes of the Pawn in that blueprint? I don't exactly understand what is the benefit of using a PlayerState if I could easily access these variables from the Actor blueprint. I mean codewise it seems that accessing another object just to get a variable would seem more costly but perhaps I'm missing something here.

avatar image ScottSpadea Dec 13 '14 at 06:01 PM

if you only control 1 character for your whole game, it doesn't really matter if you put bIsFighting in the pawn or playerState, because it doesn't need to be persistent after death. but when you imagine giving each playerController a team to control, deciding where to put the data becomes easier to understand with some simple questions:

should team members fight their separate battles? or do their team members have to share the same battle?

if you want 1 battle per team, playerState should hold the data. if you want each pawn to get into their own battles, the pawn should hold the data.

avatar image ScottSpadea Dec 13 '14 at 07:27 PM

and if you want a longer answer: Q why not put everything from pawn inside the player state?

the reason you shouldn't just put all of your pawns data into the playerState class is the same reason drill bits are sold separatly from drills. Modularity. a drill doesn't know anything about what kind of bit you will use, it just knows it will fit, because it uses the same interface.

playerController uses pawn as the interface for your character.

playerState is the replicated database for your playerController.

pawn is a polymorphic base class used like a weapon or tool.

  • pawn is an end effector, it can be swapped out at run time for a change in behavior.

imagine an extreme scenario, where you could posses any object, and at any moment, switching between pawns with totally different behavior:

the player controller tells your generic pawn to moveFoward, without knowing what the pawn actually is. then your sublcass of pawn, which might be a red blood cell, interperets that MoveFoward command as moving along a path. if your pawn was a turret, it wouldn't respond to MoveFoward at all. if your pawn was a golfer, MoveFoward might swing the golf club, while MoveBack might charge up the SwingPower.

your player controller probably shouldn't know anything about Swingpower. if you are controlling a turret, you don't need SwingPower, because turrets don't play golf. if your golfer doesn't exist, you don't need Swingpower, so Swingpower should be part of the GolferPawn. but your playerState should keep track of player stats that might edit the golfer's MaxSwingpower, so you can give the player upgrades to their golf skills. that same playerState, in a game that swapped between very different pawns all the time, could keep track of stats like TurretKills and DistanceTraveledAsABloodCell as well. but TurretAmmo should probably depend on which turret you possesed, so it should not be a PlayerState variable, it should be part of TurretPawn.

avatar image Bluarchon Dec 13 '14 at 08:10 PM

That makes sense. Thanks for explaining the concept thoroughly. I guess I was only thinking within the scope of the game I'm making which is why I never saw the point to it. In any case you've been a really great help and I've managed to make the duelling work now. Thanks again!

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question