I have a system in place for a game yet I don't know what I should use to display it. I am making a vertical shooter game and I have written the methods for all the classes controlling enemies and players, but I have not idea how to efficiently display the game. I was thinking a Canvas, that would repaint every frame, but is that really the most efficient method?
Important details:
ideal framerate: 25fps
It is a 2d game
There are anywhere between 25-100 objects on the screen at any one time, all of which are moving
All objects being displayed are images, all in PNG format
The window is 640px by 480px
Right now all the images are loaded as BufferedImage, although I could easily change this
7. I need a coordinate plane. This is the only fundamental part that cannot be changed without completely restructuring my code.
Most importantly the way I have everything set up, every frame all of the objects move and interact in a coordinate plane I devised (deals with collision detection and movement, no graphical component), then everything should get painted to the screen, simply by going through the ArrayLists which keep track of all moving objects and painting them one by one.
If Swing is acceptable, JPanel is double-buffered by default, and a javax.swing.Timer with a period of 40 ms will give you ~25 Hz updates. This example shows the basic approach, while this example shows a number of images in motion.
I need a coordinate plane.
It's not unusual to have the the model and view use different coordinates; all that's needed are functions to map one system to the other. In this game, the view relies on four methods that map tiles to pixels and vice-versa. The same approach is outlined here for map tiles.
You have a number of options available to you:
Firstly, you could use one of the existing Java game frameworks:
JMonkeyEngine (http://jmonkeyengine.com/)
Slick (http://slick.cokeandcode.com/index.php)
(Slick is aimed at 2D graphics, while JMonkey is aimed at 3D and uses OpenGL - While I have looked into their use, I've not actually used them myself)
Alternatively you can code everything yourself. From the sounds of things this is your first (graphical) game, so you may want to read up on a technique known as double buffering, whereby you write each frame off-screen and the just paint the whole thing to screen, as this can lead to smoother animation.
To get you into games development a bit more, I would highly recommend reading this site, Killer Game Programming in Java by Dr Andrew Davison, as he gives some good pointers, and also provides a good progressive learning path for new game developers, and moving them into 2D and then 3D development.
HTH
The answer really depends on whether this game is 2D or 3D.
If your game is 2D, an easy way to do what you want is to use Java's own 2D Graphics API. A good tutorial to start you off (at least in my opinion) can be found at The Java Tutorials. In my experience I have found that Java's graphics API is easy to learn, and is more efficient than one might expect. The basic technique is to have your game code keep track of the positions of all your objects, then translate those coordinates into screen coordinates and display appropriate images at those locations. I made a (very, very simple) game in Java once, and this is the method I used.
If your game is in 3D, OpenGL is definetly the way to go. I have only limited experience with OpenGL, so I'm not sure how easy the Java bindings are to work with. In general, 3D programming is a massive topic, so if this is a first-time project or you aren't prepared for a major time investment, I would attempt to find a good game framework to use or make the game 2D. If you are interested in OpenGL, or 3D programming in general, a quick Google turned up the JOGL project. I would recommend investigating JOGL as a way to access the OpenGL API from within Java code, but for actually learning OpenGL I recommend The OpenGL SuperBible(5th edition), commonly known as "The Blue Book".
The code examples are all in C++, but for the OpenGL functions it could possibly be just a matter of using a wrapper library. For example:
glDrawElements(...);
May become:
JavaGLWrapperObject.glDrawElements(...);
Unfortunately I can't give concrete examples because I haven't used OpenGL with a Java program, but the above example very coarsely approximates how OpenGL ES is used on the Android platform.
As far as performance... Java's API comes with a non-trivial ammount of overhead, but I could see it doing alright for your purposes. You may have to put a little more effort into making your algorithms efficient, and your game may not run as well on less-capable hardware. If you do decide to go the OpenGL route, it will almost certainly be much faster (again, depending on how efficient your algorithms are), but is correspondingly much harder to learn and get started with. Certainly doable, but it will be a challenge.
Canvas will quickly be too slow for 25+ fps targeted.
the number of object is irrelevant, what is is how complex they are.
if it is 100 images will take nothing compared to 1 3D model of Avatar for example.
in Java you can use either Opengl or Java3D
I would tend to go with Opengl as a personel choise
Related
I am trying to make a game where you have multiple levels where you have to figure out a way to where a certain color should go through pipes that are displayed on the screen. The pipes look like (it all should be better, but just as a reference). So basically there should be an animation of color going down these pipes (different color for different pipe). Now, I can make a gif and use that as my animation, but it's just too large (aprox. 5MB, which isn't a lot, but if you put dozens of levels, it tends to add up).What would be a solution that would be the most efficient?
Well I would first recommend you to go with Unity for Game Development.
If not then check out cocos2d or any other frameworks.
Secondly, if you want to animate things using the native code, then play around with draw() functions (as suggested by #Wakeman) of the Canvas.
Now coming to your question, if your game does not involve continuous user interaction and you are thinking of GIFs as a solution then I would recommend using Lottie library.
You can create beautiful animations in Adobe After Effects and import those (json files) in Android without hurting much memory, plus would get high resolution output.
Have you tried using the drawRect() or drawCircle()? You only need coordinations of the starting point, the turning points, and the ending point. Draw it with a recursive function with delay, and it should look good.
It would be better to construct your levels as tilemap. Every segment of pipe can be coded by number and drawn as bitmap (Sprite) that depends on its state (empty, 1/4, 1/3, 1/2 or full). Similar principles works for engines like Unity/Cocos 2D or your own renderer. This way of building your levels would be hundred times lighter in size than full screen animation and used multiple times for different levels.
For a school project i have made a program that can solve a rubiks cube (you know, that cube with all the colors). But now my teachers asked if i could do some research and try out 3d animation for one of the sides. But they want to see the mathematical way to do it. I have found a way to move the corners with the use of polar coordinates. But i do not know how i could render a cube in 3d and be able to animate it.
So my question is: how can i render things like a cube in 3d (or are there any good libraries for it) and how could i use these polar coordinates to animate it?
And is there a good tutorial out there for java 3d rendering?
i must say that i have absolutely no experience with 3d rendering, so it might be a bit difficult. But i really would like to try it out.
thanks in advance
Depending on whether you want to take an existing implementation or if you want to build code for 3D animations from scratch, you might try this tutorial. Graphics programming in this area can be quite involved; a full answer of the question is beyond the scope of this site. However, there are a few main areas.
Usage of vector math for transformation of objects (translation, rotation). This can be done directly or via projective geometry using 4-by-4 matrices. The latter is easier for concatenation of transformations.
Backface culling to remove faces of the object which cannot be seen by the camera.
Using a projection and a camera model to transform 3D coordinates to 2D coordinates.
Using a rasterizer to render the 3D vector information to the screen. Here Bresenham's algorithm might be a good start.
I would suggest you look at one of the 3D libraries. One that I've used a lot and found to be excellent is JMonkeyEngine (JME) which is designed for games but would work well for your needs. It also has an excellent tutorial that takes you from basic to very complex. In fact the first step in the tutorial is a revolving coloured cube!
JME takes a huge amount of the work out of 3D modelling. You build a scene in code with materials, lights etc. and JME does all the work to render it. You can even build your models in a tool such as Blender so you don't even need to do the modelling in code. But I will warn you that using modelling tools is definitely not for the faint hearted.
I am looking to make an arm where each joint can be controlled given an input. For example, I would receive a location each millisecond and I would need each joint to move to that new location. This is going to be used to simulate motion capture. Are there any good tutorials about how to do this. I am programming this on an atom board with limited support for openGL. I tried using C++ G3D but it seems to be too complicated for the graphics card. There were some glitches when rendering. Would a more basic OpenGL only approach be better? Are there models for arms that have pivot points built into them?
G3D itself uses OpenGL as a rasterizer backend, so I doubt that would make any differency. After all OpenGL is just a drawing API and doesn't maintain a scene. You send it commands to draw points, lines and triangles and it executes them. It's really nothing more. You need to implement scene management to do anything usefull with OpenGL, and controlling a figure is already a quite complex task.
I have recently been developing a sim game in java, as many of my questions show, and it's come a long way! Graphically, it is somewhat lacking, and at current I'm using shapes for items, people, rooms etc.
I was looking at other similar projects, and noticed that one was using OpenGL. I have been reading CokeAndCode "space invaders 103 - refactoring and OpenGL", and I still don't know if it is something I need in my game or not.
Here is a video that I used for a previous question, but it still shows basically what I have so far (http://www.screenjelly.com/watch/Bd7d7pObyFo), although I have done a lot of refactoring and re coding over the last few weeks, but graphically, nothing has changed. As I understand it, I'm currently using java2D to do this.
I really don't know how I should continue graphically with this game. This is my first project I have done outside of learning for my own enjoyment, and so I'm still rather new to this.
Thanks in advance!
This could turn into a long subjective conversation quickly but I want to state the fact that you don't need openGL. Your application doesn't need to be the best looking one out there. Nethack still attracts people and between you and me : the graphics sucks.
Do you want to learn about 2D and 3D graphics and textures and so on ? Then try stuff... best way to learn. Then you can add this to your resume.
There are a lot of tutorial to do your first steps in OpenGL or some other graphic library. You can even try Qt Jambi. But once you start, you're in for a ride ;)
According to this, it's still largely possible to implement a working graphical game in Java2D with decent performance, as long as you make sure not to do a certain number of bad things.
It might help you to check and see how your approach is, compared to this.
I have no idea how far along Java has come with OpenGL support, so were I in your place I would probably just see how much refactoring of the Java2D code I could do, and figure out what to do from there.
Hope this helps, at least a bit.
One good side of using opengl (even for 2D graphics) is that you will get (if properly done) hardware graphics acceleration for your scenes.
Also, you can use orthogonal projection and keep one of the axis (Z) as zero to do your 2D graphics. It will be easy if you want to add a 3D effect (like lightning or something) if you use OpenGL.
However it all depends on how much you want to improve the graphics, since adding OpenGL might make things a little more complicated than plain Java2D.
How to continue graphically: use textures, more interesting animations (implement a simple physics engine and/or collision detection, that always looks nice).
When you go 3d (for example using opengl) you can add lighting effects to the equation, that usually does a lot to the aesthetics of the whole. For example if the moving circle was a sphere with a nice texture (marble or something), then you could make it really role over the board, and you could specify diffuse and specular reflection values to vary the lighting like for example here.
Camera movement can also beef up the graphics.
Due to lack of capital and time we are having to do our game in 2D even though me (the developer) would prefer if it was done in 3D. I would hate for users to join the game, only to think the graphics look bad and leave. Though I suppose we just have to try and do our best.
That being said, I would like to develop the game in such a way that, should the time come, we can port to 3D as easily as possible. I know of games that had to rewrite the entire thing from scratch. I'd hate to do that, so I'd like some tips / guidelines to use when programming the game so that, when we move to 3D, it will be as simple as changing the code of 1-5 graphics rendering classes (or close) and the 3D graphics would run.
P.S It is a multiplayer roleplaying game (Not an MMORPG, much smaller in scope for now)
The simplest way to achieve this is to write the game in 3D, and render the views using a 3d to 2d projection, e.g. in plan or elevation. If the games internal mechanics are 2D and you try to move to a true 3d frame, you would probably better off with a rewrite. It also depends to an extent on what you mean by 3D, and whether you have an effective mapping option. For example, Microsofts Age of Empires is rendered in 3D, but would work perfectly well as a 2D plan. A first person shooter such as Half Life or Quake on the other hand would not.
Due to lack of capital and time we are
having to do our game in 2D even
though me (the developer) would prefer
if it was done in 3D. I would hate for
users to join the game, only to think
the graphics look bad and leave.
Though I suppose we just have to try
and do our best.
I don't think everything has to be 3D to look good. Well done 2D can look many times better than some standard 3D graphics. To have great 3D graphics you have to invest some serious effort. If your budget doesn't allow for this, I would rather try to put a lot effort into gameplay development.
Just think of (somewhat dated) Diablo II which is not 3D but still has some nice and good looking graphics.
It is certainly possible to build an architecture which could make it easier to change the graphical representation, but I think it will almost never be as simple as you described. Of course, if you just want 3D for the sake of 3D it could be done (instead of bitmaps you now render 3D models) but this is somewhat pointless. If you want to use 3D the player should be able to make use of it (e.g. by moving the camera, having more degrees of freedom, ...) but this would have to be considered in the whole design of the game and thus seriously affects gameplay.
You can use the GL ortho view. This will allow you to draw on screen using only 2D coordinates, if you want 3D later on, switch from Ortho to Perspective view and you have 3D, however i don't think it will help you reuse the code, since the 2D ortho view is usually done with textures, and you cannot transform a texture to a 3D mesh.
Maybe a better approach is to do everything in 3D, and setup your camera to look from above, if you do that later you can switch to 3D just by relocating the camera and making better models and textures. This options sounds nicer but gives you more work with the trade-off 2D to 3D portability without code changes.
An MVC pattern should help.
And I guess you're aware already, but have you looked at Java3D? Perhaps having a plug replaceable 3D rendering view based on that (but which is not necessarily polished and production ready) will keep you honest so that you don't wind up tied to 2D in some horrible way. It could be as simple as rendering your 2D stuff with some Z positioning added.