How to start with programming games

Gerry Quinn wrote:

> The only code I've ever seen from you (script for creating a 3D graphic)
> had no tests at all.

Would you test output-only HTML?

I would if the HTML conveyed business logic. I would not test every <table>
and <em> tag.

That particular project has wall-to-wall unit tests, including tests on the
OpenGL layer, tests on the math layer, and these acceptance tests:

http://flea.sourceforge.net/reference.html

On that project, I have had the occassional bug-hunt, and I have used a
debugger in the C++ layer, to see what's going on, and to learn how the
libraries work. However, I have never used a debugger on the math layer. It
is all in Ruby, it's the oldest part, and I wrote it by using Lauren Lapre's
LPARSER in tests that forced the Ruby layer to do the same things.

Here are some tests on the math layer:

def test_validTriangle

assert ! validTriangle(
[ [0, 0, 600],
[0.0, 17.36481777, 698.4807753],
[0, 0, 600] ], 0, 1, 2)

assert validTriangle(
[ [0, 0, 600],
[0.0, 17.36481777, 698.4807753],
[0, 0, 800] ], 0, 1, 2)
end

'grep test_ *.rb | wc' reveals 97 more like that.

And here's a test to check that a graphic output is crooked:

def test_Crooked
egg = startOvum 4, 33, 25
ax = egg.newRootAxiom('A')

ax.tube.right.half.left.tube(10).up.half(10).down.
halfTube.right.halfTube(1.1).hop.hop(2.1).link(ax)

growAndCompare [ egg, "4\n33\n25\nA\n" +
"A=F+z-F(10)^z(10)&Z+Z(1.1)gg(2.1)A\n@\n" ]

end

That test compares my turtle graphics commands
("right.half.left.tube(10).up.half") to the traditional (unreadable) LPARSER
graphics commands ("+z-F(10)^z"). Each time the test runs, it evaluates the
new commands, and evaluates the old commands by shelling to LPARSER.EXE.
Then the method growAndCompare() reads the output of both systems and
compares each value, to show their shapes are the same.

You should see the source to LPARSER - it's a mishmash of structureless
GWBASIC. I am sure Lapre debugged it for a long time!

Over my project's lifetime, that project has had a very low bug rate,
probably around one a month. Because of those tests, a user who writes Ruby
code into the GUI doesn't need to write more. But I should find a way to use
tests there, too. A test that the turtle graphics "look like a tree" would
be very useful, if anyone found a use for my program.

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

In article <vdhwd.830$1o1.134@newssvr19.news.prodigy.com>,
phlip_cpp@yahoo.com says...
> Gerry Quinn wrote:
>
> > The only code I've ever seen from you (script for creating a 3D graphic)
> > had no tests at all.
>
> Would you test output-only HTML?
>
> I would if the HTML conveyed business logic. I would not test every <table>
> and <em> tag.

I would test them. I wouldn't write a bunch of tests in advance, and
only code to pass the tests - that's the concept you're plugging.

But a game graphic clearly conveys game logic. Players can't interact
with stuff they can't see. What if a square is the wrong colour? - that
could mess up the level logic of a host of games, and it wonlt be
obvious to the eye either. So by your logic, you should write explicit
tests to show that everything meant to be visible is visible and
correct, before writing code to draw it.

Of course that would be silly. Levels are first coded, then tested.

That seems to me to be a huge sector of game development in which test-
first development is quite simply inapplicable.

- Gerry Quinn

Gerry Quinn wrote:

> > I would if the HTML conveyed business logic. I would not test every
<table>
> > and <em> tag.
>
> I would test them. I wouldn't write a bunch of tests in advance, and
> only code to pass the tests - that's the concept you're plugging.

I test XHTML, in bulk, by dropping it into a validating XML parser.

I just told you nobody should use TDD to force every HTML tag to exist. You
seem to enjoy shifting things people say.

And TDD does _not_ mean "write a bunch of tests in advance", which I'm sure
many people on many newsgroups have told you. And TDD does not lead to high
velocity in isolation from other techniques, such as continuous integration.

> But a game graphic clearly conveys game logic. Players can't interact
> with stuff they can't see. What if a square is the wrong colour? - that
> could mess up the level logic of a host of games, and it wonlt be
> obvious to the eye either. So by your logic, you should write explicit
> tests to show that everything meant to be visible is visible and
> correct, before writing code to draw it.
>
> Of course that would be silly. Levels are first coded, then tested.
>
> That seems to me to be a huge sector of game development in which test-
> first development is quite simply inapplicable.

Hence the challenge. Imagine a shop where every artist who tweaks a texture,
every designer who tweaks a script, and every programmer who tweaks a math
routine can hit a button and get instant feedback that the game has no bugs,
and that all levels have the same play balance & goals.

Regardless of its impossibility, which anyone with any experience in the
game industry can easily see, it's still a very good goal. So how would you
achieve it?

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

In article <boYwd.688$Y8.391@newssvr17.news.prodigy.com>,
Phlip <phlip_cpp@yahoo.com> wrote:
>Hence the challenge. Imagine a shop where every artist who tweaks a texture,
>every designer who tweaks a script, and every programmer who tweaks a math
>routine can hit a button and get instant feedback that the game has no bugs,
>and that all levels have the same play balance & goals.

Instant? We're shipping games with 4+GB of data on disk. Pop quiz:
how long will it take a standard PC to read in 4GB, doing nothing
else? How can you consider that "instant?" Now, add tests. How long
will those take? Now, add tests on a PS2 and XBox -- considering how
slow those are compared to top-of-the-line PCs. You ain't going to get
"instant" anytime soon. And, as consumers demand moreMoreMORE!!! all
the time, instant is a less and less achievable goal. If you'd worked
on commercial games, you'll have known your statement was bull.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

A more specific link would have been handy from Christer, but I'm
guessing he was pointing at the "Extreme Deprogramming" page? If so-
it's a ludicrous page on its outset that consists entirely of ad
hominems; "attacking the people, not the process" is hardly what I
would call a "thorough" analysis.

Who cares if XP enjoys a cult-like following? Even more interesting to
me is the extreme rabidity of the detractors; in my experience the
anti-XP crowd is way more like cultist zealots than the XP followers.

Why does every thread here turn into a thread about XP? Why can't
folks just answer the OP's point, and then continue on talking about
that, ignoring the chaff? I know, pot, kettle, etc., but it does truly
make me wonder.

You obviously can't test that an artist made the wood texture to look
like wood, but that's irrelevant. You can, and should (IMO and
Phlip's) test that if you have a texture that looks like X, and have
geometry that looks like Y, that on the render surface you get
something that looks vaguely like Z.

Levels are not "coded", they're "built". The builders are not
programmers, they're artists. Again, you don't test that what an
artist built looks right. You test that whatEVER an artist gives you,
it appears as the artist intended.

> But a game graphic clearly conveys game logic.

A game graphic represents a view on the database that is the game
engine. Testing user interfaces isn't trivial, but it's actually
easier in games than in most business apps because you don't have to
deal with the wonky window layer (i.e. games typically generate all of
the drawing primitives, and don't have to depend on settings in the OS
to know how features are going to be passed off to the hardware).

I'm surprised that Nathan takes this attitude.

You edit your local Quicksort routine, ignoring for a moment any
reasons why you wouldn't use the standard library one. You compile it
and run tests on it. "Instant" in this case means that tests on
Quicksort run for less than a second. Test your whole
"standard-replacement library" in a few seconds. It ain't that hard.

The point with decoupling code systems is that you can test bits of it
in isolation. Sure, you want to test the dependent bits at some point
also, but as long as the thing you're editing has adequate test
coverage, you're almost guaranteed that there will be no ripple effects
up into the rest of the game.

I would be interested to know how many of the uber-133+ game developers
here have all their source code in one huge monolithic project vs. how
many have their code broken up into libraries. Beyond that, how many
libraries do people have?

Where I work, we've got 17 libraries plus the "game code" in an
enormous monolith. We've discovered that we need way more granularity
than that to do the kind of work we want to do (i.e., the CTO has said,
"we will be doing full XP on the next project"). So lay it out,
Nathan, Christer, etc., how many libraries are you split into?

I would venture a guess that there is a parallel between "number of
libraries" and "able to see how automated testing could possibly be
tenable," but without any hard data I'm just pissing in the wind...
-tom!

Tom Plunket wrote:

> A more specific link would have been handy from Christer, but I'm
> guessing he was pointing at the "Extreme Deprogramming" page? If so-
> it's a ludicrous page on its outset that consists entirely of ad
> hominems; "attacking the people, not the process" is hardly what I
> would call a "thorough" analysis.

Blogs like HackNot use detraction as a trick to drive up their page hits.

To read someone with a reputation to defend detract from XP, read the works
of Joel Spolsky.

> Why does every thread here turn into a thread about XP?

Because directing the OP to Sourceforge.net reminded me of the average
quality of the code there.

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

[BTW, Tom, the new Google is depriving your post of the replied-to texts.
You have to click a couple times to get it back.]

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

In article <1103398614.997898.140630@c13g2000cwb.googlegroups .com>,
Tom Plunket <plunket@gmail.com> wrote:
>You edit your local Quicksort routine, ignoring for a moment any
>reasons why you wouldn't use the standard library one. You compile it
>and run tests on it. "Instant" in this case means that tests on
>Quicksort run for less than a second. Test your whole
>"standard-replacement library" in a few seconds. It ain't that hard.

Would you bother *READING* what I was responding to, as opposed to
reflexively defending anyone who uses the word "test?" Here's what I
was responding to:

>>> Hence the challenge. Imagine a shop where every artist who tweaks
>>> a texture, every designer who tweaks a script, and every
>>> programmer who tweaks a math routine can hit a button and get
>>> instant feedback that the game has no bugs, and that all levels
>>> have the same play balance & goals.

Clue time: there's a *HUGE* difference between "the game has no
bugs" and "MyQuicksort has no bugs." That's what I was jumping at, and
saying that there's no "instant" feedback where you'd get verification
"that the game has no bugs, and that all levels have the same play
balance & goals" [Phlip's words, not mine.] People who've never
shipped a commercial game in their life (like Phlip) have no clue that
their "test" mentality doesn't scale. Those defending tests (in
general) would be a lot more credible, IMHO, if they were the ones
leading the charge against those who've never actually taken the
advice they're giving to others.

Further, things like play balance are some of the things (in my
experience) that change too dang much over the course of the project.
When the director (or a focus group, or marketing, or anyone else)
says "change gameplay in XYZ to achieve ABC," then you don't just have
'goal of the week.' You've got 'goal of the week' and 'tests of the
week,' adding to your workload. Getting *LESS* change on the design
front (from all sources) would help out game development far more,
IMHO.


>I would be interested to know how many of the uber-133+ game developers
>here have all their source code in one huge monolithic project vs. how
>many have their code broken up into libraries. Beyond that, how many
>libraries do people have?

Star Wars: Battlefront had 2 .sln files, each with 4-5 .vcproj
files. One of the .sln files had things that really rarely changed
(PS2 microcode, 3rd party source like ZLib, Lua, Gamespy). The other
..sln is stuff that's all interdependent, and changed all the time.
[Lua was used for all the front end and menuing system, nowhere near
as fancy as WoW.] When we've got 3 target platforms, times 3+ build
targets each (Debug, Release, 'FINAL'), and 4+GB of raw assets,
nothing is "instant." Over past few generations, code is growing
linearly, while assets are going exponential. The problems in game
development are in the assets. Worry about them.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

Tom Plunket <plunket@gmail.com> loquated like no one had ever loquated
before with:

> A more specific link would have been handy from Christer, but I'm
> guessing he was pointing at the "Extreme Deprogramming" page? If so-
> it's a ludicrous page on its outset that consists entirely of ad
> hominems; "attacking the people, not the process" is hardly what I
> would call a "thorough" analysis.
>
> Who cares if XP enjoys a cult-like following? Even more interesting
> to me is the extreme rabidity of the detractors; in my experience the
> anti-XP crowd is way more like cultist zealots than the XP followers.

You must only know detractors then. You'll note that most people who speak
out against XP when zealots like Philip constantly push it forward are
people who do not have an agenda - they just don't like watching other push
theirs on the unsuspecting and themselves.

> Why does every thread here turn into a thread about XP?

Ask Philip. Did you think his first post was somehow not a push for XP
(which was OT to the OP's request)?

> Why can't
> folks just answer the OP's point, and then continue on talking about
> that, ignoring the chaff? I know, pot, kettle, etc., but it does
> truly make me wonder.

Indeed. This is what Christer pointed out.

WTH