D game development: a call to action

[H. S. Teoh via Digitalmars-d]

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.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.