I know the theory but obviously when it comes to real world, I just do not know. In the following example is the relation between game and player/board a composition (they are instantionated inside the Game class)? And between a board and a pawn - aggregation, because the board can exist with 0 pawns?
Class Game
{
Player p;
Gameboard b;
void Start()
{
p=new Player();
b=new Gameborad();
}
}
class Gameboard
{
List<pawn> listOfpawns=new List<pawn>();
}
}
The difference between composition and aggregation is not whether a board can exist with zero pawns, but whether pawns can exist without boards, and also whether players and game boards can exist without a game.
In other words, if destroying a game will destroy all the players and boards then you have composition. If players and boards can live outside a game, then you have aggregation.
If destroying a board with destroy the pawns then you have composition. If pawns can live without a board, you have aggregation.
In general, if destroying the container destroys its elements, that's composition. Elements whose existence is not dependent on the container are said to be held by aggregation.
The classic examples of aggregation are:
Countries within alliances, because countries continue to exist if the alliance is disbanded
People within organizations, since the people still live when the organization ceases to exist
The classic examples of composition are:
The schedule(s) of a person, since if the person goes away, the schedule does too.
Composition
An object contain other objects, stored by value. These are usually elements you think as internal to the object holding them, like a cardDeck object has card objects. Even if the deck isn't initially filled, the objects mostly have purpose only inside the holding object.
Aggregation
An object contains references to other objects, the aggregated objects are something that exist out in the program in another context, and the parent object is just holding them for organizational or functional reasons. Example given in the below site reference is a plane that holds person objects. The persons may come and go, and may be used in other parts of the program.
In This Case:
Your example I'd say falls more under Composition. Much like the deck of cards, the pawns have little meaning outside of the game board.
Terminology
The literalness "by value" or "by reference" depends on the language, when people say one or the other in this context they use it to refer to how strong an owning relationship the parent has.
Of course in Java all objects are stored by reference, But! As soon as no references to an object exist, it's eventually culled by the GC. The airplane is likely to be holding the only reference to the engine, so the engine dies when the airplane is removed. People can have other things referencing them beyond the airplane, so you can think of it less like the Airplane is holding them directly.
(Reference http://atomicobject.com/pages/Aggregation)
Ray and Vigilant are right but what is right for you depends more on the (goal of the) Application then it does on the objects itself.
Game/Player:
If the application is an ad-hoc Game: Player would be Composite
If the application does more with the Players (keeps scores/ranking): Player
would be Aggregation
or
Airplane/Engine:
If the application is a Airline: Engine would be Composite
If the application is Maintenance: Engine would be Aggregation
Related
I was thinking about making a game and couldn't think of a way to to this:
Let's say, for example, you want to make rideable horses in your game, but only the player that owns a certain horse can ride it.
I thought about giving the horses different names and then assigning them to players. Obviously, It would be many horses, so the amount of names... don't even want to think about that. Also then I'm facing a problem: How to automatize the process, so every new player can get thier horse with no problems?
Several ways of going about this:
Use datastores and have an array of horses for each user. Horses will want to be named by a unique name/id. See https://create.roblox.com/docs/scripting/data/data-stores for datastore docs.
Every time you wish to check if a player owns a horse you can query the datastore. The advantages of doing it this way is that it will be saved for each time the player rejoins.
You could also save the array of players horses inside a value instance inside the player object, again assigning each horse a unique name/id. Then reference this instance each time you wish to check if a player owns a horse. The drawback of this approach is that the data won't save between sessions.
Finally and the method I would recommend is a mixture of the two approaches. When a player joins save their horses inside a datastore but also in a value instance as in solution 2. Then during the gameplay you can reference the value instance. When the player leaves and/or every couple of minutes you could save the content of the value instance to the datastore.The reason I would recommend this approach is because you could end up being limited by the number of requests you can make to Roblox's datastores and datastores can get pretty complicated at time especially when it comes to pcalls. In general you should avoid making too many datastore requests in a short space of time.
I have been using scriptable objects as the model (data) layer for my game. I store things like unit stats there. I also started putting the sprites for the unit in this as well.
My question is: If I load a scriptable object which has a reference to a sprite, is the sprite automatically loaded as well? If I load 1000 scriptable objects with sprite references but I am not using those sprites (e.g. no GameObject is using that sprite to render), is there still a memory penalty for these sprite references? Or does the memory use only occur once a GameObject starts using the sprite to actually render? If so, if I have multiple scriptable objects with references to the same sprite, does this increase the memory as well?
I tried doing some memory inspection using the inspector but I was getting sporadic results and the memory footprint was changing too much between runs so I couldn't figure out what was going on (without changing anything I would get 2.2gb in use, then 3.1gb, then 2.6gb).
Just as Dave said in his comment, Sprite is a reference type, so Unity loads the sprite in the memory once and then all other instances of Objects that reference the specific Sprite point to its memory address (just as a C pointer system would work). So in your case, even if you create 1000 Objects from your Scriptable Object, all of them would point to the same Sprite.
Generally, if you're using Resources.Load() on an Object, then every loaded Object will use the same variable reference that the parent Scriptable Object had. But, if you're creating a new Object each time you want to create one, say with a class constructor, then each Object (and subsequently, their variables) will have their own space in the memory. In your case, that would happen if you were to use Sprite mySprite = new Sprite() every time you created a Scriptable Object.
So, there is no memory penalty for adding multiple instances of the same Sprite in your Scriptable Objects (CPU/GPU usage is another issue, not related to your question but worth mentioning nonetheless). Your memory inspection might have fluctuating values if you are performing it on your game, together with all the other operations that are being performed, so I suggest you create a new Project and then try to measure the values from the Inspector. If you do that, please share your findings here, since this is an interesting topic.
Also, check out this post from the GameDev stack exchange for more info on your question.
I was using GetChild() with the specific number as I arranged. But when the child objects started getting shuffling, I could not use GetChild().
Now I have three options.
1. Try to sort the child objects overtime they get shuffled. I need to
use this option when GetChild() is must faster compared to the
below.
2. FindGameObjectWithTag(): I read, Finding game objects with tags executes much faster than finding with names.
3. I have a total to 81 characters in the scene. Is it wise to attach all the 81 to the script upfront and access from that game
objects array?
Thanks.
If you are instantiating all the 81 characters from single point, I see it perfectly valid to store them in collection for further operations or delegating the operation to different object for processing.
It's also true that searching with tag is one of the fastest way to search around, but as you are checking for name, not for .GetComponent<T>() it's circa the same time to find what you're looking for.
From programmatical side, I'd rather stick with collection and references than gameobject names, as name can easily change for any particular reason (for ex. somebody changes name of gameobject to type of characters).
Also, please note that gameobject name can be duplicate.
Note: you are referring to attached prefabs but you should actually store gameObjects that resulted from prefabs instantiation.
This is a data structure/mapping question. I'm using MSSQL, with .NET and EF (and MVC if that's important). I have a table that represents a deck of cards. The states of a card are:
Face down in the deck
Face up in the deck (discarded)
In front of a player
In a player's hand
...and there can be X players. I have a table that represents players as well, with their own unique key. Assume that each player is in a single game, and one deck of cards is in one game.
At first, I thought there would be a one-to-many relationship between players and cards, enforced by a foreign key in the database. Player 1P has card 1C, 2C, and 4C, so cards 1C, 2C, 4C and "1P" under the PlayerID. Then there is a bit field to represent if the card was face up or face down. That works for state 3 and state 4.
How should I handle state 1 and 2? Some options:
Make the PlayerID on the Card table nullable. When I was using EF, I was running into foreign key constraints. Edit: I was running into foreign key constraints, but when I tried it now, it looks like it's working as one would expect.
Creating a dummy player called "Deck", and assign all cards in state 1 and 2 to this player. But, this didn't seem elegant; the Deck player had a lot of other baggage that I didn't want to deal with, and if I started doing multiple games, I'd need multiple Deck players.
Scrap the foreign key in the database, and make the PlayerID nullable. Enforce the constraint in the code. But then I can't do things like Player.Cards() without some extra extension code.
Have two more bit fields: "IsInDeck" and "IsDiscarded" (or some field that represents multiple states, like an int that is 0: in deck; 1: in hand; 2: in front of player; 3: discarded). That way, we don't really care what the PlayerID is if the card is in the "Discarded" state.
Some other option I haven't thought of.
Ideas? Thanks in advance.
You could try a schema like this:
The tables PLAYER, CARD, and DECK are hopefully pretty clear.
LOCATION_TYPE is a list of the kinds of locations that might apply. This would include things like "in a player's hand", "in front of a player", "face down in the deck" and "discard pile". You could use a physical table for LOCATION_TYPE or you could use an enum. The advantage of a table is that you could include some business rules like whether the location type requires a PLAYER FK in CARD_LOCATION and whether the card is visible or invisible (face up/down).
CARD_LOCATION is therefore the intersection that tells you where each card is at any given time. Your Player.Cards navigation property will work well as will your Card.Location navigation property. It is important to note that the FK from CARD_LOCATION to PLAYER is optional.
I enjoy making games and now for the first time try myself out on mobile devices. There, performance is of course a much bigger issue than on a nice PC and I find myself particularly struggling with weapon (or rather projectile) class design.
They need to be updated a lot, get destroyed/created a lot and generally require much updating.
At the moment I do it the obvious way, I create a projectile object each time I fire and destroy it on impact. Every frame all active projectiles get checked for collision with other objects.
Both steps seem like they could definitely need improvement. Are there common ways on how to handle such objects effectively?
In general I am looking for advice on how to do clean and performant class design, my googling skills were weak on this one so far.
I will gladly take any advice on this subject.
When you have lots of objects being created and destroyed in a short timespan, a common approach is to have a pool of instances already allocated that you simply reinitialise. Only if the pool is empty do you allocate new instances. Apple do this with MapKit and table views, among others. Studying those interfaces will probably serve you well.
I don't think this is about class design. Your classes are fine; it's the algorithms that need work.
They need to be updated a lot, get destroyed/created a lot and generally require much updating.
Instead of destroying every projectile, consider putting it into a dead projectile list. Then, when you need to create a new one, instead of allocating a fresh object, pull one from the the dead-list and reinitialise it. This is often quicker as you save on memory management calls.
As for updating, you need to update everything that changes - there's no way around that really.
Every frame all active projectiles get checked for collision with other objects.
Firstly - if you check every object against every other then each pair of objects gets compared twice. You can get away with half that number of checks by only comparing the objects that come later in the update list.
#Bad
for obj1 in all_objects:
for obj2 in all_objects:
if obj1 hit obj2:
resolve_collision
#Good
for obj1 in all_objects:
for obj2 in all_objects_after_obj1:
if obj1 hit obj2:
resolve_collision
How to implement 'all_objects_after_obj1' is language specific, but if you have an array or other random access structure holding your objects, you can just start the indexing from 1 after obj1.
Secondly, the hit check itself can be slow. Make sure you're not performing complex mathematics to check the collision when a simpler option would do. And if the world is big, a spatial database scheme can help, eg. a grid map or quadtree, to cut down the number of objects to check potential collisions against. But that is often awkward and a lot of work for little gain in a small game.
Both steps seem like they could definitely need improvement.
They only 'seem'? Profile the app and see where the slow parts are. It's rarely a good idea to guess at performance, because modern languages and hardware can be surprising.
As Jim wrote you can create a pool of objects and manage them. If you looking a specific design pattern there is Flyweight .Hope it will help you.