Loading ...
Sorry, an error occurred while loading the content.

My vision for my tank game (was Re: Re: Trying to decide on vision in my game)

Expand Messages
  • John Ludlow
    ... opponents ... I think a little confusion is rife here. I meant what kind of interface will the user use to customise the AI. I ve seen a few games (Core
    Message 1 of 8 , Oct 31, 2002
    • 0 Attachment
      > This whole program is intended to be an online ordeal, where your
      opponents
      > are other players with their own AI controlled tanks.
      >
      > > How will the AI be written? [Please keep it focused on game design
      > though. - Moderator]
      I think a little confusion is rife here. I meant what kind of
      interface will the user use to customise the AI. I've seen a few
      games (Core Wars was, I think, one of them) which use a weird sort of
      grid of numbers. It was completely inaccessible to me, and I got
      fustrated by it. A proper programming language I can deal with. :)

      I'll check out Omega, see what it's like, in between all the new demos
      I've found myself with this week.

      > The entire game will be written in Java (for now -- fast to develop)
      and it
      > has an interesting feature -- the ability to create an instance of
      an object
      > with its class name imbedded in a string. The side effect: You can
      write a
      > program to use objects that haven't been written yet.
      >
      > Basically you'll be able to write the AI however you want, as long
      as you
      > support a standard interface, which basically consists of the following:
      >
      > A "Get next command" method from which you return the next move you
      want the
      > tank to execute, in the form of a number designating the type of order
      > paired with an object containing all the pertenant data regarding that
      > order.
      >
      > A "Receive Message" method which receives a message flag (example flags:
      > "You have been shot" "You ran into something" "You're underwater"
      "You
      > just finished your last command") These will simply take the form of a
      > number relating to a standard set of flags.
      >
      > A "Receive Data" method, which passes a number indicating the type
      of data,
      > and an object containing the data itself. This is used for tank
      hardware
      > such as scanners and target locks (for which the updates will be
      targetting
      > data), and later will be used for reception of comms from fellow tanks
      > (there will be a wide range of "type" designations left unused for
      the AI
      > programmer to use as (s)he sees fit.
      >
      > Aside from that, a programmer has free reign, within limits. They
      have to
      > be friendly to multitasking, and make up their mind within a relatively
      > short span of time. If the game asks your AI what to do next, and it
      > doesn't know, it's expected to return a "wait" command. To
      facilitate this,
      > I may create an AI 'shell' which takes away the direct interface
      with the
      > rest of the game. The AI will run on its own process, and therefore
      will
      > have to be efficient (to an extent) to avoid unexpected idleness.
      >
      > I plan on having some pre-developed AI's for those who don't want to
      > program, adding more later, and my overall vision is to break things
      up into
      > three modules that work with the main module:
      >
      > Vision: Controls where the tank looks and when
      >
      > Navigation: Controls where the tank goes, and helps it from running
      into
      > anything, while making a hard target of itself
      >
      > Targetting: Decides how to kill things.
      >
      > If I encourage this sort of division of labour, then it will allow
      one to
      > more easily write a single module, rather than having to tackle the
      whole
      > wad at once.
      Sounds good. So to customise the AI, the user would write Java code?

      Personally, I'm into very simple programming languages. An
      object-oriented approach works very well for a lot of things. AI is
      one of the better examples. For example, you could say that when the
      robot is attacked, it

      > > Anyways, your question...
      > >
      > > I'm assuming it's basically for the AI to work out what to do next.
      > >
      > > I'm thinking a sort of low-res, grainy image from an first person
      > > perspective of the robot. An array of numbers providing the distance
      > > in a sort of sonar-type thing. Other arrays can provide other info
      > > like light, heat, etc.
      >
      > My question to that, then, is how easy that would be for the
      programmer to
      > interpret and work with? Mind you, I suppose it's only one level of
      > abstraction away from creating the "Closest ____" data I mentioned
      > earlier...

      Yeah, perhaps you could use something like that as a basis.
      Personally, I think that'd be a very simple way of providing a lot of
      visual input. If you want, you could represent it as a 3D array with
      the robot at the centre. This'd be kinda similar to your first idea,
      except in 3D. Or you could have the different layers of the 3D array
      representing different types of info.

      [Note to moderators - Ok, I can see this going a little into
      programming territory. But where do we draw the line on this one,
      since programming is a part of the game experience, which should be
      discussed?]

      Cheers

      John

      > ANYWAY, I've got to run. So much to do, so little time...
      >
      > Oh, and for those who have ANY interest, my Go AI is learning, and
      learning
      > fairly well. I saw its error drop to a level that proves it's learning
      > something more than just indeciciveness, but it ducked back up
      again. I'll
      > have a brilliant AI one of these days... ;-)
      >
      > TTFN,
      > Drew
    • Brandon J. Van Every
      ... When it gets to sound like a pile of programming babbling gobbledygook, that s when it gets the axe. It s skirting that boundary now... who cares about OO
      Message 2 of 8 , Nov 1, 2002
      • 0 Attachment
        > From: John Ludlow [mailto:jludlow3@...]
        >
        > [Note to moderators - Ok, I can see this going a little into
        > programming territory. But where do we draw the line on this one,
        > since programming is a part of the game experience, which should be
        > discussed?]

        When it gets to sound like a pile of programming babbling gobbledygook,
        that's when it gets the axe. It's skirting that boundary now... who
        cares about OO methods and embedded strings? Is OO the best thing since
        sliced bread or a programmatic detail that could be achieved plenty of
        other ways? Is OO even vaguely relevant to scripting? That's a
        discussion best left to another forum. The relevant game design +
        programming discussion to be had here, is how this API is going to be
        kept *SIMPLE* for the player. So that they're actually willing to code
        to it, and don't view it as a unique act of pain and suffering.

        I think the data structures you work with determine the simplicity, or
        not. It's not a language choice but rather a data representation
        choice. Earlier I suggested a voxel approach. Whatever you choose,
        don't make it "raw" data with a zillion little pieces and parts to it.
        Players don't want to write reams of code to play a game, they want
        results. Instant feedback! If it takes them a day to figure some
        !#@$#$!#$@! thing out then the system is wrong.


        Cheers, www.3DProgrammer.com
        Brandon Van Every Seattle, WA

        20% of the world is real.
        80% is gobbledygook we make up inside our own heads.
      • John Ludlow
        ... I agree, to an extent. The style of the language also has a big effect. Simple is a good design goal. In my (admittedly limited) experience, OO does
        Message 3 of 8 , Nov 1, 2002
        • 0 Attachment
          --- In gamedesign-l@y..., "Brandon J. Van Every" <vanevery@3...> wrote:
          > > From: John Ludlow [mailto:jludlow3@n...]
          > >
          > > [Note to moderators - Ok, I can see this going a little into
          > > programming territory. But where do we draw the line on this one,
          > > since programming is a part of the game experience, which should be
          > > discussed?]
          >
          > When it gets to sound like a pile of programming babbling gobbledygook,
          > that's when it gets the axe. It's skirting that boundary now... who
          > cares about OO methods and embedded strings? Is OO the best thing since
          > sliced bread or a programmatic detail that could be achieved plenty of
          > other ways? Is OO even vaguely relevant to scripting? That's a
          > discussion best left to another forum. The relevant game design +
          > programming discussion to be had here, is how this API is going to be
          > kept *SIMPLE* for the player. So that they're actually willing to code
          > to it, and don't view it as a unique act of pain and suffering.
          >
          > I think the data structures you work with determine the simplicity, or
          > not. It's not a language choice but rather a data representation
          > choice. Earlier I suggested a voxel approach. Whatever you choose,
          > don't make it "raw" data with a zillion little pieces and parts to it.
          > Players don't want to write reams of code to play a game, they want
          > results. Instant feedback! If it takes them a day to figure some
          > !#@$#$!#$@! thing out then the system is wrong.

          I agree, to an extent. The style of the language also has a big
          effect. Simple is a good design goal. In my (admittedly limited)
          experience, OO does make things simple. It's not perfect, but you can
          get results quickly if you have a lot of pre-written classes to use.
          This was shown by my recent attempts at C#. OO works best when you
          want to do something fairly standard.

          My idea was a low-level thing. Drew had an idea of a 'closest object'
          sort of thing, which is a higher-level style. Probably, you could
          provide both. But I'd personally do a multi-layered interface that
          gives them a way to get simple things done very quickly, but also
          gives them the option to do really clever stuff as well. Giving
          access to the sensors would be one example, and you also have various
          objects/tools/functions they can use to analyse the sensor data on the
          fly. Such as a function that scans the sensor data, recognises
          objects in the world and creates them as objects that can be used by
          the AI. So you could have a function that returns details of the
          closest object in the world.

          Right, I'm gonna shut up before Brandon rejects this for sounding too
          much like a topic on programming.
        • Drew Torrens
          From: John Ludlow ... The way it will be working is that there will be downloadable code and classes in Java that you can extend
          Message 4 of 8 , Nov 1, 2002
          • 0 Attachment
            From: "John Ludlow" <jludlow3@...>
            > > > How will the AI be written? [Please keep it focused on game design
            > > though. - Moderator]
            > I think a little confusion is rife here. I meant what kind of
            > interface will the user use to customise the AI. I've seen a few
            > games (Core Wars was, I think, one of them) which use a weird sort of
            > grid of numbers. It was completely inaccessible to me, and I got
            > fustrated by it. A proper programming language I can deal with. :)

            The way it will be working is that there will be downloadable code and
            classes in Java that you can extend using your favorite method (mine -
            command prompt and dos edit ;-D)

            That way I don't have to worry about creating my own compiler, or my own
            interface. I figured it's much easier to use an established language which
            has a lot of following... And the C programmers won't have much trouble
            with it either -- the two languages are painfully similar most of the time.

            > I'll check out Omega, see what it's like, in between all the new demos
            > I've found myself with this week.

            Be prepared. It's ancient in gaming standards. I'm sure you'll be able to
            find a handful of sites on it though (there was a webring for it the last
            time I had it installed)

            > Sounds good. So to customise the AI, the user would write Java code?

            Yup. They'd extend (inherit) a base "TankControl" class, and have free
            reign over what to do from there.

            > Personally, I'm into very simple programming languages. An
            > object-oriented approach works very well for a lot of things. AI is
            > one of the better examples. For example, you could say that when the
            > robot is attacked, it

            I think you got cut off here... ;-)

            I picked Java since it's easy to write code that depends on classes that
            haven't been written yet ;-) It saves me a lot of trouble in creating a
            compiler or interpreter.

            Java is also very forgiving to programmers compared to a lot of languages,
            and the basic kit you download from Sun gives very useful debugging messages
            :-)

            > > My question to that, then, is how easy that would be for the programmer
            to
            > > interpret and work with? Mind you, I suppose it's only one level of
            > > abstraction away from creating the "Closest ____" data I mentioned
            > > earlier...
            >
            > Yeah, perhaps you could use something like that as a basis.
            > Personally, I think that'd be a very simple way of providing a lot of
            > visual input. If you want, you could represent it as a 3D array with
            > the robot at the centre. This'd be kinda similar to your first idea,
            > except in 3D. Or you could have the different layers of the 3D array
            > representing different types of info.

            I think that would be a beast for the AI programmer to work with,
            personally... A lot of data for relatively little pertenant information...
            It looks like the winning approach so far is Ismo's, since it would require
            the least thought for the AI programmer to deal with.

            > [Note to moderators - Ok, I can see this going a little into
            > programming territory. But where do we draw the line on this one,
            > since programming is a part of the game experience, which should be
            > discussed?]

            I think as long as we stick with how to present the data to the player, that
            falls under design. As soon as we discuss how to implement that design
            decision, then that's a little less so, unless a particular aspect of the
            implementation is important to consider for the player's gaming experience
            (such as the decision to implement in Java, since that affects what language
            the players will have to deal with)

            Mind you, Java can interface with native code, so it would be fairly simple
            to write a generic class which is just a shell to hold the AI you've written
            in a different language...

            TTFN,
            Drew
          • John Ludlow
            ... design ... language which ... the time. ... able to ... last ... Found it. The language looks fairly easy, but the editor is horrible. ... Yeah, got
            Message 5 of 8 , Nov 1, 2002
            • 0 Attachment
              --- In gamedesign-l@y..., "Drew Torrens" <drew.torrens@s...> wrote:
              > From: "John Ludlow" <jludlow3@n...>
              > > > > How will the AI be written? [Please keep it focused on game
              design
              > > > though. - Moderator]
              > > I think a little confusion is rife here. I meant what kind of
              > > interface will the user use to customise the AI. I've seen a few
              > > games (Core Wars was, I think, one of them) which use a weird sort of
              > > grid of numbers. It was completely inaccessible to me, and I got
              > > fustrated by it. A proper programming language I can deal with. :)
              >
              > The way it will be working is that there will be downloadable code and
              > classes in Java that you can extend using your favorite method (mine -
              > command prompt and dos edit ;-D)
              >
              > That way I don't have to worry about creating my own compiler, or my own
              > interface. I figured it's much easier to use an established
              language which
              > has a lot of following... And the C programmers won't have much trouble
              > with it either -- the two languages are painfully similar most of
              the time.
              >
              > > I'll check out Omega, see what it's like, in between all the new demos
              > > I've found myself with this week.
              >
              > Be prepared. It's ancient in gaming standards. I'm sure you'll be
              able to
              > find a handful of sites on it though (there was a webring for it the
              last
              > time I had it installed)
              >
              Found it. The language looks fairly easy, but the editor is horrible.

              > > Sounds good. So to customise the AI, the user would write Java code?
              >
              > Yup. They'd extend (inherit) a base "TankControl" class, and have free
              > reign over what to do from there.
              >
              > > Personally, I'm into very simple programming languages. An
              > > object-oriented approach works very well for a lot of things. AI is
              > > one of the better examples. For example, you could say that when the
              > > robot is attacked, it
              >
              > I think you got cut off here... ;-)
              Yeah, got called away and lost track... :(

              I was going to say that an event could fire off.

              > I picked Java since it's easy to write code that depends on classes that
              > haven't been written yet ;-) It saves me a lot of trouble in creating a
              > compiler or interpreter.
              Yeah, I guess. I don't suppose you'd consider a C# version? No, I
              guess not...

              > > > My question to that, then, is how easy that would be for the
              programmer
              > to
              > > > interpret and work with? Mind you, I suppose it's only one level of
              > > > abstraction away from creating the "Closest ____" data I mentioned
              > > > earlier...
              > >
              > > Yeah, perhaps you could use something like that as a basis.
              > > Personally, I think that'd be a very simple way of providing a lot of
              > > visual input. If you want, you could represent it as a 3D array with
              > > the robot at the centre. This'd be kinda similar to your first idea,
              > > except in 3D. Or you could have the different layers of the 3D array
              > > representing different types of info.
              >
              > I think that would be a beast for the AI programmer to work with,
              > personally... A lot of data for relatively little pertenant
              information...

              I dunno. It'd mean a lot of data being stored, sure. But how do you
              decide what's pertinent without analysing all of the data?

              > It looks like the winning approach so far is Ismo's, since it would
              require
              > the least thought for the AI programmer to deal with.

              Sorry, I can't find Ismo's post. Did he email you directly?
            • Brandon J. Van Every
              From: John Ludlow [mailto:johnludlow_uk@yahoo.co.uk] ... OO, in my experience, causes me to bog myself down in architectural design decisions when I really
              Message 6 of 8 , Nov 1, 2002
              • 0 Attachment
                From: John Ludlow [mailto:johnludlow_uk@...]
                >
                > I agree, to an extent. The style of the language also has a big
                > effect. Simple is a good design goal. In my (admittedly limited)
                > experience, OO does make things simple.

                OO, in my experience, causes me to bog myself down in architectural
                design decisions when I really should be producing working code and
                refactoring later. It is only recently that I've finally figured out
                the proper dance, of getting things working first, and refactoring the
                OO later. I'm pleased to say that as of this evening, my burgeoning app
                doesn't know it's running on either Windows or Direct3D. I'm one step
                closer to keeping my game alive for 25 years.

                > It's not perfect, but you can
                > get results quickly if you have a lot of pre-written classes to use.
                > This was shown by my recent attempts at C#. OO works best when you
                > want to do something fairly standard.

                I've almost always been writing OO code from scratch, and never using
                someone else's OO library.


                Cheers, www.3DProgrammer.com
                Brandon Van Every Seattle, WA

                20% of the world is real.
                80% is gobbledygook we make up inside our own heads.
              • Drew Torrens
                From: John Ludlow ... Yup, I guess he did at that :-/ OOPS! Once I flesh out my approach a little bit (I ve got an hour and a
                Message 7 of 8 , Nov 2, 2002
                • 0 Attachment
                  From: "John Ludlow" <johnludlow_uk@...>
                  > Sorry, I can't find Ismo's post. Did he email you directly?

                  Yup, I guess he did at that :-/ OOPS!

                  Once I flesh out my approach a little bit (I've got an hour and a half
                  mass-transit trip today to do it in) I'll post what I'm proposing...

                  For now, i've got to get ready ;-)

                  TTFN,
                  Drew
                Your message has been successfully submitted and would be delivered to recipients shortly.