How to start with programming games

Tom Plunket <plunket@gmail.com> wrote in
news5cbt0h5cfgs3c0tb0edj91k0cv0nnl2oq@4ax.com:


> Practitioners of TDD write tests before they code, but not so
> bugs will get caught. They write the tests before the code so
> that they can develop the code to the specification more easily.
> The tests do serve as a safety net that may alert you down the
> road if failure cases are introduced, but TDD uses unit testing
> primarily (IMO) to guide development rather than hunting bugs.
>
Then skeleton based development is better.

Raghar wrote:

> > The tests do serve as a safety net that may alert you down the
> > road if failure cases are introduced, but TDD uses unit testing
> > primarily (IMO) to guide development rather than hunting bugs.
>
> Then skeleton based development is better.

It's not a skeleton, though. For all intents and purpose, it's
the software specification turned into code.

-tom!

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

> Nebu Pookins wrote:
>
>> Although it might not have been explicitly said, usually
>> when someone promotes the general methodology of "write
>> the tests before the code", they like to imply "do this,
>> and you'll catch lots of bugs!" Dan's remark, I think,
>> is that your test will only catch bugs that you can
>> think of, and if you can think of the bug, why not just
>> fix it directly instead of writing a test for it?

I think it's worth pointing out that the idea that unit testing only catches
the bugs you can think of is actually false. Let's say I write a function
to calculate the square root of a number. I can write a test to make sure
that this function, given an input of 25, returns 5. When I write the test,
I am not thinking of any specific bug that I want to catch. I expect the
test to pass. However, if some bug causes the function to fail, I find out
immediately. And if the test passes, I have a pretty good indication that
the function is at least somewhat close top correct.


--
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com

Tom Plunket wrote:

> Raghar wrote:
>
> > > The tests do serve as a safety net that may alert you down the
> > > road if failure cases are introduced, but TDD uses unit testing
> > > primarily (IMO) to guide development rather than hunting bugs.
> >
> > Then skeleton based development is better.
>
> It's not a skeleton, though. For all intents and purpose, it's
> the software specification turned into code.

A "library" is a module for sale. It must be complete, with wide interfaces
that all interact properly.

An application-specific module is not a library. It only needs to have those
interfaces and behaviors that its application needs.

TDD is among a category of practices that help make minimizing the feature
sets safe, because adding new features to old libraries is easy. If those
libraries lack tests, then adding the features is hard.

For example, suppose I use GraphViz's dot utility to translate a graph
(diagram) into SVG. Then I write a viewer that paints SVG on the screen. If
my viewer will not be sold as a "generic SVG viewer", I don't need to enable
the entire SVG specification within it. I only need to enable that narrow
subset of SVG that dot emits.

When the time comes to add different SVG abilities to the viewer, that
situation will guide us to add the correct features better than speculating
would have. And the tests on the SVG viewer will defend the earlier features
from the later changes. Without tests, one might think one has to implement
all features and then close down a module for changes. Tests make leaving
features out safer.

In some projects, the oldest code is the hardest to change. If the
application has wall-to-wall tests, and if the tests for new features call
that old code indirectly, then the oldest code can have considerable testing
pressure constraining its features. So the oldest code can be the _easiest_
to change.

However, this lecture is not the first thing the word "skeleton" spawned in
my mind ... ;-)

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

Rainer Deyke wrote:

> I think it's worth pointing out that the idea that unit testing only
catches
> the bugs you can think of is actually false. Let's say I write a function
> to calculate the square root of a number. I can write a test to make sure
> that this function, given an input of 25, returns 5. When I write the
test,
> I am not thinking of any specific bug that I want to catch. I expect the
> test to pass. However, if some bug causes the function to fail, I find
out
> immediately. And if the test passes, I have a pretty good indication that
> the function is at least somewhat close top correct.

Refactoring also helps resist bugs.

For example, today's method that takes 2, 3 and 5 and returns 10, 15 and 25,
respectively, tomorrow is unlikely to take 4 and return 301. Like algebraic
substitutions reducing an expression, duplication removal forces out special
cases.

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

> Why would you do that on a per-texture basis? Is your code so
> fragile that you have to exhaustively test every combination of
> pixels for every possible texture to feel confident that the code
> works as anticipated?

Are you forgetting that you said you could write tests that determined
whether a texture looked the same in a game engine as it did on the artist's
screen (several times I might add)? Now you can write a generic test to
ensure something "looks like" what the artist envisioned? LOL.

>> I mean, you're the one who said you could test to see if it
>> looked like it did on the artist's screen...
>
> Yep. Please enlighten me on exactly what it is that you think
> can be tested? Are you arguing that a code test should be able
> to know, "yep, this texture looks like concrete"?

That's what YOU are fucking saying Tom. Do you not understand your own
statements? YOU are the one saying that YOU can write tests that determine
whether a texture matches an artist's screen (and in another post, his
intentions.)

> Say you have a colorblind artist. Say this person makes a
> concrete texture, but it really doesn't look like concrete to
> someone who sees color more 'traditionally'. Are you suggesting
> that the game engine or the pipeline or something should change
> this artist's work to something that looks realistic? ...or
> should the engine and pipeline display what the artist generated,
> regardless of how incorrect it may be asthetically?

Are you a fucking nutter? Seriously...? I mean, YOU are the guy who has
repeatedly stated that you can write a test that discerns (to quote you
literally) "You test that whatEVER an artist gives you, it appears as the
artist intended." THOSE ARE YOUR WORDS. Do you understand what that
statement means in English? Not "do you understand what you intended to
write", but do you understand what your statement actually implies?

<snip bullshit matching your attempted 'about face' above>

>> Well, please, astonish us again. How have you written an
>> automated test to tell an artist that his reload animation is
>> crappy?
>
> Obviously if you change the parameters of the contest after the
> responses are in, it is trivial to refute whatever answers you
> don't like.

WOAH, woah, mister. Who is changing anything. I'll quote you AGAIN.

** Again, I know skinning works, and I can create composition bucket
** in which many animations can be blended together; however, I
** don't know how to write a test that tells me that the result of
** the blending is correct (and I'll hazard that nobody you know can
** either...)

* I don't know why you'd hazard that nobody I know can do so, since
* I have posted on exactly this subject in many places before.

Your response directly above states that you have posted exactly on the
subject of writing an automated test that can discern whether the blending
of multiple weight sets between disparate animations on a single skeleton is
programmatically correct. You DO realize that this is a subjective
evaluation you have said you "have posted on exactly this subject in many
places before", LOL?

> It doesn't mean that the respondents are retards,
> just that you have trouble making up your own mind. I have no
> need to astonish you again, nor have I ever stated that I could
> tell you programmatically that a given animation looks bad
> (although I could programmatically tell you in some cases that an
> animation looks bad, for instance by examining the continuity of
> the curves).

You're just backtracking now. Check your previous posts for the astonishing
things you claim to do and now claim are not things you can do.

> You're the one saying that it is impossible to take two known
> animations and blend them together and know what the resulting
> data is supposed to be.

Uh, no, stupid. YOU stated that you could write a test that discerned
whether SEVERAL (re-read the post) animations blended together produced the
correct blending. Don't blame me if you ASSumed that correct meant a
programmatic evaluation of the weighting (which would be fucking retarded as
writing the test would only test your blending code which you would have to
have already written to correctly evaluate the resultant set, just another
example of where you would not automate testing.)

> The assertion that:
>
> 1) You wrote code like this
> 2) It does what it's supposed to do
> 3) Given the inputs, you have NO IDEA what the outputs are
> supposed to look like

Uh, again, no. YOU are assuming that the outputs are syntactically
evaluated when they are not. This is the entire problem with your series of
posts which you are only trying to repair now (perhaps realizing that your
usage of the English language was incredibly loose in the beginning [giving
you the benefit of the doubt that you were trying to say the same thing all
along].) You have repeatedly stated that you can write automated tests that
can evaluate WHAT THE ARTIST INTENDED. Need I quote you yet again? That is
a subjective and semantic evaluation which you could not possibly evaluate
without an 'AI' in the traditionalist sense (any programmatic approximation
would be limited and of questionable value.)

> seems to imply that you don't understand the algorithm.
> Enlighten me and explain to me that those three points could
> possibly be true and yet you actually understand what you're
> talking about.
>
>>> There is an important ambiguity in your statement, though. What
>>> is "correct"? Is it "looks right"? Well, that is hard to test
>>> for. If it's, "performs algorithmically as I intend," then
>>> that's trivial to test for.
>>
>> Starting to backtrack and change your position to "performs
>> algorithmically" Tom? LOL...
>
> Who's backtracking?
>
> Show me posts within which I'm making a conflicting statement.
> Message IDs are sufficient, but if you'd rather cut'n'paste for
> your own amusement that'd be fine. Message IDs are still
> requested though so I can verify your research.

No problem, I have directly quoted you. I'm sure it will take you the 3 to
4 seconds it took me to find them for you. If you can't find them, say so,
and I'll gladly supply message IDs for you as well.

>> I was wondering when that would happen.
>
> Me too.
>
>> The importance of everything I have been saying to you (and you
>> can re-read to confirm all of this) is that YOU CANNOT discern
>> programmatically via automated testing ambiguous semantic
>> evaluations which are CRITICAL to game development and are
>> (apparently) one of the most serious of pipeline issues regarding
>> resources.
>
> Your loss, then, if YOU cannot do this in any case. Your loss
> also if your content creators don't know when an animation looks
> good, or when a texture looks like it's supposed to, or that the
> game is no fun.

Uh, some of these are the things that YOU stated your automated tests could
do, I actually espouse the human in the loop for this sort of test (news
flash: you don't.)

> If these sorts of things are truly the most
> serious issues in your pipeline, well, I find it hard to believe
> you're making games at all.

LOL, what are your art pipeline issues? I use Granny mostly so yes, our
pipeline issues are all subjective. What are yours?

>>> I would suggest (again) that if someone can't come up with a
>>> trivial way to test this, they don't actually know how it works.
>>
>> Of course you would.
>
> Oh the stunning wit! Thanks, WTH, I rarely meet someone so
> intellectually stimulating!

Ah, but I wasn't trying to be witty. I can only surmise that you were.

Once you actually learn to write properly you may find that you can converse
well with other English speakers. You seem to get confused about what you
wrote as opposed to what you meant to write.

WTH

In article <o5cbt0h5cfgs3c0tb0edj91k0cv0nnl2oq@4ax.com>,
plunket@gmail.com says...
> [...]
> > This is, however, a misunderstanding that might be a result of
> > too much hyping of the "powers" of testing.
>
> Perhaps, coupled with the non-obvious fact that "test-driven
> development" is more about development than it is about testing.

I'm curious, is the example given on the following page

http://www.differentpla.net/node/view/58

an accurate description (literally) of how you think we
all, using TDD/TFD, should go about writing a function
to convert a decimal number to a Roman numeral?

If not, how does that account differ from your view
of TDD/TFD?


Christer Ericson
Sony Computer Entertainment, Santa Monica

Christer Ericson wrote:
> I'm curious, is the example given on the following page
>
> http://www.differentpla.net/node/view/58
>
> an accurate description (literally) of how you think we
> all, using TDD/TFD, should go about writing a function
> to convert a decimal number to a Roman numeral?
>
> If not, how does that account differ from your view
> of TDD/TFD?

I can't answer for Tom, but that is a good example of the method Tom
and Phlip have been advocating as far as I understand it.

WTH wrote:

> Now you can write a generic test to ensure something "looks like"
> what the artist envisioned? LOL.

<Yawn> Literally, it could be surmised that that is what I meant.
I hear you on this. I prefer not to get into these Asperger's
Syndrome-fueled debates however, as the nit-picking and border
case literal adaptation has no place in worthwhile discussion.

> > Yep. Please enlighten me on exactly what it is that you think
> > can be tested? Are you arguing that a code test should be able
> > to know, "yep, this texture looks like concrete"?
>
> That's what YOU are fucking saying Tom.

Typical troll, not sure why I was so slow to pick up on it.
Bored now. Goodbye.

> (and in another post, his intentions.)

If anyone can enlighten me as to how any software might be
telepathic to this degree, I'd be interested in hearing about it.


-tom!

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

Christer Ericson wrote:

> > ...coupled with the non-obvious fact that "test-driven
> > development" is more about development than it is about testing.
>
> I'm curious, is the example given on the following page
>
> http://www.differentpla.net/node/view/58
>
> an accurate description (literally) of how you think we
> all, using TDD/TFD, should go about writing a function
> to convert a decimal number to a Roman numeral?
>
> If not, how does that account differ from your view
> of TDD/TFD?

Well, I wouldn't say that everyone "should" do that, but yes that
is an accurate representation of how TDD works in my world.

For this example, it seems like doing it TDD is probably a bit
slower than doing it "hack 'til it works," but at the same time
it's (hopefully) fairly easy to see how this method of
development can find problems while you're writing the code and
provide a stable base upon which to build other code.


-tom!

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