Community Engine Announcement Discussions

[SilverWarior]

Now consider another situation:
Programmer has a unit named Geometry. The game engine includes a unit named PGD_Geomerty. There most likely will be no unit name conflict ever.
Even if both units contain equally named type, like TVector, then the programmer will be able to refer both of them like:
Geomerty.TVector and PGD_Geometry.TVector. Such type name conflict is even more unlikely to occur if you consider that some units use Geometry, other units depend on PGD_Geometry, but it is likely that there are no units which depend both on Geomerty and PGD_Geometry unit.

That is why I suggest using prefix for unit names, but not for type names

Now you consider this situation:
As you suggest you have two units. One is named Geometry and another is named PGD_Geometry. Both of them contain equaly named type TVector.
In unit geometry TVector is defined like so:

type
  TVector = record
    X1: Integer;
    X2: Integer;
    Y1: Integer;
    Y2: Integer;
  end;

In unit PGD_Geometry TVector is defined like so:

type
  T2DPoint = recod
    X: Integer;
    Y: Integer;
  end;

  TVector = record
    P1: T2DPoint;
    P2: T2DPoint;
  end;

Now you don't have any unit which would use both Geometry and PGD_Geometry at the same time so you don't have any problems with naming conflicts.
But you are using these TVector-s in two different units. One uses Geometry and other uses PGD_Geometry.
Now tell me this when you are writing codein any of these units how do you know which TVector type definition are you using. Yes you are using only one and compiler will always know which one. But how will you know which one are you using in that particular unit.
Sure you could add unit name before type so you use Graphics.TVector or PGD_Graphics.TVector so it would become perfectly clear which definition are you actually using. But that is almost the same as if you are using type prefixes in the first place.

So you see general advice is to use prefixes for both unit names and type/class names.
Prefixes for unit names can be longer like PGD_Comunity_Engine_Graphics.
But prefixes for type/class names sould be short ones. Preferable prefix size for types/classes is 3 characters or less where 5 chareacters long prefixes are considered the largest allowed.

[dj_sharp]

But how will you know which one are you using in that particular unit.

Ctrl+Click to go to type definition, then click "Back"

Another possibility: hover mouse cursor over type. I'm not sure if there's such feature in Delphi, but in Lazarus if u have variable declaration like

var
  x: TVector;

then when user points mouse cursor over TVector, it displays hint which says in which file this type is declared like:

TVector = record
C:\Dev\MyLibrary\Geometry.pas

I believe that Delphi since 2007 does this too

If u use Notepad, than it it would be indeed more difficult to say which type u use in current unit. Perhaps I would then have to scroll file to top to observe used unit list. But when using IDE there should be no problem

[User137]

...One uses Geometry and other uses PGD_Geometry.
Now tell me this when you are writing codein any of these units how do you know which TVector type definition are you using. Yes you are using only one and compiler will always know which one. But how will you know which one are you using in that particular unit.

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.

[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.