Archived

This topic is now archived and is closed to further replies.

Metorical

Poll: So what is the hardest part of making a complete engine?

Recommended Posts

Metorical    580
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

Share this post


Link to post
Share on other sites
jamessharpe    497
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

Share this post


Link to post
Share on other sites
psykr    295
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.

Share this post


Link to post
Share on other sites
MauMan    344
The hardest part is finishing it. Programming projects are perfect and easy when there''s no code yet. When you''re chasing the 4th crash that disappears when you attach the debugger or you''re on the third day of trying to finish that feature that you thought would take 30 minutes it''s easy to get discouraged and give up.

That''s part of the reason why you see lots of "I have this great idea..." but very few "I finished my project" posts.

Share this post


Link to post
Share on other sites
Monder    993
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]

Share this post


Link to post
Share on other sites
yckx    1298
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

Share this post


Link to post
Share on other sites
dmounty    122
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.

Share this post


Link to post
Share on other sites
thebolt00    181
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

Share this post


Link to post
Share on other sites
Puzzler183    540
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).

Share this post


Link to post
Share on other sites
Newfound Ajarn    122
I'm on my third engine too (the second one was using the DX framework). I would have to say the hardest part is the documentation, mainly because I currently have very little for my engine and I keep on pushing it off to the side for a later date. One day I think I'll have to just sit down an write about the engine as a whole, and make a doxygen of it too.

// Edit: Spelling

[edited by - Newfound Ajarn on January 5, 2004 6:25:27 PM]

Share this post


Link to post
Share on other sites
for me, the hardest part is a good, fast, consistent collision detection system. and if we are talking game engine and not graphic engine, the network components were a bit of a pain as well.

Dredd
________________________________________

"To die with your sword still in its sheath is most regrettable" -- Miyomoto Musashi


Share this post


Link to post
Share on other sites
Deebo    128
The hardest part is staying focused and dedicated when you are coding those parts of the engine that are absolutly necessary for it to function right. It takes alot of thought and inginuity. It takes a long time. And when you are done, it seems like you are still at square one.

Share this post


Link to post
Share on other sites
Losec    139
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


Yup thats what I do sometimes

As for the question, again I think getting the perfect interaction between engine components is the hardest problem to overcome.




[edited by - Losec on January 5, 2004 10:52:21 PM]

Share this post


Link to post
Share on other sites
shurcool    439
To quickly answer your question, I think the hardest part in making a complete game engine would be the game engine design part, when you design the engine architecture and decide how it''s going to be structured. After that''s done (if done well), everything else is a piece of cake. Well...

---
shurcooL`

Share this post


Link to post
Share on other sites
hplus0603    11348
I agree that the hardest part seems to be finishing.

Part of that is probably that, to finish, you need to be able to make compromises. I think that the most successful people in anything (including life) are the people who are willing to make smart compromises to achieve something, and who can convince others to do the same.

For example: it''s more important to finish something that works, than to have the perfect design "under the hood".


Regarding the areas of the initial question, I would say that creating fun gameplay is the hardest part.

As for physics, graphics, networking, etc, it''s all just code.

Share this post


Link to post
Share on other sites
no one    133
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


LOL, same here. I normally can't sleep until I either test it out or atleast wright it down.

Anyway, I would say though other then that, the hardest thing for me is deffently the design, however, building a strong foundation for the rest of the engine to be built upon has been
a issue for me.



[edited by - no one on January 5, 2004 11:47:05 PM]

Share this post


Link to post
Share on other sites
JD    208
The hardest part for me now is also the design. To make a design such that it is both programmer friendly and retains the functionality and speed at the same time.

Share this post


Link to post
Share on other sites
Chacha    138
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.

Haha, that made me laugh. I do the same sometimes.

Share this post


Link to post
Share on other sites
MeshMan    134
The biggest possible problems you can ever go at is trying to make something you are not yet knowledgable for. Can you imagine building a house and then realise when you move in that you forgot to add the pipes for water and electric wiring? Well, this is exactly how most people end up. They think they want an engine, not knowing anything about how 3D collision detection math works and object orientated design patterns. You will probably never succeed to make a good engine in the first handful of engines you set out to make but it is what we all have to go through. Foundation also of what we base our design patterns on are also very important. The more aspects of an engine you research and cover, the more likely it will be a good engine that is ''useable''.

From my personal experience, i wished that before setting out my 2 year in development engine, i had created all the foundation classes that im now hacking in (such as loggers, debuggers!, memory management...). Im literally trying to take the floor boards up in my newly created house to fix the water pipes and the electric wires in! (If you know what i mean )

The hardest part of it all? Well, when i get a bug in my engine because of its debugging lackness, its like owning a 100 roomed estate and all the bulbs go off and you have to find out which bulb blew! I hope you get my point, its all about managing how objects can seamlessy talk to eachother, painlessley, and robust.

Share this post


Link to post
Share on other sites
cbenoi1    484
> Can you imagine building a house and then realise when you
> move in that you forgot to add the pipes for water and
> electric wiring? Well, this is exactly how most people end up.

Agreed. Unless it''s your 17th engine you write or adapt, the hardest parts are the original design and the very first versions of your engine. At this stage of the game you have speed, flexibility, scalability, adaptability, features, maintenance, etc all in your head and yet you have to come up with a solid solution to all those contraints AT THE SAME TIME. That is: everything plus the interconnections between the modules, and select the best compromises to achieve your goals.

There aren''t many ways around this problem, really. Either start with an existing engine you learn from and adapt to your needs, or be prepared to rewrite your engine N times. Either way you will find an educational value in the process.

-cb

Share this post


Link to post
Share on other sites
Extrarius    1412
quote:
Original post by Del Snd of Thndr
You guys are nuts! The hardest part is learning all the API''s used to build the engine! (...that''s probably why I''m not working on one yet...) lol

~del
You must not have written or tried to write an engine. The amount of information on APIs out thereis infinite when compared to the amount of information about design. The most difficult part of making an engine is most definitely the design of it on all levels.
After that, the most difficult part would be making the content for it after its done. A complete engine is a rare thing, but a complete game made using the engine is so rare that it is worth money! Few programmers are artists as well, so you usually need some help getting the art done and it isn''t easy to find reliable, talented artists that will work for free. You can buy stock art if you have some money, but I''ve found the commercial art made for indies usually has WAY too many polygons, or is only in a difficult to load/convert format, and other problems that stem from the art not being made for your specific project.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by Metorical
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

Since when was Game Logic part of an engine?

Share this post


Link to post
Share on other sites