I am currently thinking of developing an MMORPG with a Java Client. It will be a survival sandbox game, with much wilderness.
Now I would like to know if there is any program which can get the loaded world out of the cache of the running client. (as image or something else visible) I need this because the world would be huge and it will help to hand out official maps for the game.
You might want to start by looking into VBOs and VAOs (incredibly fast way of storing vertex, normal, texture... data on the GPU instead of the CPU). I'd also recommend checking out Blender, which I'm sure you've heard of, and their easily readable format known by the OBJ extension (The OBJ extension was developed by WaveFront). There are many libraries that allow you to read these files, but the format is simple enough that you can code an advanced mesh loader in around 80 lines or less.
I'm not entirely sure what you mean by your question about whether or not you can get a world out of the cache, but if you're looking to get 3D data from an image, you can check out height maps. However, height maps are better for general terrain where you will NOT have caves. Generally things like that are loaded from a 3D modeling program's output.
This might go against what other people think, but the best way to start out is by using OpenGL to its potential. Of course this involves implementing your own matrix stack for shaders and so on, but the payoff of easy engine modifications in the end is great. The good thing about OpenGL is even though you might have Java or C++ or some language that you use, the methods remaing (generally) the same. However, the syntax does vary just like the languages do themselves.
Pyglet (Python bindings for OpenGL) is an interesting place to start if you are looking to get started with OpenGL while maintaining ease of programming and quick debugging (because it is an interpreted language) and dynamic typing helps because OpenGL can be picky about the types it accepts.
Related
I have been working on a voxel game for some time now, but all that I have really accomplished was the main menu and an Item system. Now its time to make the voxel engine. I have been searching for a while now to find some tutorials or an ebook that will teach me such, but the best i could find were someones tutorials in c++, but I am making mine in Java. I have dabbled in c++ and c# in the past but it was too difficult to translate i.e. it relied on a class that java doesn't have. What I know is that there are different methods for voxel engines, they all begin with rendering a single cube, and Perlin and Simplex noise can be used to randomize terrain generation.
If anyone could point me in the correct direction, most appreciated.
I will be checking back at least once a hour incase someone feels this thread is dead.
I'm not entirely sure what you are asking, if you are asking how to make simplex noise, implement it in a voxel engine or how to start making a voxel engine.
If you are asking how to start making a voxel engine I would recommend practising with quads first (2D version) and focus on getting an understanding for the theory. Once you are happy with your understanding you should focus on the voxel class (one cube) - it is very important to learn as much as you can from it, and then add more so you can optimize rendering as much as you can, such that hidden faces are not rendered and even vertices are shared, voxel engines can be the most wasteful renderers if not optimized!
EDIT:
Optimization can be done through many methods, The first and most important is hidden face removal, this involves removing the faces of voxels that are touching which will mean you will need to check of a voxel exists on any given side of any voxel before rendering that face (e.g before rendering the left face, check if there isn't a block to the left). Next is the rendering method, do not render each face or each group individually, group them so they can be rendered faster, this can be done by using display-lists or the more technical VBOs, these ensure the data is in the GPU or the data can be given to the GPU faster, For example Minecraft groups them in chunks of huge 16x16x128 groups and uses display lists. If you really want to reduce every single vertex in memory you can also consider using strip drawing methods (in OpenGL), these will require you to define certain vertices at a certain time in rendering but allow you to reuse a vertex for multiple faces.
Next would be understanding simplex noise, I can relate to there not being much material online for noise generation algorithms, unfortunately I cannot link material that I used as that was years ago. You can implement your noise algorithm in the 2D version to prove it works in a simpler environment and then copy it to the voxel version. Typical usage would be to use the values as heights in the terrain (e.g white=255 = 255 high).
I would recommend using Unity. The engine is already made and you can add menus and titles with just a few lines of code. All of the game creation is either in C# or Javascript which shouldn't be any huge change from C++. Good luck!
i was wondering if anyone has knowledge on the recontruction of 3D objects from live video feed. Does any have any java based examples or papers JAVA based that i could be linked to as i have read up on algorithm's used to produce such 3d objects. If possible i would like to construct something such as the program demostrated in the link provided below.
Currently my program logs live video feed.
http://www.youtube.com/watch?v=brkHE517vpo&feature=related
3D reconstruction of an object from a single point of view is not really possible. You have two basic alternatives: a) To have a stereo camera system capturing the object, b) To have only one camera, but rotating the object (so you will have different points of view of the object), like the one in the video. This is a basic concept related with epipolar geometry.
There are other alternatives, but more intrusive. Some time ago I've been working on a 3D scanner based on a single camera and a laser beam.
For this, I used OpenCV which is C++ code, but now I think there are ports for Java. Have in mind that 3D reconstruction is not an easy task, and the resulting app. will have to be largely parametrized to achieve good results.
This isn't a solved problem - certain techniques can do it to a certain degree under the right conditions. For example, the linked video shows a fairly simple flat-faced object being analysed while moving slowly under relatively even lighting conditions.
The effectiveness of such techniques can also be considerably improved if you can get a second (stereo vision) video feed.
But you are unlikely to get it to work for general video feeds. Problem such as uneven lighting, objects moving in front of the camera, fast motion, focus issues etc. make the problem extremely hard to solve. The best you can probably hope for is a partial reconstruction which can then be reviewed and manually edited to correct the inevitable mistakes.
JavaCV and related projects are probably the best resource if you want to explore further. But don't get your hopes too high for a magic out-of-the-box solution!
I would like to implement a visualisation of this video in Java as experience to help me understand all of the 'troubles' in creating visualisations. I have some experience in OpenGL, and a good understanding of how to handle the physics involved. However, if anybody knows of any good game engines that may help (or at least do some of the heavy lifting involved in creating a visualisation of the above) I would be grateful.
Also, I noticed that the linked video must use many separate jets in order to operate in the way it does. Is it likely that it was created using something a little lower level such as C? Is it possible to use a higher level language like Java to control such a system?
Honestly, if you want to implement "just that", I think using a game engine is overkill. Just implement a simple particle engine on your own and you are done.
Seriously, that problem is not so difficult, any language can be used for it. The basic principle behind it is the same as behind steam organs or self player pianos. You have an input data that shows what the pattern to play is and you advance it in a given time.
Here is how I would build the basic control system. You take a black and white image. The width is exactly as wide as the number of "emitters" and the length is as long as the pattern needs to be. You read the image and start at the first line. You walk through each pixel in that line and if the pixel is black you emit a drop and if the pixel is white you don't. You then move in a given interval (maybe 25ms) to the next line and set the emitters accordingly.
The cool thing with images is that you can simply paint them in any graphic program. To get the current time to work you render the time into a image buffer in memory, then pass that into the above code. (You even get fonts if you like...)
You can use jMonkeyEngine.
JAVA OPEN GL GAME ENGINE
I've been using Incanter for my graphing needs, which was adequate but slow for my previous needs.
Now I need to embed a graph in a JPanel. Users will need to interact with the graph (e.g. clicking on certain points which the program would need to receive and deal with) by dragging and clicking. Zooming in a out is a must as well.
I've heard about JFreeChart on other SO discussions, but I see that Incanter uses that as it's graphing engine, and it seemed somewhat slow then. It it actually fast, but perhaps Incanter is doing things that slow it down?
I'm graphing up to 2 million points (simple xy-plots, really), though generally will be graphing less. Using Matlab, this is plotted in a few seconds, but Incanter can hang for minutes.
So is JFreeChart the way to go? Or something else, given my needs?
(Also, it needs to be free, as it is for research.)
Unfortunately, general purpose graphing solutions probably aren't going to scale well to 2 million points - that's big enough that you will need something specialized if you want interactive performance.
I can see a few sensible options:
Write your own custom "plotter" function that is optimized for drawing large numbers of points. You'd have to test it, but I think you might just about get the performance you want by writing the points directly to a BufferedImage using setRGB in a tight loop. If that still isn't fast enough, you can write the points directly into a byte array and construct a MemoryImageSource.
Exclude points so that you are only drawing e.g. 10,000 points maximum. This may be perfectly acceptable as long as you only really care about the overall shape of the scatter plot rather than individual points.
Pre-render all the points into e.g. a large BufferedImage then allow users to zoom in and out / interact with this static image. You might be able to "hack" JFreeChart to do this.
If OpenGL is an option (will require native code + getting up a steep learning curve!), then drop all the points in a big vertex array and get the graphics card to do it all for you. Will handle 2 million points in real-time without any difficulty.
MathGL is fast and free (GPL) plotting library. But I never test its java interface (swig based) since I'm not familiar with java :( . So, if one can help with testing then I'll be thankful.
What should a small team choose for their first game, when they are low on time but have big ambitions? I'm an experienced programmer, but haven't done any game programming before this. My designer is very talented and artistic, he has worked with 3D about an year ago but hasn't done it since so it could take him some time to learn it again, and i'm not sure if he'll be able to do a good job at it even though his graphic design skills are terrific otherwise.
Our primary concern is to get the game finished as quickly as possible, and also to do it easily since this is my first game programming project. At the same time, we don't want to have any limitations that might hinder our progress later on, or otherwise make the game not fun in certain ways.
For example, i learnt that certain animations aren't possible in 2D such as rotation etc. I would like the ability to have the player's character be able to morph into animals and there must be the ability to shoot at the monsters, (like shooting an arrow and seeing it fly through and hit the other person). Are these things possible in 2D?
In the future, if we wanted to go from 3D to 2D, would it be possible without fully rewriting the game?
You don't have to use 3D to allow for a "3D look". Things like rotations, motions or transformations can be prerecorded or prerendered as animations or image sequences and seamlessly integrated into a 2D game.
The only thing that is not possible in 2D is to navigate freely within your "game space" (like walking or flying freely, turning arbitrarily etc.)
The main concern, however, when deciding for 2D or 3D should be the gameplay. There are games that absolutely need 3D (shooters, simulations), while others do perfectly without (adventures, puzzles, ...). So you don't actually have to decide but to choose the better fit for your game idea.
Personally, I'd avoid using 3D in your first game attempt if possible to eliminate all the constraints and hassles that come with it.
When using 3D you typically have to decide for a 3D framework which will heavily influence your software design, game look and feel and overall performance. Java3D for example brings a complicated class structure that you have to adjust to.
And a lot of effort goes into making that 3D stuff work at all. Simple things like rotating a square evolve into matrix operations incorporating quaternions. Every effect has to be done in the complex 3D world, and in such a way that its 2D projected look turns out the way you intended it.
Not to mention that 3D applications often suffer a very stereotypical look that is very hard to overcome.
In 2D, you literally avoid one dimension of complexity. You do everything exactly the way it is supposed to look, you can use standard graphic applications and open file formats to simplify the workflow between the designer and the developer. And a lot of pseudo-3D effects like parallax motion, depth of field and prerendered artwork allow for astonishing looks in a 2D world.
You should go 2D. You have stated several reasons to take this approach:
You are a small team, and 3D takes
more work.
It's your first game, so
you need to keep it as simple as
possible, or the project may fail
(you are exposed to a lot of risk!)
The 3D artist needs to relearn the
crafts!
You have a (seemingly
self-imposed) deadline.
Etc.
3D takes a lot of time, and it will be best invested in improving the rest of the game. Think of all the awesome games that existed previous to the 3D era.
Do not fear to accept restrictions: whilst 3D might give you lots of possibilities, 2D may result in more creative work!
I would considre a couple of factors:
Is it a mobile or applet game? If so, I would go for the 2D version. It's very hard to get 3D right under those circumstances.
What is your designer more comfortable with? Can he more quickly model, texture and animate a characte, rather than creating all the sprites needed for a 2D character?
Tool support. What output formats can your designer produce in both 2D and 3D? What kind of formats is the middle ware, you are going to use, able to handle? Can your 3D engine load, or at least convert, .obj files (just an example, could have used any other model format.)?
Even if you would like to go the 3D way, you can still make a 2D game (sometimes called 2.5D or pseudo 3D). Also there are some nice third party frameworks out there for both 2D and 3D stuff in Java. You don't have to use java2D/java3D.
Given your requirements, I'd choose 2D . You have more tools to choose from . more available talent to contract for artwork .. and the asset pipeline is simpler. In the end it's going to be all about how good the game is on its own merits. 3D is sometimes more difficult for your average user to figure out.
Depending on what you are conceptualizing, rotations and morphing oughta be quite possible in 2D. You might even consider a pseudo-3d approach ala Paper Mario ..
Moving from 2D to 3D should not be a major issue if you design your code structure with that in mind. ..
I would recommend 2D as well. A 3D game will be more graphically demanding on the user's computer, and many things like collision detection are significantly simpler in 2D. You could even make your character models in 3D and then project them down to 2D to make the sprites for the actual game. Puzzle Pirates (http://www.puzzlepirates.com/) takes this approach and it works very well in terms of consistent lighting, etc.
I think writing a 2D or a full 3D game needs a completely different design approach what cannot be modified easily later: SUN provides a Java 2D API and a Java 3D API for the two development decisions.
For the first game with tight deadline I would vote for a 2D version. If the gameplay is interesting and the design is nice then the 3D is not a must.