What is the best approach for making an online fighting game?

Development Programming & Scripting Blueprint
1

[EDIT:] I realized the title was a bit misleading only after posting the thread. I’m actually asking for opinions on the best approach for making an online fighting game and not offering it. Sorry about that.

I’ve been learning how to use UE4 religiously for about 2-3 weeks now and I’ve managed to create an actor with movement and different skills / moves. I’m planning to make the game online so the idea is to allow other players join your hosted game. For some info about me I’ve worked as a developer for most of my career but I’ve never dealt with C++ so I mostly just developed the game in Blueprint but I’m totally open to the idea of eventually do some coding.

My current implementation involves the following assets:

  1. Pawn Blueprints - Each character in the roster has its own Pawn Blueprint. Inside each Pawn Blueprint are the specific moves, movement which should be unique for each character.
  2. Player Controller Blueprint - Just a generic blueprint for the Player Controller. I haven’t placed any logic to this yet.
  3. Level Blueprint - The persistent level holds the character selection screen. After the player selects the character, the corresponding Pawn Blueprint for that character is determined and spawned to a random location in a streamed level, and then possessed by the Player Controller Blueprint right after.

Given those I’ve a number of questions:

  1. I actually wanted to know if my decision to make the characters as Pawn BPs instead of Character BPs is correct. From my understanding, Character Blueprints were made for single-player games where the controls would always be given to that Characer Blueprint. In my case, there is a possibility to choose different characters so a default Character would not work. I’m not sure if this is correct.
  2. What’s the main purpose of creating a custom Player Controller blueprint? I noticed that I could just use the default Controller rather than create one. But perhaps someone can enlighten me as to what is the best practice for using custom Player Controller blueprints.
  3. This is my real problem as maybe I haven’t completely grasped the concept of networking in games. I have been trying to watch videos though. Anyway, when I was experimenting and still had the characters implemented as Actor Blueprints, I noticed that when running the game simulating two machines, I was able to see both characters in the client and also in the server. But once I moved to pawns, I could still see the server pawn from the client window, but I cannot see the client pawn from the server’s perspective. I have set the pawns to be replicated variables as well, and made it so that the pawns are spawned by the server. I’m not sure if I need to make it a repNotify and let the client spawn the server pawn locally so both machines can see them.

I can post screenshots of my BPs for spawning the characters once I get back home but any help before then would be appreciated.

2

Hi Bluarchon,

I updated the name of the thread to clarify your intent. I look forward to seeing what you come up with with this project!

3

Actors are approximately “anything that can have a position in the world.” You can build swappable characters on top of Actors if you want.
Pawns are Actors, and have more functionality built in to be “things that are controlled by players.” Not everything that is controlled by a player has to be a Pawn, but it is generally simpler to make it so.

When it comes to fighting games, those are typically very latency sensitive. You need to give the player some amount of time to see the wind-up to an attack so that the player can counter in time. Unfortunately, the internet may add as much as 200 milliseconds one-way latency, which for client/server means 400 ms transmission latency (unless you only do two-player games, where it’s 200 ms.) So, in addition to the built-in wind-up time in the animation, you need to add another 400 milliseconds to the wind-up animation to compensate for the worst-case latency – for fighting games, that is A LOT OF TIME and will make the game feel very sluggish.

If you can re-simulate the entire physics for times in the past, and you can trust the client to not lie (cheat,) and your game is a lot smaller in size than the machine it runs on, you may be able to use a latency-reducing technique described in GGPO: Gamasutra - The lag-fighting techniques behind GGPO’s netcode Note that the article describes the technique as “universal,” but it really isn’t – it makes certain kinds of trade-offs, and if you’re OK with making those same exact trade-offs, you can use that same technique. Those trade-offs are not appropriate for all (or even close to all) networked game situations, though.

4

[=jwatte;109417]
Actors are approximately “anything that can have a position in the world.” You can build swappable characters on top of Actors if you want.
Pawns are Actors, and have more functionality built in to be “things that are controlled by players.” Not everything that is controlled by a player has to be a Pawn, but it is generally simpler to make it so.

When it comes to fighting games, those are typically very latency sensitive. You need to give the player some amount of time to see the wind-up to an attack so that the player can counter in time. Unfortunately, the internet may add as much as 200 milliseconds one-way latency, which for client/server means 400 ms transmission latency (unless you only do two-player games, where it’s 200 ms.) So, in addition to the built-in wind-up time in the animation, you need to add another 400 milliseconds to the wind-up animation to compensate for the worst-case latency – for fighting games, that is A LOT OF TIME and will make the game feel very sluggish.

If you can re-simulate the entire physics for times in the past, and you can trust the client to not lie (cheat,) and your game is a lot smaller in size than the machine it runs on, you may be able to use a latency-reducing technique described in GGPO: The lag-fighting techniques behind GGPO’s netcode Note that the article describes the technique as “universal,” but it really isn’t – it makes certain kinds of trade-offs, and if you’re OK with making those same exact trade-offs, you can use that same technique. Those trade-offs are not appropriate for all (or even close to all) networked game situations, though.
[/]

He actually ment a Character BP rather then Actor BP. Any idea with that?

5

[= ;109386]
Hi Bluarchon,

I updated the name of the thread to clarify your intent. I look forward to seeing what you come up with with this project!
[/]

Thanks , I appreciate that.

[=jwatte;109417]
Actors are approximately “anything that can have a position in the world.” You can build swappable characters on top of Actors if you want.
Pawns are Actors, and have more functionality built in to be “things that are controlled by players.” Not everything that is controlled by a player has to be a Pawn, but it is generally simpler to make it so.
[/]

Yes and as TheOneWolf said, I actually meant the Character Blueprint vs Pawn Blueprint. My bad. I’ve never understood how to decide which one to use. Pawns made much more sense to me in a game where you can select different types of characters because you could just have your controller possess that specific pawn that the player selected. Characters on the other hand you cannot possess. I’m not sure if you can equally use Character BPs in the type of game I’m making.

[=jwatte;109417]
When it comes to fighting games, those are typically very latency sensitive. You need to give the player some amount of time to see the wind-up to an attack so that the player can counter in time. Unfortunately, the internet may add as much as 200 milliseconds one-way latency, which for client/server means 400 ms transmission latency (unless you only do two-player games, where it’s 200 ms.) So, in addition to the built-in wind-up time in the animation, you need to add another 400 milliseconds to the wind-up animation to compensate for the worst-case latency – for fighting games, that is A LOT OF TIME and will make the game feel very sluggish.

If you can re-simulate the entire physics for times in the past, and you can trust the client to not lie (cheat,) and your game is a lot smaller in size than the machine it runs on, you may be able to use a latency-reducing technique described in GGPO: The lag-fighting techniques behind GGPO’s netcode Note that the article describes the technique as “universal,” but it really isn’t – it makes certain kinds of trade-offs, and if you’re OK with making those same exact trade-offs, you can use that same technique. Those trade-offs are not appropriate for all (or even close to all) networked game situations, though.
[/]

That actually is a very good point you’ve raised that I never would have thought about, thank you. I’ll be sure to keep this in mind once I get around to testing this with multiple players. I’m kind of aiming for a super smash brothers type of game but in a 3D perspective.

As for the pawn not being visible to other clients. Would you have any clue as to why this is happening? I’d love to get started with testing damage application but I can’t even see my opponent right now.