Jump to content
  • Advertisement
Sign in to follow this  
Plumder

Queries for a packet-like action-handler for a game in C++

This topic is 2144 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey folks, I'm in the beginning-stage of a game developed by myself for experience and fun. I had a few queries and I would like some recommendations from those who are experienced in the 'theory' mentality of game dev.

 

Long story short: (In the game, charms are basically spells, so you know what I'm referring to.)

 

I'm using the idea of "packets" to send information to the local server.

A Charm-packet is what I am needing help with.

 

When a player 'casts' these charms, they must wait for the cast-time to finish before the action actually occurs. This is very similiar to how WoW and other MMO's handle spells.

 

First problem: Should I send the packet FROM the client when the player STARTS casting or when the CAST-TIME has finished?

 

I see some pros and cons from each.

 

I could send the packet when the cast-time STARTS. This would allow me to calculate when the spell should actually finish casting SERVER-SIDE, which may result in less strangeness if lag were to occur.

 

On the other hand, I could save processing power on the server but give myself less information to work with by sending the packet when the CAST-TIME is finished, when the action is due to happen.

 

I'm not sure whether this will also help me elaborate, but the packets for Charm-Casting will have the following pieces of information:

- The location of this event

- The target, caster and WHEN this event  ocurred.

 

Second problem: Should I handle the packets 100% serverside, or send a "reply" packet back to the client afterwards?

 

What I mean by this, is that the server could reply to the client's request to cast this spell.

Which would allow me to say NO aswell as YES, which may be helpful in some circumstances.

 

However, it may save some processing-power of the client if the server simply handled the packet itself.

 

----------------------------------------------------------------------------------------------------

 

If I'm speaking in riddles or not being very clear, please tell me so that I may try and be clearer.

 

Help will be greatly appreciated! biggrin.png

Share this post


Link to post
Share on other sites
Advertisement

You almost certainly want to send it as soon as you know about it, and you should definitely at least validate it server side before propagating it to other clients.

 

If the server knows about the spell as soon as possible, it can decide to inform other clients at the optimal time. To reduce the chance of cheating, this could be an estimated round trip time (or maybe a small multiple thereof) before the other client really needs to start animating or reacting. I've never played the games you reference, but essentially if your animations start immediately, the server needs to inform all clients A.S.A.P for fairness.

 

You must validate such things server-side, because delegating to the client allows the client to cheat. You may want to add a server side acknowledgement if there are unpredictable events that could prevent the client from casting the spell. For example, perhaps another player injures the client's avatar, and the spell casting animation cannot start until the hurt animation has completed. Of course, you could just optimistically start the casting animation, and just recover in the event this occurs. There is no "right" answer here, but reacting as quickly as possible on the local client usually gives the best user experience.

 

Overall,I don't see that you are really saving processing power on the server, you're just delaying when the server is processing the information, with the risk that unexpected latency spikes will have a bigger impact. I don't see this as a trade off you should desire to make.

Share this post


Link to post
Share on other sites

If you're trying to make a massively multi-player game like WoW, you should stick to sending basically just input events to the server and then doing all your simulation on the server. You don't want to let some hack skip the start-up time and just cast the "charm" immediately. I'm not saying you'll be able to prevent all cheating with this approach, but in general you want the server doing all the real work of calculating what happens in the world, and the clients just making things pretty.

 

Also, as mentioned, other players or enemies might be able to react to a player just starting a charm. I don't know whether you'll have an animation for the casting part or not, but even something as simple as a log message that says "player x started charm y" might be useful, and you might feel like adding abilities that attempt to interrupt a charm before it comes out.

 

If things are designed properly, waiting shouldn't cost very much processor time. Also, you're going to have to have some kind of timed event system for the dozens of other timed events that tend to drive these games. For example, you might have a "charm" that adds a buff for a minute or so, right? The same queue that ends charms can start them, too.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!