I was inspired to ask this question after reading the post about how hard graphics programming is. Basically what I want to know is what you think is the hardest part of an engine to make. Here are a few options although *you are not limited to these choices* Game Logic Physics GUI Audio Graphics Personally I''ve done a lot of Graphics and Physics, with those systems getting somewhere near useable I also get to do some game logic (which is by far the easiest to do but also the easiest to get wrong in terms of making a good/fun/balanced game). I''ve never tried audio programming although I think most people involved in audio programming have some background in music (please shatter this misconception if you can). Creating a GUI for a game is actually quite daunting as the benchmark is being raised every year and you don''t really have some fancy hardware to do it for you. So my vote goes to GUI programming (non windows apps e.g. custom GUI) Anyway, your thoughts -Meto

quote:Original post by neurokaotix
IMO, the hardest part of making an engine is creating the perfect structure for which each component interacts with one-another. That is far harder than the graphics or the physics, and especially GUI programming.

Funny, that''s exactly what I was going to say, the smooth interconnection of the parts of the engine is probably the hardest part.

James

That''s definitely one of the hardest parts; as a programmer, you want to make everything perfect (if time allows), and coming up with an elegant solution that satisfies you can take some time to create.

Other than that, I''d say that my "programmer''s block" is getting the motivation to finish the project once I''ve found a design flaw. For some reason, when something breaks because it was poorly designed, I lose the urge to continue.

Getting the design right is definetely the hardest part. You can easily right little graphics and physics demos that can demonstrate certain things you'll be using in your engine (if you can't then you're not ready to write an engine). The hard bit is getting all the little things you can code demos for to fit together. I've tried making many engines I ended up abandoning them at the first design fault I've found. I've now accepted that I'm never gonna to create a perfect design so with my current engine I just keep on going working round the design flaws, and I'm gonna keep on doing that until I've got a game or two running on this engine.

[edited by - Monder on January 5, 2004 3:50:44 PM]

The most difficult part for me is finally giving up on a problem for the night and going to bed, then realizing how to solve it while in that hypnogogic state right before sleep, and wondering if I should get up and go back to coding, or if I should wait until morning and hope that I still remember the answer.

yckx

quote:Original post by yckx
The most difficult part for me is finally giving up on a problem for the night and going to bed, then realizing how to solve it while in that hypnogogic state right before sleep, and wondering if I should get up and go back to coding, or if I should wait until morning and hope that I still remember the answer.

yckx

Now thats the truth . "I must remember this for tomorrow after a good nights sleep... oh, I''ll just do it now." On a more serious note. The design is the most important aspect of engine design. Because of the nature of OOP, the individual components may be fairly straightforward to code... but making a sensible and workable solution for interaction of these simple little units is the difficult part. Even on simple little structures, it''s easy to spend a lot of time deciding if certain objects or methods should be part of one object or another. Its the subtlety of designing a sensible interaction system that feels intuitive to the end user (programmer). The real key is to remember... there is no absolute correct. Where certain objects should go... can depend heavily on HOW the engine is to be used. What I like to do is this... think of a design for whatever application I imagine the engine being used in... Then on any area you feel uncertain of, think about several other applications that might use your engine. Does your design decision make sense for all of them.. if so... stick with it. If you spend all your time tweaking the semantics of interaction... you''ll never get it done.

The key is this. ALWAYS design first... theory BEFORE practise.. but don''t feel that your original design is set in stone, and slavishly follow it. If it doesn''t work for you, go back.. alter it, and analyse the ENTIRE design again (logically... from a highish level). Does it still work as a whole? Then your engine is evolving into something better :D.

In my experience its a non-coding part of engine-making that is the hardest, documentation.

Even if you just make an engine for your use you need documentation. Say you complete it in a year or two, and then realize you need to change something you did in the beginning, but cannot remember how, and why, you did it that way -- thats when documentation comes into the picture.
Also if you plan to sell/release it to someone else, documentation will become a major factor. Nobody wants to use an engine they cannot use becouse there is no documentation telling them howto.

Also, from what i''ve seen, the biggest problem with documentation is keeping it up to date with changes done to code (if you write it at same time) or that it takes so much time.

(A set of doxygen generated files isn''t equal to good documentation.. its a part of it, but not enough, so no need to point that out

The reason i think documentation is so hard to do is that its boring. Coding is most of the time fun, sometimes almost fun, and sometimes just "it have to be done". Documentation ranges from "no, please, don''t force me" to "i will never do that again!"


my 2c
-Marten

I''m making an engine and I''m on the third try, this time a complete recode. I actually have a set up I like now, because before, the code didn''t interact well or seperate the game from the engine well enough. So my vote goes to interaction of components. Now that I have that worked out, I''m well on my way to the engine being completed (I have 1300 lines done, mostly windowing, input and graphics interface code).