Can someone give an example of what is meant by "apart from the effect of any external factors"? regarding this definition of "State" below?
"In general, the state of a dynamical system is a set of values that summarizes all the
information about the past behaviour of the system that is necessary to provide a unique
description of its future behaviour, apart from the effect of any external factors. "
What does this mean, "apart from the effect of any external factors"? Any examples?
(not really important, but I'm taking this from http://www.cs.bham.ac.uk/~jxb/INC/l12.pdf . I'm not in school. I don't have a teacher to ask.)
Thanks! :)
As a simple example, think of it this way:
Ball is an object sitting on the Table object. By default, Ball rolls forward and Table is flat.
Now, we apply the state is-stopped to Ball. -- The ball is no longer rolling forward.
However, if we then apply the state is-tilted to Table, Ball will then begin moving due to the tilt and gravity.
The state of Ball is stopped, however, external forces would cause the ball to not actually be "stopped." This is why the definition includes the ignorance of "the effect of any external factors."
Related
I am new to the play-clj, and I am confused about [screen entities] as arguments for all of the functions. I went through the tutorial, but am still not getting it i think, what these for all of the functions shared arguments are and what are they containing? I know screen is a map (a record more precisely) containing various functions for the main faunction and entitites is a vector containing aspects about the objects in the game.
What kind of values are the entities and screen holding, are they dependent on the functions we define? I would be very thankful if someone could give me some declarations and examples.
Well, the question is quite general, so I'll give a general answer. If you want specific details, feel free to ask.
Although play-clj supports functional game development, the base elements backing it are Java classes; accessed, set up, and modified in an imperative way. That means you will cause a huge amount of side effects using play-clj. And some behaviour may feel out of your hand when you're used to Clojure, but it sure makes some sense.
Despite the name, screen contains a custom instance of the complete libGDX engine, that is it wraps Java-objects for sound, graphics, physics, and asset management. It gets mutated in an imperative way, by calling commands followed by a bang.
For example(let [screen (update! screen :world (box-2d))] (...)) will add a 2d physics engine to your game which will exist from that point of time, even after you leave the binding. Its functions may also mutate entities as side effects, like dropping a ball by applying gravity.
All the entities on the other hand will get treated as properly as possible by functions like step! (mutating their states by applying physics if appropriate) or render!. They are maps, and their treatment is based on properties. :body means, they need physics, :shape means they need to be drawn as a primitive, :x, :y, :width, :height etc. do what you'd expect, and so on. You can add other properties and work with them as usual.
Functions expecting these two arguments have one thing in common: If you give them a return value, the game uses this return value as entities-vector from that point of time. So don't just modify and return a single entity unless you want to leave the poor bugger on the screen all alone...
Also make sure to read the docs at https://oakes.github.io/play-clj/, they explain a lot.
I had a question regarding the way I am designing my particle system.
Right now I have a class P, which stores all the information about a particle such as speed, position, direction, type, etc. I also have a main file I will be drawing these particles, updating and instantiating them in. I want to create a list of these particles using the c++ std list library, so initially I did
std::list<P> listOfParticles;
in the main file. Here is the problem. By doing this I will essentially be forced to make my update and draw functions in the main file. I feel like this is bad practice, and that everything to do with the particle should be kept in one class, but I am unsure where to go from here in terms of best practice. Would it be a good idea to just create a list of particles in the class P where I am defining what a particle is? I feel like this isn't a smart idea though..
If anyone could guide me in the right direction I would really appreciate it.
"By doing this I will essentially be forced to make my update and draw functions in the main file"
No one is stopping you from putting declarations/definitions of class members in same/different .h/.cpp files.
EDIT:-
That's what I said, better it would be if you make this List a member of some other class where you would put all functions to manipulate this list.
Your list of particles most probably deserves its own class, let C, that will handle storage, initial spatial distribution, temporal updates... i.e. all global operations on the particle cloud. If you are sure that you will ever handle a single list, you can make it a static member.
The class that represents the individual particles (P) can be nested into (C) if there is no need to see it from outside. It will encapsulate particle data and possibly also model pairwise interaction with another particle and other single-particle operations.
I've been recently assigned to code a Entity-component-system based framework. As I'm not experienced in that matter, I have a simple question:
Can I assume, that an entity can have maximum of one component of each type? I mean like:
int COMPONENT_COUNT; //number of different components available
class Entity
{
COMPONENT* component_list[COMPONENT_COUNT];
}
then adding a component would be like
component_list[component.id]=&component; //can't add more components of this type
Is that a correct assumption? I can't think of any situation when an entity would need two or more components of the same type.
I'm going to bring up my holy bible and say, yes, an entity should only have one component type! It is blasphemous to do otherwise!
Thou shalt not create entities with more than one component of the same type or else thou shalt face eternal damnation.
I'm normally pretty loose about this stuff but when you allow your system to have more than one component of a given type attached to an entity, that complexity spreads to every single corner of your systems.
Now every system has to work against the assumption that there could be more one component of the same type attached to an entity for any component type, at which point you're constantly faced with design questions like what a physics system should do when an entity has 14 position components attached. And what happens when a rendering system finds an entity with 15 motion components but only 4 sprites, expecting a matching motion component for each sprite component? Which motion components are used for which sprite?
Life becomes a whole lot simpler when you just say, "one component instance of one component type per entity."
If you want to aggregate, then just make your component a collection of something. Instead of Bone component, make it a Skeleton component which stores a list of bones. Instead of a Pixel component, make it an Image component which stores a collection of pixels. That's all fine, and doesn't require you to violate and defile the sacred commandment above.
Well, there isn't a holy bible of entity component systems. But many implementations I'm aware of don't make any provision for this, they allow entities to have or not have some kind of component but don't support multiplicity. Likewise, from a design perspective it seems like a rather bad idea (lots of complexity for naught). You could make it work, but neither you nor I can come up with a use case. KISS and YAGNI apply, this is a reasonable assumption. And if you do later need to add a component twice or thrice, it's easy to emulate by having two or three different kinds of components. Only with variable arity you need to change the innards of the system, but that seems even more outlandish.
Urho3D allows multiple same type components - and their components derive more than once sometimes - ie StaticModel from Drawable from Component
When you make a new component type - you can add as many of them as you want to a "Node" (same thing as Entity). This was pretty much a nuisance when using Urho - always thinking about "Wait, how many of these things does this Node have?".. For what?
Like others have mentioned, seems hard to justify all those extra for/while loops that go for 1 iteration always.. With Urho I got around it by just making it my own rule to never add more than one component of a type to the node... just too confusing otherwise
Tell, don't ask principle here is often pasted to me when I use getters or setters, and people tell me not to use them.
The site clearly explains what I should and what I shouldn't do, but it doesn't really explain WHY I should tell, instead of asking.
I find using getters and setters much more efficient, and I can do more with them.
Imagine a class Warrior with attributes health and armor:
class Warrior {
unsigned int m_health;
unsigned int m_armor;
};
Now someone attacks my warrior with a special attack that reduces his armor for 5 seconds. Using setter's it would be like this:
void Attacker::attack(Warrior *target)
{
target->setHealth(target->getHealth() - m_damage);
target->setArmor(target->getArmor() - 20);
// wait 5 seconds
target->setArmor(target->getArmor() + 20);
}
And with tell, don't ask principle it would look like this (correct me if i'm wrong):
void Attacker::attack(Warrior *target)
{
target->hurt(m_damage);
target->reduceArmor(20);
// wait 5 seconds
target->increaseArmor(20);
}
Now the second one obviously looks better, but I can't find the real benefits of this.
You still need the same amount of methods (increase/decrease vs set/get) and you lose the benefit of asking if you ever need to ask.
For example, how would you set warriors health to 100?
How do you figure out whether you should use heal or hurt, and how much health you need to heal or hurt?
Also, I see setters and getters being used by some of the best programmers in the world.
Most APIs use it, and it's being used in the std lib all the time:
for (i = 0; i < vector.size(); i++) {
my_func(i);
}
// vs.
vector.execForElements(my_func);
And if I have to decide whether to believe people here linking me one article about telling, not asking, or to believe 90% of the large companies (apple, microsoft, android, most of the games, etc. etc.) who have successfully made a lot of money and working programs, it's kinda hard for me to understand why would tell, don't ask be a good principle.
Why should I use it (should I?) when everything seems easier with getters and setters?
You still need the same amount of methods (increase/decrease vs set/get) and you lose the benefit of asking if you ever need to ask.
You got it wrong. The point is to replace the getVariable and setVariable with a meaningful operation: inflictDamage, for example. Replacing getVariable with increaseVariable just gives you different more obscure names for the getter and setter.
Where does this matter. For example, you don't need to provide a setter/getter to track the armor and health differently, a single inflictDamage can be processed by the class by trying to block (and damaging the shield in the process) and then taking damage on the character if the shield is not sufficient or your algorithm demands it. At the same time you can add more complex logic in a single place.
Add a magic shield that will temporarily increase the damage caused by your weapons for a short time when taking damage, for example. If you have getter/setters all attackers need to see if you have such an item, then apply the same logic in multiple places to hopefully get to the same result. In the tell approach attackers still need to just figure out how much damage they do, and tell it to your character. The character can then figure out how the damage is spread across the items, and whether it affects the character in any other way.
Complicate the game and add fire weapons, then you can have inflictFireDamage (or pass the fire damage as a different argument to the inflictDamage function). The Warrior can figure out whether she is affected by a fire resistance spell and ignore the fire damage, rather than having all other objects in the program try to figure out how their action is going to affect the others.
Well, if that's so, why bother with getters and setters after all? You can just have public fields.
void Attacker::attack(Warrior *target)
{
target->health -= m_damage;
target->armor -= 20;
// wait 5 seconds
target->armor += 20;
}
The reason is simple here. Encapsulation. If you have setters and getters, it's no better than public field. You don't create a struct here. You create a proper member of your program with defined semantics.
Quoting the article:
The biggest danger here is that by asking for data from an object, you
are only getting data. You’re not getting an object—not in the large
sense. Even if the thing you received from a query is an object
structurally (e.g., a String) it is no longer an object semantically.
It no longer has any association with its owner object. Just because
you got a string whose contents was “RED”, you can’t ask the string
what that means. Is it the owners last name? The color of the car? The
current condition of the tachometer? An object knows these things,
data does not.
The article here suggests here that "tell, don't ask" is better here because you can't do things that make no sense.
target->setHealth(target->getArmor() - m_damage);
It doesn't make sense here, because the armor has nothing in relation to health.
Also, you got it wrong with std lib here. Getters and setters are only used in std::complex and that's because of language lacking functionality (C++ hadn't had references then). It's the opposite, actually. C++ standard library encourages usage of algorithms, to tell the things to do on containers.
std::for_each(begin(v), end(v), my_func);
std::copy(begin(v), end(v), begin(u));
One reason that comes to mind is the ability to decide where you want the control to be.
For example, with your setter/getter example, the caller can change the Warrior's health arbitrarily. At best, your setter might enforce maximum and minimum values to ensure the health remains valid. But if you use the "tell" form you can enforce additional rules. You might not allow more than a certain amount of damage or healing at once, and so on.
Using this form gives you much greater control over the Warrior's interface: you can define the operations that are permitted, and you can change their implementation without having to rewrite all the code that calls them.
At my point of view, both codes do the same thing. The difference is in the expressivity of each one. The first one (setters anad getters) can be more expressive than the second one (tell, don' ask).
It's true that, when you ask, you are going to make a decision. But it not happens in most part of times. Sometimes you just want to know or set some value of the object, and this is not possible with tell, don't ask.
Of course, when you create a program, it's important to define the responsabilities of an object and make sure that these responsabilities remains only inside the object, letting the logic of your application out of it. This we already know, but if you need ask to make a decision that's not a responsability of your object, how do you make it with tell, don't ask?
Actually, getters and setters prevails, but it's common to see the idea of tell, don't ask together with it. In other words, some APIs has getters and setters and also the methods of the tell, don't ask idea.
I understand that only the class can access the data so therefore it is "safer" and what not but I don't really understand why it is such a big deal. Maybe it is because I haven't made any programs complex enough where data could accidentally be changed but it just a bit confusing when learning classes and being told that making things private is important because it is "safer" when the only time I have changed data in a program is when I have explicitly meant to. Could anyone provide some examples where data would have been unintentionally changed had that data not been private?
Depends what you mean by "unintentional changes". All code is written by someone so if he is changing a member variable of a class then the change is intentional (at least from his side). However the implementor of the class might not have expected this and it can break the functionality.
Imagine a very simple stack:
class Stack
{
public:
int Items[10];
int CurrentItemIndex;
}
Now CurrentItemIndex points to the index which represents the current item on top of the stack. If someone goes ahead and changes it then your stack is corrupted. Similarly someone can just write stuff into Items. If something is public then it is usually a sign that it is intended for public usage.
Also making members private provides encapsulation of the implementation details. Imagine someone iterates over stack on the above implementation by examining Items. Then it will break all code if the implementation of the stack gets changed to be a linked list to allow arbitrary number of items. In the end the maintenance will kill you.
The public interface of a class should always be as stable as possible because that's what people will be using. You do not want to touch x lines of code using a class just because you changed some little detail.
The moment you start collaborating with other people on code, you'll appreciate the clarity and security of keeping your privates private.
Say you've designed a class that rotates an image. The constructor takes an image object, and there's a "rotate" method that will rotate the image the requested number of degrees and return it.
During rotation, you keep member variables with the state of the image, say for example a map of the pixels in the image itself.
Your colleagues begin to use the class, and you're responsible for keeping it working. After a few months, someone points out to you a technique that performs the manipulations more efficiently without keeping a map of the pixels.
Did you minimize your exposed interface by keeping your privates private?
If you did, you can swap out the internal implementation to use on the other technique, and the people who've been depending on your code won't need to make any changes.
If you didn't, you have no idea what bits of your internal state your colleagues are depending on, and you can't safely make any changes without contacting all of your colleagues and potentially asking them to change their code, or changing their code for them.
Is this a problem when you're working alone? Maybe not. But it is a problem when you've got an employer, or when you want to open-source that cool new library you're so proud of.
When you make a library that other people use, you want to show the most basic sub-set of your code possible to allow external code to interface with it. This is called information hiding. It would cause more issues if other developers were allowed to modify any field they wanted, perhaps in an attempt of performing some task. An attempt that would cause unspecified program behaviour.
Generally you want to hide "data" (make vars private) so when people that aren't familiar with the class don't access data directly. Instead if they use Public modifiers to access and change that data.
Eg. accessing name via public setter could check for any problems and also make first character upper case
Accessing data directly will not do those checks and possible changes.
You don't want someone to suddenly fiddle with your internals, no? So do C++'s classes.
The problem is, if anyone can suddenly change the state of a variable that is yours, your class will screw up. It's as if someone suddenly fills your gut with something you don't want. Or exchanges your lung for someone elses.
Let's say you have a BankAccount class where you store a person's NIP and cash amount. Let's put all the fields public and see what could go wrong:
class BankAccount
{
public:
std::string NIP;
int cash;
};
Now, let's pretend that you leave it this way and use it throughout your program. Later on, you find a nasty bug caused by a negative amount of cash (whether it is from calculations or simply an accident). So you spend a couple of hours finding where that negative amount came from and fix it.
You don't want this to happen again, so you decide to put the cash amount private and perform checks before setting the cash amount to avoid any other bugs like the previous one. So you go like this:
class BankAccount
{
public:
int getCash() const { return cash; }
void setCash(int amount)
{
if (amount >= 0)
cash = amount;
else
throw std::runtime_exception("Cash amount is negative.");
}
private:
int cash;
}
Now what? You have to find all the cash references and replace them. A quick and dirty Find and Replace won't fix it so easily: you must change accessors to getCash() and setters to setCash. All this time fixing something not so important that could have been avoided by hiding the implementation details within your class and only giving access to the general interface.
Sure, that's indeed a pretty dumb example, but it happened to me so many times with more complex cases(sometimes the bug is much harder to find) that I've really learned to encapsulate as much as I can. Do your future-self and the viewers of your code a favor and hide private members, you never know when your "implementation details" will change.
When you are on a project where 2 or more people are working on the same project, but you work lets, say, 2 people work on Mondays, 2 on Tuesdays, 2 on Wednesdays, etc. The next people that will continue the project won't have to go bother the other coders just to explain what/when/why it has been that way. If you know TORTOISE you will see it's very helpful.