safemode wrote:atom refers to indivisible,
And is the "SIMULATION ATOM" indivisible? No; it isn't.
aka smallest unit.
Is it the smallest unit? No it isn't. (And a common technique we might soon implement, for elastic bounce, is to subdivide the simulation into smaller steps when a collision is detected to compute bounces correctly; rendering the name downright contradictorily misleading.)
If you are familiar with anything in programming, you would be familiar with the term atomic. As in, an atomic operation.
If you're familiar with anything in programming, you'd be familiar with the term atomic, which means during which a thread cannot be interrupted by another; or a function cannot be reentered; which SIMULATION ATOM is not; and which is yet another way the term is misleading to a programmer.
The simulation atom is similar in meaning to an atomic operation, in that it is the smallest unit, but this unit references dynamic real time.
Ergo, is neither indivisible nor smallest; it varies in size.
Just because you dont understand it, doesn't make it wrong.
The fact that it's misleading makes it wrong.
Just because it's not spelled out like a java function, doesn't make it wrong either.
I don't program in java; so I cannot comment.
I have no problem at all seeing the word simulation atom and knowing that it is it's term for a unit of time ...
Programming itself has a problem with meaningless terms; and a bigger problem with misleading terms.
no different than a jiffy in the linux kernel.
Jiffy is meaningless, and so it is a bad choice of a term; but not as bad as a misleading term.
similarly, a unit is an object that can be manipulated and interact in the game.
Note your use of the word "and". "Manipulated AND interacted." So a jump point is not a unit?; or it is but it shouldn't be? Because it can be interacted with, by pressing J, but it cannot be manipulated; so it doesn't pass your x AND y definition; or did you mean x OR y? That's precisely the problem: you're trying to define what it means NOW, years after it was coded, and you probably won't succeed at defining it exactly.
Now, is the meaning of "unit" in real life "something that can be manipulated and interacted with"? If not, then how does calling it "unit" help the programmer know what the hell is meant for it to do or to be?
Now, how unit is implemented currently is wrong, and the result of a decade+ of lazy hacking.
of a decade of lazy hacking without any guidance as to what was the intent for the class, with a name as ambiguous as anyone could have come up with.
But saying that the word is somehow cursed to only referring to the mathematical term is narrow minded.
The word is cursed in real life. It has, over time, become a monstrosity, thanks to generation after generation of misusing the term until nobody knows what it means anymore. In the beginning "unit" was always "a unit of"
something, --be it a unit of measure, as per my previous post's example; or a "unit of purpose", or the minimum number
of something you can count. Then came corrupt uses of the word, such as in miltaries that call a group of soldiers on a mission a "unit", I supposed with the intent to mean that they (should?) "work as a unit" (meaning, as a single soldier?). And of course, at a "TV set" (yet another oxymoron) manufacturing plant, each "TV set" is referred to as a "unit" being shipped.
But in spite of various, and somewhat contradictory and corrupt uses of the term, you can still educe a common thread.
Now we come to the use of "unit" in the vs engine, and neither legitimate nor corrupt uses of the term from real life have any semblance to its "working definition": The kinds of things that can inherit "Unit" are so different and various, there's no way to tell these were meant to be
units of
what? Not to speak of "sub-unit" (another oxymoron)... A gun turret can be manipulated with AND interacted with (and in PU they even talk to you...); and yet they are classed as "
sub-units". The term "sub-unit", not only appears to contradict the "unity" of "unit", but it is misleading in its own right: You would think it is like a part, or constituent, when in reality it is an
attachment.
But it's not ME that has a problem with badly chosen terms in programming; it is every self-respecting programmer that does; is is programming itself, as pursuit, art and passion.
Programming is challenging, hard, error-prone; and the last thing you want to do is make things worse by being lazy about thinking what's best to call something, so that it will be obvious and clear as to what it is meant to do.
What would have been so wrong about calling it "GameObject"?
Units are referred to manipulated objects in numerous games and even end users are walking around wondering what these "units" are referring to in games like warcraft, starcraft etc.
Well, in Starcraft, a "unit" is A soldier, for example; ONE soldier; and in that sense it is "
a unit of infantry". That is nowhere nearly as wrong as what vegastrike calls "unit".
Using Starcraft as an example, what vegastrike does is as if Starcraft were to call (class) "soldier" a class
of type "unit", which is completely meaningless and wrong.
there is a limit to being pedantic about names
Never heard of such a limit; but if there is, I'm sure I'm nowhere near it.
I name a counter "i", not because it's more descriptive than naming every counter some simile of "counter" but because it's faster to just type i and it's context
you mean
its context? Am I being pedantic?
is easily understood regardless of what it's called.
You just don't get it. What it's called IS important. Using i for a counter is okay NOT because what it's called doesn't matter, but because i and j are well understood to be counter variables in programmers' lingo; so they are quite clear. If you were to use z as a counter, it would be BAD programming, because most programmers would tend to think it refers to a position in an axis.
The problem in VS code is that sometimes the context is not easily understood. This is a problem with the structure and lack of documentation, not the names of things.
It is because of lack of documentation secondarily; but because of the names of things primarily. A program where things are named carefully is usually self-documenting, and you hardly need to write any comments.
Dont get hung up on silly things like names.
Names are NOT "silly things". The vs engine is inscrutable precisely because the original coders thought. just like you do, that names are "silly things".
This is no different from what some engineers in the field of electronics do, who think that schematic diagrams are "silly things" --just a means to produce a circuit board. So they get a prototype assembled much faster than the better engineers; but then they spend months debugging their designs, because the schematic diagram is inscrutable.
Similarly, programmers of your philosopy think that sources are "just a means to an end", namely to produce an executable; and can't grasp the concept that sources are "documents"; that they are meant to make code ***clear***, so that it can be read and maintained.
When it comes to unit, it's got much more important problems....what you call it is the last of them.
No; it is precisely the first. All the other problems came after, and are the consequences of the first. The purpose of "unit" not being self-evident, anything went into it.
As for graviton, i explained what the graviton does. It acts as the base unit that all units that get physically manipulated inherit.
That's what "unit" does right now; and its name is somewhat more clear than "graviton"... So, all you want to do is change the name, to make it even more inscrutable?
It holds the variables for mass, velocity (vector velocity), position,
What's wrong with "PhysicalObject", then?
and if simulated gravity is enabled or not. That's it. Physics need only operate on it when doing transforms. By unit, i refer to all objects in the game that move, and occupy space in the game and have mass. This is not the same "unit" as we currently know and love, but to whatever idealized classes you can imagine that refer to things like planets, suns, ships, turrets, missiles, bases , asteroids, etc.
So, instead of writing paragraph after paragraph, post after post, explaining your "graviton"; why not just call it "PhysicsObject" and let its purpose be obvious? Can't you see the practical value of proper names? Time is money. You wasted hours of my time, and wasted hours of your own time, for what reason? Just because you like the term "graviton" and want to use it no matter what?
It's as if we were arguing about cars and I consistently used the word "springs" to mean "shocks", and "shocks" to mean "springs", confusing the hell out of you, and once you figure out the problem and raise an issue with it I were to call you silly and pedantic for giving a damn what the exact names of these things are.
Hey, I don't like names any more than you do; but we've got a language; let's use it.
The name "PhysicsObject" applied to a class that contains position, mass and velocity, doesn't even need a one-line comment explaining what it is. It is obvious even to a non-programmer.
How or why you would have come up with a term as bad as "Graviton" for it is what I find baffling. There must be a genetic trait that makes some people seek clarity, and makes others pursue confusion and obscurity.
Or do you work in marketing?
Because, frankly, there's nothing new, at all, about having a class PhysicsObject that has mass, position and velocity, and is the base class for all physical object classes. Absolutely nothing new about it, except for the (pretentious) name "Graviton". Seems like trying to push a new and silly buzzword.
And it would be better for it to be programmed as a template trait:
Code: Select all
template < class Derived, typename T >
class PhysicalObject : protected AbstractPhysicalState<T>
{
void check_invariants(); //throw
public:
void SimulationStep( milliseconds time );
};
//where,
template < class AbstractState >
class SimPhysicalState
{
AbstractPhysicalState a, b; //a and be can be either current or previous-next; and swap roles before each step
mutable AbstractPhysicalState *prevnext; //in a PhysicsStep processing, next state overwrites previous, while...
mutable AbstractPhysicalState *current; //...current remains read-only and read-accessible to other threads
void flipPrevnextAndCurrent();
virtual PhysicalStep_( milliseconds time );
public:
void PhysicalStep( milliseconds time )
{
flipPrevnextAndCurrent();
PhysicalStep_( time );
}
AbstractPhysicalState const & currentState() const { return *current; } //reentrant and thread-safe
AbstractPhysicalState & prevnextState() { return *previous; }
};
//where
class AbstractPhysicalState
{
public:
virtual ~AbstractPhysicalState() = 0;
.........
};
template < typename Precision > //e.g. float, double
class SpringPhysicalState : public AbstractPhysicalState
{
...............
};
template < typename Precision > //e.g. float, double
class InertialPhysicalState : public AbstractPhysicalState
{
typedef vec3<Precision> vec3_t;
typedef Precision scalar_T;
vec3_t position;
vec3_t momentum;
vec3_t velocity;
scalar_t mass;
scalar_t inverse_mass;
milliseconds time_stamp;
};
//alignments notwithstanding; in fact, where
template < typename Precision >
class vec3
{
typedef Precision scalar_t;
scalar_t x, y, z;
scalar_t __padding__; //for proper alignment
public:
...........
};
I hope you understand that "Unit", the way we understand it [:D], may need one PhysicsObject-derived object PER moving part...
I hope you ALSO understand that the code I wrote above is not only incomplete (lacks orientation quaternion, tensor of inertia and torque and torque axis, as well as a forces accumulator, and various odds and ends), but is is also limited to weights.
Springs need a different set of data, as they use positions as inputs, and output forces.
So, what you called Graviton, and I renamed to PhysicsObject, should really be called WeightObject or MassObject.
And most physical objects need one or more weights and zero or more springs, as well as pivot points with axes and motion limits.
So I'm not sure about the wisdom of deriving GameObject from MassObject. It should really derive from PhysicalSystem, which may boil down to a single MassObject in the simplest case (as currently covered).
You see now how names are not "silly things"?
The act of looking for better names has just led me to the realization that my class system was not general enough.
And when you design a class system that is not general enough, later you're stuck with having to refactor it, which is a lot harder to do than to design a class system properly from the get go.