Josh

I don't see any reason it wouldn't work, but I don't know any specifics about Onlive's servers.

You're going to have to be the top 1% of indie developers to do that.

Sorry, I have seen some timing methods in C++ that were wildly inaccurate. I don't remember if clock() is one, but I know I saw some that gave results with errors of 100 millisecs or more. In C++, I use timeGetTime() on Windows. This only occurs if you call Flip(1).

They probably have some simple requirements, but I doubt there's anything much to worry about. Due to the nature of their system, I don't really see them ever opening up to indies much.

I was thinking this morning how Apple has influenced my life and the company Leadwerks. You might ask why I am talking about this, since we are only now coming out with our first product for any Apple operating system. Well, before Windows existed, back in the 1980's, this was my first computer: The first "game" I ever made was in Macintosh Paint. I drew a road from a top-down view, with barriers randomly placed on either side. I drew a race car, zoomed in the image, and used the selection lasso to cut it from the page. By dragging the selected pixels to the top of the screen, I could make the image scroll, causing the road to move beneath my car, and I had to move the mouse left and right to avoid the barriers. (I tried to forget the order I had placed them in.) I also used this machine to paint my first textures, before texture mapping was invented. I drew sides of buildings with variations with windows and doors. Although the monitor displayed only two colors, black and white, you could approximate gray by stippling pixels. There was also the option to use colored pencils once you printed out the images. I would print these on paper and then construct buildings out of paper with them, a precursor to the work we would do later with CSG modeling. My uncle also wrote some of the early Mac games, including "Save the Farm", and "Hot Air Balloon". I actually have the original apps and amazingly they run on my 2010 iMac with an emulator. Last year, as we began development of Leadwerks3D, I bought my first Apple products in my adult life, including a 27" iMac, iPhone 4, and iPad 2. I've been really impressed with the quality and design of these products, and although I am not quite sure their OpenGL 3.2 drivers are there yet, I think high-end graphics on Mac has a good future. (I had it confirmed from another developer that OpenGL 3.2 MRTs do work on Mac, so I still have some experimentation to do. I suspect the multisampled texture format I am using may be causing a problem...) Ever since I started putting out videos of our new engine running on mobile devices, there has been a tremendous response from developers, both inside the Leadwerks community and beyond. I think the rise of the iPhone as a gaming device was sort of accidental. They had a device that could run apps, then they discovered people were playing games more and more on them. However, all indie game developers should be grateful Apple developed a thriving ecosystem for third party developers, because without them I don't think we would see the resurgence of indie game development like we have. Even if you are developing primarily for Android, you have to admit that platform would not be as good as it is without the influence of iOS. In a sea of mediocrity, one man cared about his work enough to make sure that everything his company put out was a cohesive reflection of his tastes and standards. I don't agree with every decision Apple has made, but I have a great deal of respect for the way Steve Jobs had a coherent vision and brought it to life, instead of just blindly reacting to what he thought would make money. He rejected the "low quality, low confidence, low price, low effort" approach the rest of the tech industry has taken, and won. Without him I think Leadwerks would be without what I think will be our most successful platforms, and indie game developers would not have the same opportunities that are present today. We should all be grateful for that. http://www.youtube.com/watch?v=uwOjsYNcUW0

I may call the AI class an "Actor" and switch our Actor class to something else, like "Modifier" or something. Maybe the class functions would look something like this: Actor::SetTargetEntity(Entity* entity, int mode, float distance) Makes an actor follow an entity. distance When the actor gets this close, it stops following. mode: 0 - always follow 1 - move to last visible point 2 - stop when line of sight is lost 3 - stop when a line of sight is acquired (for projectile enemies) Actor::SetTargetPosition(Vec3 position, float distance) distance When the actor gets this close, it stops following. You could do all this manually in script, but my guess is there are ways I can make it more optimal if it's built into the engine, like staggering the updates or running it on a separate thread. Maybe the actor would have Lua functions like this: function actor:TargetReached() function actor:TargetLost() function actor:TargetAcquired() function actor:GotBoredAndTookANap()???

Try calling Millisecs() and see what those values give you.

That's simple? I really doubt you are asking for code like that, since I can't even make heads or tails of it. I think you just want a finished game you can play around with, which is fine. Let's just be honest about what we're talking about and call it what it is.

Regarding the AI following: Normally the player moves through a map and alerts enemies when they come within a certain range and have a direct line of sight. You don't normally have a mob of enemies chasing a player through a map. Enemies should be faster than the player, so that they are forced to deal with them as they are encountered. So what would normally happen is you would move to an area, encounter some enemies, be forced to fight them there, then move on. Since enemies would be placed around the map in different locations, they normally would not all be coming at you from one direction.

There are some rather expensive commercial alternatives. The speed doesn't really matter, at some point, because ideally the processing will occur on a separate thread and the engine won't wait for the results.

Here's what I'm thinking: -Melee enemies stop when they reach a certain distance. Zombies, anything with a sword, anything that bites. -Enemies with projectile weapons should stop on two conditions. 1. A clear line of site to their target exists. 2. They are within firing range (consider a crossbow or something with a high arc). The second type of enemy might retrace their steps to back away from the player when not firing, stopping when the line of sight is broken. This might be a good approximation for running for cover, then coming out to shoot, then hiding again.

Crowd navigation is built into Leadwerks3D. You just set a destination, and your characters will automatically travel wherever you tell them to go. I think having navigation built into the engine will give us better results than a third party add-on would. We can automatically recalculate sections of the map that change, AI script functions can be called when certain events occur, and the code to control characters is extremely simple.

That's a function of the player radius. It chooses the shortest path, so the player will come very close to corners when they go around them. The scale of the obstacles in this test scene is quite big, so the player radius is very small in comparison.

There's basically no API to worry about. You just have a command to find a path, and don't have to worry about anything else. As far as controller movement goes, I think I'll just leave that to the user, and have some example scripts. It's very easy to just point it to the next node and go.

The reason it uses tiles is so that if a single tile changes, you can recalculate only that data, instead of the whole map.

I fixed our AI navigation problems and got pathfinding to work using navmeshes. Now you can easily make a horde of zombies chase after the player without setting up any waypoints. Which is the whole point of this, of course. The problem had to do with a polygon filter, and I am still not sure what is going on, so I disabled it for now.

Yep, that's what it looked like when I went back and watched it. Some polys in segmented tiles seem to be invalid.

They don't actually use physics, they just do a raycast in the manner I first described.

I'm testing the Leadwerks3D AI navigation and getting some interesting results. I'm not sure why it's acting this way, but we'll get it figured out soon. It seems like the navigation gets "stuck" on corners, fails to enter some tiles, and likes to take the scenic route to some destinations. B)

I believe this is just an OS thing

I have never seen a game that used that level of detail in character physics.

Use the character controller.

I'd use a cubemap. Real-time reflection for a small pool of water is sort of overkill.

Navmeshes can have multiple levels and overhangs, so you only need one for a small or medium sized scene. It's not a per-model thing, it can handle all geometry, and the engine will take care of that automatically. Dynamically recalculating sections can be done by running it on a separate thread and getting the results a few frames later. Again, the engine just does it automatically for you. I don't know if mobile devices will have enough power for this, but when was the last time you worried about waypoint AI not being dynamic? For very large scenes, I think you will need to create multiple navmeshes in the editor, because otherwise the navmesh data might exceed system memory. If you have ten miles of terrain and three towns, you would probably create navmeshes for each town, and then link them together with conventional waypoints that just follow the roads between them.

So after about three weeks of pain and frustration, I have successfully calculated my first path using Recast navigation. This has been a new experience for me. I've implemented half a dozen low-level C++ libraries, and never had any serious trouble, but Recast Navigation is something else. The technology underlying Recast is impressive. First they take triangle geometry, convert it to voxels, then calculate navigation, and convert it back into rough polygons. You can read about the process in more detail here: https://sites.google.com/site/recastnavigation/MikkoMononen_RecastSlides.pdf The results seem pretty reliable, and although the speed of regenerating a tile is slow, it can be done on a separate thread and doesn't have to be updated all that often. I have two criticisms of the library. First, the code is a total mess. I can't complain too much since it's a free library, and I definitely appreciate Mikko putting it out there, but integrating it into the engine was a hellish process. I wouldn't even call Recast a code library so much as it is an open-source program. The amount of work it took to figure out what was going on was far beyond any library I have worked with, and it could have been wrapped up into a set of much simpler commands (which is what my end result was). Second, I believe converting polygons to voxels and back is the technically wrong way to go about this. Constructive solid geometry is perfect for navmeshes, autogenerated or otherwise. It would be very fast to generate. It could be dynamically updated quickly. The results would also be 100% accurate virtually all the time. However, it would require all navigation geometry to be modeled with CSG, and although I would be fine with that, I know others will want to use arbitrary polygonal geometry. So that's one thing I would do different if I were making an engine for just myself. There's an example of why you need to be flexible with your goals sometimes. Still, it's great to be able to build navigation data for any scene and make a character walk around in it without any waypoints or ray casts. Below is my very first result with Recast. There's some obvious strange results with the path, but the point is that it's working, to some extent. It's a minor miracle I am able to plot any kind of path at all. The hard part is done, and I'm sure I'll get any remaining issues ironed out pretty quickly: Building AI features right into the engine will give us better integration than using a third-party add-on, or trying to build it on top of the engine. First example, we can use physics geometry instead of visual polygons, and make the engine automatically invalidate and update sections of a map when objects move. This will give you powerful AI features that work perfectly with the rest of the engine, so you can control characters with just a few lines of script code. When this is done, it's reasonable to expect to be able to program something like Left 4 Dead in just a couple hundred lines of script (or less, if you just feel dragging some premade scripts around and attaching them to entities). Once the pathfinding is all tidied up, it will be a big moment, because it means at that point I will know everything I need to finish Leadwerks3D! When setting out with Leadwerks3D, the things I hadn't done before were what I was most worried about. I attacked the unknown issues first. Now that we are coming to the end of this long research and development phase, all that remains is a lot of hard work. It's all stuff I have done before, so I expect the remaining tasks to go pretty quickly. It's also pretty awesome to have a clear picture of how this massive piece of technology all works...four platforms, with rendering technology stretching from fixed-function graphics all the way to Shader Model 5 hardware tessellation...plus the easiest art pipeline ever and a script and flowgraph system that no one has ever done. The scope of this engine is just so much bigger than anything I have ever done, and it actually works! B)