Too hard way ?

Started by
4 comments, last by KulSeran 14 years ago
I was thinking about how hard and complicated things should be made. I was reading this article because I'm about to write my own particle system. http://www.gamedev.net/reference/programming/features/extpart/page2.asp Ok, it works great and it looks appealing, but it's not simple to code and, worse, it's not simple to read, as far as I'm concerned. In that case, one can write a particle system in a simpler way, avoid using a Policy-based design, maybe obtaining the same results, but perhaps with less code and a greater readability. Question is: does it really worth using that sophisticated designs ? thanks !
Advertisement
Quote:Original post by NiGoea
Question is: does it really worth using that sophisticated designs ?
As usual with design questions I would say that the answer is "for some people it is, for some people it isn't".

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

Quote:Original post by nobodynews
Quote:Original post by NiGoea
Question is: does it really worth using that sophisticated designs ?
As usual with design questions I would say that the answer is "for some people it is, for some people it isn't".


Yes but... it's like sometimes it appears to me that programmers like to make things hard just to prove they are skilled, just to be "fancy". I mean, that particle design doesn't carry any relevant improvement. It's just complicated to me :)
I'm always get a bit confused in front of this kind of coding...
I was trying to ask which is the limit between simplicity and usefulness. Yes, kind of philosophical question... sorry :)
Quote:Original post by NiGoea
I was trying to ask which is the limit between simplicity and usefulness.


Find the synergy between alternatives while leveraging best practices of both and remaining risk averse in proactively avoiding worst-case scenario of either.
Quote:
Original post by NiGoea
Yes but... it's like sometimes it appears to me that programmers like to make things hard just to prove they are skilled, just to be "fancy". I mean, that particle design doesn't carry any relevant improvement. It's just complicated to me :)


I totally disagree. It is mostly helping to break down the design to many pieces. If things don't help they simply won't exist. Just like someone told me before ECC memory isn't good for gaming, that's absolutely wrong!
Quote:
In that case, one can write a particle system in a simpler way, avoid using a Policy-based design, maybe obtaining the same results, but perhaps with less code and a greater readability.

Ha. Sorry had to laugh.
I've worked with 4 or 5 iterations of our particle systems at work. None of them please me yet.

If you make specific particle systems for specific tasks, it is really easy to write concise and easy to read code. But you end up with dozens of systems that all replicate some amount of base code and only have a couple differences.

If you make general particle systems with lots of options to select, it is really easy to write readable code that is super slow. It is harder to write general systems that are still very fast. You want to take care of as many choices as possible at the compiler level, so the particle system contains the minimal amount of code. The choices there are often between having fugly code that uses templates or #defines, or lots of duplicated boilerplate. Duplicated code is almost always bad, because it leads directly to mistakes and unmaintainable code. #defines and templates are ugly, but they are flexable. #defines though are REALLY ugly. Where as templated classes let you group together "policies" in one place.

The problem is that you are trying to strike a delicate balance. You want to be able to add new things easily since for any feature you can think of, YAGNI so don't write it now. Write the feature when someone needs it, just let them know they should be asking you for features. You want artists to be able to have as much control over the effect as posible, and be able to choose and combine everything at runtime. You want the system to be fast, since you have thousands of particles to update every frame and only a set window to do the update in before they start to hold up the rest of the frame.

This topic is closed to new replies.

Advertisement