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.
Related
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
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.
I am trying to learn my first programming language. Unfortunately I picked the Iphone to start. Thought it would be easy... ooops. Anyway 4 weeks later I've actually got a couple of working apps! kind of...
One of my apps that had a couple of text boxes and a couple of labels.
Each person has a has button that starts a timer that decrements a label's text for a countdown.
I have 2 separate timers that fire two separate methods that increment variables, play a song, update some labels etc, relative to each person. Not war and piece on the amount of code, but enough not to want to have to change both sets every time I figure out how to do something new.
What is a better way to set this up so that I can work with just one set of code per person? I get the whole "person" as an object idea and that it should be it's own class and that I should be probably sub classing it from all the reading I've done. I just don't know how to practically apply it with actual code.
I think the first place to start is to realize that timers are (almost always) part of the interface and not part of the data model. Unless you have a very strange set of requirements, the timers shouldn't be related to your person data objects at all.
You want to maintain strict seperation between data and the interface. This is the key idea behind the badly misnamed Model-View-Controller pattern. It should be called Model-Controller-View to reflect that the controller mediates between the model and the view.
In your case, it sounds like you have a person object that is your data model. Ideally, that model will work without any direct links to any particular interface. A good data model will work with standard views, a web view or even a text based command line interface. It shouldn't matter to your model because it is only concerned with storing or manipulating data without regard to how it will be displayed or used.
Timers that update the interface belong in the controller because they have nothing to do with the data. The same data displayed in different interfaces would need different timers. You probably only need one timer that simply calls a method in the controller that updates all the interface elements as needed. In that method, the controller then fetches the data it needs to display from the appropriate objects in the data model (Instances of the person class in your case).
For example, suppose you have multiple person objects each with it's own countdown number. You would have the countdown value stored in the person object as a property. A single timer in the controller would fire once per second and call a method in the controller. That method would then ask each person object for its countdown value. Upon being asked for the value, the person object would automatically decrement the countdown value.
With this design, you could handle an arbitrarily large number of person objects, each with its own countdown attribute, with just a single timer and one method in the controller.
We could talk for object oriented design for hours maybe months and years. Design principles exist by they are best learned and mastered through experience and a lot of practice.
If you need 2 timers each one calling 1 method that plays a unique role then you are probably stuck with the 2 timers. If there are common tasks/responsibilities in your two timers you could create an abstract timer that implements these common tasks and extend it for more specific behavior (method implementation).
I have found role based design helpful in many situations, but as i said you will have to practice and of course know the basics of object orientation and inheritance.
I'm developing an iPhone application and am new to Objective-C as well as SQLite. That being said, I have been struggling w/ designing a practical data management solution that is worthy of existing. Any help would be greatly appreciated.
Here's the deal:
The majority of the data my application interacts with is stored in five tables in the local SQLite database. Each table has a corresponding Class which handles initialization, hydration, dehydration, deletion, etc. for each object/row in the corresponding table. Whenever the application loads, it populates five NSMutableArrays (one for each type of object). In addition to a Primary Key, each object instance always has an ID attribute available, regardless of hydration state. In most cases it is a UUID which I can then easily reference.
Before a few days ago, I would simply access the objects via these arrays by tracking down their UUID. I would then proceed to hydrate/dehydrate them as I needed. However, some of the objects I have also maintain their own arrays which reference other object's UUIDs. In the event that I must track down one of these "child" objects via it's UUID, it becomes a bit more difficult.
In order to avoid having to enumerate through one of the previously mentioned arrays to find a "parent" object's UUID, and then proceed to find the "child's" UUID, I added a DataController w/ a singleton instance to simplify the process.
I had hoped that the DataController could provide a single access point to the local database and make things easier, but I'm not so certain that is the case. Basically, what I did is create multiple NSMutableDicationaries. Whenever the DataController is initialized, it enumerates through each of the previously mentioned NSMutableArrays maintained in the Application Delegate and creates a key/value pair in the corresponding dictionary, using the given object as the value and it's UUID as the key.
The DataController then exposes procedures that allow a client to call in w/ a desired object's UUID to retrieve a reference to the actual object. Whenever their is a request for an object, the DataController automatically hydrates the object in question and then returns it. I did this because I wanted to take control of hydration out of the client's hands to prevent dehydrating an object being referenced multiple times.
I realize that in most cases I could just make a mutable copy of the object and then if necessary replace the original object down the road, but I wanted to avoid that scenario if at all possible. I therefore added an additional dictionary to monitor what objects are hydrated at any given time using the object's UUID as the key and a fluctuating count representing the number of hydrations w/out an offset dehydration. My goal w/ this approach was to have the DataController automatically dehydrate any object once it's "hydration retainment count" hit zero, but this could easily lead to significant memory leaks as it currently relies on the caller to later call a procedure that decreases the hydration retainment count of the object. There are obviously many cases when this is just not obvious or maybe not even easily accomplished, and if only one calling object fails to do so properly I encounter the exact opposite scenario I was trying to prevent in the first place. Ironic, huh?
Anyway, I'm thinking that if I proceed w/ this approach that it will just end badly. I'm tempted to go back to the original plan but doing so makes me want to cringe and I'm sure there is a more elegant solution floating around out there. As I said before, any advice would be greatly appreciated. Thanks in advance.
I'd also be aware (as I'm sure you are) that CoreData is just around the corner, and make sure you make the right choice for the future.
Have you considered implementing this via the NSCoder interface? Not sure that it wouldn't be more trouble than it's worth, but if what you want is to extract all the data out into an in-memory object graph, and save it back later, that might be appropriate. If you're actually using SQL queries to limit the amount of in-memory data, then obviously, this wouldn't be the way to do it.
I decided to go w/ Core Data after all.
SqlDataReader is a faster way to process the stored procedure. What are some of the advantage/disadvantages of using SQLDataReader?
I assume you mean "instead of loading the results into a DataTable"?
Advantages: you're in control of how the data is loaded. You can ask for specific data types, and you don't end up loading the whole set of data into memory all at the same time unless you want to. Basically, if you want the data but don't need a data table (e.g. you're going to populate your own kind of collection) you don't get the overhead of the intermediate step.
Disadvantages: you're in control of how the data is loaded, which means it's easier to make a mistake and there's more work to do.
What's your use case here? Do you have a good reason to believe that the overhead of using a normal (or strongly typed) data table is significantly hurting performance? I'd only use SqlDataReader directly if I had a good reason to do so.
The key advantage is obviously speed - that's the main reason you'd choose a SQLDataReader.
One potential disadvantage not already mentioned is that the SQLDataReader is forward only, so you can only go through the records once in sequence - that's one of the things that allows it to be so fast. In many cases that's fine but if you need to iterate over the records more than once or add/edit/delete data you'll need to use one of the alternatives.
It also remains connected until you've worked through all the records and close the reader (of course, you can opt to close it earlier, but then you can't access any of the remaining records). If you're going to perform any lengthy processing on the records as you iterate over them, you may find that you impact other connections to the database.
It depends on what you need to do. If you get back a page of results from the database (say 20 records), it would be better to use a data adapter to fill a DataSet, and bind that to something in the UI.
But if you need to process many records, 1 at a time, use SqlDataReader.
Advantages: Faster, less memory.
Disadvantages: Must remain connected, must remember to close the reader.
The data might not be concluesive and you are not in control of your actions that why the milk man down the road has always got to carry data with him or else they gona get cracked by the data and the policeman will not carry any data because they think that is wrong to keep other people's data and its wrong to do so. There is a girl who lives in Sheffield and she loves to go out and play most the times that she s in the house that is why I dont like to talk to her because her parents and her other fwends got taken to peace gardens thats a place that everyone likes to sing and stay. usually famous Celebs get to hang aroun dthere but there are always top security because we dont want to get skanked down them ends. KK see u now I need 2 go and chill in the west end PEACE!!!£"$$$ Made of MOney MAN$$$$