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.
Related
I am having a tough time learning JFrame. So I thought that can I skip JFrame or will it effect my ultimate goal of learning android game development?
JFrame, is a frame which allows output. Output is the easiest part of any game development. The hardest part is rendering to an Image object, based off a set of 'world' objects that have to be defined by the game logic. A JFrame is just a simple way of outputting your players view into the world. The most crucial part to any game, be it android, iPhone, Xbox, playstation, or PC, is what happens in the background.
for 3D games you need to learn a lot of math - trig, matrices, maybe a little calculus even -, for 2D its a lot simpler, however you still need to know some math. You may wish to implement some simple physics, in which case youll need a comprehensive knowledge of mechanics, and how objects interact with each other. youll then need to build something that can manage these objects and implements all the functionality above.
Having done the above, you now need to render these world objects to an area of memory, so that they can be read by the output device, be it a JFrame, or smartphone screen and shown to the user.
To conclude, I would not get yourself hung up on smartphone development, using swing or awt can be a lot simpler than developing on a smartphone, and the back end of your program, which will most likely account for over 90% of your code, can, in most cases, just be swapped out for the smartphone code and just change the front end.
Hope this helps
I'm working on a simple game with libGDX and want to make the main character to be fixed in the center of the screen and the world move when I press a button. I was wondering how to do... I was thinking to add a physicsBody to the world that contains other bodies and apply impulses to it when the button is pressed, is this possible in libGDX? And if it is, can i apply other impulses or forces to the bodies contained in the world's physicsBody? I think this way would be the best for me if it is possible, because i have to work a lot with physics, but if you have other ideas tell me please
There's no need to think about applying forces to all the non-character objects, that's just going to get messy very quickly.
The simple solution is to move your camera so that it always looks at your character. So your game loop may look something like:-
Process input
Update physics, character and other entity positions.
Move camera to point at character's new position.
Render
This way, you can update your game world without having to think about the camera at all. Then, when it comes to rendering, you can position your camera and render your graphics without needing to know anything about the game physics. It keeps the physics and rendering relatively independent, and makes it much easier to change things in the future.
For example, you may later decide that you want the camera to follow your character for the most part, but then follow a baddy whilst it is their turn. This is now easy to do, you just specify the character / entity to look at in your game logic, and then position the camera to look at whatever target that is, before you render.
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...
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'm working on a 2D four-side scrolling game and I am currently implementing collisions. I was surprised to see that there is no pixel-perfect collision library implemented in the standard library, and so I wrote my own collision "engine" with geometrical forms to represent non-geometrical figures. For now, it works fine, but I really want to know if there's a way to just get it all over with, thanks to a well-built library. If anyone knows of one, please share it.
I recommend you to take a look to AndEngine. You can see one video here about 2d pixel perfect collision:
http://www.youtube.com/watch?v=abbXURuDaTo