OK, I''m in the design phase for my game engine and I''m considering implementing an abstraction layer over at least the 3D portion of the API (to support both DirectX and OpenGL). However, I''m not a multi-person team (heh) so the time I have available to do the work is limited, and I''m wondering if it''s worth the effort to abstract away from the 3D API if I''m not planning on going multiplatform. Any comments, observations, etc. - especially from folks that have actually done this - appreciated.

My advice would be to ditch the abstraction and just get things working. Especially if this is your first game, it should be small-scale. Too many hobbyists get entrenched in writing their own library to wrap a graphics API that they never get anything done.

yeah I agree, do everthing as quick and dirty as possible. Getting it done at any cost should be your goal. I''m serious.

Yeah, api abstraction is good, but only include things you REALLY need. Make it really simple. Only add things to the wrapper when you truly need them.

That''s a very tough question.

If this is your first attempt at writing any kind of game or engine, or if you only want to get a game working and don''t care about how well the code is written or if it''s reusable, then I''d say don''t worry about the abstraction.

However , if you''ve had practice in writing games/engines, or you want to learn how to do things the right way, then I would highly recommend doing API and also OS abstraction, for several reasons.

1) It teaches you to think ahead and design a very flexable engine.

2) You never know if you want to port your game to another OS in the future, or another API, so planning ahead for the future is a Good Thing. This is the same reason I recommend designing your game with a client/server architecture, even if your game won''t support network play. If you ever change your mind and want to add it later it will be impossibly unless you plan ahead. Besides, it''s great practice for when you do the real thing.

3) You learn a lot about the pluses and minuses of not just each API or OS, but also on each compiler. The techniques and tidbits you learn are invaluable.

4) Not doing OS and API abstraction teaches you bad programming habits. A lot of people will disagree with me on this point, and that''s fine. IMO it''s just way to easy to say, "Hmmm, the graphics subsystem needs a HWND so I''ll just make it a global variable", or, "I need to write a class for opening/saving files, and I''ll just use the the Win32 functions because it''s ''easier''". Doing things the "easy" right now means a lot of code rewrite in the future. Code reuse is a Good Thing.

I''m in the middle of writing my OS and API independant 3D engine and I''ve learned more than I thought possible. Of course I''ve ran into road blocks left and right and it''s taking me a lot longer to write, but it''s totally worth it, imo.

If you don''t write an OS/API abstracted engine now, then I''d do it sometime in the future.


- Houdini

I would suggest a simple abstraction interface so that most of your code does not interact directly with directx or opengl. I like the small abstraction because directx functions and constants are hard to remember and generally ugly.


Mike

no no no, these people are leading you astray. Abstraction is great but death for beginners. I worked for so long trying to make a great game. I worked for a year and gave up. Then I learned a bit more and started making another game. I got halfway done four times, each time the code was prettier than the last but generally did less, after a year I gave up. Then I set out to make something simple and finished in a few days. True I did learn a lot from the complex projects I attempted as a newbie, I ended up learning half the stuff in Design Patterns on my own simply through trial and error. However I never finished anything and there is something about finishing that is important. Make a simple game and then work up. Bite off something small, because it will grow as you chew on it. Later you can rewrite one of your ugly programs and make it nicer or just make a different program and make that one nice.

quote:

---

Original post by Scarab
OK, I''m in the design phase for my game engine and I''m considering implementing an abstraction layer over at least the 3D portion of the API (to support both DirectX and OpenGL). However, I''m not a multi-person team (heh) so the time I have available to do the work is limited, and I''m wondering if it''s worth the effort to abstract away from the 3D API if I''m not planning on going multiplatform.

Any comments, observations, etc. - especially from folks that have actually done this - appreciated.

---

I''ve been making a C++ modular engine for almost a year now (in my spare time) and only now Im getting somewhere. I''d say: aim low if this is your first time. I''ve done more rewriting so far than I care to tell. Its painful to have to change a baseclass and then all derived classes because you have misjudged something or you need a feature. ''RSI, here I come'' is what I think every tine I have to do that.

Having said that, Im 18 years old and I have never done such a thing before plus I hope to reuse this engine for every 3D game I am going to make in the future.

It just depends on your goals I guess. Quake3 for instance, has a very poorly designed engine (from a OO point of view) but it definatly kicks ass for a certain genre games. It has relatively little sourcecode too.

Well, this surely isn''t my first effort, especially if you count the five titles I worked on for the Compaq/Fisher-Price Wonder Cruiser (I know, kids games, but what the heck) or all the open-source work I did on RealityFactory using the Genesis3D engine (http://www.genesis3d.com/~rfactory now spun off on its own)... so I don''t think I qualify as a beginner... not a heavyweight, though, which is why I solicit opinions here!

I''m going to go ahead with building on a thin abstraction layer because (a) it encourages good design and (b) there is the REMOTE possibility I might want to port this to the Mac or Linux at some time. And it''s _only_ the engine, I''m not doing a whole game - I''m focusing on technology development for potential outside users. I''ve planned an 18-24 month development cycle so I can take the time to Do It Right and not just rush through and produce an unmaintainable mess! I''m a bit concerned about the overhead such an abstraction layer might impose, but considering what''s going to be the "low end" system in about a year or so the abstraction layer overhead will be miniscule compared to the rest of the system.

Slightly OT, I''m using UML to help in designing the engine - we use it at the office to design realtime embedded systems, and while a game engine isn''t typically embedded (unless you''re talking consoles) realtime it certainly is! It''s an experiment.. applying modern software engineering practices to game development.. we''ll see if it works or not, hee hee!