Hi everyone, this is my 1st game in JME,
Please click the link to view the video: http://www.youtube.com/watch?v=tzU84otHVWw
This game is not yet finished, I am open to your suggestions…
2 Likes
Good start. Make it cool and get fun! 
Nice start, but the gun feels a bit « Spritish » if you know what i mean and maybe it is but i prefer real 3D objects for weapons, my opinion aniway nice start.
Gratz! Its fun, isn’t it?
Thank you guys for your nice comments…
I like it! What you could do is make the gun less, as mathieu said, Spritish. I would recommend using an actual Model for the gun. The sky could probably be less attention-seeking, other than that, I like it!
This reminds me… I was thinking the other day it would be really good if we had simple demos of FPS controller with gun mesh and weapon bob, 3rd person controller with cursor decal etc. Has anyone made anything like that so far? I have a 3rd person control I might be able to make into an example, not done an FPS before though.
Sweet!
I am currently working on an FPS game and that is exactly my goal. @monkeychops , I intend to make weapon bob, dynamic cross hairs, animations, weapon sway movement as well as camera. I am deciding on whether i am going to use ray casting for the bullets or actual objects. THe objects move too fast for reliable collision, but for rays,I have a method that calls shoot() when I create a ray and get the intersection. The problem is, is that it only generates the rays so fast and it cant keep up with a rapid fire gun. It gets like 2 per second. Do you have any suggestions how to make the rays produce quicker because my goal is to make a really dynamic, solid FPS game, or at least an FPS engine which other people can use and make online Muliplayers. I dont know how I will make the gun lung left, right, up, down when I move the mouse quickly, but I will work on it. The ray system I am using is a little variation of the tutorial for rays. What do you recomend to make it churn out rays quicker? once I get the ray system working solid, I can work on graphic and animation.
@jrlowe awesome, sounds like you have a good idea what you want to achieve.
I am not an expert on JME really, but 2 rays per second seems quite wrong to me… That’s only 1 ray every 30 frames or so… you should be able to do quite a few rays per frame.
The picking example here would be roughly what you need to find your target https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:beginner:hello_picking
@monkeychops, that tutorial is indeed the one that I implemented into my game. I call the method to create the ray and leave the red mark every time the simple update is called as long as the mouse button is down, but the red mark that shows where I am hitting is quite slow. Im getting around 200 FPS but for some reason it does not want to work fast. It does the System.println ever time it shoots and it is literally really slow. Have any ideas what is causing this problem?
You have something odd in your world. In HeroDex when people are dragging cards around etc there is a ray being fired every frame to track the mouse action and it has no noticeable impact on frame rate at all - even back before I turned on the frame rate limiting and it was getting 100s of fps.
Hi
It would be better if the weapon moved a bit when shooting. You can keep the sprite if you really want to preserve the style as is. Otherwise, you can find a few free nice models online and convert them to a format suitable for JMonkeyEngine 3.
@jrlowe it is difficult to explain it to you very shortly but I use rays only as a first step in my blueprints. There are tons of things to do to get reliable collision detection in a first person shooter. I achieved most of the things you talked except moving the weapon when the player moves, I just move it when reloading, shooting, picking it up, … I spoke about that once in my blog here in the subsection entitled “Improvement of collisions detection”. You need spatial partitioning in order to avoid performing computations on the whole level. You need to use several picking methods to avoid performing heavy computations when the bullet doesn’t go through the bounding volume of the tested mesh. You need some maths and physics if you really want to miss no collision, including inverse cinematics.
@gouessej , I recently took a break from the FPS engine and I would like to know how you positioned your gun and attached it. A cam node? also, I am having trouble exporting simple animations because the are not present under the scene composer. I succesfully exported and animation once a while back and it added an animation control. An the reason I am doing rays for shooting is because im pretty sure that is what modern games use, (but they cast multiple rays and use calculations) and it is much faster than dealing with small rigid bodies and having 1000’s of objects flying around.
1 Like
@jrlowe You can use a node that simply follows the camera, com.jme3.scene.CameraNode should work. You can attach your gun to this node and set a translation to it so that it’s on your left or on your right.
I use MD2 (and MD3 soon) animations in my game, they were supported in JMonkeyEngine 2 but not in JMonkeyEngine 3. I don’t think I can help you.
I’m alone on my project, I don’t try to use trendy means to solve my problems if I’m not sure they do. Why are you sure that modern games use rays? Maybe my explanations were not easily understandable.
At first, just throwing a ray in the whole scene (as is, without sorting) is a bad idea because it can require a lot of time and you still have to save all collisions and compare them to find the real collision and if you don’t do that, if you just pick the first one, it will be buggy. For example, if 2 guys are aligned in front of your gun, you may kill the wrong guy instead of the closest one. You can spend less time in the software picking by splitting your scene into smaller parts (spatial subdivision) and then you can start throwing your ray in your “sub-scene” first.
Secondly, you can use a less accurate but very fast picking method in order to use a more accurate one (but slower) if and only if it has a chance to be useful. For example, perform a test on the bounding box before performing a test on the mesh itself.
Thirdly, rays are fine for … rays Lasers. However, they aren’t good for “slow” (not instantaneous) and/or large projectiles, typically rockets. You can use multiple rays but it works only if testing collisions at discrete times is enough which is the case only with static enemies. As soon as your enemies move, the tests at discrete times may lead to miss some collisions or to find wrong collisions. That’s why inverse kinematics are useful, it allows to check whether your bullet has just collided between 2 discrete instants.
Spatial partitioning has been used in games for decades, bounding volumes for collisions too and the more advanced method I mention in my blog isn’t new.
I have done some reasearch and it seems like most people making these games now cast a series of rays to calculate the “bullet” path. There is also a method to get the closet collision so only the closet object will be detected if you don’t allow the rays to penetrate some materials. Hey, I could be wrong, there are most definately gonna be other better ways, this is just a way I have seen a lot.
<cite>@jrlowe said:</cite> I have done some reasearch and it seems like most people making these games now cast a series of rays to calculate the "bullet" path.Maybe you're right but most of people simply don't share their findings.
<cite>@jrlowe said:</cite> There is also a method to get the closet collision so only the closet object will be detected if you don't allow the rays to penetrate some materials.That's what I mentioned in my last post, you can sort the candidates before throwing a ray or throw a ray first and compare the collision results to find the closest object. The materials that can't be penetrated allow to skip some candidates but you have to find which ones are between the gun and the concerned material(s).
<cite>@jrlowe said:</cite> Hey, I could be wrong, there are most definately gonna be other better ways, this is just a way I have seen a lot.Actually, what you mentioned is very vague, these are just a few hints. Yes, you can use several rays for a single bullet but the bigger the projectile is, the worse this approach is, using the equation of a cylinder or a few triangles is more efficient than using tons of rays. I started programming games for fun in 1999, it would be nice if you didn't have to spend months in looking for a nice solution and to do the same mistakes than me, that's why I write some articles and I release my source code. Trials and errors helped me in understanding the limitations of the known "methods" but I think it can be discouraging and you can see that there are a very few FPS written in Java. If you really think that there are "better" methods, just try them but some of them will lead to what I mentioned in my last posts, miss of collisions, wrong collisions, lack of scalability, incompatibility with shaders on some hardware (especially build-in OpenGL picking) ...
I guess I will try your method because you asid you tried other methods and they didn’t work well and if you got yours to work, hey, I’ll try it!
Is there anywhere I can find your source code for this type of approach?
@jrlowe I advise you to read this paragraph to understand what I mean about continuous collision detection: