Road Kill Kenny

Flip the switch Igor!

LE::TVec3 velocity = LE::GetBodyVelocity(LE::TBody) LE::TVec3 omega = LE::GetBodyOmega(LE::TBody) When both velocity & omega = (0,0,0) or very close to the body is at rest.

Well for future consideration. Macklebee, Marley Ghost & DaDonik. All three very honest and very capable. Sometimes the silent giants do the best work. Of course I'd like in as well but I'm not about to sing myself praises.

Thanks guys. Appreciate it all. @Paul: Yes I agree AI is more about behaviors and decision making. Movement along the path is just another step by step algorithm without any decisions to make.

Judging by the Display Picture.. it looks like it was copy pasted from a fasion model image.. I think you are on to something Josh.

Fixed the problem where the character goes backwards to the closest / first node in the path list.

::::BE WARNED THIS IS A LONG ONE:::: Path finding is a technique used in many games that allows an object to find its way around obstructions to get from one point to another. There are a lot of miss understandings regarding this technique and many treat it as a mystery that is best left for the more experienced programmers. However, the big scary word 'AI' is not nearly as scary or complex as some may think. My entire path finding system only contains 4 classes, 1 struct and about 450 lines of source excluding comments. I'm sure you'd agree that this isn't really that much. On that note I'd like to point out that path finding isn't even AI itself despite popular belief and the fact that it is written about in many AI books. Path finding is simply a tool that AI utilizes to determine several points that an object must go through to physically get from 'A' to 'B' in the shortest or most favorable route possible. The AI comes in firstly when the object decides where it has to go for starters dependent on its behavior and secondly when it decides what to do with the path given to it by the path finding system. Another reason I disagree that it is AI is because the path finding doesn't belong to an object at all. It is an single external system that the objects AI consults for information. Well now that that is out of the way I'll get on with it. Today I completed a full path finding system for my game. The path finding network is nodal and it utilizes the A* path finding algorithm. The most important feature of the system is the following funtion: std::vector<Node*> GetPath(LE::TVec3 startPos, LE::TVec3 endPos) This function simple returns a list of Nodes that the object must traverse in order to get from the startPos to the endPos. How the object uses that information is up to that objects AI behaviors. Here is a quick video of it working in the game: In my mind are three important sides to path finding including: The Node Network Heuristic Calculation The path finding algorithm that uses the Node network as an input and outputs a path The Node Network The node network or path finding graph is simply a bunch of nodes (i.e. 3D points in space) with Links between each other representing paths that are possible to be taken without hitting obstructions. The below screenshot shows a visual representation of the nodal network. Each node contains a list of links that are Outgoing from themselves. That way when the algorithm assesses a node it can quickly and easily access its outgoing links. Each link contains a pointer to its start Node and its end Node as well as a cost. The cost is important for the sake of the A* algorithm as it needs to know how difficult each link is so that it can pick the optimal route. Most costs are usually calculated by distance between nodes. However, they can be increased or decreased for different reasons. For example, you may consider a higher costs than normal for travelling uphill and a lower cost for travelling downhill. The choice is up to you. I have utilized my level editor to facilitate the creation of this path network in a quick and efficient way. This way the path finding network can utilize DDD (Data Driven Design). The classes I made for nodes and links are as follows: class Node { public: Node::Node(u_int id, u_int subID, std::string origin, LE::TVec3 Pos); Node::~Node(); void SetPosition(LE::TVec3 Pos); std::vector<Link*> GetLinks(); void CheckLinks(); void AddLink(u_int destId); void AddLink(std::string destOrigin, u_int destID); void AddLink(Node* node); void AddLink(Link* link); void DrawNode(); // Needs more work here LE::TVec3 pos; std::string origin; u_int id; u_int subID; private: std::vector<Link*> nodeLinks; PathMan* pMan; }; class Link { public: Link::Link(u_int NodeIDA, u_int NodeIDB); Link::Link(Node* start, Node* end); Link::~Link(); Node* GetStartNode(); Node* GetEndNode(); void SetCost(float cost); void CalcCost(); //Editor only float GetCost(); bool CheckLink(); void SetBlocked(bool block); void DrawLink(); //Debugging only private: Node* startNode; Node* endNode; float linkCost; bool blocked; PathMan* pMan; }; Excuse all the overloading functions. I wasn't sure which method I would want to use to AddLinks so I made a bunch of them. Now you may not understand it all as some of the stuff is specific to my game. However, you should be able to get the general gist. The Heuristic Estimation The heuristic estimation is the estimation of how far it is from any given node in the network being assessed to the destination node. The closer this estimate is to the actual distance the better. However, it does not need to be perfect. Now don't take me the wrong way this is an estimate of the distance that the object needs to travel to get from A to B not the birds eye distance. The A* algorithm will behave differently depending on if the heuristic is under or over estimated: Underestimating will cause the A* algorithm to take longer. The more it is underestimated the longer the process time will be. However, under estimating will always return the shortest path. Overestimation will cause the A* algorithm to not necessarily take the best path. However, it will finish quickly and is not a problem if the overestimation is minor. Getting the estimate just right will give the best balance of processing speed and accuracy. However, in order to estimate this distance perfectly you have to solve the path finding problem.... which is just stupid. There are a number of ways that the heuristic can be estimated including Euclidean distance, look up tables or by solving a "High Level Bucket Nodes" path. Euclidean Distance:This is the distance from point A to point B in a straight line. This has the potential to be either fairly accurate or grossly under-estimating depending on the geometry of your level. However, it is always garunteed to under-estimate so if you don't mind a bit of lacking in speed Euclidean distance is the way to go. Look Up Tables: A level can be broken up into bigger sections or buckets. The distance from each bucket to another bucket is pre-determined in a level file and the heuristic estimation simply looks up in the table the approximate distance from the bucket that start Node belongs to to the bucket that the end Node belongs to. ​High Level Bucket Nodes: Just like the look up tables, the level is broken up into big sections or buckets. A node is put in the middle of each bucket and a quick path finding algorithm is run to find the distance from the the bucket containing the start node and the bucket containing the end node. This means running a high level path finding algorithm using Euclidean Distance as the heuristic. Depending on the size of the level buckets and how many their are this usually is very quick and will provide a pretty close estimate. Each method has its pro's and con's. I guess it is just very dependent on how your level is set out and how much performance you are willing to play with. As the Euclidean heuristic will always give a good path I decided to use it just to get the path finding going. However, I may change to another to improve performance when it gets to optimization. The A* Algorithm The A* algorithm is a very well known and common algorithm used for many games path finding. As it is so common I'm not going to talk about it very much. It can be found in many places on the internet but beware, you will get the best information from an AI book as internet sites tend to leave out bits and pieces of information. This blog has gone long enough and I don't think I could do the A* justice without making this 3 times longer. I may write a tutorial on it using C++ someday but that's a big maybe.. I have a game to make XD. I shall bore you no further. Check out the path finding network being created in the editor. Enjoy

Looking good guys. Keep it going. I like the new dirty comic shader effect. I think it suites the game and enhances the feel. Think I might give iClone a go. I love doing animation

Apparently you can write a game entirely in script but I doubt it will be very easy and will be very messy when you try make it more than just one level that plays instantly. I personally don't see how it would be any easier to write a full architecture in script than in code as the concepts will still be the same. If you are using script to write an entire game then it really isn't script is it.. it's actually just code using a different language with all the overheads that come along with that so I don't see the point of using it for an entire game. Fact is making games is hard and although LE3 may assist in that way more than LE2 it won't magically make your game for you. I can see a lot of people being dissapointed because their expectations were un-realistic.

... or an ogre @Xaron the API commands will be similar, however, as it is written in C++ and there is some new functionality, and some less :|, there will be differences. It shouldn't be too hard but definately not a "Find & Replace" Job.

If this wasn't the case just about all prior LE2 users would have left by now.

Yes that's why I way its important to get it right first before exporting rather than scaling in code.

In LE2 you generally need to get the scale right before conversion. However, it is a static gmf mesh then Marley Ghost once made a scale tool and uploaded it somewhere not sure atm can't find the link to the post but maybe someone else can find it. Note that this doesn't work on animated meshes with bones only static meshes.

Thanks guys XD

Up until this point everything has been one big question mark. Will I finish my game? Will I run into project breaking road blocks? Will I have the resources? Am I crazy to think that I can actually do this? ... All of these question weigh heavily on my mind at all times and I'm sure a lot on other individual (Yes screw the word indie) developers minds as well. The road is so long and the light at the end of the tunnel is just so far away. It can be very dis-heartening sometimes especially when it is not always "just a matter of time" but a combination of a matter of time and a matter of a lot of damn hard and innovative work. However, for the first time I am pleased to say that the light at the end of the tunnel is getting brighter every day. Major milestones are being met and now there is no doubt in my mind that I will finish and release this game. This feeling comes just after completing the first alpha build for my level editor. The editor makes everything so much easier with the DDD capabilities and the ability to allow me to throw together levels very quickly, test new mechanics in relevant scenes and ultimately make each level of my game how I want it. The below two video's show the state of the editor at the moment and what it is capable of. The second video shows a quick demo level I made in the editor which took maybe 45mins to create. That might seem slow but I'm still getting used to the editor myself and there are some usability optimizations to be made as I come across them. Enjoy: In Editor: In Game: From now on there are just a few things I need to do. The first thing is the pathfinding system which will be nodal and will utilize the A* algorithm. It is mostly complete but still needs a bit more work. I also need to finish my in game stealth / alert system which is also almost finished. Following that I will create more enemies, traps and gameplay mechanics that will make the game fun to play. Finally I will be putting these gameplay mechanics into a series of levels with story and all artwork combined to make my complete game... I plan to officially announce the game soon so stay tuned.

Also check out Desura

Yes you don't need to update those if you are using framework. It may look like your framerate is droping but I think it might actually just be what it is printing. Because you UpdateAppTime here and the framework does as well, it might think it is going faster than it actually is. At least that the only reason I can think why you would be getting more fps with this.

Oh no you didn't just...... ROAR!!! QUEENSLANDER!!!!

That should work pretty well except that does not take into acount jumping up... say for example you jumped all that time going up contributes to the damage you take + all the time going down. In a game where you jump on jump pads and your landing is actually higher than your starting then you could still take damage with this technique. Not a problem if jumping is minimal, However, if it is an issue, You could also try recording the Z height at the beginning of being airborne and then record the Z height of when the controller is no longer airborne. Get the difference between the two and you have the height distance fallen / gained and base your damage / death off of that height difference value.... However, this doesn't take into acount if you jumped up you are getting more height from your initial airborne height. This may or may not be an issue but if it is you could find the height at the peak of the jump as your first Z height and then calculate the distance.. There are a range of ways to do it. Pick the one that suites the mechanics of your game and gives the best benefit cost ratio for your game.

Nope

Yeh I'm glad you found that comment it was a good find. Funny thing is I read that page when I made the code but never the comments. Awesome find man. Will change the topic name

I don't see why z-sort would do that.... Are you animating the props with bones or are you just using LE::TurnEntity().. I don't see why z-sort would cause the one to turn around the other if you are using the latter... and I'm not sure why it would do this even with bones. From my very limited understanding z-sorting is all about which objects to draw first so that objects closer to you are drawn on top of objects further away. I would have thought this would only affect the rendering. Then again I don't know a whole deal about the topic so maybe I'm wrong. Can't say I know exactly what z-sort = 1 in the material does have only used it a few times and for what I can't remember lol.

Yes thanks a lot Daimour. It works perfectly now. Never would have thaught the win32 Api function call had anything to do with it lol. Here's the new code for that function, works the charm static std::string K_Win::FileOpen(){ OPENFILENAME ofn; char fileName[MAX_PATH] = ""; ZeroMemory(&ofn, sizeof(ofn)); ofn.lStructSize = sizeof(OPENFILENAME); ofn.hwndOwner = NULL; ofn.lpstrFilter = "SQLite3 Files (*.*)\0*.*\0"; ofn.lpstrFile = fileName; ofn.nMaxFile = MAX_PATH; ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY; ofn.lpstrDefExt = ""; std::string fileNameStr; char curDir[MAX_PATH]; GetCurrentDirectory(MAX_PATH, curDir); if(GetOpenFileName(&ofn)) fileNameStr = fileName; SetCurrentDirectory(curDir); return fileNameStr; }

Are you sure they were just dinosaurs that were inflatable? XD

Hmm very interesting.... and rather annoying that it changes the directory. Not sure why it does, I can't see any value in changing the working directory considering the GetOpenFileName() function returns an absolute path and not a local file name. Thanks for the info. I should be able to solve it based on that info If I use SetCurrentDirectory() immediately after GetOpenFileName() to change the directory back to the default directory then it should work. http://msdn.microsof...0(v=vs.85).aspx