D game development: a call to action

[Manu via Digitalmars-d]

On 19 December 2014 at 03:44, H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Thu, Dec 18, 2014 at 05:33:24PM +0000, Sebastiaan Koppe via Digitalmars-d wrote:
>> On Sunday, 14 December 2014 at 08:02:47 UTC, ketmar via Digitalmars-d wrote:
>> >>I find a much bigger problem is tendency for some programmers to
>> >>commit over-abstraction, sacrificing heaps of efficiency/performance
>> >>in the process. Most open-source engines are this kind, and will
>> >>never release a AAA game in a competitive market.
>> >ah, that's the other end of the spectrum (and my own problem too ;-).
>> >i'm still searching for good heuristic that will tell me when i
>> >should stop abstracting and just write the damn thing. ;-)
>>
>> Programming is a wicked problem; you only know how to do it after you
>> done it. So my suggestion is to just write the damn thing, and then
>> rewrite the whole thing if it bugs you too much. Essentially a lot of
>> rinse-and-repeat.
>>
>> I always do refactoring manually, so I developed a nack for knowing
>> how to write quick code that is easy to refactor.
>>
>> Ofcourse having clients screaming in your neck helps alot too :)
>
> IME, starting out with abstraction rarely works well. If you're a
> one-man team, you'll never finish abstracting; if you're a multi-person
> team, the whole thing will be so over-engineered, baroque, and
> inefficient, that by the time you're halfway through it you already feel
> like rewriting it (again).
>
> What works best IME is to just have a quick initial design to guide you
> (don't worry too much about abstracting it to the ideal, just have
> enough overall target items to set the direction so that you aren't
> getting yourself into the forest, and so that you have a rough
> high-level overview of how the whole thing is gonna fit together), then
> start coding. Most of the abstractions will come from refactoring, which
> should be done frequently. Abstractions derived in this way tend to be
> far more effective, because they will arise from actual usage patterns
> in your code, rather than some ivory-tower idealistic
> theoretically-beautiful model that will either never get implemented or
> is so far removed from reality that it's completely impractical and
> doesn't work well in practice.

I agree.

My rule for abstraction is to apply it as minimally as possible to
avoid any platform-specific api being called from front-end code.
That should be a good initial target. Further refinement will reveal
it's self in practise, in the way that you say.