Naming conventions for classes that technically could/should have the same name

Question

Simple summary of a real problem:

1. I'm making a chess game
2. The engine that makes the chess do the magic is its own independent code (by design, for easy implementation)
3. I am now implementing the chess game into a game (Minecraft, but could be any mod-able game)

Problem:

1. The code that runs the chess has classes like "Board", "Game", "Piece", "Square", etc.
2. The code that runs the implementation, in an optimal world, would have classes with the same name, but that would make everything I'm doing in my IDE into a jungle

Question:

• What's the best way to solve this? I'm thinking about calling the core chess game classes into something like "EBoard", "EPiece", etc., "E" being short for "Engine" /edit: i do not mean for this to be an opinion based question; "best way to solve it" as in "most logical for the IDE to digest what I'm doing"

Note:

• This is not a "name that thing" question. It is partially, but I am also asking because I'm looking for naming conventions that IDEs can handle well. In prior projects I have made errors like naming classes in full upper case letters occasionally, and the IDE had problems recognizing that i was actually looking for a class. You get the idea.

Answer 1

Sometimes such classes would be named as Base- or Core- to indicate that they are to be extended in other implementations, so you'd have CoreBoard and CorePiece.

Depending on the language you're using, you could also use namespaces to distinguish between the two sets of classes. You could have a namespace for the Engine, and other namespaces for specific implementations. For example: jaylawl.games.engine.Board for the Engine's Board, and jaylawl.games.chess.Board for your Chess board.

Personally, I prefer the second option, but that may be language-specific.

---

If you plan to have both classes in the same scope, maybe you need better names. Perhaps instead of Board for the game engine, use something more generic, such as GameArea, to allow for future games that might not have a "board" in the same way that chess does. Maybe PlayerToken instead of Piece, GameAreaComponent instead of Square (one day you might want to have a game that has a board with a hexagonal layout instead of square), etc...