Tim Shea

Just to expand a little bit on Rick's (correct) response, in order to provide networked multiplayer to your games you would need a third party library. Because Leadwerks is C++ based, you would have your choice of any number of robust, high performance libraries to choose from, but there is a substantial amount of work involved. However, keep in mind that you can build local multiplayer games without any additional components, and local multiplayer is best multiplayer

Looking back at the Kickstarter, Oculus support was just past the level reached. That being said, even if Josh decides not to integrate it himself, to my knowledge there are only two things needed to use the Rift, the skeletal model which is updated based on the headtracker, and a custom projection matrix. If the hardware turns out to be worthwhile, someone here will almost certainly put something together.

Since you are just starting out, an excellent option would be to download Blender and work through (at least a few) basic modeling, texturing, animating, and exporting tutorials. 3D game art is a huge subject, but even if you plan to focus on game design or technical development, having a reasonable understanding of the asset creation process can be tremendously useful. Plus, you might produce some placeholder-quality assets in the process. Edit: And it's pretty fun in its own right!

Keep in mind, Evayr's use case for this approach was that the laptop which he is temporarily using to develop is too slow to run Leadwerks properly. It is an impressive improvement and certainly worth considering for some game types, but in general game engines use physics systems for good reasons.

A lot of AAA games will use an animation engine that blends together a strafe animation and a run animation depending on the angle. This requires really good assets though. From the videos I could find, I think this is what Gears does, though it also doesn't let you see the character's lower legs, which might minimize the slidiness. Gears does an excellent job of giving the character movement a heavy feel, so that would reduce the slidiness too. Games with really "tight" controls, like competitive shooters, might instead use the turret-style torso, but honestly that looks horrific to me. Games that aren't shooters (and don't need a reticle) can just rotate the character entirely in the direction they are moving.

There's already a leadwerks wiki: http://www.leadwerks.com/wiki/index.php?title=Main_Page It would be awesome if that was cleaned up and updated for LE 3.X, because then there would only be one outdated source of Leadwerks documentation clogging google searches, instead of two.

Evayr, just keep in mind that there will be position offsets applied and findpath should work well. This has the added benefit that if you have squads/collections of units, you should be able to share paths (thus reduce pathfinding cost) using formations.

Yep, that worked. I found that the precise destination point (plus the y bias of the character I think) is actually in the path, but not the last point. So, if I call find path with the point (5, 0, 5), the second to last point is (5, 1.25, 5), but the last point is (5.06##, 1.25, 5.039##). I'm not sure why this is. In any case, the skew on the final point is small enough that an epsilon of 0.1 ignores it. This is my implementation (reduced to the general form), if anyone is interested: bool PathExists(World* world, Entity* entity, Vec3 destination, float epsilon = 0.1) { // Based on Josh's input and a quick test, this seems to work if (path != NULL) { Vec2 pathBackXZ = path->points.back().xz(); Vec2 pointXZ = point.xz(); return (pathBackXZ.DistanceToPoint(pointXZ) < epsilon); } else return false; } Thanks Josh.

Actually I just tested with a point that was completely outside of my level geometry (as opposed to just inaccessible) and FindPath did return NULL, so I stand corrected. However, my question still stands for obstacles, etc. If I set the destination inside a pillar for example, the entity will just endlessly try to walk into the pillar.

I can't seem to find any documentation for the NavMesh class, specifically the FindPath function. I need to check whether a path exists from an entity to a given point before invoking the GoToPoint method, and I was hoping I could use the FindPath method to do that. I thought perhaps FindPath would return NULL if a valid path did not exist, but that doesn't seem to be the case. Does anyone else know how to check if the path returned is valid, or is there some better way to do what I'm trying to do? Thanks!

Another thing to keep in mind is that if you plan on reusing elements of game code across multiple games, wrapping your classes in a namespace is a very good idea. Namespaces keep your class names from polluting the global context.

Wings by Daedalus What is it? An artificial intelligence library for use in games. A set of tools to help you incorporate high quality intelligent behavior into your games without the headaches. Who are we? A team of five Computer Science majors at CSU Sacramento sponsored by Josh of Leadwerks Software and advised by Dr. Ahmed Salem, Associate Professor at CSUS. What do we want? Game developers (that's you!) to share your experiences and priorities with respect to gameplay and artificial intelligence. Your feedback will help us shape the Wings library. Please take our six question survey below: http://www.surveymonkey.com/s/MTFKQ9G For more information on the team and the project: http://athena.ecs.csus.edu/~daedalus/ If you have any questions or concerns prior to taking the survey, please feel free to post them here.

The kickstarter is looking fantastic right now, nearly 60% backed with 38 days to go. It does specifically include the OpenGL 4 renderer, whether that means it's going to be Leadwerks 3.1 or not. However, Josh hasn't announced any stretch goals yet and has specifically said he is open to suggestions. So, if graphics are your priority and you would most likely purchase 3.1 anyway to get the upgraded renderer, why not back the kickstarter, get Linux and GL 4, and get to provide input for the stretch goals, if any? Of course, I'm trying to convince you because I'd love to get some extras, but we'll ignore that part

Yougroove, you're definitely right that not all devs need these advanced features and not all devs will want to use the same ones. I think the best solution for this is to provide an add-on component that provides first class integration with LE3 without any overhead in cases where it isn't wanted. It shouldn't be that difficult to manage. Rick, I agree that a state machine implementation would be a substantial benefit to devs. Its probably the one AI technique that is so ubiquitous in games that there really isn't a good argument to omitting it from an AI suite. Perception is pretty tricky to manage in a game-agnostic way because the things and types of things that can be perceived will vary so much, but steering is also a great candidate since it's well understood and widely used.

If you attach the camera to a physics object, like a small sphere, and then apply a spring force (proportional to distance) towards the target position, the physics engine can handle this for you. More complex collision shapes can also keep the camera a minimum distance from terrain, or ensure an unobstructed line of sight to (or beyond) the character.

Friction is working correctly in the video you posted. If there was no friction, under a linear applied force, the ball would slide without rotating, under an applied torque, the ball would rotate without moving. Since your ball is both rotating and moving friction is working. What you are looking for is rolling resistance, and I'm not sure how that is applied in LE. With regards to your wall collisions, the problem is that the restitution is relatively high. This setting allows for energy to be absorbed during collisions to dampen oscillating interactions. A squishy ball like a soccer ball should have a moderate restitution, a bouncy ball and a solid ball like a billiard ball should both have low restitution. Again, I'm not sure exactly how that's set in LE, but I'm sure there is a setting.

You probably don't want to take the cross product of the position and the velocity, but rather, the delta between the collision position and the object position crossed with the velocity. That is possibly also why position is given as a float* rather than a Vec3, as position is a point not (directly) a vector.

Hello everyone, I'm a new user and I'm trying to get familiar with the engine. Specifically, I'm pretty interested in what kinds of advanced gameplay and mechanics can be (or have been) implemented. This is kind of open ended, but if anyone feels like discussing the sorts of things they've done or seen, I'd appreciate it. Also, things you've tried to do or considered but couldn't? Thanks!