Hello! I just stumbled on CGE (I use Delphi at work and think I saw that you are presenting at DelphiCon). It looks like a really capable and well thought out engine so I’m interested in learning how to use it. I’ve used a number of engines over the years, including some home-made ones, so not starting completely from scratch.
I mostly like to make 2d games and so am starting to look at the platformer example to get an understanding of how things are approached. I’m just wondering how to be able to visualize the colliders for debugging and troubleshooting. Most engines I’ve used have a way to show the colliders at runtime for this reason - especially if you need to carefully position or scale the collider to match a particular part of the 2d character or object. I’ve haven’t spent a huge amount of time with your documentation, but haven’t come across that yet. Is there a way to view these during runtime?
thanks!
It is not possible yet, but indeed it is something we want to add soon.
More details: Right now you have to add physics colliders (instance of class like TBoxCollider or TSphereCollider along with the instance of TRigidBody) using the code, and specify collider size in code (though you can of course base it on e.g. object’s bounding box, so you don’t need to explicitly hardcode the actual numbers).
See the physics manual in Physics | Manual | Castle Game Engine , see examples in examples/physics in CGE sources, and in case of the platformer demo – you can just grep for the word Collider in examples/platformer/code/ and see all places where it was manually coded.
Setting up the colliders this way is indeed quite tiresome, and not how we want it to be forever 
The plan is to:
-
Remake both TRigidBody and TXxxCollider to be TCastleBehavior descendants. The TCastleBehavior descendants can be added using CGE editor already (see news post – Adding behaviors in CGE editor (TCastleBillboard, TCastleSoundSource) – Castle Game Engine).
-
Add a visualization of the colliders then inside CGE editor. So, colliders would be visible at design-time.
-
Such visualization should be available at runtime too, perhaps through just some trivial global boolean in CGE like DebugVisualizeColliders.
It will effectively give us better integration of physics inside CGE editor, and as a side-effect I would be able to answer your question with a trivial answer like "use global DebugVisualizeColliders". It’s not done yet – but we plan this, and it’s very within our reach. Which means it may/should really realistically happen within a month or 2, so still in 2021 Stay tuned for our news.
1 Like
Ah, OK, thanks for the detailed answer. I can understand it is hard (and takes a lot of time) to get every feature that is desirable into an engine. In my home-made engines, I just focus on the features I want to use, so they are not general purpose/flexible engines like Castle is shooting for. The debug drawing is a pretty standard and (I’d say) necessary so glad to hear it might be coming along soon! I think the idea of making it so colliders can be adding through the editor and visualized even at runtime with a boolean is exactly the way to go.
I did notice it looks like Kraft has some debug drawing already implemented, but it is controlled by a compiler directive “DebugDraw” in the kraft.pas file.