22 replies to this topic

[Gamer3D]

So you like the path system being very plain?
-SNIP-
Also you are correct you were not defending that they have a built in path system, but you were defending the built in path system the way it is which is why I asked you to elaborate.

Most paths will be of the type generated by the motion planning grid. They have a single start point, a single endpoint, and no branches. These paths work quite well for creating patrol routes, cinematics, and many other pre-defined motions.
GM's system is simple enough to be efficient and easy to update while still filling all the most common needs for a path. In layman's terms, it does its job well. Adding branching would almost certainly make it less efficient, and any additional level of complexity will add to the work required to update the path engine (For example, moving it from Delphi to C++).

Personally, I'd prefer it to be an extension, but it might be too late for that now.

So do you feel it should also be removed if you do not agree with my first paragraph suggestions then?

The problem with removal is that the path system is pervasive. Removing or changing it would require changes to the motion planning systems, the IDE, and many games. Put simply, any benefits of removing it are negated by the problems that removing it will generate.

But I rethought your suggestion of creating multiple paths that connect to one another at the point of "branching", because the only problem with I have is it would be a pain to switch between paths constantly and keep them aligned without seeing it visually. So what if a path could actually contain more than one path in the same path? Do you understand what I mean, what if we had the two branches from the original path in the same path, so all 3 paths were actually 1 path. Can you think of a way this could be sucessfully implemented?

I'd suggest keeping track of some switch points, shared by both paths. When this path is crossed (Check the position on the path each step), switch to the new path at its switch point. Same goes for rejoining. You might also need to keep track whether to negate the path speed at that point to correctly handle the rejoining case I showed.

Note: That's a very rough sketch of how I'd do it if I had to start right now. Given time, I could probably find a more elegant solution, but this one should work.

Do you or do you not like the idea of exposing index/vertex buffers? Because again you still did not answer my question when I asked you what you thought of manipulating terrain data for instance in real time (eg. battlefield can make craters in the terrain, etc.). Again I am not supporting hacks either I know exactly what you mean and I became aware of this with the 3D particle extension and the GMOgre extension, but I am not suggesting a hack either I am suggesting that vertex/index buffers not be exposed through libraries but become an integrated part of GM and that the changes in GM9 reflect this.

I don't think the current model system is set up properly for it, because determining which vertex belongs to the triangle you wish to animate could be tricky (And allowing noobs to be able to create their own buffers could be the stuff of nightmares).

Keep in mind that it can be a lot harder to safely remove a feature than it was to add it, because other features will soon depend on the implementation. (As is the case with paths)

By the way, you could probably animate a portion of a terrain in real time using the current system by using a quadtree of terrain meshes to draw everything but a small region as models.

One last note:
Here's my short list of GM systems I think would work better as extensions (In descending order of my current perception of the usefulness of externalizing them):

• Multiplayer
• The entire set of ds_ functions. (While these functions are mostly good, I see no reason for them to be internal to GM. Also, I wrote a better ds_priority than YoYo did and can't directly replace the functions)
• Motion planning (Again, a fully self-contained system. Also good to have it external to give more freedom when changing the path system)
• Particles (Note: The current system might not do well as an extension because of how it's drawn)
• The health/score system (Replace it with a few scripts, perhaps?)
• Paths
• Timelines

[PivotGamer84]

Delete this post, wrong thread.

Edited by PivotGamer84, 06 March 2012 - 01:08 AM.

[szotyi41]

Thank you! Solved the problem