Hey, are you looking to migrate away from Unity to an open-source game engine, that doesn’t charge any royalties for releasing on any platform?

• See our list of features and the engine overview for Unity developers.

• If you wonder about picking up Pascal we explain why it’s a modern and productive language and have learning resources.

• So just download the engine and play with it 🙂 Follow the manual for full docs.

• And if you want to know what’s coming soon: see our roadmap, including engine on Steam and web target. Recent developments are summarized here.

New features this week:

1. We improved how the camera gizmos for 2D are visualized and work. Now they show the projection near and far as a box, that makes sense both in typical 2D view (orthographic, direction -Z) and 3D (free view, perspective or ortho). Also we fixed rendering and selecting camera gizmos in some cases.

2. We added a tab with information or warnings specific to a given component to the object inspector panel (on the right).

   It reports now these warnings:

   • TCastleRigidBody without TCastleCollider or vice versa. Both these behaviors must exist to enable physics, only one of them isn’t really useful.
   • Physical objects with non-uniform scale. Non-uniform scale cannot be fully supported, due to the underlying limitations of physics engines.
   • TCastleMeshCollider with unassigned TCastleMeshCollider.Mesh.
   • Joint without a TCastleRigidBody and TCastleCollider.
   • UI element outside of the parent area. Mouse clicks would not reach such element.

   We had a long-standing plan to warn about some easy mistakes in the editor — this is a start. In the future we want to make these warnings more visible (as icons in the hierarchy, and as per-project “some warnings reported” icon) so you can quickly see if there are any warnings. For now, this is a start: when selecting given component, just look whether the Warnings tab appears.

   Note that we don’t really want to introduce now a lot of new warnings. A warning is only warranted if there’s a reasonably high chance that it’s a user error, not a deliberate setup. Moreover, in general our API design should minimize the possibilities to make such errors, by making invalid state impossible. That being said, no design shields users perfectly from all possible mistakes 🙂 So when we see you likely have an unexpected state (e.g. a rigid body component without a collider is just ignored) we warn about it.

Like the development? Please support us on Patreon!