Recent

Author Topic: How does Castle Game Engine compare with engines like Unity, Godot and Unreal?  (Read 3832 times)

Seenkao

  • Hero Member
  • *****
  • Posts: 550
    • New ZenGL.
I see several active topics on this forum dedicated to ZenGL, seems like it's a 2D-only engine.
ZenGL currently has no 3D support.
Прошу не путать! Движок в основном для 2D.  :) Уже год или больше как можно использовать полный функционал OpenGL (OpenGL ES) используя ZenGL. Поэтому используя ZenGL вы можете делать 3D приложения, но делать вам надо будет это вручную.

Так же есть несколько демок демонстрирующих возможности использования 3D.

Но, думаю, лучше использовать CGE для 3D приложений.

-----------------------
Google translate:
Please don't be confused! The engine is mainly for 2D. :) For a year or more now you can use the full functionality of OpenGL (OpenGL ES) using ZenGL. Therefore, using ZenGL you can make 3D applications, but you will have to do it manually.

There are also several demos demonstrating the possibilities of using 3D.

But I think it's better to use CGE for 3D applications.
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11453
  • FPC developer.
It is probably why ZenGL (Russian? Ukraine war?) has switched to Sourceforge and I suspect it may be why Free Pascal maintains its sourceforge based system, though that could be just down to history.

No. Sourceforge also suffers from this.  It was one of the motivations to keep own (SVN/FTP) servers at the time.

Sourceforge mostly was just download traffic mitigation

Josevaldo

  • Newbie
  • Posts: 1
Hello, I've known CGE for a few years and have always dabbled with Godot 3.0 to make ArchViz presentations. However, after the release of Godot version 4, some things changed, even plugins that I used in version 4 stopped working in 4.0. Confused that I was scared, because I suffered from this when PHP 4 gave way to PHP 5 and since then big changes from one version to another leave me in panic, because from Delphi 7 to Delphi 8 and then the change from barland to embarland fed an immense insecurity. I spent 2 years watching Lazarus before it started building a calculator just like home. Two years have passed and I still haven't ventured into creating anything that would make my client dependent and me committed to him and would have to study everything I already thought I knew.

I'm now more relaxed with lazarus due to the community's concern about maintaining compatibility with previous releases and the same can be said about Blender. Wise choices When I refer to michalis ( CGE ) I'm happy to choose an old technology that doesn't worry about fads and other frills, that modernizes without losing its identity and that knows very well who it is. Modernizing is not changing and some technologies have changed with the theme of modernization. I'm trying out your michalis tool and I'm happy that I'm no longer stuck with Godot and its features. I hope I can learn so I can contribute to this project that I see a lot of potential. My only tip to make it more user-friendly would be to change the name of the Background component to environment and with that add more resources aimed at this purpose, as Background is a visual component haha, environment would also be, however, it would control many more cool things and many archviz designers would benefit as building technicians that we are, we are not interested in why or how things work but we want to deliver to our client a room with good lighting and a cool background. . Ahhh, see the coppercube itinerary system -  . This matches the CGE and its inspector palette. It would be really cool to be able to configure some pre-built scripts while CGE generates pascal programming.

Translated by Google from Brazilian Portuguese

Moderator notice: offtopic link removed.
« Last Edit: April 08, 2024, 01:41:38 pm by marcov »

Aistis

  • New Member
  • *
  • Posts: 11
I'm currently thinking about what should I use for my hobby projects - Godot or CGE - so I will share my thoughts bellow.

I am currently playing around with CGE a bit. But I find it quite cumbersome to use. I consider myself a beginner in gamedev and this is what I've experienced after using it for a bit over a few weeks.

I had to implement my own 2d pathfinding algorithm (because I couldn't find any mention of it in the API) which isn't hard to do, but it took me some time as I'm not that great of a programmer (especially since I wasted quite a bit of time trying to understand which queue data structure in Pascal to use, but this is more of an issue with me not knowing Pascal rather than CGE's fault). Godot seems to have it out of the box, both 2d and 3d.

Then I had to do some research to find out why an almost empty CGE game project was showing up as leaking memory in heaptrc just to learn that the Indy network code is intentionally leaking memory and that it's safe to ignore it. Which is bothersome because it makes heapstrc annoying to use on Windows unless I redirect the output to a file.

I find the lack of tutorials quite detrimental as I already have to have at least some gamedev knowledge to do something in CGE. Then having to translate said knowledge to find the functions I need in the CGE API documentation which isn't as easy as it sounds (despite already having experience with having to do just so with Heaps.io whose API documentation was almost non-existing). While with Godot there's almost a tutorial for everything - even for whole complete games.

As far as I understand Godot also has what you could say is/was the only good thing about GameMaker which is the ability to rapidly prototype.

I still haven't actually used Godot apart from opening the editor and being close to midway into watching an 11 hour introduction to Godot 4 (https://youtu.be/nAh_Kx5Zh5Q). However, for my own personal hobby games that I don't plan on making money from, I believe Godot is more than enough, especially how both fast and easy it seems to use with its scripting language.

A lot of games are rather basic logic wise where I believe a few lines of interpreted scripting code wouldn't hinder a game's overall performance since all performance critical code is done in-engine. Gamedev is also more than just programming. And as far as I understand, it's easier to make your art assets do something in Godot, letting you iterate faster on your ideas, than it is in CGE.

However, that is not to say that I'm thinking of ditching CGE completely. Godot uses an interpreted language for its game logic. You can also use C# if you want, but any performance critical code you'll need you'll have to write it in C++. Depending on the game type and its requirements, CGE still seems viable to my amateur eyes. After all, why not use both? Prototype your game in Godot. Then when you properly construct a vision of what you want to achieve, make it in CGE.


Dzandaa

  • Sr. Member
  • ****
  • Posts: 252
  • From C# to Lazarus
Hi,

I tested Godot a few years ago.
The Script language is very similar to Python but you also can use C#.
It is object-oriented, allows character rigging, collision detection, path finding, sound, camera, light and environmental lighting, etc.
The editor is easy to use. Cross compiler exists for Windows, Linux, macOS, Web and even Android.

And it is Open Source.

I just wrote a little 3D game for testing.

Here are some pictures.

And also a little video on my personal site.

http://www.treedeepicz.be/gallery3/index.php/pages/show/Video

B->
Dzandaa

michalis

  • Full Member
  • ***
  • Posts: 140
    • Castle Game Engine
I'm currently thinking about what should I use for my hobby projects - Godot or CGE - so I will share my thoughts bellow.

First of all, thank you very much for the feedback! We need this to improve CGE.

And, to be clear, I (as CGE author/lead) will not try to argue here whether CGE or Godot is better -- Godot is open source and thus I love it :) Let me just try to go into details about some of the things you mentioned, to understand best how to "close the gap" between CGE and Godot:

Then I had to do some research to find out why an almost empty CGE game project was showing up as leaking memory in heaptrc just to learn that the Indy network code is intentionally leaking memory and that it's safe to ignore it. Which is bothersome because it makes heapstrc annoying to use on Windows unless I redirect the output to a file.

Note that we don't use Indy. Except client/server examples ( https://castle-engine.io/wp/2024/04/12/improvements-to-our-client-server-tcp-communication/ ). Our web request class (TCastleDownload) is based on FpHttpClient, which is part of FPC.

There was indeed a known memory leak, for which we had a PR: https://github.com/castle-engine/castle-engine/pull/581 .

- Original note: It's not something we want to ignore -- on the contrary, memory leaks are something we treat like any other bug and they have to be fixed. It's just that in this case, this is not so trivial (I want to test and iterate on the solution from PR, as it is a bit cumbersome), and it didn't seem priority (an "almost empty CGE project" doesn't use TCastleDownload, IMHO :) -- but this of course depends on the project type you want to do). You can subscribe to https://github.com/castle-engine/castle-engine/pull/581 on GitHub to be notified when it's applied.

- Edited note: I did some changes and applied PR https://github.com/castle-engine/castle-engine/pull/581 :) No memory leaks should occur anymore. If you observe any leaks in CGE, please submit a bug (using GitHub issues, https://github.com/castle-engine/castle-engine/issues ).


I find the lack of tutorials quite detrimental as I already have to have at least some gamedev knowledge to do something in CGE. Then having to translate said knowledge to find the functions I need in the CGE API documentation which isn't as easy as it sounds (despite already having experience with having to do just so with Heaps.io whose API documentation was almost non-existing). While with Godot there's almost a tutorial for everything - even for whole complete games.

Agreed. We need more learning materials.

Note that we have manual ( https://castle-engine.io/manual_intro.php with 3D tutorial), API docs ( https://castle-engine.io/apidoc/html/ ), YouTube channel ( https://www.youtube.com/c/CastleGameEngine ), recently we published 2 tutorial articles "Bad Chess" ( https://castle-engine.io/bad_chess ). But this is never enough, I want to make more :)

Can you point which parts do you feel are not covered by existing docs? Which need more tutorials most desperately? And do you like more videos, or written (text) tutorials?

And as far as I understand, it's easier to make your art assets do something in Godot, letting you iterate faster on your ideas, than it is in CGE.

Can you point out details?

We work on engine editor for many years now, and I do want it to allow "rapidly prototyping" games. It even works for me in my experiments and jams, but then I know CGE by heart :) So I really need honest user feedback -- you used Godot, you expected feature X, but CGE doesn't have X and it is detrimental to iterate over games fast. Can you list such most important features - X1, X2, X3 for you? Can you point examples of most important things that you feel are missing in CGE editor?

Again, to be clear: I absolutely do not try to argue in favor of CGE over Godot. I love Godot. It's an open source game engine, which is at the core of what I also want to achieve with CGE. I'm just looking to pinpoint the most important things that we should improve in CGE :) Thank you for the feedback!
 
« Last Edit: April 16, 2024, 01:05:24 am by michalis »

michalis

  • Full Member
  • ***
  • Posts: 140
    • Castle Game Engine
Note about memory leaks and TCastleDownload: I did some changes to https://github.com/castle-engine/castle-engine/pull/581 and applied it. No more memory leaks should occur. If you find any memory leak in CGE  ( https://castle-engine.io/memory_leaks ) please report a bug.

Aistis

  • New Member
  • *
  • Posts: 11

Then I had to do some research to find out why an almost empty CGE game project was showing up as leaking memory in heaptrc just to learn that the Indy network code is intentionally leaking memory and that it's safe to ignore it. Which is bothersome because it makes heapstrc annoying to use on Windows unless I redirect the output to a file.

Note that we don't use Indy. Except client/server examples ( https://castle-engine.io/wp/2024/04/12/improvements-to-our-client-server-tcp-communication/ ). Our web request class (TCastleDownload) is based on FpHttpClient, which is part of FPC.

There was indeed a known memory leak, for which we had a PR: https://github.com/castle-engine/castle-engine/pull/581 .

- Original note: It's not something we want to ignore -- on the contrary, memory leaks are something we treat like any other bug and they have to be fixed. It's just that in this case, this is not so trivial (I want to test and iterate on the solution from PR, as it is a bit cumbersome), and it didn't seem priority (an "almost empty CGE project" doesn't use TCastleDownload, IMHO :) -- but this of course depends on the project type you want to do). You can subscribe to https://github.com/castle-engine/castle-engine/pull/581 on GitHub to be notified when it's applied.

- Edited note: I did some changes and applied PR https://github.com/castle-engine/castle-engine/pull/581 :) No memory leaks should occur anymore. If you observe any leaks in CGE, please submit a bug (using GitHub issues, https://github.com/castle-engine/castle-engine/issues ).

Apologies, I had worded it wrong. I should've said that I used the example TCP server/client networking example on which I later started building my own project on. But the example was already leaking memory prior to me making any changes (thus me calling it an "almost empty project"), to which I discovered that it was because of the way Indy is handling threading and that it's leaking memory on purpose.

I use the Indy package that can be downloaded with the Lazarus package manager. So it might be a bit outdated, and the current version might not be leaky anymore. I haven't checked it.

...

Regarding everything else, it isn't really my intention to critique CGE and make Godot look more favourable. I was pressed on time to finish my post before I had to leave, so I might've rushed a bit.

My idea is that Godot is better for beginners purely because of its popularity, which in turn means that a lot of tutorials (be it good or terrible) are being constantly written by its users, and you can easily get the advice you need from their currently large user base. That popularity also means that they get more financial support to develop the project. Factually speaking, Godot is a stronger project in that sense.

CGE is in peculiar spot. It being written in Pascal might put a lot of folk off (I myself learnt about Object Pascal being a thing just a year or two ago despite learning to program in Pascal for 3 years in high-school and 2 more years at college, yikes!). Our friend circle would always joke about Pascal and how it doesn't have any real world use cases - which isn't true. Our year being the last one to be taught Pascal didn't make it any better since the argument to changing the whole education system to teach C++ instead was based on the premise that it's more useful in the real world and has objects and classes. The prejudice against and the low popularity of Pascal might hinder CGE's popularity greatly, thus making it harder to get that critical mass that Godot has. Which means less user-written tutorials or general advice beginners can get online.

I, myself, currently see CGE to be something more akin to XNA or MonoGame, while Godot seems to be like Unity and Unreal. How true is that is for people to check for themselves as I've only used CGE for just a few weeks and I am not that well versed in the engine or its tools yet. But my opinion here might be unfair to CGE because I dived into code first, mostly ignoring the bundled GUI Castle Editor. However, unlike Unity or Unreal, Godot doesn't have that many commercial successes made with it, and I think CGE actually has an advantage here, being able to compile to machine code thanks to Pascal.

Likening CGE to XNA or MonoGame might be a bit unfair as I find CGE not only easier to use but it also supports proper 3d, which at least when I tried it in MonoGame a few years ago was a pain to do. Not to mention how easy it is to set up on different OSes compared to MonoGame.

Functionally, CGE reminds me of Heaps.io. However, CGE has way more documentation than Heaps.io ever had, and if you do have some prior knowledge of using a game engine, you can find your way around. Not to mention that CGE is built on top of existing quite robust technologies (FreePascal compiler) unlike Heaps.io (having to work with haXe + HashLink + Heaps.io stack of custom mainly gamedev-orientated software, with HashLink not even properly supporting Linux when I had last used it).

I don't think I had played around with CGE or Godot enough to write something of more substance, so I can't really give any proper suggestions.

« Last Edit: April 16, 2024, 12:26:47 pm by Aistis »

michalis

  • Full Member
  • ***
  • Posts: 140
    • Castle Game Engine
I should've said that I used the example TCP server/client networking example on which I later started building my own project on. But the example was already leaking memory prior to me making any changes (thus me calling it an "almost empty project"), to which I discovered that it was because of the way Indy is handling threading and that it's leaking memory on purpose.

Thanks for clarifying -- so you specifically have a memory leak in our TCP client/server examples (the ones I happened to rework a lot last week, https://castle-engine.io/wp/2024/04/12/improvements-to-our-client-server-tcp-communication/ ).

Tested and addressed:

1. We indeed had one memory leak in CGE code connecting CGE + Indy, fixed in https://github.com/castle-engine/castle-engine/commit/7b7cfb7129e9b153907d90c9831d74c75cc76f76

2. But in general, Indy is leaking memory by default, by design -- this is unrelated to Castle Game Engine. I documented this now on https://castle-engine.io/manual_network.php#section_indy_memory_leaks , pointing how to avoid it (define FREE_ON_FINAL in Indy sources) but also warning it is not reliable (Indy source code warns that it will only work if your code gives all Indy threads time to terminate -- e.g. this means you cannot just disconnect right at application exit; so first disconnect, give some non-zero time for threads to finish, then close the app).

Experimenting, I was able to have CGE examples client/server indeed exit without memory leaks, tested with FPC HeapTrc, adding "<compiler_options detect_memory_leaks="true">" to CastleEngineManifest.xml . But I also saw why this is not default in Indy, as one can indeed get application crash (Access Violation) at exit when FREE_ON_FINAL is defined and you stop server / disconnect client right when application exits.

This sucks, but I'm afraid we cannot do anything more with this on CGE side, i.e. this is how Indy works, unrelated to CGE. Hopefully my new documentation at least makes it a "known limitation". If this is a blocker, you should just not use Indy. We support other networking options and we plan more -- see https://castle-engine.io/manual_network.php which I updated today. There's TCastleDownload to communicate with HTTP REST, we have example using RNL, we plan Nakama integration.

As for memory leaks, in general, if you find a memory leak, please let me know. This is a bug, we fix it like any other :) We care about memory leaks, we have a documentation page dedicated to it ( https://castle-engine.io/memory_leaks ), we have option in CastleEngineManifest.xml to easily activate leak detection too. Even if the leak isn't large/often, we want to fix it, to avoid "obscuring" from developer more important leaks. And fixing memory leaks generally means also "making the code properly organized, to consciously control the lifetime of your objects" which is a good thing for code quality, so we do advise it.

Quote
Regarding everything else, it isn't really my intention to critique CGE and make Godot look more favourable.

No worries, and I'm really open to all feedback, including critique and including comparisons with other game engines! We only learn from it.

Background: CGE did improve a lot in recent years because we removed a lot of "friction points" based on user feedback. And we do look at "what others do" in various situations (in particular Godot, Unity, Blender -- while Blender is not a game engine, some UX ideas translate) and this has been beneficial as well. In all of this we keep our own vision (modern Pascal, but also focus on standards glTF, X3D and resulting interoperability with other tools, also how components for UI and TCastleTransform work together...), but we would be foolish to ignore what others do right. So I need a feedback, I need these comparisons too, to be able to improve CGE in the right direction.

As for your points about Godot, I agree. Godot does have bigger user-base than CGE, this also implies more people providing support and tutorials. In general, Godot along with Unity and Unreal Engine rule when it comes to popularity, CGE is just a contender here :) With hopes to grow.

As for Pascal, we try to address the common question "why Pascal" by https://castle-engine.io/why_pascal and https://castle-engine.io/modern_pascal . And compared to other games engines, we do benefit from e.g. having both engine and games written in the same language (all people who make games also automatically can tweak the engine!) and from using a standard language, not specific to our engine (we're happy to delegate hard work of making compilers, transpilers etc. to FPC/Delphi :) ). I feel these properties of Pascal give us some "edge" over some other engines. Time will tell how much.

I have to play more with MonoGame and  Heaps.io that you mention. Admittedly most of my "other game engines" experience is from Unity / Godot / Unreal (roughly in this order of familiarity). Something for me to learn!

Thanks again for feedback and really keep it coming! :)
« Last Edit: April 17, 2024, 02:53:52 am by michalis »

 

TinyPortal © 2005-2018