I want to have an object that stay at one side of an actor, and so its physics don't need to be computed, and the prediction can be done with the actor itself.
How do I do this properly ?
The scenario you are describing probably consists of only one game object, which has two rendering resources. At all times there is only one physical entity. The dimensions of the physical entity may need to be enlarged to represent both resources.
Take for example, a pirate and his parrot. The parrot is constantly hovering around the pirate, wherever the pirate goes. In this case, the correct approach is to use only a single game object, which represents both the pirate and the parrot. The pirate has one game object, but this game object has two render resources which are associated with it. Those two resources could be two sprites: one for the pirate and one for his parrot.
Note: There actually is a way to disable client-side prediction for a game object. Any class which derives from GameObject, including DynamicObject and PhysicalObject, can override the following two functions to return zero instead of null. This will disable all bending.
get bendingMultiple() { return null; }
get bendingVelocityMultiple() { return null; }
Related
I have a grain in Orleans for the players of a game. A player has several properties that I want to access directly in the client. Is it possible, is it efficient and does it make sense to have these as public properties on the grain? Or, should I have a GetAllState method that returns a DTO with the current value of these properties in the grain?
public interface IPlayerGrain : IGrainWithIntegerKey
{
// Individual public properties to access grain state?
string Name { get; }
int Score { get; }
int Health { get; }
// Or, get all the current grain state as DTO?
Task<PlayerState> GetAllState();
}
From my current understanding I think I will need to use GetAllState as I think any communication into the grain needs to be via a method and this may pass between silos. So, you probably want to minimise the number of messages passed and wouldnt want to pass three messages to get Name, Score and Health. Or, is message passing pretty cheap and not something I should worry about doing too much? In my example I've only included 3 properties, but in my real game there will be many more.
However, I don't really like the idea of having an anemic DTO model that is just a copy of the grain's internal properties.
So I was wondering if there was a better way, or a preferred pattern for this sort of thing in Orleans?
I think this depends a lot on the life cycle and access patterns of the properties. Do the properties tend to change independently or together? (At first glance, they seem to change independently and at quite different rates; I assume that Score and Health can change very frequently, but Name would almost never change.) And given that Name changes very infrequently, would it be a good fit for your access patterns to retrieve it every time you wanted an updated Score or Health value? Maybe Score and Health would be frequently accessed together, and Name along with other more static properties also belong together.
If you let these kinds of questions drive your API before you think about the cost of message passing, you will probably find some good sweet spots (probably not the whole state of the grain). You might also consider having a Player grain and a PlayerStats grain that have different life cycles and that correspond more closely to the change rate of various pieces of data.
Introduction of a complex return type to minimize roundtrips is a valid solution.
However, I wouldn't return the whole internal state, as I assume that not all the clients need all the data all the time. It may also be a sign that you have a business logic implemented outside of the grains and you should move it into the grain.
You might also consider that Health and Score, which are likely to change frequently, be exposed in a stream.
This might sound a dumb question but I am trying to understand the basics of 3d game programming and wanted to know this thing.
I have looked at the samples here https://code.msdn.microsoft.com/Direct3D-Tutorial-Win32-829979ef and I get it how each object's vertices and indexes to those vertices are stored in vertex buffer and index buffer respectively.
What I want to understand is how would I render a scene where I have multiple objects ? How should the vertex and index buffers be set? And how should a draw called be implemented ?
A reference or an example will help please.
To elaborate on Chuck's link, the process by which you will render multiple objects will vary depending on the architecture you choose to use.
Every model is divided into a number sections equal to the number of textures/material combinations it has. Each of these sections consists of a unique texture/material combination and will have its own vertex/index buffer pair.
The reason for this is because the HLSL is primarily designed to operate on a single texture and material at a time. You bind the vertex and index buffers of a single section to the pipeline along with the corresponding texture/material, perform a draw call on it, then bind the buffers/texture/material for the next section until the whole model has been rendered.
The cool part is that you only need to load a model once. As long as you have the information for that model, you can create instances of the model using the same data but different position matricies. This lets you create hundreds or thousands of copies of an object.
My scratch codeed engine handles models like this: during initialization, a model manager class is used to load in all the different models I use and store each unique model into a model class. I then take a pointer to the model class and feed it into scenery managers which give information on what contexts the model appears in. When I populate the game world with scenery, my game tile uses a scenery list class to handle a list of instance structures and render lists. The instance structure holds information such as position/scale/orientation, an AABB, and a pointer to the model class. Each frame, I frustum cull the scenery and populate the render lists with only the instance structures of potentially visible objects and produce an instance buffer for each list to contain the positional information. Then, I can loop through each render list, assign the appropriate buffers and textures, and draw indexed instanced() to render all the copies of the model section.
I'm not sure how my process compares to other engines, but it should serve as a reasonable example of how you might handle multiple objects and then multiple instances of objects. The levels of abstraction I have in my process were chosen due to how my engine works (random world generation). The exact method you use will vary based on your application.
Here is a basic diagram showing a fairly bare-bones set up:
In the VIPER design pattern, should the Interactor return all the information that might be used by multiple presenter actions or should I have a separate struct for each one?
In my case, I have a map that displays places. To display those places I need to retrieve a list of PlaceItem's from a PlacesInteractor which could have only a coordinate and a color (used to change the pin's head color) that would be transformed into a annotations by the presenter.
Now lets say that when the user selects one of the annotations in the map, a callout bubble should be displayed with more details like the place's name and a circle with the color.
Now I should create a RetrievePlaceCalloutInteractor that would return only the information for one place instead of a list of information for multiple places (Right? Or should I have only one Interactor for both scenarios?).
Should this RetrievePlaceCalloutInteractor return a PlaceCalloutItem with only the name and the color (no coordinate) of the place or should I have a single PlaceItem with coordinate, color and name, that would be returned by the RetrievePlaceCalloutInteractor and by the PlaceInteractor, and would be used by the presenter to construct either a CalloutStruct or a list of MKAnnotations?
Thank you.
VIPER is a pattern, not a very formal pattern, not a religion or a complete app architecture. For me VIPER helped to think more about a cleaner architecture but on the way I had to make decisions that were better for my specific scenario without caring to much about VIPER but about clean architecture. So, from my experience and my point of view the answer to your question is 'depends'.
In my case most of the 'Items' (I call them DO from Display Object or Data Object) have almost a one to one relationship with the 'Entities' (I call them MO from Model Object). Most of the interactors manipulate one type of Entity and they have one MO-DO mapper. I usually use the same DO for different use cases if the interactor handle more than one use case.
BUT
I also have some modules using different DOs for different uses cases, although they relate to the same entity, and also I have some DOs with combine the information of several Entities, let's say for example I needed the user name to add it to 'edited by' of a blog post I use the same DO to combine Post and User Entities.
I think VIPER 'wants' one interactor per module, that kind of forces you to have multiple use cases (related) in it, but it is up to you if you want to use different Items (my DOs) or only one.
Being a purist of clean architecture you should have different interactors, different requests and different responses for each use case.
So, as I started, it depends, the important thing is to 'draw' the boundaries properly and it doesn't matter if it's one or ten Items you use for that.
I wonder if there are any benefits if i use multiple instances of Ogre::RaySceneQuery for same scene. Or if there are any things that requires it's own special instance?
Usually you only perform one query at one time, so there's no need to use a new RSQ instance each time.
Even if you're doing multiple types of queries you have to give the RSQ a new ray each time, so there won't be any difference if you do this using one or more instances.
Usually the code looks something like this:
Ogre::SceneManager* mSceneMgr;
Ogre::Ray ray; //whatever you want to query
Ogre::RaySceneQuery* mRaySceneQuery = mSceneMgr->createRayQuery(Ogre::Ray());
mRaySceneQuery->setRay(ray);
Ogre::RaySceneQueryResult &result = mRaySceneQuery->execute();
//loop through the result
For each new ray you want to test you have to give the RSQ the new ray. Usually the rays are dependent on some coordinates (the player, the camera, ...) and you have to update the rays each iteration.
In case you have a static ray, a ray which doesn't depend on something and will be the same vector each and every iteration you may save the call to setRay(Ogre::Ray) if you use another RSQ instance for this specific ray only, but i doubt that this will be a huge performance boost or even noticeable as you still have to execute the query.
There's another point you should consider: query masks.
Every entity can have a binary mask which determines if it can get hit by a ray query.
Let's suppose you have this structure
enum QueryFlags {
FRIENDS = 1<<0;
FOES = 1<<1;
}
and every frame you wanna test if something hit a friend and/or a foe. There are a few possibilities:
You may check for both at once with mRaySceneQuery->setQueryMask(FRIENDS | FOES) and check every retrieved result if it is a friend or a foe.
You may execute two queries, one for FRIENDS and a second for the FOES.
You may use two RSQs, one for the friends and a second for the foe. This way you save a call to setQueryMask each time. As above I doubt this will give a significant performance gain, but I prefer the last option.
I'm designing a game object in F#. In C++, I would make classes to represent the graphical aspect, physical etc each with dynamic values, and then add instances of those classes to a GameObject. I could use the same design in F# with mutable types, but I'm trying to keep everything immutable. So if I used the same design I would be recreating thousands of large objects each frame, and probably spend all cpu time just allocating.
Is there some way I can define a type where I could link to another object's values and supply new ones, to cut down on allocations?
Eg to change the colour of a box, I want to use the old box's memory with a new graphics piece, and use the old graphics piece's memory with a new colour:
let box = ...
...
let changedBox = {box with
graphics = { box.graphics with colour = blue} }
Yes, exactly. Assuming that "the big object" is in fact a reference graph of many smaller objects, then the typical "update of an immutable" just creates one or two new small objects and references the same old ones for the rest.
For example, if Person has a Name and Address, and Address has a Street and City and State and Zip, and I need to update the zip of a person, then I only need to create new objects for the spanning tree from the root to the Zip. See e.g. the red-black color diagrams in this blog. In the person example, the Name, Street, City, and State objects would be reused, but the ZIp would be a new object, and the Address would be a new object (since it contains the new Zip), and the Person would be a new object (since it contains the new Address). Does it make sense?