OK, let me clarify what I just wrote above. This is from my experience of working on my personal 'pet' 'backyard' project.

When I started the personal 3D Engine Wrapper project, I only had this MFC template project in front of me. My thoughts were I would stack-build the first few bricks right here. So I did, I wrote classes around the generic MFC template. And that took some time, though. I kept adding more code until I got some functionality in, like loading from .obj and .mtl files. VBOs were defined so that the polygons got loaded in there. And so are the material subsystem were created as well.

Up to that point I was trying to get a render, and I did. The model got loaded into the VBO and the materials loading and rendering as well. When I saw the render I was stunned because Fraps was telling me FPS was right there at 60 FPS. Whoaaa! That's awesome for a start.

Once I got that working, I decided to split the code, this is the part where I had to carefully pick-out code that went to the Lib module. That took some work and effort on where exactly the split was. And when the smoke cleared, I finally got a solution file with two projects in there, the first was the Win32 project and the second was the Win32 Library project. Now, I'm happy because I got the engine where I want it to be.

I'm sure some developers will say it's too early to make the split. To me, though, I would do it exactly at the milestone which is basically carving the Engine right when you get the first render. From there, an Engine is now born, two codebase entirely going in its own direction.

Want to see the proof? Click the link below and download the project. See for yourself.

Quote:Original post by electricdragon
Whew! I made it all the way through the thread in one sitting....

Seems there are a lot of guys(gals?) all sitting at home making engines. I wonder what would happen if y'all got together and worked on the SAME engine?

You would have a lot of conflict, disagreement, chaos, and ultimately nothing would get done. It be more wasted effort than just having the separate entities work on their own separate engines.

As you can see there is already significant disagreement of the "fluff" behind the word "engine", so you can't expect multiple people to work on the same project when multiple definitions, specifically conflicting, and multiple views are in place.

Taking too much on your pitchfork is ussually what happens when thinking about a super engine that can do Super Mario Bros, Halflife4 and Flight Simulator at the same time. On the other hand, at school we learned its good to make several layers of abstraction. Instead of coding a very specific application, you'd first make a more abstract structure(-> 'engine'). Then use it later for the final (specific) part. Coding right away on the game itself feels bad, dirty, and it does happen that an additional feature doesn't fit in the puzzle later on. But I agree with those saying that coding an (big) engine ussually results in nothing... because its simply too much work! And if you ever finish it, its probably outdated already.

I made that mistake as well, several times. Although it also had to do with my skills. Bad engines lead to even worse products in the end. But luckily I learned from my faults, so each attempt to create a new engine gets better.

Currently I'm doing it a little bit different. I don't focus on the final game, and neither on an universal engine. Instead I focus on a sandbox kinda like editor. Just as important as the engine, are the tools. I'm making a big editor that can do every task that is finally needed in the game (materials, shaders, sound, scripting, models, mapping, and rendering). I have a relative simple demo scene in mind that I like to make with my editor, and I add its required features to the editor step by step. But instead of adding them quick & dirty, I'll put them in a nice abstract engine structure, with optional future features in my mind. Thanks to all the failed attempts in the past I finally know a little bit howto do it :) Ow, and for the real game-specific such as AI, events or game mechanics, I reserve scripts. This way it keeps flexible.


So, I'm building the engine and the editor, plus actual game content at the same time. I found out this works motivating. Which is extremely important if you're planning an ambitious (>2/4 years development) game. Creating editors is ussually boring, but now I can actually play something in my editor with nice graphics and gameplay == motivating. Creating an engine on itself without testing it in practice might not be a good idea either, but yet again, via the editor and some maps the engine keeps getting tested in practice.

Just keep in mind what you actually want to do. Skip the engine if you just want to make a fun game in a relative short time. If you plan a big game with lots of features, you'll probably gonna need an engine. Lot's of things can change in 2 or 3 years (especially with graphics), so you might need to keep the rendering system flexible. But don't try to make a super engine that is capable of everything... It's a waste of time.

Greetings,
Rick

When I'm trying to solve problems I haven't solved before, I keep my abstractions as shallow as possible. As the complexity (and my understanding of the problem) increases, I'll add abstractions. I'm always thinking about how to better abstract things, but I don't until I need to.

There's nothing worse than building a nice tower of abstraction, only to find you didn't fully understand the problem domain, and you have to hack and fight your abstractions, or tear them down and rebuild.