Why should you even use kinematic bodies instead of dynamic bodies with no gravity? I mean a dynamic body can also collide with static bodies and have some other adjustable parameters that kinematic bodies do not have, right. Therefore, I would really love to hear why you would want to do this and if it even can be lead to some advantages.
Your time is much appreciated!
It's a matter of what you want b2World::Step to do to the body. Basically this method's body related post-conditions are as follows:
Static bodies are unmoved.
Kinetic bodies are moved based on their previous velocities.
Dynamic bodies are moved based on their previous velocities, gravity, applied forces, applied impulses, masses, damping, and the restitution and friction values of their fixtures when they experience collisions.
So kinematic bodies can be useful when the only thing that you want to have happen to the body is to have it moved based on a velocity you'd given it.
Related
I'm writing code for mouse picking in 3D space. So far I've made Ray and AABB classes. What I need is a function for Ray-AABB intersecting. I know how to write it and make it work, my question is which class should define said funcion? Should it be a member of Ray or AABB, both, neither? What are the best practices for object oriented approach?
For me it makes the most sense to implement that function as a member of "engine" class, more like a procedure rather than a function. However I want my code to be truly object oriented.
I would say: neither.
Ray: Structure (Members: Start, End)
AABB: Structure (Members: Position, Size).
Ray-AABB intersection method could be in a Physics or Intersection class (Depends on your actual context) as static methods (Or functions in a namespace, depends on your coding convention).
Object oriented is fine, but it doesn't mean that everything you create should be a class.
Data oriented is a very good approach (CPU friendly with less cache misses).
EDIT: A good coding rule is to think your things independently, meaning that the AABB implementation shouldn't be dependent on the Ray implementation.
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 several static bodies and I want them behave like planets. Each static body should have gravity like force to affect on dynamic bodies. Currently I'm applying applyForce:atLocalPoint to dynamic bodies if distance to them less that some value. But current implementation do not behave like gravity, objects are start rotating and moving not to the centre of static bodies. Is the predefined behaviour in cocos 2d v3 with chipmunk for such behaviour?
I'm having a little circular-dependency problem. It works fine, but it makes for ugly-seeming code. It's in the context of a Snake game.
I have a class, Snake, which contains a vector of SnakeSegments, and manages their interaction (for instance moving and growing as a unit, rather than as separate entities).
When a SnakeSegment collides with a Food object, it flips its hasEaten member to true. The Snake routinely queries the SnakeSegments, essentially for this member. If any of the queries return positive (i.e. one has hit food), then the Snake will grow as a unit (i.e. expand the head and shrink the tail). This is all fine and good, but I'd much prefer a more signal-based approach, where, when a SnakeSegment hits food, it sends an alert (signal, interrupt, etc.) to the Snake class, which tells it to grow. This means I wouldn't have ugly code in my Snake's Update function, checking all the segments; and I would instead have an OnEat() function in my Snake class.
However, this leads to circular dependencies; the Snake contains a vector of SnakeSegments, and the SnakeSegments have a Snake& or Snake* member, which tells them whom to alert when they eat. In the code, I essentially just have to pre-declare the Snake class:
class Snake;
class SnakeSegment
{
...
Snake* alertOnEat;
...
};
and my Snake class just works normally
#include "SnakeSegment.hpp"
class Snake
{
...
std::vector segments;
...
void OnEat();
...
};
Are there any nicer designs to this? Note that it isn't just a problem occuring here; a similar problem occurs in a number of areas (e.g. the GameWorld contains a Snake member, and the Snake alerts the GameWorld when it dies), so a solution specific to Snake and SnakeSegment isn't what I'm looking for.
Your current design is perfectly fine in most situations. Yes, it creates a circular dependency, but it also is the simplest and the clearest way to do it.
However, you should limit those dependencies between interfaces or base classes rather than to the derived classes directly. The world-snake dependency is a good example. You probablly don't necessarily want the World class to know about all the possible game object types. However, what you can do is derive all your game objects from a common GameObject class and make World and GameObject interdependant.
There are also more complicated ways to avoid dependencies all with their pros and cons, they mostly differ on the level of separation and clarity. Among those, function pointers, delegates, observers, listerners, functors, etc.
In the end, it always come down to how much complexity you are ready to introduce to your architecture in exchange of flexibility and clear separation of concerns.
Never forget that design is compromise.
What you may want to look at for this problem is the Observer/Observable design pattern. It allows you to create objects that observe (Snake) observable objects (SnakeSegment) and get notified right away when their state has changed.
Wikipedia has a good example of it written in many languages including C++.
It's a common pattern used in a lot of GUI development so the View layer can change when any of the underlying Model data changes.