Community Engine Announcement Discussions

[AthenaOfDelphi]

In Lazarus you can see it by hovering mouse over the type name, and it will tell what unit it comes from. Or you can ctrl-click the type and it will take to definition. I think same thing applies for Delphi.
Edit: Nice dj, covering same things at the same time

I prefer not to use prefixes for class names, but unit names yes. Not any long ones because we're going to be adding them to uses list, and for convenience sake short is better.

To avoid such issues, the guideline (open for comment by devs) is unit names will be prefixed with PGDCE and type and class names will be prefixed with TCE (obviously the T is standard anyway). They are short, clear and should avoid any such naming confusion. Ordinarily I'm not keen on prefixes, but with a project such as this, to avoid potential issues with user code bases I think they are a necessary evil :-)

[User137]

I can't see any potential issues, and like they said before, certain types can be referred to as unitname.type. I would say it would hurt the programmer even more and consistently if he had to type TCE everywhere, even something like TCEVector3f?

[de_jean_7777]

Some often used types, such as vectors, should be without a prefix. In my engine, I used "oxu" as a prefix for units. So something like "ceu" or "uce" can be used instead of pgdce, if anyone finds it too long.

[pitfiend]

Well, after a quick look on the naming used by JEDI JCL, they use Jcl as identifier, followed by unit name, then class/component name. For JEDI JVCL, they use Jv as identifier, in some cases only initial unit character is used. For class fields the naming is direct, no prefix.
So I agree with our CE prefix and the JEDI guideline for the rest.

[pstudio]

Well, it seems like an interesting project you guys (and gal(s)) are undertaking here.

I'm sorry if the answer is written somewhere, but exactly how do you envision the final engine?
What sort of features do you dream this engine will have in a stable state?
It's a dead given that it will offer 2D/3D rendering, (basic) input system and other basics for game development, but what about the higher level stuff?
What's the overall arcihtecture of of the engine and a game developed with it? What kind of game object/entity handling will be offered?
Will the engine be more data driven and designer friendly versus focussed on just exposing functionality through an API?
Will there be an editor at some point?
What kind of engines would you like to compare this with? How ambitious of an engine do you want to create?

You probably haven't settled on many of these things yet, but at this point all I know is that you want to make a game engine. What that means to you I don't know.

[SilverWarior]

As you have guested we still didn't firmly decided on what exactly we will put in the final engine.
So far the general concensus is that we make it object oriented and of modular design.
We don't plan of focusing the game engine to specific game genre in the first place. But modular design should alow you to quickly focus the engine to desired game genre by including or excluding certain features.
Modular design will also alow you to extend the engine with your own code if needed.
We are leaving an option for making specific editor but at first we want to focus on the engine itself.
What is our wish for final product? We want this game engine is to be able to compare with other comercial game engines out there like Unity.
But my personal wish is that we make this engine even better than Unity

Anywhay we are currently in making of a basic design document for the engine.
Naturally as soon as more firm decisions are made we will notify the comunity about this since this is a comunity based project after all.