#Slow Paced Multiplayer Fighting Game (UnscriptedDuels)

1 messages · Page 1 of 1 (latest)

tranquil salmon
#

Hello peeps, I thought I'd develop the project a little bit more this time before sharing, unlike my previous attempts at making a project, lol.

Anyways, here is another attempt at making a multiplayer game for the first time. I've been playing a lot of Roblox: Duel Warriors recently and thought "hey this seems simple enough, why not try to recreate it?" and here we are.

#

It all started with the server reconciliation logic on Jan 31st and honestly I'm quite proud of actually making it to this point within a month

image.png
#

Oh yeah, if any of you are down to test this hunk of messy netcode, just let me know! 😅 I'll probably have the dedicated server running by next week.

#

Slow Paced Multiplayer Fighting Game (Doesn't have a name yet lol)

spare python
tranquil salmon
tranquil salmon
#

Heya peeps, it's been a week since I've posted here. I was recently tackling quite a difficult challenge for me. Getting abilities to swap at run time as well as making sure the animations get paired correctly. I was struggling quite a bit to get the correct syncing working. Much frustration was involved as I wrapped my head around netcode.

Anyways, it works now! You can swap them at runtime. I've also played a little too much marvel rivals so I decided to try and add the little demo videos haha.

hard grail
#

Wow I really like the animation and art style of this.

#

Even though it’s still a prototype.

#

I see the vision.

tranquil salmon
wicked osprey
#

Default cube is op

tranquil salmon
#

Hello again, it's been 1.5 months since starting this project and I've hit a fabulous milestone of

  • setting up the dedicated server
  • spinning up a sleeping server through the game
  • listing out servers that are active so that people may join.

Although i must say, as expected, my netcode is quite literally garbage and horrible. Things are so laggy its confusing, abilities not performing as expected and latency becomes very much more apparent because I'm no longer testing it locally. There's still a lot of work to be done and a lot of mindset changes to adopt like "does this really need to be synced 1 to 1 or can I just fake it on the client".

All in all, I still think it's great work getting to this point where other people are actually being able to play the game. Pat on the back for my very first multiplayer game. Now would be a good time to catch up on tech debt. Optimize things and start adding more features to the game. I've established a rather rough but comfortable foundation and all I need to do is round the edges and see what I make of this. I hope that this project reaches more people so I could get a better grasp of how to run multiplayer games because I love the social aspect of them and would like to make more once I've completed this game.

image.png image.png
#

I guess we have a name now haha

#

Slow Paced Multiplayer Fighting Game (UnscriptedDuels)

tranquil salmon
#

Client authority or Server Authority? Then I tried doing both and things were a little smoother. Not sure what repercussions this would have but things seem fine for now.

tranquil salmon
#

Ive since defaulted to testing the game on 100 and 200ms ping delays to actually see what the game really looks like. RTT is the plague of all multiplayer games and I think I should be getting more accustomed to dealing with it. Rather than just hoping things will work out

#

It's kind of interesting to slowly learn all the things we take for granted in multiplayer games. Lag Compensation, Client Prediction and all that

gilded idol
#

What networking are you using?

tranquil salmon
#

I've since learned about lag compensation and how servers "turn back time" to evaluate a position that has already passed. Here I used it to evaluate a position that I know the packets have already travelled to the server..

Essentially we take the ping of the client and use that as our "waiting time" before starting to validate the position. The waiting time gives time for the packets to be sent and received, making any time after that safe to validate.

Red box - that's us, in the past. The point in time where packets are probably received by the server already.
Green box - that's us, in the server's past. The point in time we use to validate if we need to reconcile.

tranquil salmon
gilded idol
tranquil salmon
gilded idol
tranquil salmon
#

There are tons of helpful tutorials online, especially from codemonkey that provide good starting points for different aspects of ngo

gilded idol
#

Hm ok. First thing I have to do is come up with a game idea 😦 Been trying for a couple of days now

tranquil salmon
gilded idol
#

Just to see if I like it probably. I'm not new to Unity or anything, it's just ideas are hard for me

tranquil salmon
#

well, I hope you find one that sticks! 😄

gilded idol
#

Yeah. Well your game looks really cool, definitely reminds me of those battle grounds game. Never seen a acutal "game" like this. Good luck

tranquil salmon
#

Hey thanks man! good luck to you too

tranquil salmon
#

Not sure if it's a good idea but I decided to make the reconciliation range dependant on the ping of the player. Higher ping means more forgiving and lower ping means they can be a little more strict and expect a little more accuracy. The WireSphere represents said range.

I've seen other strategies such as relaxing the strictness if the client prediction often gets it right. I may try that if this one doesn't work but things seem a little better now.

Left side - Player with an average rtt of 350ms ping
Right side - Player with an average rtt of 100ms

I say average because I'm using ema for the ping.

#

I shall proceed to extend this functionality to the attacks as well.

Using a point in time and verifying if the server should allow the hit to go through based on the ping of the player.

tranquil salmon