Hello everyone,
I am looking some pointers on how I should go about with prevent models from passing through each other, and also making sections of the terrain impassable. The setup I am running right now is a very simple flat terrain created using the scene editor and I have a model inside this terrain(which is added within the code rather than right away with the scene editor) which is assigned to a control for its moving with the following code inside the controlUpdate()
protected void controlUpdate(float tpf) {
if (moveSwitch) {
move = tpf * 5.0f;
vectry = unit.getWorldTranslation();
vecmove = location.getWorldTranslation();
remainingDist = unit.getLocalTranslation().distance(vecmove);
if (remainingDist > 0.05f && !unit.getWorldTranslation().equals(vecmove)) {
vectry2 = vectry.interpolate(vecmove, move / remainingDist);
unit.lookAt(vecmove, Vector3f.UNIT_Y);
unit.setLocalTranslation(vectry2);
} else {
if (remainingDist <= 0.02f && !unit.getWorldTranslation().equals(vecmove)) {
unit.setLocalTranslation(vecmove);
}
}
if(unit.getWorldTranslation().equals(location.getWorldTranslation())){
moveSwitch = false;
}
}
}
With this code, the unit always walks in flat direction (i.e y always = to 0), and goes through anything in the scene located on the terrain?
I somewhat understand this code but I am at loss as to what I should do next. Is my approach wrong? Should I be doing all this type of stuff through the terrain editor, or doing everything through the code (i.e do no load a scene file, but rather setup everything with code)? I looked into bounding boxes and did not know if that was what I needed, or how to use them.
Any help would be greatly appreciated.
-hardboss
@hardboss said:
Hello everyone,
I am looking some pointers on how I should go about with prevent models from passing through each other, and also making sections of the terrain impassable.
There are number of ways to do this. If your using JBullet, there is a tutorial on setting up collision detection... if not, using 7-point ray casting (up, down, true north, south, east, west and the seventh being in the direction the object is moving) will do the trick fairly well. Of course, you'll need to write some rudimentary physics... taking in to account object size, gravity, among other things.
For impassable areas, either the angle of the slope will stop a physics object (or custom implementation of physics)... or you could add geometries with a completely transparent, unshaded material to the collidables portion of your scene graph (I believe ghost nodes are used for this) if the object would otherwise be traverse-able.
You could also if the world logic is 2d use a wihte black image, and just translate te x,z coordinates to that traverseable map to see if the next wanted position is valid.
Hi, thanks for replying so fast.
The type of game I am implementing is based on the Heroes of Might and Magic franchise. I donât know if youâre familiar with these types of games, but they have virtually no physics in them and I would like to avoid them as well. The game is turn based, and the type of movement that is required is very simple - You get a maximum amount of moving points per turn to do all of your movements across the map. The reason why I am asking these questions is because I want to start working on a path creation/finding algorithm, where I select a unit and click on another location on the map, and it will display a path to that location and the user will be able to complete the path or not. But before I can do that, I need to make sure the foundation of bounds is nice and solid.
This is my first medium sized game project - Sorry if I am misusing terminology or if the answer is obvious.
-hardboss
Itâs 3d.
Avoidance is pretty easy, if youâre using tiles, you just need to make sure you keep track of if a tile is âoccupiedâ, and factor that in when doing your pathfinding (occupied tile cost becomes POSITIVE_INFINITY). It starts to get more complicated if you have lots of units all moving at the same time âŚ
WIP Hex Engine - Deadlock Resolver - YouTube
... but if you're going turn based you shouldn't need to worry about that.
If you're not dealing with tiles, things can get a bit trickier, you could have a look at MonkeyZone and see how the pathfinding is handled in there, might be a good starting point.
Hmm very interesting approach with the tiles (Again Iâm a novice in design patterns for video games). Like I said before, I am generating my terrain within a scene, which I do not think is tiles based.
I am thinking that the type of game I am building could be a candidate to the tiles terrain. Do you have any pointers on how to go about with this in terms of implementation? Or have any references I could read over? (I think my base design or approach might be wrong.
There is a steering library in the jmonkeyplatform-contribution/AI project. Steering allows entities to avoid other entities, follow them, stay near them, flee from them, etc. It isnât very documented yet, but it is quite straight forward.
For navigating terrain you probably want a Nav Mesh. The SDK has a navmesh generator built into it (you need the latest nightly from Trunk, although it might be on the stable Beta branch now, canât remember). There is a navMesh pathfinder (a different piece of code) available in the Monkey Zone source code, free to use.
Both of these approaches are non tile based.
Wow thanks Sploreg, great stuff. It generated the mesh exactly how I needed it.
However, I donât know how to access the mesh that is generated in the scene generator within the code, let alone how to use it but I will take a look at MonkeyZone source code for the actual path creation. Is there any documentation on the usage online? I only found one other thread where you were the major contributor to the topic. Anything would help tremendously (as a side note, weâre going to give our project to the community anyhow as soon as weâre done with it - Itâs for a year long game development course).
I have a feeling iâm missing something about the development process while using the SDK. My approach was the create the world(all the non-interactable stuff) in the scene editor, then load the scene editor into code and then load all the other spatials that you can interact with (i,e they are associated to controls such as âMoveUnitControlâ) via the code. I know that you can add controls through the scene editor, but something about me was telling me its incomplete and I shouldnât rely on it too much for the actual game logic and things as such. Am I thinking wrong?
There isnât a guide on how to use MonkeyZone, it is more of a code example. In it there is a nav mesh pathfinder (canât remember the actual class name, just search for âpathfinderâ), but it will take in the polygon mesh that the SDK generates and build up a data structure from it.
Hooking the world up to your game logic is often a tricky part, that takes a few tries to get right. Currently the SDK lets you attach a custom control to any spatial (right click, add control, custom control, select from the list). It scans your projects for any Controls and lets you add them to your spatial. This gives you a hook into your game (but possibly through a MyApp.getApp() static call). What I am currently doing is giving all of my entities that âdo somethingâ a flag in the UserData field of the spatial, letting my app know that this spatial object is part of something that âdoes stuffâ. I have a post loading step that scans all the spatials in the scene for this flag, and links them up accordingly with their correct config files. I have some strange requirements so my way might not be the best for you. But start by adding some custom controls to your spatials.
Remember that controls is where all your logic and update loop operations should live; relevant to a spatial.
Oh man, I wish I could put more thumbs up. Many thanks for the great help. You couldnât of phrased your explanation better, I get the whole picture now.