BGE DEV: Ben's new Raycast To function now in SVN

I think we need a .blend that would show where current functions would be really slow and this would be really fast.

It sounds like a neat function, I just don’t know of any really good examples right now.

New rayCastTo() python method for KX_GameObject:


Look towards another point/KX_GameObject and return first object hit within dist with a property that match prop, None if no object found or if it does not match prop.

other = 3-tuple (xyz coordinates) or object reference (target=center of object)
(type = list [x,y,z] or object reference)
dist = max distance of detection (can be negative => look behind)
If 0 or omitted => detect up to other
prop = property name that object must have
If empty or omitted => detect any object

I thought of this feature when I was implementing the AI of bots in an FPS game. The problem is as follow: considering a complicated map with places to hide, hooks, mazes, etc, how can you teach a bot to walk through this map and find the player wherever he’s hiding.
My idea was to place empty objects (nodes) at strategic positions so that any area of the map is at least visible from one node and each node at least is visible from another node. These nodes are totally idle all the time and don’t take any CPU.
When the bot wants to find the player, he can “ask” the nodes which one is seeing the player and run to that node by following the graph of connected nodes.
With this new function, this whole process can be automated: creating the map of connected nodes (nodes that see each other) at startup and find in realtime where is the player. Even the bot idle movement can be automated by walking randomly through the graph of nodes.
I know it sounds complicated (AI creation IS complicated) but the good thing is that this development can be done once and reused in various maps and games. It is also based on well known path finding algorithms.
Without this function, you must set on each node a ray sensor and a TrackTo actuator so that the ray sensor is always pointing at the player, a huge waste of CPU. In addition, the graph of nodes must be done manually.

So the AI can see around corners! That’s cheating :wink:

Do you have a .blend we could look at that has this fast AI node thing in action?

Also, can it work like, the player doesn’t have to be directly in front of the node for the node to see it? Or can you scale the node and the area where it sees the player is increased?

I could find this very useful for a system where objects are deleted and created again based on where the player is if I need like a 1000 physics objects throughout a level with corridors and many rooms, currently I need a ray, radar, or near sensor to use detection if they need to create the objects and that’s really slow when they need to do that, this really fast way of doing it where not all objects have to do it at once could be very beneficial.

Good news, I’ve found and fixed the ghost bug with dynamic objects: ghost property will be preserved on objects created with AddObject actuator.
I’ve comitted the fix.

Read my second post because you probably missed that.

Good news, I’ve found and fixed the ghost bug with dynamic objects: ghost property will be preserved on objects created with AddObject actuator.
I’ve comitted the fix.

That’s great, there’s more people then you think who need that.

Do you have a .blend we could look at that has this fast AI node thing in action?

Not yet (didn’t have the function before :)) but I will update my FPS template ( with this kind of logic in the coming weeks.

Also, can it work like, the player doesn’t have to be directly in front of the node for the node to see it?

Not now: the bug in the RayCast function is not fixed yet (no possibility of “X-Ray” mode). This means that the player must be in direct sight for the node to see it.

can you scale the node and the area where it sees the player is increased?

Not really. Don’t forget that this is just a function to send a ray from an object to any point you want. As the starting point is always an object center, it doesn’t matter how large is the object.
There is normally a mode called “island sleeping” that does more of less what you want to do: the objects that are out of camera frustrum go to sleep and take little CPU. I’ve not checked if this mode works correctly.

This ‘island/object sleeping’ function would be a very good thing for huge indoor levels full of 1000’s of physics objects throughout or huge outdoor scenes where fog limits sight range, in other words this would be very good to have for very large levels, and for the former, the importance of lots of objects in indoor levels is that stark empty levels would be boring.

Do see if you can do that, there’s some games being developed now by others that could really use it (Like the WIP helicopter game)

OK, I’ll have a look at the island sleeping mode when I have time (not this week unfortunately).
I can’t promise anything: BCON4 (feature freeze) is approaching fast and I don’t think there is enough time left for optimizing much the BGE before final 2.46 release.
Previous weeks have been intense for me and I need to slow down a bit.

Generally speaking, I have some doubts on the utility of optimizing the BGE much further. I often read Social repeating that the problem with the BGE is the BGE itself and I agree with him to some extend. Fixing bugs is easy (well…in a way) and but optimizing means rewriting larger portions of code or even changing the foundations.

It doesn’t make sense to rewrite everything when there are other open source game engines that have been developped in a better way from the start. I’ve gained a lot of experience with the Blender code and I think this knowledge will be best used in helping on the integration of such optimized game engine in Blender.

I’d like to get the forum’s opinion on that question: better spend the time on optimizing the BGE or integrating CS?

Anyway, this is for the future (Blender 2.50?). For the time being, I’ll continue with the BGE, it’s fun!

P.S. Official RC2 release is planned for next Sunday. It will contain all my bug fixes. It will be important to test all your games against it; the stability of the final release depends on that.

I vote for fixing main bugs( probably done, which is GREAT and THANKS! ) and then integrating CS with possibilty to not use gamelogic bricks!

Optimizing the BGE so it’s nice and fast will give Blender a great built in solution for creating complex games without needing to port large projects over to CS.

Also, C-106 Delta is interested in also optimizing the BGE, but he’s having compiler problems, why not get in touch with him and he can help you do the optimization work, 2 developers can do this much faster then just one, don’t forget Ovidiu can help too.

Hey Ben

I’d love the current game engine to be bug free and optimised in the short term. Then I could develop game play prototypes and if they look successful then get it running in a more advanced engine.

thank you for all your hard work

ps Maybe you could write a ‘lod switcher’ logic brick. That would speed up games if users put the effort in and built lods for their games. (And for the Nintendo DS developers an option to switch texture filters to point sampled)

An optimized BGE in the short term could also be great for developers to create very complex games if graphics aren’t an issue, we can’t just let the BGE die, the game engine is a key feature that sets Blender apart from 3DS Max or other big budget apps, it’s one of Blender’s most unique features.

Hi, Ben. I am replying to your question:

The biggest advantage of BGE is, that everything you model or animate in Blender can be seen at once you press magical “P” button. Logic bricks are great start for people, who are not programmers.

But if you will be making game projects longer time, you will use python scripting more and after long (maybe short) time you will begin to feel “bound” by BGE sometimes.

I would appreciate more freedom in scripting - I mean more build-in functions and access to everything in the game. And mainly normal collision system.

(I am using BGE over 5 years so I know what I am talking about ;).)

If there is a way to evolve BGE, I am for it. If there can be plugged Crystal Space in Blender and it will “behave” similar to BGE in Blender, I am for Crystal Space integration.

In all cases, I dont think, that BGE should be removed from Blender. BGE has been “growing” for years and it is perfect tool for learning programming.

I also think, that if someone can make game engines plugable into Blender, it could be a step forward.

There might be more optimized open source game engines than BGE, but I haven’t yet seen another as easy and fast to use as BGE. Most of them, if not all, require programming knowledge. BGE is great because you don’t have to know any C++ or even any scripting language to make games, but it provides an oppoturnity to learn some python.

There might be some commercial engines which provide the same ease of use, but how many of them comes with a full-blown modeling tool? Anyway they’re not free or open source so they have no chance :no:

Although my own projects tend to be rather complex, I must admit that BGE is best for making simple games and realtime visualizations. I’m not sure how tight the CS integration to Blender will be, but I doubt it will be as simple to use as the good old BGE. And thanks to Ben’s (and few others) hard work, BGE is now more usable than ever.

I wouldn’t be very upset if BGE wasn’t optimized much further, because it might then require a big rewrite. Bug free BGE is IMO more important since BGE can’t compete with more advanced engines anyway. Let CS integration take care of that.

BGE can’t compete with more advanced engines anyway.
You “can” make near to professional games in BGE but it requires a great deal of work… and there are hardly any artist that work “this” hard at a game. Also, from a developers point of view, this is a joke. BGE will only continue to improve.

The BGE can compete if it had a development team to optimize it and did other improvements.

If everyone had the “oh well it can’t compete” the BGE would’ve been dead and out of Blender by now.

You can surely make simple professional games, but BGE just doesn’t have many of the advanced features many dedicated game engines have, like visareas, terrain LOD, dynamic loading of the objects etc… I am pretty sure implementing these might need major restructuring of the code and lots of work. Smaller optimizations like the ray thing Ben made are of course possible and very welcome.

Which is why Ben can enlist Ovidiu and C-106 Delta to speed things up.

One developer may need a long time to optimize things, 3 developers would make things go a lot faster.

Ben has said he would look at something called ‘island sleeping’ after this week, but by then BCon 4 would roll around so it won’t be in 2.46.

Someone should find that link to the conference with that guy talking about optimizing BGE. Problem is that most of it has to be rewritten probably.

I still like the idea of nodes instead of logic bricks.

Haven’t tried CS so I don’t really have an opinion if it’s better or not.