Castle Game Engine 4.0.0 released

[LP]

I don't think there are good enough engines out there yet, to say that we have something finished for most needs. We don't hear about those supposed engines being used or maintained even monthly.

I'm sure that every single developer, author of such engines, will have reasons of why his/her engine is good enough and why are they doing it, but you are right - each of those engines is only "good" for whoever does them, but being "good" doesn't really mean "useful", even for the original author.

Think of it as if everyone would be trying to create his/her own car engine - we'd have many of these engines, all stuck in each person's garage, but you can't put any of them into any of the existing or newly built cars due to incompatibilities. This would be really sad as all those talented people could have used their talent to create something more useful both for themselves and people around them, rather wasting their time.

A popular YAGNI principle states that you shouldn't be working on particular functionality until you actually need it. You can find many other such principles, such as KISS, Overengineering, etc.

Therefore, once you have specific game idea in mind, and maybe even some spec for it, you can narrow down game's requirements, then work and implement them, effectively using minimal effort to achieve highest impact (the last part can be used to define "wisdom", by the way).

Looking at this engine, I see a lot of potential, but I would love to have a game associated with it that you can actually play; until then, it's just a random set of arbitrary functionality, not dissimilar with many others that I've linked earlier.

The real trick is that when you actually try to make a game out of your engine, is when you realize that you have to "adapt" your game ideas very much to the engine you've created, so you have to either redesign/rewrite your engine to fit your new game ideas (which would essentially restart the vicious cycle), abandon your game ideas, or deform them greatly to fit within the engine in such way that it makes the game senseless.

Instead, you can take the article's advice, and start working on actual game. After you have released one or several games, or their versions, you will start to find reusable patterns that you will eventually isolate, so they will be reused in multiple projects of yours, becoming your base framework (which, again, is not going to be an engine as such). Many of the "engines" Wagenheimer mentioned are exactly such frameworks, and even so they may not necessarily be useful for a particular project. For instance, in my personal experience, I've known GLScene for many years and it has a lot of fantastic solutions, but due to its design/implementation specifics (see my earlier post about functional and non-functional requirements), I could never use any of it in my projects, not even partially.

[hwnd]

I use nxPascal in my map editor project and without nxPascal i still would search for good and working picking code.
later i have plan to implement a top down game with that. Nothing fancy, but something interesting to have fun with.
Maybe it will be built in into that editor, kinda like preview of map where you can walk around and see how it will look in real game.

[phibermon]

It's true that writing an engine is a learning experience, I personally develop my engine because I enjoy experimenting with new techniques, I designed it's scope so I could learn about aspects of their design that I was interested in myself. So it's not going to offer everything you need for a game, only a small subset. but enough to decrease the development time of a game. I think that's the best you can hope for unless you've got a big team of people, and I do think it would be better to have one or two really good community contributed engines than all these talented developers, reinventing the wheel independently.

It's difficult to draw devs together in this way because I suppose that many of them also enjoy learning new engine techniques and improving their engines.

But if there's more than two devs that are just trying to create a kick ass engine for people to use, it'd be a shame to duplicate effort.

[Cybermonkey]

Just to lead discussion back to the Castle Game Engine: is it possible to use Newton Dynamics? Or has anyone tried to use it with this engine?

[michalis]

First of all, thanks for all the comments!

As for the "write games, not engines" --- of course, I 100% agree. Even though I just announced a release of my engine The playable games are where the fun is, and the engine would not be created if I wasn't dreaming about actually using it for a lot of my future games.

I started creating the engine basically because there were no good 3D engines (at the time) that did what I wanted (including using standardized 3D-modeller-agnostic format like VRML/X3D, and being friendly to FPC/Lazarus, and 100% portable and tested on OSes other than Windows, and open-source, ...).

I'm quite confident that my engine has the features that I need, as I was targetting what I will need in my planned games. The old "The Castle" game is also fully ported to new 4.0.0 version, as one way to proove that the engine is 100% ready for making actual games, not just a technological demo. Other demos in engine examples, like the fixed-camera and isometric demos, hopefully show that the engine is modular --- you can use the engine components for other games than just "normal" 3D FPS-like games. And of course I hope it will be useful for others, and of course others are welcome to extend it and contribute

I hope to release a game (working title "Three Servants") this year, in fact most of 2013 will hopefully be spent on making this game. The game will be open-source, I hope to get some funds by crowd-funding (on kickstarted or similar pages) for this game and/or development of some engine features. So, I share the desire to actually have a new playable (and great) game showcasing this engine.

Just to lead discussion back to the Castle Game Engine: is it possible to use Newton Dynamics? Or has anyone tried to use it with this engine?

Not yet. Integration with physics is planned, but not yet done (aside from our own collisions and gravity system, but these do not really deserve the name "physics simulation"). I plan to integrate with Bullet (as it became a very capable physics engine in recent years, with both rigid and soft body, and optional OpenCL, and Android compatibility, an a lot of (large and small) names using it).

Contributions to this are very welcome (for Bullet or other physics engine of your choice, like Newton).

You should be able integrate the Castle Game Engine with any physics engine without modifying our source code --- just pass appropriate objects to physics engine, and apply back the transformations. Care has been taken that all transformations can dynamically change without any loss of speed. For more involved tasks, some integration may be necessary, but as I said: I welcome contributions here

In another news: Castle Game Engine 4.0.1 was just released. This is a minor release that adds some fixes/improvements around font-related units and examples, like the CastleGLWindowsFonts unit.

[Cybermonkey]

Are there any Pascal headers for Bullet?

[michalis]

Are there any Pascal headers for Bullet?

Not yet, as far as I know. But creating a basic Pascal header, that wraps what is exposed inside Bullet-C-Api.h, should be trivial. And once you have this, you can translate to Pascal a Bullet demo like BulletDinoDemo. And then you have working Bullet with rigid body , which you can start to integrate with Castle Game Engine.

(The next step is to extend Bullet-C-Api.h to add there soft body and other stuff, and then translate that to Pascal too. Currently Buller C header doesn't include the full Bullet API (that is only in Bullet C++ object-oriented API), but Bullet developers have stated many times that they welcome contributions there.)