I realized that if a build a game engine with an OOP language, this game engine will not be able to be used by structured languages. I have already started to write my game engine(992 lines so far), but it is written in Object Pascal. And I am using the component library to create windows(or forms) which use classes.

- On the one hand, the game engine is easily writen if it is in OOP. And, since I am using FPC, the Game Engine could be multiplatform.

- On the other hand, tha game engine would be smaller if structured, but I will have to write it again.

Opinions are very, very, very wellcome.

By the way, as far, I'm writting the class that will manager the main loop of the game.

_________________
"Life finds a way." - Ian Malcolm
My WebBlog: PixelDeveloper
English is not my native language, so excuse me for any writing mistakes.

How do you plan on people using your engine? Will it be like a link-library? A stand-alone "game maker"?

If it is a link-library, you would probably be able to abstract things so that the language doesn't matter so much. For example, a DLL is usually written in C or C++, but can be used by any program language.

If you plan on something that does not allow a user to use your engine externally, then you could look into adding scripting capabilities to your engine.

Otherwise, more information is needed for us to give you any worthwhile suggestions.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

I planning this engine to be a static-library, then it will be a stand-alone executable as result.(I don't like DLL dependencies).

My great question is that: "How do you plan on people using your engine?"
I don't know if most of people use OOP or structured language for game programming. Knowing that, I will make the game engine according to the statistic, and considering the pros and cons I listed before.

_________________
"Life finds a way." - Ian Malcolm
My WebBlog: PixelDeveloper
English is not my native language, so excuse me for any writing mistakes.

I think designing and implementing a game engine is much easier in an object oriented language. If you don't care very deeply about the couple of people who use plain C for game programming, I'd just go ahead and continue to write the engine with an object oriented design. I can't think of any language that is used for game development nowadays that doesn't support object orientation in some way.
There are many drawbacks to not taking advantage of object orientation, but the only benefit of not using it is supporting C as far as I can see.

The usual suspects are as framework, or as library.

A library is you providing a set of routines/functions that can be called (and usually do something useful). For example, a drawing library, with functions like 'draw-line'.

A framework is where you provide the surroundings, and I fill in the blank holes. An example is the main game routine, where a user provides a time-has-progressed routine to update all his state after waiting. You provide the code that calls that routine 'when needed'.

I don't see any difference here, so what do you mean?

If you write a class with only data, and another class that operates on that data, you are doing structured programming in an OOP language. If you have a C struct, and a set of functions, with the first argument a pointer to that struct, you are doing OOP in C.

OOP is about the idea that you have data and code that belongs together. You can do that with any language. The only difference is that some languages povide a little more support for you to do one style, but that's about it.

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

I agree. No matter how you slice it, a programming language is just syntactic sugar for machine code (either CPU-dependent machine code for a specific CPU instruction set; or, bytecode used to program a virtual machine). Machine code is just syntactic sugar for memory operations.

OOP programming languages use classes and objects. Non-OOP languages use primitive data types (and often structs). However, while these abstractions may look different, and may behave differently, they are more or less the same under the hood. They have to in order to interact with the underlying platform, which runs on CPU instructions and memory addresses. Assuming your library or framework exposes its innards in a meaningful way, its utilities can be accessed.

If you do some sort of "special" formatting (in the form of specific object structures) that is specific to a particular language, that might be problematic -- but depending on the intentions of your library, using this kind of formatting would probably be completely unnecessary (if not undesirable).

Long story short: As long as your library can be given meaningful data, understand how to process that data, and return a primitive result, the only limits are those imposed by outside code (i.e. platform security, user error, etc.).

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."