Sign in with
Sign up | Sign in
Your question

intelligence is a search for satisfaction

Last response: in Video Games
Share
Anonymous
August 8, 2004 6:36:10 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

42. :-)

And yes, it's cross-posted for a reason.

I've been doing a lot of voter registration lately... which is boring, and
low paying, which causes me to goof off once I'm done working. So, quite a
lot of Galactic Civilizations and not a lot of OCaml progress. It is not a
loss though. I've been keeping a notebook of all the ways GalCiv is boring,
and how I'm going to fix them. This has led me to a profound insight on the
nature of intelligence and searching, not to mention game design.

GalCiv suffers from the "unit pushing problem." As a human being, I spend
the vast majority of my time futzing with whether this unit is 7 squares
away from that enemy unit. In a world of better game AI, it wouldn't be so
hard to compute regions of safety from enemy units. However, then I'd still
have to make a lot of decisions about where to put my units. I envision an
architecture with lotsa set operations on regions. While planning the
architecture, I notice its O(bad) algorithmic behavior, where 'bad' might be
n^4, some higher polynomial, or maybe exponential. All depends on how much
thinking I want to do, and how much I'm willing to limit the scope of my
problems. Maybe I can have my clean architecture if I settle for a board of
only 16x16 squares. Maybe that is what a current PC can handle.

The operations required are all rather rote, basic computations. Just
computing distances from one thing to another. This makes me consider how
much the human brain is simply a more powerful computer, with better analog
sensing equipment, and thus able to leverage physics (light, heat, contact
forces) as part of the computing process. We do lotsa things that aren't
very complicated, it's just gazillions of operations in parallel. Our
brains point out how puny our computers really are, great as they may seem
for problems we're not so good at.

Some day we'll have enough silicon gates to equal a human brain. If Moore's
Law holds we'll have 'em soon. Even if Moore's Law fails at some point in
the future, there is too much industrial interest in the capability. It'll
happen, even if we have to go back to building-sized computers to get things
done. Of course, each and every one of us has working proof of concept that
these computers need not be building-sized. If silicon computing doesn't do
it, biological computing will.

Given the gates, will we have 'intelligence' ? What is 'intelligence' ?

I say, we will. Because 'intelligence' is merely a search for satisfaction.
We have been trying to get satisfaction for millions of years. That's why
we're at where we're at on the food chain. Searching for satisfaction is an
evolutionary advantage; we have been "selected for" our willingness to
search.

Searches take the form of trial and error until better methods are refined.
The first searches weren't rocket science: pick up a stick and bash another
monkey in the head with it. Good way to secure your food, water, and mates.
But refined for generations upon generations, with brains proving more adept
at storage and symbolic manipulations, and you arrive at the ICBM. Of
course there are many other evolutionary stimulants besides warfare. My
point is just that the seemingly complicated modern forms of 'intelligence'
have their bootstrapping root in fairly simple animal behaviors. That's the
magic of evolution: it gets more complicated as life goes on.

We are also not so complicated if you thought about humanity from the
perspective of a 'God'. By 'God' I just mean something much higher up the
evolutionary ladder than we currently are. Notice all the tedious,
repetitive tasks in your life? Notice how humanity's problems are so basic?
Like "Gee we don't feed everybody" even though we grow enough food to do so.
Notice how few people aspire to much of anything? Notice that even the ones
that do, will mostly be erased by history in 100 years or so? Maybe 1000
years if they're particularly profound. Education being the province of the
wealthy, there was less philosophical competition in Aristotle's time. ;-)

Do you see the cockroach in your own life? Where is your 'intelligence' ?
You are simply searching for satisfaction, at the evolutionary level you are
capable of doing so.

If intelligence is about searching for satisfaction, and everyone wants to
be satisfied, why aren't more people smarter? Well, the species doesn't
really need everyone to be smart to propagate. In fact, it's probably
advantageous to the species, or at least to its smarter members, to have a
lot of dumber drones doing their bidding. There's probably an optimum smart
/ dumb ratio under any given economic regime. The current regime is global
capitalism; has the ratio changed that much from provincial monarchs
ordering uneducated peasants around? Probably not by so much, considering
how much of the world is still in poverty while producing goods and services
for industrialized nations. Not trying to grind a political axe here, just
trying to point out what 'intelligence' in our species really is.

At any rate, the 'smartest' among us are just algorithmically compulsive.
We search because we have a biological drive to search. Many searches are
tried. Some 'succeed', meaning they displace paradigms.

Even global capitalism might be displaced someday. What would we do with a
technology that allowed us to easily grow food anywhere? Or get energy
cheaply anywhere? Or manufacture lotsa things cheaply anywhere? Of course,
we could also use these things to edit ourselves out of existence. :-)
Natural Selection at least has the benefit of promoting stable designs
rather than wild experiments!

How does this relate to OCaml?

Well, I've said before, I'm not sure that 'programming languages' are really
the answer as far as productivity goes. I've wondered if OCaml is not the
answer, but the thing that will lead me to the answer.

Maybe what we really need are architectures that can handle massive search
spaces. Profoundly stated, all programming language research as we know it
today may be an evolutionary dead end. Why should we tie algorithmic search
to the quaintness of what human beings can type at a keyboard and see on a
2D screen? Why do things with our parochial human notions of 'syntax' or
other linguistic constructs? Just so that human beings can understand and
verify what's going on? Isn't that always going to be a 'cottage industry'
approach to computation?

Ok, so, let's say you're more interested in the here and now than 20 years
hence. I will be thinking about what OCaml does or doesn't do to handle
search problems. Turn Based Strategy games are the particular search
problems I'm working on right now. They're difficult; it'll be interesting
to see how much of the architecture is better done in a higher level
language, and how much as inflexible but massively high performance low
level computation.


Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Anonymous
August 9, 2004 6:19:08 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

In article <2nnk2fF2nut4U1@uni-berlin.de>,
try_vanevery_at_mycompanyname@yahoo.com says...
>
> I say, we will. Because 'intelligence' is merely a search for satisfaction.
> We have been trying to get satisfaction for millions of years. That's why
> we're at where we're at on the food chain. Searching for satisfaction is an
> evolutionary advantage; we have been "selected for" our willingness to
> search.

According to the 'Hitchhiker's Guide to the Galaxy', flying was simply a
matter of throwing yourself at the ground - and missing. Maybe
intelligence is searching for satisfaction, and missing? Okay, enough
philosophy.

> Searches take the form of trial and error until better methods are refined.
> The first searches weren't rocket science: pick up a stick and bash another
> monkey in the head with it. Good way to secure your food, water, and mates.
> But refined for generations upon generations, with brains proving more adept
> at storage and symbolic manipulations, and you arrive at the ICBM.

> Maybe what we really need are architectures that can handle massive search
> spaces. Profoundly stated, all programming language research as we know it
> today may be an evolutionary dead end. Why should we tie algorithmic search
> to the quaintness of what human beings can type at a keyboard and see on a
> 2D screen? Why do things with our parochial human notions of 'syntax' or
> other linguistic constructs? Just so that human beings can understand and
> verify what's going on? Isn't that always going to be a 'cottage industry'
> approach to computation?

Well, our programming techniques are a bit more complicated than that.
One way of looking at programming something complicated like a game is
that is is a case of creating a new language that is appropriate to the
problem. C++ and Ocaml don't have GetShortestPath keywords, but your
map manipulation class (in either) will have a function that does it.
When you use it you are writing in a higher level language that is good
for war games.

Of course, shortest path algorithms [or maybe for this example,
influence map algorithms] are trivial, but once you have them you can
start working on the trickier GetSafeLocation() functions. At that
point you'll be into real AI...

> Ok, so, let's say you're more interested in the here and now than 20 years
> hence. I will be thinking about what OCaml does or doesn't do to handle
> search problems. Turn Based Strategy games are the particular search
> problems I'm working on right now. They're difficult; it'll be interesting
> to see how much of the architecture is better done in a higher level
> language, and how much as inflexible but massively high performance low
> level computation.

Every journey begins with a single step. If you only know roughly where
you are going, you can still start building the basic components of your
new language.

One reason I like C++ is that it gives you a relatively free hand with
the syntax of the languages you build with it!

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, and Screensavers
Try Chomp! - the new game of logical deduction
Anonymous
August 9, 2004 6:19:09 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Gerry Quinn wrote:
>
> Of course, shortest path algorithms [or maybe for this example,
> influence map algorithms] are trivial, but once you have them you can
> start working on the trickier GetSafeLocation() functions. At that
> point you'll be into real AI...

Not really. It's just more map crunching. It all depends on what is meant
by 'real' here. I did say we should embrace our inner cockroach. "We're
all just crunching."

> One reason I like C++ is that it gives you a relatively free hand with
> the syntax of the languages you build with it!

I think the OCaml guys would scoff at that. OCaml is proven at creating
domain-specific languages; it is definitely a "language maker's" tool.
That's part of why I've thought it may not be the answer, but it may lead me
to the answer. So I'll keep going with it for awhile, even if something
turns sour.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Related resources
Anonymous
August 10, 2004 3:32:51 AM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

<snip>

Sorry to ignore the point of most of your post, but how are you finding
OCaml? I had a brief look at it recently, but not enough to judge it.
Anonymous
August 10, 2004 3:40:16 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Tue, 10 Aug 2004, Peter Ashford wrote:

> In what way does OCaml eclipse that kind of tool creation ability that
> you get from OO languages?
>

I'll answer for Haskell, as I don't use ML much, but some of the points
still stand:

1) There are excellent parsing tools available - in particular, this seems
to be where Spirit got its inspiration from

2) The pattern-matching facilities, which operate on any data type. They
make mildly complicated transformations on trees and graphs an absolute
doddle.

3) Higher-order functions make it easier to build up code at run-time.

4) Techniques such as monads and monad transformers make it even easier -
you can build the semantics of your DSL piece-by-piece.

5) The type systems are more suited to this kind of work.

--
flippa@flippac.org
Anonymous
August 10, 2004 4:20:44 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

>
>>One reason I like C++ is that it gives you a relatively free hand with
>>the syntax of the languages you build with it!
>
>
> I think the OCaml guys would scoff at that. OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead me
> to the answer. So I'll keep going with it for awhile, even if something
> turns sour.
>

That's interesting. I was agreeing with Gerry insofar as any OO
language kind of is building up a language to solve your problem (if you
accept that the objects you build become effectively an extension to the
core language)

In what way does OCaml eclipse that kind of tool creation ability that
you get from OO languages?
Anonymous
August 10, 2004 6:02:37 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

In article <2npsk1F3gnj8U1@uni-berlin.de>,
try_vanevery_at_mycompanyname@yahoo.com says...
> Gerry Quinn wrote:
> >
> > Of course, shortest path algorithms [or maybe for this example,
> > influence map algorithms] are trivial, but once you have them you can
> > start working on the trickier GetSafeLocation() functions. At that
> > point you'll be into real AI...
>
> Not really. It's just more map crunching. It all depends on what is meant
> by 'real' here. I did say we should embrace our inner cockroach. "We're
> all just crunching."

It's not obvious to me how to define a safe location, or that such a
definition is even possible. What is safe depends on a lot of
circumstances. It's a fuzzy problem, whereas a shortest path analysis
just involves plugging in a standard algorithm.

> > One reason I like C++ is that it gives you a relatively free hand with
> > the syntax of the languages you build with it!
>
> I think the OCaml guys would scoff at that. OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead me
> to the answer. So I'll keep going with it for awhile, even if something
> turns sour.

Well, maybe both C++ and Ocaml have this property. My own view is that
designing and programming games is hard, and so long as your language is
powerful, scales well, and is not too awful, it's not the problem. Of
course you think C++ is too awful - I'm happy to stick with it.

- Gerry Quinn
Anonymous
August 10, 2004 6:02:38 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Gerry Quinn wrote:
> In article <2npsk1F3gnj8U1@uni-berlin.de>,
> try_vanevery_at_mycompanyname@yahoo.com says...
>> Gerry Quinn wrote:
>>>
>>> Of course, shortest path algorithms [or maybe for this example,
>>> influence map algorithms] are trivial, but once you have them you
>>> can start working on the trickier GetSafeLocation() functions. At
>>> that point you'll be into real AI...
>>
>> Not really. It's just more map crunching. It all depends on what
>> is meant by 'real' here. I did say we should embrace our inner
>> cockroach. "We're all just crunching."
>
> It's not obvious to me how to define a safe location, or that such a
> definition is even possible. What is safe depends on a lot of
> circumstances. It's a fuzzy problem, whereas a shortest path analysis
> just involves plugging in a standard algorithm.

Having more constraints, and not being completely solveable, doesn't make it
any more than a number crunching problem. From a goal oriented standpoint,
all that really matters is that it's computed to be "safe enough to win the
game." And if that doesn't pan out in practice, it just has to be "safe
enough to have seemingly put up a good fight." Look at a real war. You
know the joke about Military Intelligence, right?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Anonymous
August 10, 2004 9:11:41 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:

>
> 3) Higher-order functions make it easier to build up code at run-time.
>

3.1 - An example: you have this foreach in C#

foreach (<TYPE> <IDENTIFIER> in <COLLECTION>)
{
do something with IDENTIFIER
}

can you write a similar construct named map

map (<TYPE> <IDENTIFIER> in <COLLECTION> to <COLLECTION>)
{
return (something calculated using IDENTIFIER)
}

which collects the return values into a destination collection? No, your
best choice is to use delegates, so that you have to declare a new type for
the delegate, and write a separate function representing the body of the
"map". Compare this with the simplicity of the map operation in OCaml or
Haskell :)  And think that you can rewrite map yourself if you like.

V.
Anonymous
August 11, 2004 4:59:24 AM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Wed, 11 Aug 2004, Peter Ashford wrote:

> Philippa Cowderoy wrote:
> > 3) Higher-order functions make it easier to build up code at run-time.
> >
> > 4) Techniques such as monads and monad transformers make it even easier -
> > you can build the semantics of your DSL piece-by-piece.
>
> Could you give an example?
>

A fun one's the List monad - it represents computations that can return
zero or more results, instead of functions that always return one
result[1]. Makes it easy to write code that maintains a list of
possibilities and filters them down, for example - but more interestingly,
if you only want one result then under lazy evaluation it's equivalent to
backtracking.

Supposing you want to bolt exceptions on top of this, you could apply the
ErrorT monad transformer to it. Alternatively, you could apply a ListT
transformer to the Error monad - these produce two different results.
ErrorT on top of List yields a semantics where an exception appears within
the list of possible results and can be caught appropriately, whereas
ListT on top of Error produces a system where an exception stops the whole
computation.

Prolog, anyone?

> > 5) The type systems are more suited to this kind of work.
> >
>
> I really must get around to playing more with OCaml. I really love LISP
> but that's as far as I've ever gone with Functional Languages (except
> for dabbling briefly with Erlang) and I have to say the 'hard core'
> functional languages freak me out somewhat :o ) I just don't get them.
> Which is all the more reason to put the effort in a learn one properly :o )
>

Any idea what bugs you? It's a bit weird working without state at first,
certainly. Well, until you find all the tricks for providing state when
you really really need it (gee, I'm talking a stateful protocol over the
network here...).

If you decide to learn Haskell, you might find these two links useful:
http://www.haskell.org/tutorial/ (general tutorial)
http://www.nomaware.com/monads/html/ (a decent tutorial on monads)

I'm afraid somebody else'll have to provide equivalent links for OCaml,
I've not really used it any.

[1] Monads effectively provide means to embed a semantics that's
higher-order[2] into Haskell, and Haskell within that semantics. There's
an Identity monad that represents Haskell semantics on top of which you can
apply monad transformers, for example. A more generic framework called
Arrows relaxes the higher-order restriction.

[2] By which I mean that computations can take computations as
parameters and return computations as results - if there's an existing
use of the term that differs from this, could somebody enlighten me
btw? - this has a consequence, which is that any data the monad keeps
(state being the classical example) won't branch any - this allows the IO
monad to represent a function of type world->world without ever trying to
duplicate the world, thus allowing a pure (if not complete) language to
express interaction with the outside world without giving too many
physicists big headaches.

--
flippa@flippac.org
Anonymous
August 11, 2004 1:23:24 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:

> On Tue, 10 Aug 2004, Peter Ashford wrote:
>
>
>>In what way does OCaml eclipse that kind of tool creation ability that
>>you get from OO languages?
>>
>
>
> I'll answer for Haskell, as I don't use ML much, but some of the points
> still stand:
>
> 1) There are excellent parsing tools available - in particular, this seems
> to be where Spirit got its inspiration from
>
> 2) The pattern-matching facilities, which operate on any data type. They
> make mildly complicated transformations on trees and graphs an absolute
> doddle.

Okay, that'll explain the language creation benefits that Brandon was
talking about,

> 3) Higher-order functions make it easier to build up code at run-time.
>
> 4) Techniques such as monads and monad transformers make it even easier -
> you can build the semantics of your DSL piece-by-piece.

Could you give an example?

> 5) The type systems are more suited to this kind of work.
>

I really must get around to playing more with OCaml. I really love LISP
but that's as far as I've ever gone with Functional Languages (except
for dabbling briefly with Erlang) and I have to say the 'hard core'
functional languages freak me out somewhat :o ) I just don't get them.
Which is all the more reason to put the effort in a learn one properly :o )
Anonymous
August 11, 2004 1:33:05 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

>
> Well, maybe both C++ and Ocaml have this property. My own view is that
> designing and programming games is hard, and so long as your language is
> powerful, scales well, and is not too awful, it's not the problem. Of
> course you think C++ is too awful - I'm happy to stick with it.

That's my point of view as well (of course, insert Java for C++ :o ) )

I don't often find myself with programming issues which I can figure out
how fix but can't really express cleanly with the language I'm using. I
suppose that's part of the reason I'm a little dubious about the
advantages of using a functional language.

<uninformed opinion>
FL's seem to have lots of benefits that seem very high level and obscure
whereas the problems I end up solving usually don't seem to require
especially complex or unusal programming approaches to defeat. The real
work is figuring out what I want to do and a good algorithm to do it
rather than wrangling with the language.
</uninformed opinion>
Anonymous
August 11, 2004 2:57:24 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

In article <BabSc.11649$N77.518130@news.xtra.co.nz>, me@here.there.com
says...
> >
> > Well, maybe both C++ and Ocaml have this property. My own view is that
> > designing and programming games is hard, and so long as your language is
> > powerful, scales well, and is not too awful, it's not the problem. Of
> > course you think C++ is too awful - I'm happy to stick with it.
>
> That's my point of view as well (of course, insert Java for C++ :o ) )

Java is way too awful for me - but at least we each have one reasonably
capable language we can stand...

> I don't often find myself with programming issues which I can figure out
> how fix but can't really express cleanly with the language I'm using. I
> suppose that's part of the reason I'm a little dubious about the
> advantages of using a functional language.
>
> <uninformed opinion>
> FL's seem to have lots of benefits that seem very high level and obscure
> whereas the problems I end up solving usually don't seem to require
> especially complex or unusal programming approaches to defeat. The real
> work is figuring out what I want to do and a good algorithm to do it
> rather than wrangling with the language.
> </uninformed opinion>

I agree entirely. My recent game 'Chomp' was quite challenging
algorithmically (in an 'arrays of vectors of lists of vectors' kind of
way) but I don't think expressing the search algorithms was the main
difficulty.

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, and Screensavers
Try Chomp! - the new game of logical deduction
Anonymous
August 11, 2004 7:12:25 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

>>I really must get around to playing more with OCaml. I really love LISP
>>but that's as far as I've ever gone with Functional Languages (except
>>for dabbling briefly with Erlang) and I have to say the 'hard core'
>>functional languages freak me out somewhat :o ) I just don't get them.
>>Which is all the more reason to put the effort in a learn one properly :o )
>>
>
>
> Any idea what bugs you? It's a bit weird working without state at first,
> certainly. Well, until you find all the tricks for providing state when
> you really really need it (gee, I'm talking a stateful protocol over the
> network here...).


I think it's just that I've very much settled into the OO way of viewing
the world - solving a problem is creating a bunch of objects which
simulate the problem domain with appropriate behaviours. I think that
philosphically that view point appeals to me since I've always viewed
understanding and theories as a modelling task (you build a model, try
it out and refine it or replace it when it doesn't match obverved /
desired behaviour) FP seems a long way away from that - nothing
neccessarily wrong with FP, more to do with how I think about code.

I guess the other thing is that FP tends to be littered with
mathematical terms and I'm not fond of maths. :o )
Anonymous
August 11, 2004 7:30:44 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Wed, 11 Aug 2004, Peter Ashford wrote:

> I think it's just that I've very much settled into the OO way of viewing
> the world - solving a problem is creating a bunch of objects which
> simulate the problem domain with appropriate behaviours. I think that
> philosphically that view point appeals to me since I've always viewed
> understanding and theories as a modelling task (you build a model, try
> it out and refine it or replace it when it doesn't match obverved /
> desired behaviour) FP seems a long way away from that - nothing
> neccessarily wrong with FP, more to do with how I think about code.
>

The approach I take in FP isn't all that different. In a (classed) OO
language, classes form a little language with its own semantics. Monads
also do something similar - I've been trying to figure out the exact
relationship, in some ways monads seem to generalise classes. I suspect
(but may be wrong) that objects are effectively the closure of a monadic
computation.

The main difference this seems to make is that you're encouraged to
rewrite the rules that objects and the like sit on top of - the List monad
being a great example thereof.

--
flippa@flippac.org
Anonymous
August 12, 2004 3:03:52 AM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Wed, 11 Aug 2004 00:59:24 +0100, Philippa Cowderoy
<flippa@flippac.org> wrote:

>[2] By which I mean that computations can take computations as
>parameters and return computations as results - if there's an existing
>use of the term that differs from this, could somebody enlighten me
>btw? - this has a consequence, which is that any data the monad keeps
>(state being the classical example) won't branch any - this allows the IO
>monad to represent a function of type world->world without ever trying to
>duplicate the world, thus allowing a pure (if not complete) language to
>express interaction with the outside world without giving too many
>physicists big headaches.

Is that like a statically typed version of Scheme's continuations? If
not, what (apart from the static typing) is the difference?

--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
Anonymous
August 12, 2004 2:44:04 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:

> On Wed, 11 Aug 2004, Peter Ashford wrote:
>
>
>>I think it's just that I've very much settled into the OO way of viewing
>>the world - solving a problem is creating a bunch of objects which
>>simulate the problem domain with appropriate behaviours. I think that
>>philosphically that view point appeals to me since I've always viewed
>>understanding and theories as a modelling task (you build a model, try
>>it out and refine it or replace it when it doesn't match obverved /
>>desired behaviour) FP seems a long way away from that - nothing
>>neccessarily wrong with FP, more to do with how I think about code.
>>
>
>
> The approach I take in FP isn't all that different. In a (classed) OO
> language, classes form a little language with its own semantics. Monads
> also do something similar - I've been trying to figure out the exact
> relationship, in some ways monads seem to generalise classes. I suspect
> (but may be wrong) that objects are effectively the closure of a monadic
> computation.
>
> The main difference this seems to make is that you're encouraged to
> rewrite the rules that objects and the like sit on top of - the List monad
> being a great example thereof.
>

I'm clearly going to have to just try this stuff. I read what you're
saying and it may as well be written in Swahili :o ) I'm just a simple
programmer - I have no idea what Monads and closures are. And you know,
I think it's that element of FP - the language used to describe it and
it's benifits - that keeps dumasses like me from being drawn to giving
FP a go :o )

That said, I will give it a go. ;-) I clearly need to broaden my horizons.
Anonymous
August 12, 2004 3:46:03 PM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Philippa Cowderoy wrote:
>
>>I think it's just that I've very much settled into the OO way of viewing
>>the world - solving a problem is creating a bunch of objects which
>>simulate the problem domain with appropriate behaviours. I think that
>>philosphically that view point appeals to me since I've always viewed
>>understanding and theories as a modelling task (you build a model, try
>>it out and refine it or replace it when it doesn't match obverved /
>>desired behaviour) FP seems a long way away from that - nothing
>>neccessarily wrong with FP, more to do with how I think about code.
>
> The approach I take in FP isn't all that different. In a (classed) OO
> language, classes form a little language with its own semantics. Monads
> also do something similar - I've been trying to figure out the exact
> relationship, in some ways monads seem to generalise classes. I suspect
> (but may be wrong) that objects are effectively the closure of a monadic
> computation.

Have to disagree here. You don't have to go all the way to monads to
find some analogy for objects in FP. Monads are powerful but pretty
advanced abstractions and I do not see a close relation to the everyday
use of objects.

Above all, objects (or rather, classes) are good old ADTs and ADTs are
plain simple in FPLs. I design in terms of ADTs all the time. Mind you,
objects give you a bit more than basic ADTs, but often this add-on is
not needed, or available by different means. In any case, the way of
thinking about them is not so much different.

Cheers,

- Andreas

--
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
Anonymous
August 13, 2004 5:49:14 AM

Archived from groups: comp.ai.philosophy,comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

"Brandon J. Van Every" wrote:

> 42. :-)
>
> And yes, it's cross-posted for a reason.
>
> I've been doing a lot of voter registration lately... which is boring, and
> low paying, which causes me to goof off once I'm done working. So, quite a
> lot of Galactic Civilizations and not a lot of OCaml progress. It is not a
> loss though. I've been keeping a notebook of all the ways GalCiv is boring,
> and how I'm going to fix them. This has led me to a profound insight on the
> nature of intelligence and searching, not to mention game design.
>
> GalCiv suffers from the "unit pushing problem." As a human being, I spend
> the vast majority of my time futzing with whether this unit is 7 squares
> away from that enemy unit. In a world of better game AI, it wouldn't be so
> hard to compute regions of safety from enemy units. However, then I'd still
> have to make a lot of decisions about where to put my units. I envision an
> architecture with lotsa set operations on regions. While planning the
> architecture, I notice its O(bad) algorithmic behavior, where 'bad' might be
> n^4, some higher polynomial, or maybe exponential. All depends on how much
> thinking I want to do, and how much I'm willing to limit the scope of my
> problems. Maybe I can have my clean architecture if I settle for a board of
> only 16x16 squares. Maybe that is what a current PC can handle.
> ....
>
> Cheers, www.indiegamedesign.com
> Brandon Van Every Seattle, WA
>
> "The pioneer is the one with the arrows in his back."
> - anonymous entrepreneur



For your NxN (high N) collision/effect radius problem -- shouldnt some kind
of zonal or quadtree type mechanism be a good way to knock down the
number of comparisons required ??? (Zone membership sets to limit comparisons

to current zone set and any overlapped adjacent zones... ie- your 16x16
implemented
as zones would lower required comparisons by a factor of 256...)
I favor a cartesian zone method myself, but also make use of those zones for
rollin/rollout of a world map thats too big to fit in memory and large areas of
the
map that can run in an abstract (low detail) mode (while rolled out).
Anonymous
August 13, 2004 5:49:15 AM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Eternal Vigilance wrote:
>
> For your NxN (high N) collision/effect radius problem -- shouldnt
> some kind of zonal or quadtree type mechanism be a good way to knock
> down the
> number of comparisons required ??? (Zone membership sets to limit
> comparisons
>
> to current zone set and any overlapped adjacent zones... ie- your
> 16x16 implemented
> as zones would lower required comparisons by a factor of 256...)
> I favor a cartesian zone method myself, but also make use of those
> zones for rollin/rollout of a world map thats too big to fit in
> memory and large areas of the
> map that can run in an abstract (low detail) mode (while rolled out).

My study of AI map problems indicates that there's no such thing as
hierarchical compression of pathfinding. If you want correct paths, you
must retain all information. If you are willing to accept loss of
information, you can have a hierarchy. That's actually militarily
realistic - you could justify units screwing up when they get to a new area
that they haven't scouted before and don't have any maps. Still, my current
thinking is I'd like an architecture that can 'globally, flatly' handle a
map of a given size. With that requirement, it might have to be a pretty
small map.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Anonymous
August 14, 2004 6:46:50 PM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:

> My study of AI map problems indicates that there's no such thing as
> hierarchical compression of pathfinding. If you want correct paths, you

Have you looked at Hierarchical A* by Holte et al?

http://www.csi.uottowa.ca/~holte/Publications/tr-95-18....

--
mail1dotstofanetdotdk
Anonymous
August 14, 2004 11:52:41 PM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

"Bjorn Reese" <breese@see.signature> wrote in message
news:p an.2004.08.14.12.46.46.82396@see.signature...
> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
>
> > My study of AI map problems indicates that there's no such thing as
> > hierarchical compression of pathfinding. If you want correct paths, you
>
> Have you looked at Hierarchical A* by Holte et al?
>
> http://www.csi.uottowa.ca/~holte/Publications/tr-95-18....

That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18....
As in OttAwa.
Anonymous
August 15, 2004 2:09:59 AM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Alan Bal jeu wrote:
> "Bjorn Reese" <breese@see.signature> wrote in message
> news:p an.2004.08.14.12.46.46.82396@see.signature...
>> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
>>
>>> My study of AI map problems indicates that there's no such thing as
>>> hierarchical compression of pathfinding. If you want correct
>>> paths, you
>>
>> Have you looked at Hierarchical A* by Holte et al?
>>
>> http://www.csi.uottowa.ca/~holte/Publications/tr-95-18....
>
> That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18....
> As in OttAwa.

I believe I have, but it has been awhile. Does the paper say you can
hierarchize without losing path info?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Anonymous
August 15, 2004 5:22:08 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

>
> Not sure I understand what is meant by this. Array bounds are checked. I
> don't know about stack growth.
>
> I know all you 'real programmers' just shake your heads at how I approach
> problems, but my strategy right now is just not to write code. Instead, I
> keep reading other people's documentation and code until "something sticks."

Your approach is not that bad. If I had made a similar approach to Clean I
wouldn't have had that many troubles to turn away. Surely, my time was not
wasted and Clean introduced me into the functional programming world.

How did your CommonLisp experience turn out? If I recall it right wasn't there
some flames on comp.lang.lisp?

What, just in case, if you encounter that ML/OCaml will never fullfill what you
plan to produce. Will you distain the languages then? What will you say
nowadays to someone who asks you about your opinion on CommonLisp.

Fensterbrett
Anonymous
August 15, 2004 7:18:27 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message
news:411F4760.6E557519@kfunigraz.ac.at...
> "Brandon J. Van Every" wrote:
>
>>
>> Not sure I understand what is meant by this. Array bounds are checked.
>> I
>> don't know about stack growth.
>>
>> I know all you 'real programmers' just shake your heads at how I approach
>> problems, but my strategy right now is just not to write code. Instead,
>> I
>> keep reading other people's documentation and code until "something
>> sticks."
>
> Your approach is not that bad. If I had made a similar approach to Clean I
> wouldn't have had that many troubles to turn away. Surely, my time was not
> wasted and Clean introduced me into the functional programming world.
>
> How did your CommonLisp experience turn out? If I recall it right wasn't
> there
> some flames on comp.lang.lisp?
>
> What, just in case, if you encounter that ML/OCaml will never fullfill
> what you
> plan to produce. Will you distain the languages then? What will you say
> nowadays to someone who asks you about your opinion on CommonLisp.
>
hmm...
I am unsure of my oppinion of scheme and common lisp anymore...

imo they were decent, albeit the syntax was in general more of a negative
point than a positive one (yes, cool things were possible, but at the cost
that it is difficult to get people to use it...).
oh well, this may not matter much.

many of the other features can and have been duplicated in others (the
syntax is one of the main distinguishing factors, well, along with "apply
everything" and the macro system, but these are related to the syntax...).

or something...
Anonymous
August 16, 2004 1:47:35 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

> This 'roll your own' mentality seemed to
> pervade the Lisp community. Lotsa fragmented implementations and C FFIs
> that don't agree with each other.

They lay to much attention on the CommonLisp standard. The much I applaud such
an undertaking the more one must say that it is doomed to fail.

Surely, Scheme world is much more cluttered but there is/was never a problem
to introduce new things.

Some even do not consider Bigloo a real Scheme and vote for a single
implementation instead. We would have then: Perl, Python, Ruby, Bigloo,
DrScheme (PLT), Chicken,...

Not a bad idea I would assume.


>
> OCaml is unified, unlike the Scheme universe. The Standard ML universe
> doesn't matter from an industrial standpoint. They're academics, they don't
> take marketing or industrialization seriously. OCaml is an academic product
> as well, but more nods have been made to practicality. OCaml has emerged as
> the language with the momentum in ML-land. That said, OCaml has a long ways
> to go before it's at Python levels of industrialization.

Just for the gossip: If you carefully study the OCaml distribution you will see
some code snippets from Manuel S. He worked during his PhD in the OCaml team, I
assume. Now he is the boss behind Bigloo. In former days -as far as I can
remember - there were even some interoperabilty between Bigloo and OCaml code.



> The main things bugging me about OCaml are a so-so C FFI and baroque syntax.
> I'm worried about selling this to game developers as a successor to C++.
> Also, the language principles and I are starting to dislike each other.

The big tradgedy in that world: Clean! Clean has all the good syntax.
Disadvantage: Clean is used by assumingly only 20 people around the world. It
had a bright future, though.

>
> More accurately, I'm starting to dislike them; I think they've disliked me
> from the outset, they're just less polite about it now. Increasingly, for
> industrialization problems, I'm seeing all academics as obstacles to be
> routed around. They don't share core concerns with a game developer or an
> entrepreneur.

What I gather from fa.caml: I think they do not dislike you. But I must
honestly say that your noise and approach seems a bit odd.

Even if you do not like OCaml, you should start to program a little bit in it.
It took me around 1 year to get used to Clean (functional prohramming).
However, I have jettisoned the idea to program exclusively in functional
programming style. It is simply not true that pure functional programming style
leads to better code and readability as the proponents of the paradigm want to
make you believe. Surely a map, and fold is cool, but once they get used in
form of 10 different of such constructs in one single line you are lost
eventually?

From that point of view: OCaml shines due to their loops. Also Scheme shines in
that respect.

Also what functional programming proponents often forget: a good basic
understanding of general constructs or paradigms, e.g. object oriented
programming, search trees, how to organize your data and code and things like
that are often more important than to know how to implement a foldr and foldl
construct,

Fensterbrett
Anonymous
August 16, 2004 1:47:36 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>>
>> More accurately, I'm starting to dislike them; I think they've
>> disliked me from the outset, they're just less polite about it now.
>> Increasingly, for industrialization problems, I'm seeing all
>> academics as obstacles to be routed around. They don't share core
>> concerns with a game developer or an entrepreneur.
>
> What I gather from fa.caml: I think they do not dislike you. But I
> must honestly say that your noise and approach seems a bit odd.

Sure it's odd. OCaml also hasn't gotten certain things done yet, so they
need someone else in their gene pool other than what's 'normal'. It really
disturbs me how normative the tastes of a Bayesian spam filter can become.
Spam filter says something is 'not normal'. Cranky people agree that I'm
not normal and that they don't like what I post. Non-cranky people don't
say anything, but meanwhile, public perception shifts towards the idea that
it's best for people to have 'normal' behavior. Maybe even that the
Bayesian filter should be praised! This strikes me as a local minima in
some hill climbing problem of language growth. "Trapped in the bowl," so to
speak.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Anonymous
August 16, 2004 1:47:37 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

> It really
> disturbs me how normative the tastes of a Bayesian spam filter can
> become.
> Spam filter says something is 'not normal'. Cranky people agree that
> I'm
> not normal and that they don't like what I post. Non-cranky people
> don't
> say anything, but meanwhile, public perception shifts towards the idea
> that
> it's best for people to have 'normal' behavior.

That's right, it's got to be the fault of a Bayesian filter! Nothing at
all to do with your propensity to behave like an ass.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I dream things that never were and say, "Why not?"
-- Robert F. Kennedy (after George Bernard Shaw)
Anonymous
August 16, 2004 2:42:16 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

cr88192 wrote:

>
> usually my experience was people whining about the parens and the prefix
> math notation:
> (+ (* 3 3) (* 4 4)) vs. 3*3+4*4

Where is the problem here?

Even at lengthy formulas the Scheme code does not get into ones way.

However, how often does a web application programmer or business type
programmer (equal the mass) have to deal with formulas?

(define (strange x y z)
(* (x y z)
(+ (* (- x y)
(/ x z))
(/ y (* x x x)))))

define strange x y z:
((x/y)/z) * ((x-y)*(x/z) + (y/(3*x))


Fensterbrett
PS: My Emacs knowledge is zero. However, I have to use it because Bigloo ships
with Bee which is based on Emacs. I use mostly the mouse under Emacs and I know
3 or 4 key combinations. But I never had to count any parenthesis.
Anonymous
August 16, 2004 2:42:17 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message
news:41207368.5BD998EF@kfunigraz.ac.at...
> cr88192 wrote:
>
>>
>> usually my experience was people whining about the parens and the prefix
>> math notation:
>> (+ (* 3 3) (* 4 4)) vs. 3*3+4*4
>
> Where is the problem here?
>
well, the fact that the former looks different than the latter.

> Even at lengthy formulas the Scheme code does not get into ones way.
>
this depends on who is saying it.
I personally didn't have a problem with this, albeit I didn't really like
the way s-exps looked in general though.

> However, how often does a web application programmer or business type
> programmer (equal the mass) have to deal with formulas?
>
> (define (strange x y z)
> (* (x y z)
> (+ (* (- x y)
> (/ x z))
> (/ y (* x x x)))))
>
> define strange x y z:
> ((x/y)/z) * ((x-y)*(x/z) + (y/(3*x))
>
with operator precedence, a few more parens could be eliminated:
x/y/z*((x-y)*x/z + y/3*x)

>
> Fensterbrett
> PS: My Emacs knowledge is zero. However, I have to use it because Bigloo
> ships
> with Bee which is based on Emacs. I use mostly the mouse under Emacs and I
> know
> 3 or 4 key combinations. But I never had to count any parenthesis.
>
parens counting becomes an issue when using notepad...

I could use emacs decently well myself.


there is not really a good/clear reason why there is a problem with
s-expressions, one would likely need to go into more subjective realms to
understand this...

or something.
Anonymous
August 16, 2004 3:34:26 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

On Mon, 16 Aug 2004, Siegfried Gonzi wrote:

> PS: Just out of curiosity: did you ever consider Haskell for your journey to
> heaven?
>

Too slow for Brandon's purposes at the moment, even with strictness
annotations etc all over the place.

--
flippa@flippac.org
Anonymous
August 16, 2004 4:02:53 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

>
> Sure it's odd. OCaml also hasn't gotten certain things done yet, so they
> need someone else in their gene pool other than what's 'normal'. It really
> disturbs me how normative the tastes of a Bayesian spam filter can become.
> Spam filter says something is 'not normal'. Cranky people agree that I'm
> not normal and that they don't like what I post. Non-cranky people don't
> say anything, but meanwhile, public perception shifts towards the idea that
> it's best for people to have 'normal' behavior. Maybe even that the
> Bayesian filter should be praised! This strikes me as a local minima in
> some hill climbing problem of language growth. "Trapped in the bowl," so to
> speak.

It is not that bad. I think. Most of your posts made it through to the OCaml
mailing list.

Take into considerations: The Clean mailing list actually is human- moderated.
I only mention this because there you wouldn't have had the chance to see
light.

>

Personllay I think it is pure insanity to moderate a Clean mailing list which
has only a few members. From that point of view: the Caml mailing list is very
open.

As I said: your apporach is a bit mad, but not unintelligent. Because it is
often better not to get involved into programming language problems in a
first run. Nevertheless you should write some simple OCaml code.

What I do not understand: if your bussines model stands. Why don't you look for
investors and then in turn that money is spend in outsourcing the project to
paid C++ programmers? You are still the boss of the design and poject.

If your bussines model is sound and ready, why are you sure then that you will
grasp OCaml within a couple of days? A conservative estimate would be along the
lines of 1 year for mastering OCaml programming in production code. It is the
same when Stroustroup says that mastering C++ for production code takes one at
least 6 to 12 months provided he will programm every day in C++.

Fensterbrett
PS: Just out of curiosity: did you ever consider Haskell for your journey to
heaven?
Anonymous
August 16, 2004 5:40:42 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Brandon J. Van Every wrote:

> The main things bvgging me abovt OCaml are a so-so C FFI and baroqve syntax.
> I'm worried abovt selling this to game developers as a svccessor to C++.
> Also, the langvage principles and I are starting to dislike each other.
> More accvrately, I'm starting to dislike them; I think they've disliked me
> from the ovtset, they're jvst less polite abovt it now. Increasingly, for
> indvstrialization problems, I'm seeing all academics as obstacles to be
> rovted arovnd. They don't share core concerns with a game developer or an
> entreprenevr.

Not to tvrn yov off the 'one trve path' (i.e. fvnctional programming)
bvt it jvst occvrred to me that Cyclone
(http://www.research.att.com/projects/cyclone/) might fit yovr bill.
Have yov looked at it?

From the web page:
-----------------------------------------------------------------------
Cyclone is a programming langvage based on C that is safe, meaning that
it rvles ovt programs that have bvffer overflows, dangling pointers,
format string attacks, and so on. High-level, type-safe langvages, svch
as Java, Scheme, or ML also provide safety, bvt they don't give the same
control over data representations and memory management that C does
(witness the fact that the rvn-time systems for these langvages are
vsvally written in C.) Fvrthermore, porting legacy C code to these
langvages or interfacing with legacy C libraries is a difficvlt and
error-prone process. The goal of Cyclone is to give programmers the same
low-level control and performance of C withovt sacrificing safety, and
to make it easy to port or interface with legacy C code.

Cyclone also provides modern featvres for convenient programming:

* Tagged vnions
* ML-style datatypes
* Parametric polymorphism
* Pattern matching
* Exceptions
* Anonymovs strvcts eqvivalent by strvctvre
* Parameterized typedefs
* An extensive library for container types and other common vtilities
* A lexer generator and parser generator
* Fvnction-level debvgging with gdb and profiling with gprof
-----------------------------------------------------------------------

Svre, it's neither 'fvnctional' (nor 'object oriented') bvt it does lend
a healthy amovnt of featvres and techniqves from fvnctional programming
(e.g. type inference), fitting it to 'C'-code and performance wovld be
other points to stress.

Points against covld be lack of a native windows environment (rvns vnder
cygwin thovgh) and that's it's not that matvre yet. (Thovgh more so one
might add than some of the other alternatives yov've mentioned).

Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Anonymous
August 16, 2004 7:17:57 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

> Oh yeah, and the Franz Lisp guy was a total ass. Arrogant, "it's your fault
> if... you haven't done your homework... you're a bad developer..." kind of
> customer service ethic. In contrast, the Intel C++ guy is a total
> sweetheart. If I can't get rid of C/C++ land, if I'm stuck with
> interoperating to some degree, I will eventually check out the Intel
> compiler.
>
> The dealbreaker was no open source version that ran on Windows.

Umm.... CLISP? http://clisp.cons.org/
Anonymous
August 18, 2004 12:28:37 AM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2o88t7F7nst9U1@uni-berlin.de...
> Alan Bal jeu wrote:
> > "Bjorn Reese" <breese@see.signature> wrote in message
> > news:p an.2004.08.14.12.46.46.82396@see.signature...
> >> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
> >>
> >>> My study of AI map problems indicates that there's no such thing as
> >>> hierarchical compression of pathfinding. If you want correct
> >>> paths, you
> >>
> >> Have you looked at Hierarchical A* by Holte et al?
> >>
> >> http://www.csi.uottowa.ca/~holte/Publications/tr-95-18....
> >
> > That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18....
> > As in OttAwa.
>
> I believe I have, but it has been awhile. Does the paper say you can
> hierarchize without losing path info?

It seems applicable to your problem. It proposes abstracting parts of the
problem away, and then after a good candidate is identified put the details
back in.

To solve the influence problem on
A B C D
E F G H
I J K l
M N O P
you might replace that map with
Q R
S T
and a conservative influence function derived from the original data. Run
the initial search on the abstraction, and then link that to a refining
search on the detailed map.

Holte's newer papers have even better information on how to search
effectively.
Anonymous
August 18, 2004 7:03:05 AM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Siegfried Gonzi wrote:
>
> It is not that bad. I think. Most of your posts made it through to
> the OCaml mailing list.

It's particularly bad for my ML Seattle announces. The Bayesian filter
judges them to be waaaay different from all my other OCaml posts, which only
need a certain .sig to get passed. Keywords like 'beer' are highly
problematic.

What I really resent, is Xavier's recent characterization of my ML Seattle
announce as being somehow ill-formed, just because the Bayesian filter
rejects it. It's like, rolling all antipathies / dislikes for me into one
package, then blasting me for something that isn't applicable. Why
*shouldn't* a local user group announcement occur on caml-list? "It's not
applicable to everyone in the world" is nonsense, what's the transmission
vector supposed to be instead? The forum's right, the nature of the
announce is right; why *shouldn't* it mention food, parking, and nature of
venue? This is like saying caml-list is too anal to announce a public
gathering at a conference or something.

> Take into considerations: The Clean mailing list actually is human-
> moderated. I only mention this because there you wouldn't have had
> the chance to see light.

I don't know that that's true. It depends upon the degree of topic Nazism
vs. civility enforcement. I agree I wouldn't survive in a topic Nazi
regime. In a civil regime, I'd do fine. I may post things that are pointed
about a technology, but I don't attack people personally. I often receive
personal attacks for what I post, and that's part of what degrades a forum.
The difference is that politically speaking, I get blamed for all personal
attacks that come my way. It's not someone else's fault for gratuitously
ragging on me or ML Seattle, it's my fault for not being the academic /
technical product that other people want to hear about.

> Personllay I think it is pure insanity to moderate a Clean mailing
> list which has only a few members. From that point of view: the Caml
> mailing list is very open.

I don't know about 'pure insanity' but it doesn't strike me as efficient. I
think people can self-moderate in small numbers. That said, starting
http://groups.yahoo.com/group/ocamlgames/ recently, I have reserved the
right to start moderating the group if there's a complete meltdown. Some of
our initial debates have indeed gotten a little toasty. So I've said, "I
don't want to end up having to moderate this list" at least twice now. A
moderation threat does get most people to behave better, including me. :-)

> What I do not understand: if your bussines model stands. Why don't
> you look for investors and then in turn that money is spend in
> outsourcing the project to paid C++ programmers? You are still the
> boss of the design and poject.

Because chasing investors consumes lots of time. Time is a resource worth
money. Talking to MBAs is not my strong suit, I'm a programmer and artist,
not a MBA. I can do it to some degree, but only to a degree. First and
foremost I'm a software architect and I'm going to architect things
properly. That means not architecting stuff in timewasting languages like
C++. I don't believe that farming it all out overseas is the best course.
First you need some money to do that, and I currently have none. I'll play
the game differently when I do have wads of money, but I'm facing the
realities of bootstrapping right now.

Second you have control issues, you can't give the Indians your whole job
because then they'll just steal your stuff. How are you going to sue them
overseas? You won't be able to. So you have to keep a core for yourself,
and that core should be something they can't do themselves. Ergo, I need to
be the CTO 'brains', and only farm out the non-brainy, repetitive, tedious
labor stuff to overseas outfits. That's not a trivial set of architectural
decisions to make, actually.

Finally, my strategic goal is to amplify the power of a solo programmer. I
don't believe in this 'team mentality' the rest of the computer world has.
What I see are softwares getting written by big expensive teams that don't
accomplish all that much, because there's no will to do anything other than
throw bodies at problems. All of industry's tools are designed with teams
in mind, never individuals. The capital intensive approach does work,
sorta, but it can never be used by those who lack capital. This in turn
restricts creative freedom. The more suits holding onto the money, the more
boring your game or art project has to be. Ultimately, I want one lone
auteur to be able to produce viable interactive works for public sale.

That's an idealistic vision. I'm not in business for myself to just make
money, I'm in it to fulfil my ideals. For me, that's what being an indie is
about. I want to control the means of production, design it according to my
own terms. Not some cattle pack's terms. I want to make millions of
dollars doing exactly what *I* want to do. Doing what I want to do comes
first, before any money. I'm not getting that time back before I die, and
chasing around a bunch of MBA idiots with no vision ain't my idea of a good
time.

My problems overlap other people's problems to some degree, and that is
where Open Source business models become possible.

> If your bussines model is sound and ready,

"Sound and ready?" That in and of itself is a contradiction in terms.
Business models that are being readied for deployment aren't sound, they're
calculated risks.

> why are you sure then
> that you will grasp OCaml within a couple of days?

Who said I thought so? Who said I haven't put a lot of time into
understanding OCaml already?

> A conservative
> estimate would be along the lines of 1 year for mastering OCaml
> programming in production code. It is the same when Stroustroup says
> that mastering C++ for production code takes one at least 6 to 12
> months provided he will programm every day in C++.

That's a gross overestimate for an experienced coder. OCaml is only a
language, after all. The main work of a project is its design and
architecture, not its language. Languages merely facilitate or hinder the
design more or less.

> Fensterbrett
> PS: Just out of curiosity: did you ever consider Haskell for your
> journey to heaven?

I have chased down information about Haskell. Nothing I looked at made me
take it seriously.
I see no evidence that it's anything other than an academic project. It
doesn't have performance, and it doesn't make any nods to commercial
relevance. Between Haskell and OCaml, for commercial purposes the choice is
bluntly obvious. Haskell may end up having the more far reaching impact
upon academic language R&D, but that is totally irrelevant to game
developers here and now.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
Anonymous
August 18, 2004 7:10:15 AM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Stefan Axelsson wrote:
>
> Not to turn you off the 'one true path' (i.e. functional programming)
> but it just occurred to me that Cyclone
> (http://www.research.att.com/projects/cyclone/) might fit your bill.
> Have you looked at it?

I haven't, although I think I may have heard of it. I'm not interested in
figuring out the dynamics of Yet Another Language Forum (YALF) at the
moment. The main reason I'm even vaguely considering Felix in any sense at
all is because John Skaller has been on caml-list so much, and private
conversations with him have actually gone somewhere. My current attitude
is, OCaml has to completely bite me in the ass for me to give up on it right
now. I really haven't attempted the proof of concept yet, and that's the
only way to definitively say yea or nay. Otherwise one risks prevarication
forever.

Duly bookmarked.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Anonymous
August 18, 2004 7:22:50 AM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

Alan Bal jeu wrote:
>>>>
>>>> Have you looked at Hierarchical A* by Holte et al?
>
> It seems applicable to your problem. It proposes abstracting parts
> of the problem away, and then after a good candidate is identified
> put the details back in.

That would seem to assume that the terrain is classifiable into chunks whose
more abstract representations are "worth it." I can think of scattered
twisty maze problems that would never be worth it.

An approach that I've considered, which I wouldn't call 'hierarchical', is
to just classify uniform terrain areas as convex polyhedra. If you've got a
huge desert in Saudi Arabia then it could all be just one big uniform
terrain node. Of course, this approach assumes you're tracing linear paths
across these polyhedra, and it isn't computationally cheap to do that sort
of thing. Ergo I'm not worrying about it anymore, because I think
discretization into some form, like hexes, is pretty much what games have to
do in the here and now. I suppose I could do a discrete version of the same
idea, classifying rougly convex regions of uniform hex terrain into sets.

However, there's still the problem of which way a path cuts across a region.
It could skirt the edge of a region, or go straight across it. Thus the
notion of a region isn't so useful. You could put a maximum bound on it,
i.e. all paths across a circle are no more than 2*r in length. Maybe
there's a metric for minimum paths I haven't thought of, that relates to the
perimeter. Either way, you're going to be dealing with chains of equations,
trying to guesstimate minimum and maximum path lengths with an awful lot of
flexibility. I'm not sure this is really buying anything over just
searching directly. It could buy something if the terrain region is 'large'
and paths aren't willy-nilly pathological, but what should we really expect
in the abstract?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

Taking risk where others will not.
Anonymous
August 20, 2004 1:19:54 AM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

> "Topic Nazi" just means someone who's rather anal about whether things
> are
> on-topic or not.

And with a degree in sociocultural anthropology, no less.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ All I know is / I need you in my life
-- India Arie
Anonymous
August 20, 2004 8:13:39 AM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

> I don't know that that's true. It depends upon the degree of topic
> Nazism vs. civility enforcement. I agree I wouldn't survive in a
> topic Nazi regime. In a civil regime, I'd do fine. I may post
> things that are pointed about a technology, but I don't attack people
> personally. I often receive personal attacks for what I post, and
> that's part of what degrades a forum. The difference is that
> politically speaking, I get blamed for all personal attacks that come
> my way. It's not someone else's fault for gratuitously ragging on me
> or ML Seattle, it's my fault for not being the academic / technical
> product that other people want to hear about.

Brandon, you're infamous for attacking the beliefs and practices of others,
if not the others themselves, without the application of logical thought and
then participating in protracted defenses of things you should never have
said in the first place.

A perfect example was your multi-week diatribe defending your assertion that
learning C or C++ had no commercial value.

WTH
Anonymous
August 20, 2004 1:15:48 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" wrote:

>
>
> > What would you haved Python used for?
>
> Funny you should ask that. It turns out I need a production pipeline
> immediately, so I'm back to worrying about Nebula2
> http://nebuladevice.cubik.org , C++, and Python. I will work with these
> until I have time to add OCaml support. Also I think non-technical people
> will do way better with Python than with OCaml, so I might keep it for
> artist written scripts, even if real programmers end up using OCaml.

Let me ask the following. How do you estimate your luck that your game will
really gain momentum? I played the last time on my computer 8 years ago, so I
am not representative for a player. However, I red a news the other day that
games in Germay do not hook on because as opposed to games from America they
are way too complicated. I cannot comment on this, though.

I think it must be extremly hard to forecast whether people will like my game
or not. Personally I wouldn't have such nerves.

Do you ask people in polls what they would like to play with?

Fentserbrett

>
Anonymous
August 20, 2004 2:16:42 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>>
>>> What would you haved Python used for?
>>
>> Funny you should ask that. It turns out I need a production pipeline
>> immediately, so I'm back to worrying about Nebula2
>> http://nebuladevice.cubik.org , C++, and Python. I will work with
>> these until I have time to add OCaml support. Also I think
>> non-technical people will do way better with Python than with OCaml,
>> so I might keep it for artist written scripts, even if real
>> programmers end up using OCaml.
>
> Let me ask the following. How do you estimate your luck that your
> game will really gain momentum?

We aren't leaving it to luck. When it's time, we'll make a proper marketing
effort.

Right now I'm only concerned with proving that we have a production pipeline
that can absorb art, audio, and code. I want a 5 minute interactive art
piece, not even a game. If we can reach this milestone then I'll consider
my partnership with my art-business friend to be viable. Also we would have
something to hand off to some MBA friends of his. They'd shop it around and
use it to get funding.

> I played the last time on my computer
> 8 years ago, so I am not representative for a player. However, I red
> a news the other day that games in Germay do not hook on because as
> opposed to games from America they are way too complicated. I cannot
> comment on this, though.
>
> I think it must be extremly hard to forecast whether people will like
> my game or not. Personally I wouldn't have such nerves.

I'm too arrogant to care whether people like my game or not. What I mean by
that is, it's not my job as a Game Designer to wring my hands.

It *is* my job to make accomodation both to my business partner and to the
tastes of the general public, to the degree that I want to make money and
establish notoriety. For instance his tastes run more towards twitchy FPS
than to wargames. Also I don't think he has any idea how to bootstrap, he
seems to think in terms of "get money people and go big big big." Also he
is more of an artist than a gamer, I have a lot more experience with many
kinds of games than he does. That's ok; he can be the Art Director and CEO,
I'll be the Game Designer and CTO. We each have some skill in the other's
area, so that's a check and balance. Well, he doesn't know much of anything
about programming, so that puts me in a good position right now.

Anyways, that means as Game Designer and CTO I'm going to make some tough
decisions about what direction we're going to take, game design-wise. You
might not "have the nerves," but I am sure of what I can inflict upon the
world. I only worry about how much time and money it will take. I
definitely have a bootstrapping mentality, as well as an exit strategy
mentality if the partnership fizzles.

> Do you ask people in polls what they would like to play with?

Nope. I do go to the game stores, look at what's on the shelves, and roll
my eyes, however. Also I make it a point to eventually play any game that
has wild commercial success, so that I'm conversant with the mainstream
industry trends.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

Taking risk where others will not.
Anonymous
August 20, 2004 3:09:59 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

In article <4125A524.39F63892@kfunigraz.ac.at>,
siegfried.gonzi@kfunigraz.ac.at says...

> Let me ask the following. How do you estimate your luck that your game will
> really gain momentum? I played the last time on my computer 8 years ago, so I
> am not representative for a player. However, I red a news the other day that
> games in Germay do not hook on because as opposed to games from America they
> are way too complicated. I cannot comment on this, though.

You aren't a player! That news almost certainly refers to board games,
not computer games. (In board games there is a 'German games' genre,
which, whether due to good taste or snobbishness, are considered by
afficionados to be greatly superior to those favoured by the common
herd.)

- Gerry Quinn
Anonymous
August 21, 2004 3:33:08 AM

Archived from groups: comp.ai.games,comp.lang.functional,comp.games.development.programming.algorithms (More info?)

"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2ogoipFacjhsU1@uni-berlin.de...
> Alan Bal jeu wrote:
> >>>>
> >>>> Have you looked at Hierarchical A* by Holte et al?
> >
> > It seems applicable to your problem. It proposes abstracting parts
> > of the problem away, and then after a good candidate is identified
> > put the details back in.
>
> That would seem to assume that the terrain is classifiable into chunks
whose
> more abstract representations are "worth it." I can think of scattered
> twisty maze problems that would never be worth it.

This just shows that your problem is more complex than the samples
discussed in the paper. A simple mapping may be difficult to achieve
for your case. But it's worth trying anyway.

>
> An approach that I've considered, which I wouldn't call 'hierarchical', is
> to just classify uniform terrain areas as convex polyhedra.
That still qualifies as hierarchical. 'Uniform' may not be necessary.
Mostly uniform can still be approximated pretty well.

>
> However, there's still the problem of which way a path cuts across a
region.
> It could skirt the edge of a region, or go straight across it. Thus the
> notion of a region isn't so useful. You could put a maximum bound on it,
> i.e. all paths across a circle are no more than 2*r in length. Maybe
> there's a metric for minimum paths I haven't thought of, that relates to
the
> perimeter. Either way, you're going to be dealing with chains of
equations,
> trying to guesstimate minimum and maximum path lengths with an awful lot
of
> flexibility. I'm not sure this is really buying anything over just
> searching directly. It could buy something if the terrain region is
'large'
> and paths aren't willy-nilly pathological, but what should we really
expect
> in the abstract?

It's all up to you to decide what works or doesn't. You can try an
abstraction where
the choices are "around" and "through" for some larger terrain. Maybe you
can make it work, or maybe you can't.
Anonymous
August 21, 2004 6:05:32 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote
in news:2ompblFc81dbU1@uni-berlin.de:

>> Do you ask people in polls what they would like to play with?
>
> Nope. I do go to the game stores, look at what's on the shelves, and
> roll my eyes, however. Also I make it a point to eventually play any
> game that has wild commercial success, so that I'm conversant with the
> mainstream industry trends.

Hmmm plain spoken, and above board. Interesting.

I probably spend too much time in the gaming newsgroups but that comment
definetly would heat up a discussion there. The present mainstream
industry is considered to be in reversal. Few new games, even fewer
decent ones. Mostly new versions of older games that did wellm even
though the new version is done by a lesser team and teribly
disappointing. More work done on the packaging of the box and the ads
than on the game itself. But you make it sound like thats the direction
you are knowingly headed down so I guess thats OK. Kindof the fast-food
of gaming.

The hot topics in the newsgroups at the moment have shifted strongly
toward indie games that are published but available thru online sites
only. Even games which were released years ago. I would call them
successes but not what would be considered "wild commercial success"

But then you should consider me biased since Im on the publishing side
with a definate preference for good long-life strategic games even if
they arent as glitzy as the usual shelfware.

Gandalf Parker
-- most of "my favorite sites" includes
ShrapnelGames.com, Dom2minions.com, SDmud.org,
Community.Net, Techno-Mage.com, and Alt-Hacker.org,
Anonymous
August 21, 2004 6:05:33 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Gandalf Parker wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote
> in news:2ompblFc81dbU1@uni-berlin.de:
>
>>> Do you ask people in polls what they would like to play with?
>>
>> Nope. I do go to the game stores, look at what's on the shelves, and
>> roll my eyes, however. Also I make it a point to eventually play any
>> game that has wild commercial success, so that I'm conversant with
>> the mainstream industry trends.
>
> Hmmm plain spoken, and above board. Interesting.
>
> I probably spend too much time in the gaming newsgroups but that
> comment definetly would heat up a discussion there. The present
> mainstream industry is considered to be in reversal. Few new games,
> even fewer decent ones. Mostly new versions of older games that did
> wellm even though the new version is done by a lesser team and teribly
> disappointing. More work done on the packaging of the box and the ads
> than on the game itself.

That sounds like what I see in the stores.

> But you make it sound like thats the
> direction you are knowingly headed down so I guess thats OK. Kindof
> the fast-food of gaming.

WTF??!? how do you conclude that because I observe the mainstream industry,
I embrace it?

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Anonymous
August 21, 2004 9:37:10 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

In article <Xns954C487792B7Bgandalfparker@208.201.224.154>,
gandalf@most.of.my.favorite.sites says...
>
> I probably spend too much time in the gaming newsgroups but that comment
> definetly would heat up a discussion there. The present mainstream
> industry is considered to be in reversal. Few new games, even fewer
> decent ones. Mostly new versions of older games that did wellm even
> though the new version is done by a lesser team and teribly
> disappointing. More work done on the packaging of the box and the ads
> than on the game itself. But you make it sound like thats the direction
> you are knowingly headed down so I guess thats OK. Kindof the fast-food
> of gaming.

"considered to be in reversal" seems too strong. People bitch about
games, always have done, always will do.

- Gerry Quinn
Anonymous
August 21, 2004 9:47:51 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Gerry Quinn <gerryq@DELETETHISindigo.ie> wrote in
news:MPG.1b918a8f6c44dd869898b5@news.indigo.ie:

> In article <Xns954C487792B7Bgandalfparker@208.201.224.154>,
> gandalf@most.of.my.favorite.sites says...
>>
>> I probably spend too much time in the gaming newsgroups but that
>> comment definetly would heat up a discussion there. The present
>> mainstream industry is considered to be in reversal. Few new games,
>> even fewer decent ones. Mostly new versions of older games that did
>> wellm even though the new version is done by a lesser team and
>> teribly disappointing. More work done on the packaging of the box and
>> the ads than on the game itself. But you make it sound like thats the
>> direction you are knowingly headed down so I guess thats OK. Kindof
>> the fast-food of gaming.
>
> "considered to be in reversal" seems too strong. People bitch about
> games, always have done, always will do.

Yes but usually there is some back and forth traffic on both sides about
new games. Lately there have been more questions about why there is NO
traffic about the new games. WHen someone posts "whats the latest xxxxxxx
game you would recommend" the replies tend to be games that have been out
for almost a year.

Many of the glitzy-package/full-page-ad type of publishers seem to be
downsizing, dropping projects, or even going under completely. Not all,
but there seems to be more bad news than good about the big favorites for
6 months or so.

Again, I may be biased since those are the companies that some of our
indie developers have pointed at and say "why dont you do that for me?"
but lately we have had hard examples we can reply back with as "did you
see what is happening with xxxxx?"

Gandalf Parker
Anonymous
August 21, 2004 9:47:52 PM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Gandalf Parker wrote:

> Yes but usually there is some back and forth traffic on both sides
> about
> new games. Lately there have been more questions about why there is NO
> traffic about the new games. WHen someone posts "whats the latest
> xxxxxxx
> game you would recommend" the replies tend to be games that have been
> out
> for almost a year.

So wait, you're judging the health of the computer gaming industry based
on the activity in newsgroups?

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Who shall stand guard to the guards themselves?
-- Juvenal
Anonymous
August 22, 2004 6:25:24 AM

Archived from groups: comp.lang.functional,comp.games.development.programming.algorithms,comp.ai.games (More info?)

Erik Max Francis <max@alcyone.com> wrote in
news:4127CA25.B38A1C6B@alcyone.com:

> Gandalf Parker wrote:
>
>> Yes but usually there is some back and forth traffic on both sides
>> about new games. Lately there have been more questions about why
>> there is NO traffic about the new games. WHen someone posts "whats
>> the latest xxxxxxx game you would recommend" the replies tend to be
>> games that have been out for almost a year.
>
> So wait, you're judging the health of the computer gaming industry
> based on the activity in newsgroups?

No I tend to judge the quality of the gaming industry based on the
newsgroups. And trends also. I judge the health of the gaming industry
based on the industries inside magazines.

Gandalf Parker
!