   Brainstorming engine design
  I'm in the process of putting together an engine of my own, and am currently brainstorming how it will all fit together. The core will be written in C++. I want to use erlang styled C# scripting for each game object or "actor." That is to say, each game entity will have it's own lightweight "thread" which executes cooperatively with the rest of the objects, in a linear manner. These scripts communicate with each other by passing messages. It would be event driven. This way objects can easily be scripted without the use of complex state systems. Second Life has a similar system. I chose C# because for one thing I know it, and it offers a lot of features and is easy to program with. It also offers greater performance than Python or LUA.One of the hardest things I see is how to interface the two; the C++ engine core and the C# object scripts. The whole idea of this engine is to offer a reusable and feature rich framework on which to build games. The idea is that the only programming the game developers should have to worry about is the object scripts, which will be easily written in C#. My idea was to keep the engine (or perhaps framework if you want to look at it that way) separate of the game. The engine would be installed independently of the game. I was thinking one way to accomplish this may be to have be to have the game be a simple front-end written in C#. It's only purpose would be to host the object scripts and provide an execution point for the game. It would than communicate with the actual engine which is a separate process using IPC (perhapse named pipes). Maybe this isn't making much sense to anyone yet, but if it is, I'd appreciate your thought on the matter. I'd love to get started on this, but I still cant quite figure this concept out yet.   
  If anyone here simply has no idea what I mean by erlang style scripts, there is a post right here on GameDev that goes into it's significance pretty well.http://www.gamedev.net/community/forums/topic.asp?topic_id=463963   ;  Someone has to say it.  "Don't make engines, make games."theTroll   ;  First things first: what are the requirements for your engine?Performance isn't so much language-specific as it is interpreter-specific. From what I've seen, there are various Python interpreters around, some specifically aimed at performance. Just saying, it's not only the language that counts. Besides, 'fast enough' is good enough. Which is where requirements come into play again. ;)Separating engine code from game-code makes sense, but having the engine as a separate application? Is there a specific reason for that? It sounds like you're overengineering things without taking into account what's actually practical. Just keep things simple, to the point. Write only what you need. YAGNI.Taking that one step further, and as TheTroll already mentioned, are you sure you need to roll your own engine, or is there an engine out there that already suits your needs?   ;  Well, may main reason for using C# is because I love C# and hate both Python and LUA. Also, I want to build an engine, not a game. I don't even think of it so much as an "engine" because that terminology seems flawed. I'm thinking of this as more of a game framework.   ;Quote:Original post by lpcstrWell, may main reason for using C# is because I love C# and hate both Python and LUA. Also, I want to build an engine, not a game. I don't even think of it so much as an "engine" because that terminology seems flawed. I'm thinking of this as more of a game framework.Have you at least made a game before?   ;Quote:Original post by nobodynewsHave you at least made a game before?I've made games based around other engines and have had a limited amount of OpenGL programming in a C++ / Unix programming environment, though I fail to see why it is necessary for you to know this.   ;  Instead of creating a game engine you should create a simple game. Write a simple FPS and use good OOP techniques so your code is reusable. Attempting to write one kick ass engine to do all things is a neat idea but the reality is each engine will require some molding to the individual game idea.Cookie cutter game engines seem to produce a generic game in the end.   ;  I knew this was the reaction I would get. I didn't come here asking what my project should be or if my project was worth it.   ;  ejthayer makes a good point, aiming right at the core of the problem. An engine is often tailored to a specific genre, for various reasons. What kind of game is your engine's focus? Do you want to create an extremely generic engine, or a more specifc one?   