When two simulation systems are connected via HLA how are the physics engines linked?
For example, if two armoured vehicles (entities) tank A from federate A and tank B from federate B collide how is the collision physics resolved?
As I understand it, there are collision and detonation interactions that convey who hit who and the velocity but is this enough to fully resolve the collision effects?
Presumably, each federate is responsible publishing the collision interaction message and applying those message to its own entity physics engine. I can't help but think, surely there is more to it that this.
Any details or resources would be greatly appreciated.
In HLA, the RTI doesn't calculate anything it merely facilitates the communication between the federates and keeps track of time. If you have a physics engine in your federated simulation, you either have to have it implemented as its own federate that other federates need to query to resolve the physics, or each federate keeps track of their own physics.
In your example, two federates each publish a single object of type "Tank" which has attributes "Geometry" and "WorldCoordinates". Lets say they keep track of their own physics. Each federate should subscribe to every other "WorldCoordinates" of every physical object in the region, and calculate when there is a collision between their owned object and the colliding object. If you have a separate federate calculating physics (i.e. it's a submarine simulation and red team positions are masked), then the physics federate needs to subscribe to all the "WorldCoordinates" and "Geometry" attributes and calculate collisions based on that then send an interaction to the federates that own those objects.
Related
I have managed to sync my ridigbodies real good but I just noticed that when a client (that's not the master) collides with one it doesn't move, it's locked, while reading on the net I had an idea when the object collides with a rigidbody I just transfer the ownership of that object to that client for the moment for this client to process the collision (I have tested this and it works really good, both clients sync perfectly)
is this recommended? performance-wise and security/cheating wise?
Thanks!
Short answer:
Transferring ownership of a GameObject to a client, when that client needs to control and update the object data, is fine. In cases of detecting cheating possibilities, always have one client (typically the master client or a dedicated server) validate, correct and sync the data to all clients.
I will not make any assumptions. Based on your explanation of the issue, it seems your GameObject Rigidbody IsKinematic was not being synced, causing the collisions having different effects at each client end. But in case that might not be the issue, I have a longer answer hoping it might help for this or other scenarios.
Longer version:
Sync Rigidibody data over the network where it is fundamentally required to be present on the client GameObject. The rest of the Rigidbody data can be created / calculated / simulated on each client individually:
This way, you will make sure all parameters of that Rigidbody are correct (e.g. isKinematic is correctly enabled/disabled on all clients)
Your games will always have the minimum required data to create/simulate the rest of the events and effects properly, reducing network lags and improving performance.
Where data validation is required, the master client will always validate the non-master client data, makes the crucial adjustments and decisions and updates the room data for all clients where necessary. This reduces the chances of players cheating.
Developers will find bugs easier when the events that are supposed to take place on each client, do not align with what is expected. This shows itself more often in scenarios where several events should take place at the same time and on each client.
Much longer version:
When I use PUN2 on GameObjects in my games, I only sync Rigidbody where those GameObjects require Rigidbody values to be present on the clients during collisions to perform specific tasks (e.g. using the velocity or direction for dynamic sound/visual effects), or when the master is validating and correcting the data needed for the non-master clients (as a result of network delay or cheat/hack tampering the data on client side).
When using PUN2 (up to this date), I update its class internal code to my needs. For example, PhotonRigidbodyView does not sync the kinematic state of a Rigidbody yet. When I need this in my games, I could override the class with my CustomPhotonRigidbodyView class (and/or updating the PhotonRigidbodyView a bit).
Does it effect the performance when using PhotonRigidbodyView? Yes, when not used with care, it does decrease it when there are too many objects syncing over the network at the same time. The clients will see jagged movements.
Does it allow cheaters to take advantage of this data, manipulate it and send it over to the clients? Yes, if the game is vulnerable to basic cheats. Then again, the topic of security/cheat detection is quite vast, so for each game definition of "basic" cheats are different.
Is it a good idea to transfer ownership momentarily to be processed on client side? Yes in some cases, other cases no:
If doing this momentary transfer is the only place you do this and it solves all your problems (except cheating), then use it so you won't spend too much time fixing this one part in a different way.
If the Rigidbody or Transform data is being validated and/or synced, either constantly or in periodic intervals by one client (to prevent cheating or to sync client data properly at crucial times), then it is fine to transfer momentarily too.
I typically transfer ownership, when the object data must be changed by the client (e.g. grabbing / dragging around / shooting / throwing) and once the action is performed, ownership will be back to the master to be validated and synced for all clients (including the one that just transferred the ownership). This results in more time spent on testing, catching unwanted (possibly unseen) bugs, and reduced cheating possibilities.
In case a developer working on your game has not properly optimized the Collider and/or Rigidbody components for each GameObject yet, please make sure you have done so before syncing their data over the network. This page in Unity doc may be a good reference to check whether your GameObjects need to be static colliders or dynamic colliders:
https://docs.unity3d.com/Manual/class-Rigidbody.html
https://docs.unity3d.com/Manual/CollidersOverview.html
Once the GameObjects that need a Rigidbody component are identified, then you can decide which ones need to be fully synced over the network or partially synced and/or their ownership transferred when required.
I hope my answer does not confuse any of the readers. If there is anything not clear, please mention in the comment and I will improve my answer for you.
Update: 2019-05-10 (reply to the 2nd comment):
For a pool game involving so many GameObjects, I would not transfer the ownership of all objects to a client. I would:
Create a struct holding the necessary information such as:
ball_id: indicating which ball is being hit by the pool stick
hit_info: a Vector3 representing the position (on the ball surface) and direction of the hit applied to the ball, by the hit stick.
hit_force: the required force to apply to the Rigidbody of the ball that is being hit by the hit stick.
and any other information that I might need, when the player hits the ball with stick.
I can then combine this information and pass them to the AddForceAtPosition method of the Rigidbody of the ball.
Dispatch this struct in the room, for all the clients to receive.
Once each client receives this message, including the sender, (in OnEvent as EventData containing the Phton Event Data), it will apply this info to the correct ball and will create its own version of physics (small differences will be noticed between each client).
This way:
I have the minimum amount of information passed over the network to make the simulations happen on all clients
Improved performance of the game by avoiding parsing and applying unnecessary Rigidbody data
Reduced the cheating possibilities of a client moving any of the other balls that they are not supposed to, around the table or into the pots.
To increase security as well as making sure the balls on all clients are exactly where they are supposed to be, another struct will be dispatched for example by the master client, indicating the exact position (and rotation) of each ball on the pool table (or in the pot).
I would sync the ball positions periodically (either at pre-defined intervals or at specific moments of my choosing depending on the game state) to all clients to overcome any incorrect positions at any moment in the game. This periodic sync can be done by the master client or a dedicated server.
I am trying to make a game with multiple types of zombies that take multiple hits to kill. For example, I have a runner zombie sprite node that has 2 health. When it is hit once it speeds up and when it is hit again it dies. I have been trying to get my enemies to be multiple hits and I never figured it out. Do I make a class with various properties such as a health variable or do I make a function? Identify all of the enemies and their health? Help Please!
Obviously, there are many ways of doing this, but if you are using GameplayKit's Entities and Components, then it would be logical to store this kind of data in a health component.
In general, if your game is getting complex, have a look at GameplayKit's guidelines and likely you will find all the answers.
I'm designing some kind of MMO strategy game with thousands of players. Since the game will not have frequent operations, i think it will not have scalability issues using Unity HLAPI. Using HLAPI, every GameObject with NetworkIdentity is spawned in each client. Since different players should not necessary be aware of each GameObject, how can I control which GameObjects are spawned on each player?
For example, suppose there is a giant map, and a discrete coordinate system. On each pair (x,y) there is a player Game Object. The server should be aware of each of them, but clients don't care about players far away from them. So I think the client performance will be affected if I spawn every GameObject on every client.
I'm creating a Unet application, where the server is responsible for spawning units, and the clients (obviously) see the units and their movements. Clients can spawn stuff via server commands, and typical interactions.
What i'm hoping to allow, however, is each client to redefine their global 'origin' point. So if i'm in the world and i see it in front of me, i'd like to be able to turn around and determine that "hey! that point over there is now the origin", and have all the components move to that new location (which should be handled automatically by the NetworkTransforms).
Does anyone know how i would be able to accomplish this? Or even implement some sort of NetworkTransformOffset script based off the network transform?
Yes....
By moving everything by an amount equal to -1 * new_origin yourself.
I would like to create a baseball simulation game.
Are these sports management games based on luck? A management game entirely based on luck is not fair, but it cannot be too predictable either. How does the logic behind these games work?
It's all about probability and statistics. You set the chance of something happening based on some attributes you assign, and then the random factor comes in during play to make things less predictable and more fun. Generally you get a load of statistics from some external source, encode them into your game's database, and write a system that compares random numbers to these statistics to generate results that approximate the real-life observations that the stats were based on.
Oversimplified example: say your game has Babe Ruth who hits a home run 8.5% of the time, and some lesser guy who hits one 4% of the time. These are the attributes you test against. So for each pitch you simulate, pick a random number between 0 and 100%. If it's less than or equal to the attribute, the batter scores a home run, if it's greater than the attribute, they don't. After a few pitches you'll start to see Babe Ruth's quality show relative to the other guy as he will tend to hit over twice as many home runs.
In reality you'd have more than 1 attribute for this, depending on the kind of pitching for example. And the other player might get to choose which relief pitchers to use to try and exploit weaknesses in the batter's abilities. So the gameplay comes from the interplay between these various attributes, with you trying to maximise the chance that the attribute tests work in your favour.
PS. Apologies for any mistakes regarding baseball: I'm English so can't be expected to understand these things. ;)
As you have already figured out, the core component of such games is the match simulation engine. As Spence said so, you want that simulation to "look right" rather than to "be right".
I worked on a rugby game simulation some time ago and there's an approach that works quite well. Your match is a finite state machine. Each game phase is a state, has an outcome which translates to a phase transition or changes in game state (score, replacements, ...).
Add in a event/listener system to handle things that are not strictly related to the structure of the game you're simulating and you have a good structure (everytime something happens in your simulation, a foul for instance, fire an event; the listeners can be a comment-generation system or an AI responsible for teams' strategies).
You can start with a rough simulation engine that handles things at a team level using an average of your players' stats and then move on to something more detailed that's simulating things at a player level. I think that kind of iterative approach suits a game simulation very well because you want it to look right, and as soon as an element looks right you can stop iterating on it and work on another part of your system.
Random is of course part of the game because as you said so, you don't want games to be too predictable. A very simple thing to do is to have virtual dice rolls against a player and team statistics when they are performing a particular action (throwing the ball for instance).
Edit: I make the assumption that we're talking about management games like Hattrick, where you're managing a roster and simulating game results rather than 2D/3D graphical simulations.
Usually timing plus a randomness to make the game replayable EDIT To clarify I mean in terms of when the pitch comes at you, if it was exact you could learn to play it perfectly, you would need a small randomness around the exact time that you swing to make the game have some chance). AI has a big part in this if you do things like curve balls, add the ability to steal bases etc.
Getting games "right" isn't a factor of design or maths so much as a feel. You will try something, play it, and see if it was fun. If it isn't try different algorithms or gameplay until you get it right.
A simulation is very much about an imagined world in that you create classes that represent all aspects of an imagined world. You need to model the players, specify the game rules, and game dynamics.
http://cplus.about.com/b/2008/05/31/nathans-zombie-simulator-in-c.htm
Look here for agent based model: http://www.montemagno.com/projects.html
One great thing about creating your own game is that you get to decide how the game logic is going to work. If you want the game to have a high degree of luck you can design that in. If you don't want the game to have a high degree of luck then you can design it out.
It's your game, you get to make up the rules.
Are you talking about a baseball game you play or a game simulator? Baseball games can be arcade-like or fantasy sports like or a blend.
I was at Dynamix when Front Page Sports Baseball was made. It was stats-based, meaning that you could play out games and seasons using the stats of the various players. That meant licensing Major League data. It used stats to influence outcomes.
There was a regular mode and a "fast-sim" mode that could breeze through the games faster.
I think Kylotan has the right strategy. Baseball has stats for everything. Simulate a game to the most detailed level you can manage. Combine player stats to determine a percentage chance for every outcome. Use randomness to decide the outcome.
For instance: The chance of a hit is based on Batting Average, Pitcher's ERA, etc. The opposing team's feilding percent determines the chance an out becomes an error.
Every stat you display to the 'manager' when selecting lineups should have some effect on gameplay - otherwise the manager is making decisions based on misleading information.
you ought to check out franchise ball. there is a browsable demo.
http://promo.franchiseball.com