Jump to content

Josh

Staff
  • Content Count

    16,320
  • Joined

  • Last visited

Everything posted by Josh

  1. Josh

    VSCode Lua debugger

    Okay, my modules are loading now but they cause LuaJIT to crash.
  2. Josh

    VSCode Lua debugger

    I compiled LuaSocket with LuaJIT in x64 mode but I am getting "The specified procedure was not found" when Lua tries to load the DLL.
  3. Josh

    Bone Attachments

    This library might be useful for simple IK: https://github.com/TheComet/ik
  4. Another update is available, adding this and dynamic navmeshes.
  5. New beta is uploaded, with dynamic navmeshes.

  6. It actually accepts separate values for all three axes. I am using zero for X and Z and 0.35 for the height, which seems to work, but I will add a radius parameter for XZ and an optional height parameter.
  7. In this example I am doing a regular camera pick and then checking to see if that point lies on the navmesh. I do not have the radius value exposed because I didn't see a point to that, but if you want I will add that in as an optional parameter.
  8. Yeah but it can still load LE4 maps.
  9. Considering a dark theme for the forum.

  10. A new update is available for beta testers. This adds navmesh pathfinding, bone attachments, and the beginning of the Lua debugging capabilities.New commands for creating navigation meshes for AI pathfinding are included. NavMesh Pathfinding In Leadwerks Game Engine 5 you can create your own navmeshes and AI agents, with all your own parameters for player height, step height, walkable slope, etc.: shared_ptr<NavMesh> CreateNavMesh(shared_ptr<World> world, const float width, const float height, const float depth, const int tilesx, const int tilesz, const float agentradius = 0.4, const float agentheight = 1.8, const float agentstepheight = 0.501, const float maxslope = 45.01f); You can create AI agents yourself now: shared_ptr<NavAgent> CreateNavAgent(shared_ptr<NavMesh> navmesh, const float radius, const float height, const UpdateFlags updateflags) Here are some of the NavAgent methods you can use: void NavAgent::SetPosition(const float x, const float y, const float z); void NavAgent::SetRotation(const float angle); bool NavAgent::Navigate(const float x, const float y, const float z); New capabilities let you find a random point on the navmesh, or test to see if a point lies on a navmesh. As @reepblue pointed out, in addition to AI this feature could be used to test if a player is able to teleport to a position with VR locomotion: bool NavMesh::FindRandomPoint(Vec3& point) bool NavMesh::IntersectsPoint(const Vec3& point) You can call Entity::Attach(agent) to attach an entity to an agent so it follows it around. You can even create multiple navmeshes for different sized characters. In the video below, I created one navmesh for the little goblins, and another one with different parameters for the big guy. I created agents for each character on the appropriate sized navmesh, and then I created a big AI agent on both navmeshes. On the navmesh with big parameters, I use the regular navigation system, but the big agent on the little navmesh gets manually repositioned each frame. This results in an agent the little goblins walk around, and the end result is mixing of the two character sizes. The current implementation is static-only and will be built at the time of creation. You need to call Entity::SetNavigationMode(true) on any entities you want to contribute to the navmesh. Physics shape geometry will be used for navigation, not visible mesh geometry. I plan to add support for dynamic navmeshes that rebuild as the level changes next. Note that by default there is no interaction between physics and navigation. If you want AI agents to be collidable with the physics system, you need to create a physics object and position that as the agents move. This gives you complete control over the whole system. Bone Attachments To improve speed bones are a special type of object in Leadwerks Game Engine 5, and are an entity. Bone attachments allow you to "parent" an entity to a bone, so you can do things like place a sword in a character's hand. You can read more about bone attachments here: Lua Debugging in Visual Studio Code The beginnings of our Lua debugging system are taking shape. You can now launch your game directly from VSCode. To do this, open the project folder in VSCode. Install the "Lua Debugger" extension from DevCat. Press F5 and the game should start running. See the .vscode/launch.json file for more details.
  11. Okay, LE5 beta now has static navmeshes. I tested with a loaded level. We have everything we need to start creating this.
  12. This will serve as our first test map for bot movement. I will have basic pathfinding out soon: testmap.zip
  13. I was thinking about power-ups, and if you have room full of them , you don't want the bot randomly going to each one. What you should do is first check for all powerups within a certain radius of the player, then trace a path to them with FindPath(). If the total path length is much longer than the direct distance, discard it, because you can assume it is out of reach or on the other side of a wall or something. Find the nearest powerup, by path length, not by simple distance, and move to that. Once you get there, repeat the process. This will make the AI scoop up powerups in a manner that looks more natural and is more efficient than just randomly going after them.
  14. The power-up situation is interesting because it is a subroutine. Once that task is complete, the player goes back to whatever they were doing before, whether it is patrolling or fighting. Pathfinding will soon be available in the new engine so at that part we can start experimenting with this. There are two ways I can think of that we can handle the patroling. Recast has a FindRandomPoint() function I am integrating. So patrolling could just amount to find a random point in the navmesh, go there, then find another. The other way is to add "breadcrumbs". They don't have to be linked together and they don't require a clear line of sight, but they give the bot some points of interest they can travel around to. Perhaps powerups, weapons, and breadcrumbs could all be treated as potential destinations. Ideally I would like to avoid a situation where the AI gets to their destination and then doubles back on their path, because it would just look unnatural. But I don't want to make things to complicated either.
  15. The beta includes an example of a coroutine sequence. I think maybe this could be developed into the sort of system you are talking about. The base routine would be patroling, which consists of: Choose a random point on the map. Navigate there. Repeat. There are three events I can think of that would interrupt this behavior. Bot sees a powerup they like. Bot sees a player they don't like. Bot is shot by someone who doesn't like them. Each of those events would cause the behavior to branch off into a different coroutine sequence. Perhaps the entire bot AI can be defined in the Start function as a series of coroutines, and the Update() function won't be used at all.
  16. One player class? Yeah. I'm aiming for 1000 lines of code, maximum, and to keep it as simple as possible. The idea is to make a core game that is very easy to understand, and then let people go crazy adding whatever they want to it.
  17. Josh

    Bone Attachments

    The physics system is an IK system, and could be used for character joints. It's not easy, but renaming a bunch of commands would not make it any easier.
  18. Josh

    Bone Attachments

    No plans for this.
  19. Josh

    VSCode Lua debugger

    Oh god, it's not compatible with 5.1 nor is it compatible with 5.3. What are these guys thinking?
  20. Josh

    VSCode Lua debugger

    I don't know what Lua file is supposed to get executed.
  21. Josh

    Bone Attachments

    Bones can also be positioned with code, using many of the same commands as the entity system (although they are not the same code internally).
  22. Josh

    Bone Attachments

    In Leadwerks Game Engine 4, bones are a type of entity. This is nice because all the regular entity commands work just the same on them, and there is not much to think about. However, for ultimate performance in Leadwerks 5 we treat bones differently. Each model can have a skeleton made up of bones. Skeletons can be unique for each model, or shared between models. Animation occurs on a skeleton, not a model. When a skeleton is animated, every model that uses that skeleton will display the same motion. Skeletons animations are performed on one or more separate threads, and the skeleton bones are able to skip a lot of overhead that would be required if they were entities, like updating the scene octree. This system allows for thousands of animated characters to be displayed with basically no impact on framerate: This is not some special case I created that isn't practical for real use. This is the default animation system, and you can always rely on it working this fast. There is one small issue that this design neglects, however, and that is the simple situation where we want to attach a weapon or other item to an animated character, that isn't built into that model. In Leadwerks 4 we would just parent the model to the bone, but we said bones are no longer entities so this won't work. So how do we do this? The answer is with bone attachments: auto gun = LoadModel(world, "Models/gun.gltf"); gun->Attach(player, "R_Hand"); Every time the model animation is updated, the gun orientation will be forced to match the bone we specified. If we want to adjust the orientation of the gun relative to the bone, then we can use a pivot: auto gun = LoadModel(world, "Models/gun.gltf"); auto gunholder = CreatePivot(world); gunholder->Attach(player, "R_Hand"); gun->SetParent(gunholder); gun->SetRotation(0,180,0); Attaching an entity to a bone does not take ownership of the entity, so you need to maintain a handle to it until you want it to be deleted. One way to do this is to just parent the entity to the model you are attaching to: auto gun = LoadModel(world, "Models/gun.gltf"); gun->Attach(player, "R_Hand"); gun->SetParent(player); gun = nullptr; //player model keeps the gun in scope In this example I created some spheres to indicate where the model bones are, and attached them to the model bones: Bone attachments involve three separate objects, the entity, the model, and the bone. This would be totally impossible to do without weak pointers in C++.
  23. Has anyone been able to use the Lua debugger VSCode extension by "devcat"? I am trying to get this working. It requires luasocket and I am not sure how to set that up.
×
×
  • Create New...