How to start with programming games

Christer Ericson wrote:

> > > Oh, bummer. Who would have guessed?
> >
> > Yeah, amazing that one research project from one University dated
> > from 2002 explains everyones experiences ever with test-first.
> > Surely nothing's been learned since, and surely the Germans
> > researched every software project?
>
> Oh, so you _were_ bothered to download and read the
> PostScript file after all. Can't trust you on anything you
> say, can I.

??? Don't trust that which you don't want to, but since I didn't
read the paper I don't know what you're thinking I read in it.
From the website one can glean that they're German, and from the
date on the website, one can surmise that the paper dated '2002'
was written then. Otherwise?

I have since hoped that Acrobat Reader would read PS files, but
the completely unrelated document that I downloaded from the
University of Kentucky did not open in that program.

> Well, Philip seems to be convinced TDD requires refactoring
> (I surmised this from him saying "Tom, TDD requires refactoring.")
> and considering how much he obsesses about the topic, I'd believe
> him over you on this. In other words, betcha you're wrong.

Are you going to tell me now that since that example was written
in C++, that both TDD and refactoring, jointly and separately,
require the use of C++?

-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

Christer Ericson wrote:

> As I've said numerous times to you, these days, programming is
> (in general) not a bottleneck in professional games production,
> asset production is.

FWIW, I've never had a game job where this was generally the
case. Certainly times in which one is waiting for assets, but
during the end-of-development as well as the beginning, the
coders are the ones working while the artists are the ones being
highly-paid testers (or simply just surfing the web).

In other words, just because Christer said it doesn't make it so.

-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

Phlip wrote:

> Tom Plunket wrote:
>
> > The fact that TDD enables quick and painless refactoring confuses
> > some into thinking that TDD requires refactoring, when in fact
> > TDD requires nothing of the sort.
>
> Tom, TDD requires refactoring.

I stand by my assertion that while TDD enables refactoring,
perhaps even begs it to occur, that in no way does TDD require
it. After all, if all possible tests pass then there's no reason
to change the code further (excepting things like developer
sanity).

Regardless, refactoring is done in the absence of TDD, so saying
that one does it when doing TDD is a bit pointless. Like saying,
"I don't like sushi" when at McDonald's, the statement may be
accurate or it may not be, but it really doesn't matter because
it doesn't have any bearing on the question of what you're going
to be ordering.

Anyhow, I did so well. I stayed away for so long. I got lured
by the promise of intelligent discourse only to find a master
troll at his finest.

When will I learn? Oh- I have already. I just forgot to
implement what I had learned.

-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

Christer Ericson wrote:

> (I'm so narrow-minded that the long slow bug hunts that come to
> my mind have been those that no methodology would have found, so
> help me here.)

....he says, having only tried the methodology that he uses.
<sigh>

Whatever, but it is funny. Christer is a funny man, after all.

Read this thread if you care.

http://groups-beta.google.com/group/...7c6cfd441c0390

If Outlook screws the link up, try a better newsreader. If
Gravity screws up the link, ditto.

-tom!

--
There's really no reason to send a copy of your
followup to my email address, so please don't.

In article <879uv0tgg9ct0l8efmpo2668hrf47i87uc@4ax.com>,
plunket@gmail.com says...
> Christer Ericson wrote:
>
> > As I've said numerous times to you, these days, programming is
> > (in general) not a bottleneck in professional games production,
> > asset production is.
>
> FWIW, I've never had a game job where this was generally the
> case. Certainly times in which one is waiting for assets, but
> during the end-of-development as well as the beginning, the
> coders are the ones working while the artists are the ones being
> highly-paid testers (or simply just surfing the web).

Well, this is a matter of process, of course. If, say, you
have little art in your game, then art is unlikely to be
a bottleneck.

However, for the two times you mention, programming should
not (but may of course be in some instances, which is why I
said "in general") be bottlenecks, because...

a) Games are increasingly data-driven. This means that
a lot of tasks previously performed by programmers are
now performed by artists and designers. (Setting up of
trigger volumes, triggering tasks, collision geometry,
etc.) These are areas that tend to have a lot of QA
bugs reported at the end of a project. Furthermore,
data-driven engines have less code, resulting in less
code bugs overall. Those bugs are also found earlier,
in that the code becomes static much earlier than in
a non-data-driven engine (because its the data that
changes, not so much the code).

b) As for the start of the project, sure, if you are writing
an engine from scratch then that clearly is a programming
bottleneck. Today (and wise from having been there) I
would expect any clued-in professional developer in
that situation to buy, borrow, or steal an existing
full-featured engine to allow asset creation to proceed
so as not to allow programming to be a bottleneck.

In other words, I'm not claiming that the scenario you
mention does not happen (it does). I do claim it is going
away, however, simply because of changing methodologies
(data-driven engines) and because you cannot afford to
have artists sit doing nothing for 6-12 months at the
start of a project.


> In other words, just because Christer said it doesn't make it so.

Indeed not.


--
Christer Ericson
http://realtimecollisiondetection.net/

In article <29buv05eec2uvo74t902vfm7v4iam8o4bn@4ax.com>,
plunket@gmail.com says...
> Christer Ericson wrote:
>
> > (I'm so narrow-minded that the long slow bug hunts that come to
> > my mind have been those that no methodology would have found, so
> > help me here.)
>
> ...he says, having only tried the methodology that he uses.

Well, Philip avoided answering the question about what "slow"
is in terms of time, but to me "long slow bug hunts" means
those intermittent bugs that happen once in a blue moon and
when you track it down a month(*) later, it turns out to have
been, say, a race condition between the completion of a DMA
and the disposal of a resource linked to the DMA list.

That, to me, is a "long slow bug hunt". As I said, perhaps
I'm being narrow-minded in my interpretation. Help me out
here, what is "long slow" in actual time?

Also, tell me, how does TDD help track down the race condition
above?


(*) Not debugging time, but actual time passed since the
bug was first observed, perhaps occuring, say, 3-4 times
between first occurance and being solved.

--
Christer Ericson
http://realtimecollisiondetection.net/

Tom Plunket wrote:

> I stand by my assertion that while TDD enables refactoring,
> perhaps even begs it to occur, that in no way does TDD require
> it. After all, if all possible tests pass then there's no reason
> to change the code further (excepting things like developer
> sanity).

<argumentum type="ad authoritatum">
The first example in the first TDD book shows
how to write tests and a fake implementation,
and how refactoring to merge specially selected
duplication. The point is tests lead design.
</argumentum>

> Anyhow, I did so well. I stayed away for so long. I got lured
> by the promise of intelligent discourse only to find a master
> troll at his finest.

Sorry. I'l try not to do it again. ;-)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Tom Plunket wrote:

> Read this thread if you care.
>
>
http://groups-beta.google.com/group/...7c6cfd441c0390

The *way* I use a debugger has changed significantly. First*ly, I
don't use it very often. The act of keeping the program pas*sing all
its tests every few minutes means that there just aren't eno*ugh bugs
to require debugging. Moreover, what bugs do exist are simp*le to find
because: I just added them, and/or they are discovered by a* failing
unit test that pinpoints them.

The amount of time I spend debugging has shrunk by a huge am*ount, and
the need for a really good debugger has diminished.


The key is to make very tiny changes, and execute *all* the *unit tests
between each change. The size of each change should be just* a few
minutes.


-----
Robert C. Martin

Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > writes:
> Also, tell me, how does TDD help track down the race condition
> above?

I would say the help is when you have constructed a test case that exercises
the race condition (if you can!), then it is much easier to fix the problem.

In my experience simply using the debugger in this case would not work since
the race condition would often not occur due to the timing differences when
pausing and stepping.

However, given that you would have a test driver dedicated to running the
scenario, it is pretty easy to tweak the code with measurements and
alternative variations until you have a sense of where the problem is.

That is, the test case focuses the situation to the problem at hand.

Note: I do not in fact strictly practice TDD. But I always set up regression
suites with "important" test cases, and any defect automatically becomes a
test case.

For me, the combination of a test case and debugger makes most bugs solvable
in just minutes to at most a few hours. The "long slow bug hunt" is a rare
occurence. That last time that happened to me was with memory leaks in a large
Java application.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

>> The point is tests lead design.

That alone is enough to mark you out as an imbecile at any ISV. Stick to
consulting and working for tire manufacturing concerns.

WTH