intelligence is a search for satisfaction

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
54 answers Last reply
More about intelligence search satisfaction
  1. 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
  2. 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
  3. 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.
  4. 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
  5. 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?
  6. 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
  7. 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.
  8. 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.
  9. 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
  10. 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)
  11. 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>
  12. 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
  13. 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)
  14. 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
  15. 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.
  16. 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.
  17. 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
  18. 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).
  19. 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
  20. 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.ps

    --
    mail1dotstofanetdotdk
  21. 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:pan.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.ps

    That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
    As in OttAwa.
  22. 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:pan.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.ps
    >
    > That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
    > 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.
  23. 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
  24. 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...
  25. 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
  26. 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.
  27. 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)
  28. 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.
  29. 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.
  30. 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
  31. 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?
  32. 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)
  33. 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/
  34. 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:pan.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.ps
    > >
    > > That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
    > > 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.
  35. 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."
  36. 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."
  37. 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.
  38. 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
  39. 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
  40. 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

    >
  41. 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.
  42. 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
  43. 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.
  44. 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,
  45. 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.
  46. 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
  47. 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
  48. 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
  49. 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
Ask a new question

Read More

Games Video Games