Hello everyone, I love GG, and the progress the team has made regarding it.

Just a few questions, which I can't seem to find an answer for...

1. I remember reading about multi cores being worked on for the CPU's last year. Is this still being worked on? Does anyone know the progress of that?

2. Is the AI being worked on? I'm reading through the Feature voting board and I don't really see an option for "AI Rework" or something of the sorts. (In my opinion they need a ton of work).

3. Is it just me or do Waypoints not work at all? Even when I try placing them down they either A: don't show up at all, or B: they show up halfway across the map for me to find. I've verified my files and what not, even uninstalled and reinstalled GG still no luck. Is this an issue others are having?

4. Is there work planned for bringing optimizations to lets say the amount of AI/Trees/Vegetation you have on your map? (currently even if you throw down lets say 10 A.I and a mini forest it really takes a big hit to your FPS (is this because of the single core usage that GG currently has, and does this tie in with the Multi Core?).


Again, these are just questions, I'm not raging/Trolling/throwing a fit like I know a lot of different people do on different forums.

If anyone has any knowledge about some, or all of these questions that'd be great!

And I know Lee is currently busy with meetings and what not, so Like "The Next" stated in another forum, he'll be back to "full strength" on the coding and feature voting board after these meetings wrap up, so maybe I should've waited to ask these questions, but hey, I'm impatient .

Thanks everyone,

-TodaysKiller (Justin)

The AI navigating stairs and slopes will require a number of changes to the current AI. So hopefully things are much approved with this "feature" item. waypoints may have to be reconsidered when dealing with stairs and such as we may have to look into a nav-mesh type of solution.

Hoping we get something easier to use than this:



Navmesh building is very buggy in many engines out there. Not sure how Lee plans to tackle this issue.

some sort of nav mesh should of been done well before now and is embarrassing for an engine not to have some sort of nav for A.I
not all want to run around in the park you know. work rounds are not a solution. i have been around on the forums from 2006 and am
concerned were gg is going, as regards development, concentrating on packs is not the answer . i am not being rude or judgemental
but you must have priorities, as we will just have a another x10 or classic on our hands running before we can walk leads to failure
again. what is the point having all the packs if A.I cant navigate them. if tgc want to generate money then fix the problem packs will sell
and generate monies people will be more confident in the engine knowing it is able to build levels of choice and not be just a scene creator.

When placing waypoints it will appear at the centre of the screen so make sure you are in top-down view (press g)

AI would come under navigating stairs and whatever as said above.

I believe dx11 update should help a little with using lots of the same entites close together as it should include some sort of batched rendering... But dx11 work is on hold again.
Personally I don't think GG will improve much as far as performance is concerned, you're best to just accept it and create your levels accordingly... I'll be happy if I'm wrong though

Thanks for all of the replies everyone . I'm happy with where it is, I'm able to create a game and enjoy doing so. Just those things I mentioned could be worked on, and it'd make it perfect.

Current, AI characters work only in the "X" and "Z" access. The only up/down capability ("Y") is based upon the height of the base terrain at the X and Z position where the character is located at that point in time.

The Player/Camera works in a similar fashion, but the camera has the ability to recognize movement from one object to another, and is not limited to the base terrain. Thus, when you move forward from the terrain to an object (say a set of steps), the player replaces the terrain as it's base object, and the "Y" value (up/down) of the Player/camera is now tied to the "Y" value of the surface of the new object. With each movement forward (up the steps for example) the "Y" value is adjusted and the Camera moves up the steps. When you reach the top of the steps and step onto the next object (the upper floor to which the stairs lead) the new object provides the "Y" values allowing the Camera to move across this new surface.

AI characters do not yet have this same ability. One must assume that they will eventually.

As for the Way points, I assume they will work one day. However, with the power of the LUA language it is much easier to program specific character movements along a desired path, then it is to set-up way points which the AI characters may or may not recognize. Regardless, at present the way points will only work on the surface of the terrain.

Controlling AI character movements in LUA can be done now, but is limited to the X/Y/Z of the terrain. When the ability of AI characters to recognize non-terrain surfaces reaches the same point as the camera, then AI will be a much more useful tool.

As I understand it, the Nav issues with AI characters has to do with the fact that Lee has yet to implement the "Y" coordinates (up/down) for AI.

The Camera has the ability to recognize that it has transitioned to another generally horizontal surface (of a mesh object), which sets the "Y" parameter for the entity (in this case the player/camera) to that value and object. As the camera moves over the objects surface, the "Y" parameter is adjusted with each movement. So if the camera steps onto a higher surface (such as a stair) which is higher or lower that the current "Y" value, the "Y" value is adjusted, and the camera moves up or down accordingly.

When the camera transitions to a different object's surface, the cycle of adjusting the "Y" shifts to the new surface and the process continues.

AI characters do not have this ability to transition from one surface to another as all of their XYZ coordinates are based upon the terrain. When the AI system adds the features that the Player/Camera already has, then AI will become a much more useful tool, and transitions from terrain to interiors will become possible.

The first thing to keep in mind here changes the concept of open world.
Here you can define the areas that the player can visit ,in other words, you do not have to delimited the area with invisible walls, mountains, water, etc, in order to prevent the player go to the areas, that you are not interested.

open world
Obviously there will be the "open world" mode, but not as we know it; however you can add mountains, water, rocks, etc. to the scene, but they can not be navigable up to you, that only part of the geometry.

Why worry about some mountains that are at the bottom of the scene, if you have decided that they are only part of the geometry, the less things you should take the engine, the more you simplify the map better.

There will also be houses, parks, entities (barrels, boxes, lamps, etc), all represent barriers to prevent the player, as well as the obstacles mentioned above (water, rocks, etc.)

The engine could create an internal map, with all defined, navigable and non-navigable areas.

Note: In the video navigable areas are green, and non-navigable, are red color.

Rectangles and circles around the obstacle, represents the boundary of the navigable area.

And many, many other things that would be impossible to comment on a post.

This can be anything but easy; it has to create a pathfinding algorithm, sufficiently robust as to find the shortest path between point A and point B, taking into account all the obstacles they may have.

You can put all kinds of things on the scene, and all of them must be taken into account.

Imagine a scene in which you put a brick of milk, a health pack, ammo, and all within walking distance of each other.

Considering that law of physics that said, every body has a place in space,
aforementioned entities so do obviously, however although small, there is a gap between them; Well, this distance must be considered navigable?
or conversely, should group all the objects at a distance, say, small enough to be considered navigable, and therefore should be grouped and treated as a single entity, when classified as non-navigable and create a unique anchor for all of them.

At first glance it is clear, but the engine does not therefore non often overlooked anything or nothing for granted, the engine will take into account these short distances in their calculations, and if we are not told what to do about, the engine becomes crazy.

Well now that more or less, we have created our map of obstacles, the engine will work with this map internally.

Now comes the hard part.

find the shortest path between point A and point B

We already have point A and B (A = start point B = end point)

Many pathfinding algorithms are nodes-based.

I'm no expert, but I think having these nodes would help you find the right way; the way that uses fewer nodes will be the shortest.

In our case, the nodes would come represented by the vertex, and would have "good nodes" and "bad nodes", so we should not include the bad nodes when calculating the shorter or practicable way, of course without leaving thinking about them, because they represent areas that can not navigate, therefore its importance is vital.

And then there's this, applied to enclosed spaces, like navigate a home, building, industry, etc.

Maybe something we already have, could help, even if this waypoint should be much improved.

Wayoints to create horizontally and vertically, as well as rectangular and circular, to smooth a turn, could be just fine.

Although these are just my ideas, I'm also not taking into account many factors unknown to me, but certainly there. Above all the code that you add, you must work in complete harmony with the rest of code, and this is very difficult to achieve.

In addition, the development team but wonderful, is very small, and they have many fronts, many things that work. When you want to add one thing, you have to work on others as well, to make the first run; therefore it is impossible to work exclusively on one thing, from start to finish.

So thanks to the development team for all the effort and dedication.



Sorry for the longest post, and thanks for watch the video.

3com

I would like the addition of nodes with the current way point editor. So the AI can decide which paths to take from a variety of options.

If you check out this video check out at 8:15

Nice vid.
Videos like this are talking us how difficult is, and howmany resources we need to take in count, when thinking in "AAA" games.

Maybe I have to begin thinking about "aaa" games firts.

And yeah, have the chance to choose ramdom path, would be very nice. I like too!

3com

There are a number of "standard" algorithms for path-finding. Most of them require some sort of navigation mesh (node mesh), that is the basis for finding the shortest path between A and B.

That part is "easy" (easier than the following in any event) ... it gets to be a lot more involved when the AI has to deal with dynamic obstacles (e.g. a large bolder that falls off a cliff and now blocks part of the node mesh, or a barrel that was shot by the player and happens to land between the player and the AI.

There are algorithms that allow an autonomous entity to navigate through UNKNOWN territory.

I am absolutely sure that the dev team could implement those algorithms and devise a GG-type process for defining node meshes.

I would think that the true challenge is balancing the AI "awareness" with the required computing power. After all, implementing "smart" AI that navigates autonomously through any level would be cool, but useless, if the FPS drops to the equivalent of a slide show of photographs.

While I was still dabbling with 3D GameStudio, someone had implemented an add-on that allowed for node-meshes (which then required a separate compiler to produce a "machine readable form" of the mesh). He also included a set of routines for goal-oriented behaviour. It worked quite well - conceptionally - but if you added more than 4 AI, your gameplay would seriously degrade.

Having said all that, I would still find it very worthwhile to have some of those capabilities ... but that functionality would probably absolutely have to be written in C++ ... LUA would be too slow.

Cheers,
Fendrik

I will need to think about nav meshes and their variants as I develop the Easy Building Editor which is currently top of the list for the next item. Being able to have characters move easily from floor to floor, up and down stairs and ramps, in and out of doors, will be crucial to keep the GameGuru 'easy' moniker. To this end, crafting endless sheets of geometry to walk on does not seem to be the way to go, especially as you will want to drop down whole cities in minutes I am warming to the idea you simply 'paint' the parts you want to walk on when the entity gets created, and the engine simply loads that data in and deals with nav-meshy stuff in the background. The building editor will likely have this 'floor' stuff encoded into the 'parts' so the end user never really has to define any nav meshes directly, only content creators and those who like to tinker Right now we are using A* which is a 2D closest route routine, but it has the downside of not handling islands very well, can take an eon to calculate the nodes that define the shortcuts when AI is in action and is pretty much incapable of dealing with vertical layers of navigation. Of course, emails on open source free for commercial use nav-mesh magic would be welcomed at lee@thegamecreators.com