I'm in the planning stages of game dev. and am wondering whether or not to pick unity or Libgdx. I already know quite a bit of java, and I want to make a 2D sidescroller that uses ragdoll physics with animation. I have been looking pretty hard, but haven't found a good resource for this yet with Libgdx. It seems possible with Unity though. The resources I have found so far with Libgdx are :
Rube
Glee2d
Spine
Blender
So far with this it seems possible to make a level with a skeletal 2d animating sprite, but is it possible to apply ragdoll physics to this creation so, for example, if an enemy was shot it would react like a ragdoll?
I appreciate any help!
Thanks,
You could clearly use libgdx for that.
You'd have to create the ragdoll as box2d bodies (which can be done with rube). For rendering the ragdoll, you could use the setUserData() methods in box2d to bind an actor to the body/fixture. After each simulation step you would update the actors and create the proper rendering.
You could then place the ragdoll somewhere and shoot it with some other box2d body, let's say a cannonball...
Related
I'm creating a 2d game using the Java version of Box2d.
I know that the engine is generally paired with a separate library to handle animation, but I'm looking for something simple, with a more rustic feel, so I'm considering handling the animation from scratch.
The animation I am trying to create is something for the collision of two objects.
I'm using openGl to handle the graphics, and I pretty much have everything set up with the fps and rendering, it's just a matter of tweaking the frames to make it look smooth.
I tried bliting images of some things that I drew myself and it looked atrocious. I think the main problem is that the animation frame images are not linked to the physics forces and so they don't blend well.
What I want to try next is a sort 'spark effect' using a small number of pixels that sort of resemble 'dust' exploding off of the colliding images. If you've ever played dxball, you may recall a similar effect when the ball collided with the paddle at high speed.
As you can see in the above image, the principles are fairly simple. I figure by creating a set of small bodies with fixtures, I can use the box2d engine to produce this effect. I already have code that grabs the point of collision for all bodies, and am familiar enough with parabolic functions that I pretty sure I can create the force direction.
I'm just not sure if there is a better way of doing this, or how to apply a polynomial function to a body like in the image.
Does anybody know how to achieve this functionality with box2d? Any built in methods or documentation that would be helpful?
As a point of reference, the following snippet of code demonstrates the drawing of a small, red box on all of the collision points.
for(Vec2 point : listener.worldmanifold.points){
glPushMatrix();
newpos = point.mul(30);
glTranslatef(newpos.x, newpos.y, 0);
glColor3f(1,0,0);
glRectf(-2, -2, 2, 2);
glPopMatrix();
}
i am learning libgdx. i want to create a 2d fps game using libgdx, which is basically no physics environment. in that case lot of collision will be there (for example lot of bullets hitting multiple objects). i need to check intersecting of every sprite's rectangle with other sprites. in this way there may be thousand sprite's, checking every sprite with other 999 sprites in every time isn't definitely not a good idea.
libgdx has scene2d which has hit detection api's, is that solve my problem?
or
i should use box2d collision detection?
or
is there any other way to detect collision in libgdx?
i want to create a 2d fps game
As much as i know FPS means "First-Person-Shooter" -> a shooter with the first person perspective. That means, that it is 3D.
So pleas clarify what you mean.
Now to the collision detection question:
Scene2Ds hit detection is used for input like touch or
mouseevents. So it is used to detect, if an Actor is touched,
clicked...
Box2D is a 2D physic-engine which can not only do collision
detection for you, but it can also do the collision response as well
as the physics simulation (gravity and things like that).
Libgdx offers the Intersector class, which you could use for
overlap tests. The organization/the management of the collision
detection is up to you.
It would be better if you tell us how your game should work, how your world should be managed etc.
For example, if your world is tilebased, the collision detection between wall and player could be a simple check, if the tile is occupied -> collision, if not -> no collision.
Also it is important to know the shapes of your objects. A rectangle-rectangle collision detection is different from a rectangle-circle collision detection.
So now there are 3 solutions for your problem:
- Use Box2D and read tutorials on how to use it
- Do some research on collision detection, read tutorials and take a look at some sample projects
- Give us more informations about the game, its objects, their shapes etc.
How do you draw elements with JBox2D? I'm fine using the DebugDraw, I just want to find a quick way to do this in Java since I haven't worked much with graphics.
Do I need to use a Canvas? Or a JFrame? And how does the world know when I call
world.drawDebugData()
where to draw it to?
How could I devise a class that just drew points where I want them, and integrate this with JBox2D?
...
while(true)
world.step(timeStep, velocityIterations, positionIterations);
Vec2 position = body.getPosition();
float angle = body.getAngle();
System.out.printf("%4.2f %4.2f %4.2f\n", position.x, position.y, angle);
}
I imagine I could put this code somewhere inside this while loop, but I'm not exactly sure where. Is there a function that's called every time a World steps? Can I put a draw function in there? I'm even ok using the DebugDraw if I could figure it out...
Could you please help me understand what kind of class would take all the objects in the World object and draw them continually? (and where to draw to?)
You can easily create new testbed tests, this is the best way to test out your new physics ideas and not worry about drawing and GUI stuff. It even supports adding extra real-time options. Check it out here:
https://code.google.com/p/jbox2d/wiki/Testbed
It's difficult to know where to organize everything if you're not used to programming games and physics engines.
Dyn4j is another great physics library that has great examples explaining where to put everything and even how the user can interact with the world. A lot about the dyn4j library is identical to box2d/jbox2d, so if you just try out their examples real quick, it will lend a hand to figuring out how to render graphics in box2d.
I'm currently developing a 2D RPG with LWJGL, and am still in the engine stage of development. I've got a lot of the tech I want created, but one of my big problems is fixing the camera on the player. All the solutions I've seen involve moving the world and keeping the player still, which can work, but it seems apparent that this can cause some calculation issues if not closely monitored. Normally, I'd write a system where I wouldn't have to worry about it, but I refuse, because I eventually intend on adding multiplayer capability, where a moving world would be unplayable.
Is there a way to affix the camera to an object or point that can move WITHOUT using translate to move the world around? Also, I'd like to avoid Slick if possible. That would require me to rework much of my game engine as it currently stands.
Whenever you are going to project the 3d viewport onto a 2d screen you need to move everything according to the point of view of the observer (the so called camera or view).
I guess you can't escape from this. What you usually do is having a Camera object which holds position and rotation that is used to build the view matrix which is passed to the vertices of your scene through a uniform to the shaders. Passing transformation matrices to shaders is the normality so you shouldn't feel burdened by it. You can always premultiply it with the perspective matrix.
You must move the whole world to match the position of your camera just because you need to transform everything in your scene as it is seen from that point of view, otherwise how could you then project it on your screen? There is no "move the camera, keep the world still" concept.
Move the world visually, it's how every other RPG does it. Don't move the actual world's location though.
Draw everything but the ui normally, than translate it all according to the players position (i.e. glTranslate2f(-player.x,-player.y)). This is all done in the render method. On networked multiplayer, the viewport is done to that specific player (i.e. Bob's screen is translated based off Bob's position, Jane's is translated based off Jane's position). Should you instead want single-screen multiplayer, you will probably have to use mutliple framebuffers (one per player), and use them as viewports.
I would like to develop a game on Android platform, I have about a year experience with Java and also used the OpenGL library in C++. I also programmed Minesweeper and Connect Four in Java. Basically, here's the type of game I want to create:
Pressing the screen would make your character go up in the screen and releasing it will make it go down. I know there are games like this already but it doesn't matter to me, it's my current goal.
The structure of both games I programmed was quite easy, it was only a GridLayout. This wouldn't fit in any defined layout. Then, I have absolutely no idea how to test a character/environment collision. I'm also wondering what would be the easiest/fastest way to draw the "collision" environment, I assume it would be with OpenGL but from what I know, it would still take a long time and wouldn't be that easy.
I've been trying to find a tutorial about this but obviously, I've been unsuccessful.
PS: I already know the basics to make an Android app so you shouldn't need to worry about that.
think about each segment of what you're trying to achieve individually.
First off, you could probably read up on libgdx: http://code.google.com/p/libgdx/
it's a great android game engine which will do alot for the work for you.
For the player, think of it as just incrementing the players y position by a few pixels if it's pressed down, else decrement it.
For the map, you'd probably need some sort of 2d polygon based collision for the upper and lower collideable environments, libgdx has a physics library built in but i'm not sure how the support it for polygon-based collision. And finally, just create the map and make it wider than your game screen, and just move the camera along as the player moves.