Improving a sector's visibility

Archived from groups: rec.games.empire (More info?)

There should be a way to increase a sector's visibility numbers by
parking a zeppelin in a sector. Of course that sector would need to
have fuel and maybe bombs and guns, but it should give any sector
(even an 0% wilderness) view numbers something like 157% of a fully
improved sector to represent the increased distance to the horizon.
Doing so would be a big improvement in realism (and isn't that the
whole point?) and lower micromanagement with only a minor increase in
code complexity. Just my .02 USD.

- James
50 answers Last reply
More about improving sector visibility
  1. Archived from groups: rec.games.empire (More info?)

    James Calivar wrote:

    > There should be a way to increase a sector's visibility numbers by
    > parking a zeppelin in a sector. Of course that sector would need to
    > have fuel and maybe bombs and guns, but it should give any sector
    > (even an 0% wilderness) view numbers something like 157% of a fully
    > improved sector to represent the increased distance to the horizon.
    > Doing so would be a big improvement in realism (and isn't that the
    > whole point?) and lower micromanagement with only a minor increase in
    > code complexity. Just my .02 USD.
    >
    > - James

    Can this be applied for other VTOL craft - that could work in
    theoretically the same way?
  2. Archived from groups: rec.games.empire (More info?)

    "Gemini" <spam@nospam.org> wrote in message
    news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
    > James Calivar wrote:
    >
    > > There should be a way to increase a sector's visibility numbers by
    > > parking a zeppelin in a sector. Of course that sector would need to
    > > have fuel and maybe bombs and guns, but it should give any sector
    > > (even an 0% wilderness) view numbers something like 157% of a fully
    > > improved sector to represent the increased distance to the horizon.
    > > Doing so would be a big improvement in realism (and isn't that the
    > > whole point?) and lower micromanagement with only a minor increase in
    > > code complexity. Just my .02 USD.
    > >
    > > - James
    >
    > Can this be applied for other VTOL craft - that could work in
    > theoretically the same way?

    Not unless they have the capability to "hover" for an extended period of
    time.
  3. Archived from groups: rec.games.empire (More info?)

    In article <8fd1f87.0409290726.b6829ad@posting.google.com>,
    James Calivar <amheiserbush@yahoo.com.au> wrote:
    >There should be a way to increase a sector's visibility numbers by
    >parking a zeppelin in a sector. Of course that sector would need to
    >have fuel and maybe bombs and guns, but it should give any sector
    >(even an 0% wilderness) view numbers something like 157% of a fully
    >improved sector to represent the increased distance to the horizon.
    >Doing so would be a big improvement in realism (and isn't that the
    >whole point?) and lower micromanagement with only a minor increase in
    >code complexity. Just my .02 USD.

    He found it! The holy grail! A change in the code that is a minor
    increase, improves realism, and reduces micromangement!!! OH MY GOD!!!!
    CALL GUINESS!!!!!

    :)

    How does this *lower* micromanagement? Seems to me it increases
    it; you've got to build a zep, get it to the sector in question,
    get at least some petrol into the sector, and then have some method
    of determining sector visibility overlaps to make sure you don't
    have an unexpected gap in coverage (though we don't currently have
    such a mechanism for, say, radar stations...it would be nice though).

    Realism? That's not the target of code development. In all cases
    where playability and realism are in disagreement, playability
    trumps realism. The target is playability. If our goal is realism,
    Empire would die. Rapidly.

    Realism is having a population of millions that can do the job
    of micromanagement for you. In Empire, you're a small number of
    people running a country. The game has to encapsulate realism
    into something that is playable; this means realism tends to
    lose out. You can't possibly immitate reality with the tools
    currently available to the average user.

    As for the minor code change this would take; write it and
    submit it to Wolfpack. We'll be happy to make it an available
    patch.

    -Geoff
    aka Mithrilien
  4. Archived from groups: rec.games.empire (More info?)

    In article <cjeqr2$ke7$1@home.itg.ti.com>,
    James Calivar <amheiserbush@yahoo.com.au> wrote:
    >"Gemini" <spam@nospam.org> wrote in message
    >news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
    >> James Calivar wrote:
    >>
    >> > There should be a way to increase a sector's visibility numbers by
    >> > parking a zeppelin in a sector. Of course that sector would need to
    >> > have fuel and maybe bombs and guns, but it should give any sector
    >> > (even an 0% wilderness) view numbers something like 157% of a fully
    >> > improved sector to represent the increased distance to the horizon.
    >> > Doing so would be a big improvement in realism (and isn't that the
    >> > whole point?) and lower micromanagement with only a minor increase in
    >> > code complexity. Just my .02 USD.
    >> >
    >> > - James
    >>
    >> Can this be applied for other VTOL craft - that could work in
    >> theoretically the same way?
    >
    >Not unless they have the capability to "hover" for an extended period of
    >time.
    >

    You're opening a can of worms.

    Define 'hover'. A number of early planes that featured low air speeds
    could maintain position over a given area while flying into the wind.
    Certainly such a plane can 'hover' for quite a long period by doing
    small race tracks of a few miles in length. Also, later planes can
    certainly maintain the observational equivalent of a hover by simply
    flying in slow circles (say, the 'size' of an Empire sector). Then
    of course there's JF2s.

    -Geoff
    aka Mithrilien
  5. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:

    > In article <cjeqr2$ke7$1@home.itg.ti.com>,
    > James Calivar <amheiserbush@yahoo.com.au> wrote:
    >
    >>"Gemini" <spam@nospam.org> wrote in message
    >>news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
    >>
    >>>James Calivar wrote:
    >>>
    >>>
    >>>>There should be a way to increase a sector's visibility numbers by
    >>>>parking a zeppelin in a sector. Of course that sector would need to
    >>>>have fuel and maybe bombs and guns, but it should give any sector
    >>>>(even an 0% wilderness) view numbers something like 157% of a fully
    >>>>improved sector to represent the increased distance to the horizon.
    >>>>Doing so would be a big improvement in realism (and isn't that the
    >>>>whole point?) and lower micromanagement with only a minor increase in
    >>>>code complexity. Just my .02 USD.
    >>>>
    >>>>- James
    >>>
    >>>Can this be applied for other VTOL craft - that could work in
    >>>theoretically the same way?
    >>
    >>Not unless they have the capability to "hover" for an extended period of
    >>time.
    >>
    >
    >
    > You're opening a can of worms.
    >
    > Define 'hover'. A number of early planes that featured low air speeds
    > could maintain position over a given area while flying into the wind.
    > Certainly such a plane can 'hover' for quite a long period by doing
    > small race tracks of a few miles in length. Also, later planes can
    > certainly maintain the observational equivalent of a hover by simply
    > flying in slow circles (say, the 'size' of an Empire sector). Then
    > of course there's JF2s.
    >
    > -Geoff
    > aka Mithrilien
    >
    >
    That's what I was thinking. Like E2s (AWACS) and such.
  6. Archived from groups: rec.games.empire (More info?)

    James Calivar <amheiserbush@yahoo.com.au> wrote:
    > "Gemini" <spam@nospam.org> wrote in message
    > news:e3eb0$415aeb84$d89e2d68$19414@dcanet.allthenewsgroups.com...
    > > James Calivar wrote:
    > >
    > > > There should be a way to increase a sector's visibility numbers by
    > > > parking a zeppelin in a sector. Of course that sector would need to
    > > > have fuel and maybe bombs and guns, but it should give any sector
    > > > (even an 0% wilderness) view numbers something like 157% of a fully
    > > > improved sector to represent the increased distance to the horizon.
    > > > Doing so would be a big improvement in realism (and isn't that the
    > > > whole point?) and lower micromanagement with only a minor increase in
    > > > code complexity. Just my .02 USD.
    > > >
    > > > - James
    > >
    > > Can this be applied for other VTOL craft - that could work in
    > > theoretically the same way?

    > Not unless they have the capability to "hover" for an extended period of
    > time.

    I'd rather have an air radar satellite type, which is a balloon-carried
    radar. It can also be deorbited and relaunched at player's leisure time.

    But still we need an aircraft detection radar first.


    --
    Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
    Email: romm@empire.tau.ac.il http://www.nasa.proj.ac.il/
    Phone/Fax: +972-(0)3-6405205 (work), +972-(0)50-734-18-34 (home)
    ----------------------------------------------------------------------
    The economy depends about as much on economists as the weather does on
    weather forecasters.
    -- Jean-Paul Kauffmann
  7. Archived from groups: rec.games.empire (More info?)

    In article <d748d$415b2a4f$d89e2d68$20840@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >Geoff Cashman wrote:
    >> You're opening a can of worms.
    >>
    >> Define 'hover'. A number of early planes that featured low air speeds
    >> could maintain position over a given area while flying into the wind.
    >> Certainly such a plane can 'hover' for quite a long period by doing
    >> small race tracks of a few miles in length. Also, later planes can
    >> certainly maintain the observational equivalent of a hover by simply
    >> flying in slow circles (say, the 'size' of an Empire sector). Then
    >> of course there's JF2s.
    >>
    >
    >That's what I was thinking. Like E2s (AWACS) and such.
    >

    The only way I can see that working is to have a mission for
    that type of operation. The plane gets dedicated to the operation
    and while it is on that mission designation it detects anything
    it can see while aloft, which is defined as being on the mission.

    In this scenario, it should be depleting petrol every update,
    at a minimum, and mobility. But, that's abusable; take plane
    off mission before update. So, you'd have to do it per ETU.
    Deplete some petrol and mobility when plane/zep is placed on
    observation mission, and continue depleting at <x> rate per
    ETU while on that mission.

    Sounds fine so far, right?

    Nope.

    Micromanagement headache; keeping all sectors supplied
    with petrol that have planes on observation missions.
    Worse, you have to keep track per ETU or dump a large
    amount of petrol in the sector before starting the mission.

    Anything that you can place on automatic needs to be
    something you can forget about managing after you
    initiate the automatic action. Some things in Empire fail
    that rule of thumb right now. These things generate
    micromanagement. I'd rather not add more of them.

    -Geoff
  8. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:
    > In article <d748d$415b2a4f$d89e2d68$20840@dcanet.allthenewsgroups.com>,
    > Gemini <spam@nospam.org> wrote:
    >
    >>Geoff Cashman wrote:
    >>
    >>>You're opening a can of worms.
    >>>
    >>>Define 'hover'. A number of early planes that featured low air speeds
    >>>could maintain position over a given area while flying into the wind.
    >>>Certainly such a plane can 'hover' for quite a long period by doing
    >>>small race tracks of a few miles in length. Also, later planes can
    >>>certainly maintain the observational equivalent of a hover by simply
    >>>flying in slow circles (say, the 'size' of an Empire sector). Then
    >>>of course there's JF2s.
    >>>
    >>
    >>That's what I was thinking. Like E2s (AWACS) and such.
    >>
    >
    >
    > The only way I can see that working is to have a mission for
    > that type of operation. The plane gets dedicated to the operation
    > and while it is on that mission designation it detects anything
    > it can see while aloft, which is defined as being on the mission.
    >
    > In this scenario, it should be depleting petrol every update,
    > at a minimum, and mobility. But, that's abusable; take plane
    > off mission before update. So, you'd have to do it per ETU.
    > Deplete some petrol and mobility when plane/zep is placed on
    > observation mission, and continue depleting at <x> rate per
    > ETU while on that mission.
    >
    > Sounds fine so far, right?
    >
    > Nope.
    >
    > Micromanagement headache; keeping all sectors supplied
    > with petrol that have planes on observation missions.
    > Worse, you have to keep track per ETU or dump a large
    > amount of petrol in the sector before starting the mission.
    >
    > Anything that you can place on automatic needs to be
    > something you can forget about managing after you
    > initiate the automatic action. Some things in Empire fail
    > that rule of thumb right now. These things generate
    > micromanagement. I'd rather not add more of them.
    >
    > -Geoff
    >
    >
    >
    >

    Well, what about if you also had refueling planes that could be given a
    refuel mission. They sit in the airfield, and, during an ETU click or
    Update or whatever, and aircraft that are on a "AWACS" mission that drop
    below a certain fuel level, get refueld by the refueler aircraft (kinda
    like real life). Then, all you have to do is keep fuel on the airfield
    (which you would be doing anyway). That should reduce the
    micromanagement aspect - although I'd imagine it would add considerably
    to the coding requirements.

    Gemini
  9. Archived from groups: rec.games.empire (More info?)

    theobviousgcashman@theobviousindiana.edu (Geoff Cashman) writes:

    > In article <d748d$415b2a4f$d89e2d68$20840@dcanet.allthenewsgroups.com>,
    > Gemini <spam@nospam.org> wrote:
    >>Geoff Cashman wrote:
    >>> You're opening a can of worms.
    >>>
    >>> Define 'hover'. A number of early planes that featured low air speeds
    >>> could maintain position over a given area while flying into the wind.
    >>> Certainly such a plane can 'hover' for quite a long period by doing
    >>> small race tracks of a few miles in length. Also, later planes can
    >>> certainly maintain the observational equivalent of a hover by simply
    >>> flying in slow circles (say, the 'size' of an Empire sector). Then
    >>> of course there's JF2s.
    >>>
    >>
    >>That's what I was thinking. Like E2s (AWACS) and such.
    >>
    >
    > The only way I can see that working is to have a mission for
    > that type of operation. The plane gets dedicated to the operation
    > and while it is on that mission designation it detects anything
    > it can see while aloft, which is defined as being on the mission.
    >
    > In this scenario, it should be depleting petrol every update,
    > at a minimum, and mobility. But, that's abusable; take plane
    > off mission before update. So, you'd have to do it per ETU.
    > Deplete some petrol and mobility when plane/zep is placed on
    > observation mission, and continue depleting at <x> rate per
    > ETU while on that mission.

    I can imagine players crazy enough to take the plane off the mission
    right before the next ETU tick. To counter that, you also need to
    charge mobility when the plane is taken off the mission, rounding
    fractions randomly.

    > Sounds fine so far, right?
    >
    > Nope.
    >
    > Micromanagement headache; keeping all sectors supplied
    > with petrol that have planes on observation missions.
    > Worse, you have to keep track per ETU or dump a large
    > amount of petrol in the sector before starting the mission.

    The plane could use the supply code to draw petrol as needed. The
    supply code has a simplistic design, which is barely adequate, and is
    ugly and full of bugs.

    > Anything that you can place on automatic needs to be
    > something you can forget about managing after you
    > initiate the automatic action. Some things in Empire fail
    > that rule of thumb right now. These things generate
    > micromanagement. I'd rather not add more of them.

    Absolutely.

    AEW is a nice idea; it's been around for some time. Maybe somebody
    can code it and try it in a game.

    A word of caution regarding features. Empire doesn't suffer any
    shortage of features. In fact, it's staggering below their weight.
    Slapping on a new feature or two is fairly easy. Much easier than
    cleaning up a mess of ill-designed, misfitting, buggy `features'
    afterwards. More glamorous, too.

    For every new feature, I'd like to see at least two misfeatures fixed
    or taken out. And the most valuable features at this time might be
    the not so glamorous ones, like better support for clients, or better
    tools for deities.

    This is not an official policy, just an attitude.

    And if you code a nice feature, and players like it, and its code is
    okay, of course it can go in, attitude or not.
  10. Archived from groups: rec.games.empire (More info?)

    "Markus Armbruster" <armbru@pond.sub.org> wrote in message

    > For every new feature, I'd like to see at least two misfeatures fixed
    > or taken out.

    Ohh, Ohh can I pick some?
    Lets start off with yanking out BTUs and the anti command. :-)

    Mark
  11. Archived from groups: rec.games.empire (More info?)

    In article <cQN6d.1874$wF2.90110@news.uswest.net>,
    Scott Zielinski <scottz@websagacity.com> wrote:
    >Well, what about if you also had refueling planes that could be given a
    >refuel mission. They sit in the airfield, and, during an ETU click or
    >Update or whatever, and aircraft that are on a "AWACS" mission that drop
    >below a certain fuel level, get refueld by the refueler aircraft (kinda
    >like real life). Then, all you have to do is keep fuel on the airfield
    >(which you would be doing anyway). That should reduce the
    >micromanagement aspect - although I'd imagine it would add considerably
    >to the coding requirements.

    That doesn't reduce the micromanagement. It just shifts it from
    one plane to another. In fact, it even adds to management since
    you have to 'mission' the AEW platform *and* the refueling platform.

    -Geoff
    aka Mithrilien
  12. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:
    > In article <cQN6d.1874$wF2.90110@news.uswest.net>,
    > Scott Zielinski <scottz@websagacity.com> wrote:
    >
    >>Well, what about if you also had refueling planes that could be given a
    >>refuel mission. They sit in the airfield, and, during an ETU click or
    >>Update or whatever, and aircraft that are on a "AWACS" mission that drop
    >>below a certain fuel level, get refueld by the refueler aircraft (kinda
    >>like real life). Then, all you have to do is keep fuel on the airfield
    >>(which you would be doing anyway). That should reduce the
    >>micromanagement aspect - although I'd imagine it would add considerably
    >>to the coding requirements.
    >
    >
    > That doesn't reduce the micromanagement. It just shifts it from
    > one plane to another. In fact, it even adds to management since
    > you have to 'mission' the AEW platform *and* the refueling platform.
    >
    > -Geoff
    > aka Mithrilien
    >

    Not really. Missions are set and forget, and if u have multiple AWACS is
    what I was referring to. Then u would only have to worry about fuel in 1
    sector, not each sector the AWACS is in. And for the whole area, you
    would only need to mission one refueler plane.

    Gemini
  13. Archived from groups: rec.games.empire (More info?)

    In article <87vfdwqo3m.fsf@pond.sub.org>,
    Markus Armbruster <armbru@pond.sub.org> wrote:
    >
    >A word of caution regarding features. Empire doesn't suffer any
    >shortage of features. In fact, it's staggering below their weight.
    >Slapping on a new feature or two is fairly easy. Much easier than
    >cleaning up a mess of ill-designed, misfitting, buggy `features'
    >afterwards. More glamorous, too.
    >

    Yep. Being a good steward of the code isn't sexy. In fact, some players
    actually get actively *mad* at you for it. But, it is what is good for
    the code and good for the game over the long run. In the near term, it
    often isn't very rewarding.


    >For every new feature, I'd like to see at least two misfeatures fixed
    >or taken out. And the most valuable features at this time might be
    >the not so glamorous ones, like better support for clients, or better
    >tools for deities.

    Preach on, brother Markus.


    >This is not an official policy, just an attitude.

    The attitude is the principle on which I've been adminstering Wolfpack
    for the last two years. In so far as a policy can be official within
    Empire, this attitude is policy.


    >And if you code a nice feature, and players like it, and its code is
    >okay, of course it can go in, attitude or not.

    Absolutely!

    Too often, players have interpreted my attitude as reluctance to
    consider changes, or custom mods to the code. NOT AT ALL what I
    intend!

    -Geoff
    aka Mithrilien
  14. Archived from groups: rec.games.empire (More info?)

    In article <daa03$415c3308$d89e2d68$26222@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >
    >Not really. Missions are set and forget, and if u have multiple AWACS is
    >what I was referring to. Then u would only have to worry about fuel in 1
    >sector, not each sector the AWACS is in. And for the whole area, you
    >would only need to mission one refueler plane.
    >

    Ah, I see what you're getting at. Ok, I can see that. Even makes sense
    from an operational point of view.

    Having a very hard time getting a programming view around it though.
    I don't want to think about the command syntax players would have to
    use!!! Probably just as bad as "order".

    -Geoff
    aka Mithrilien
  15. Archived from groups: rec.games.empire (More info?)

    In article <2s2t9cF1gi2heU1@uni-berlin.de>,
    Mark Stokje <mst_dont_spam_me@yahoo.com> wrote:
    >
    >"Markus Armbruster" <armbru@pond.sub.org> wrote in message
    >
    >> For every new feature, I'd like to see at least two misfeatures fixed
    >> or taken out.
    >
    >Ohh, Ohh can I pick some?
    >Lets start off with yanking out BTUs and the anti command. :-)
    >

    ....and here's the other side of the "what do you do first" coin;
    Esentially, anything that you do with the Empire code that is NOT
    a bug fix has ramifications (often substantial) on the game. It
    is quite often the case that you can not predict all the ways in
    which a change can impact the game.

    Empire is a very complex environment, with a whole slew of properties
    and variables interacting with each other to produce a game playing
    environment. The dependencies within the system are oftne obscure,
    and apparently unrelated.

    It's kinda like attempting weather control at this stage of human
    technological development. Can we attempt it? Yep. In fact, we have.
    But, the unintended results are too widespread and variable to imagine.
    Bird flaps its wings in China, rain falls in Iceland. Remove BTUs in
    Empire, and who the knows what the hell will happen.

    I've come up with some amazing solutions to long term problems
    that plague Empire. I've spent hours honing the solution into
    a workable form. Then, I put it in front of another set of Empire
    eyes and the whole thing gets shot down faster than a sparrow with
    a .30-06 shell in it's head (or what's left of it's head).

    Scoping the impact of changes in Empire is *very* difficult.

    -Geoff
    aka Mithrilien
  16. Archived from groups: rec.games.empire (More info?)

    "Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:

    > "Markus Armbruster" <armbru@pond.sub.org> wrote in message
    >
    >> For every new feature, I'd like to see at least two misfeatures fixed
    >> or taken out.
    >
    > Ohh, Ohh can I pick some?
    > Lets start off with yanking out BTUs and the anti command. :-)

    Hear, hear!

    I invite everybody to nominate misfeatures to yank.
  17. Archived from groups: rec.games.empire (More info?)

    Markus Armbruster wrote:

    > "Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:
    >
    >
    >>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
    >>
    >>
    >>>For every new feature, I'd like to see at least two misfeatures fixed
    >>>or taken out.
    >>
    >>Ohh, Ohh can I pick some?
    >>Lets start off with yanking out BTUs and the anti command. :-)
    >
    >
    > Hear, hear!
    >
    > I invite everybody to nominate misfeatures to yank.

    I say yank UPDATES...make it real time!
  18. Archived from groups: rec.games.empire (More info?)

    In article <58b19$415c480b$d89e2d68$27203@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >Markus Armbruster wrote:
    >
    >> "Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:
    >>
    >>
    >>>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
    >>>
    >>>
    >>>>For every new feature, I'd like to see at least two misfeatures fixed
    >>>>or taken out.
    >>>
    >>>Ohh, Ohh can I pick some?
    >>>Lets start off with yanking out BTUs and the anti command. :-)
    >>
    >>
    >> Hear, hear!
    >>
    >> I invite everybody to nominate misfeatures to yank.
    >
    >I say yank UPDATES...make it real time!

    Much of that already exists with MOB_ACCESS.

    If you want to make everything update per ETU, you're into
    micro updates. We've found out the hardway that micro updates
    are absolutely HORRIBLE.

    -Geoff
  19. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:

    > In article <58b19$415c480b$d89e2d68$27203@dcanet.allthenewsgroups.com>,
    > Gemini <spam@nospam.org> wrote:
    >
    >>Markus Armbruster wrote:
    >>
    >>
    >>>"Mark Stokje" <mst_dont_spam_me@yahoo.com> writes:
    >>>
    >>>
    >>>
    >>>>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
    >>>>
    >>>>
    >>>>
    >>>>>For every new feature, I'd like to see at least two misfeatures fixed
    >>>>>or taken out.
    >>>>
    >>>>Ohh, Ohh can I pick some?
    >>>>Lets start off with yanking out BTUs and the anti command. :-)
    >>>
    >>>
    >>>Hear, hear!
    >>>
    >>>I invite everybody to nominate misfeatures to yank.
    >>
    >>I say yank UPDATES...make it real time!
    >
    >
    > Much of that already exists with MOB_ACCESS.
    >
    > If you want to make everything update per ETU, you're into
    > micro updates. We've found out the hardway that micro updates
    > are absolutely HORRIBLE.
    >
    > -Geoff
    >
    I could never get MOB_ACCESS to work - at least as far as I could tell.
    Maybe I missed its purpose...

    G][
  20. Archived from groups: rec.games.empire (More info?)

    "Gemini" <spam@nospam.org> wrote in message news:25957$415c5cce$d89e2d68
    > >
    > I could never get MOB_ACCESS to work - at least as far as I could tell.
    > Maybe I missed its purpose...
    >
    Never been in a game with it, but here's its purpose

    http://makeashorterlink.com/?Q53C31A69

    Mark
  21. Archived from groups: rec.games.empire (More info?)

    In article <25957$415c5cce$d89e2d68$28041@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >Geoff Cashman wrote:
    >> Much of that already exists with MOB_ACCESS.
    >>
    >> If you want to make everything update per ETU, you're into
    >> micro updates. We've found out the hardway that micro updates
    >> are absolutely HORRIBLE.
    >>
    >> -Geoff
    >>
    >I could never get MOB_ACCESS to work - at least as far as I could tell.
    >Maybe I missed its purpose...
    >

    Simple. MOB_ACCESS enabled games result in unit, ship, plane,
    and sector mobility being inreased by appropriate amounts
    every ETU, rather than every update.

    -Geoff
  22. Archived from groups: rec.games.empire (More info?)

    "Mark Stokje" <mst_dont_spam_me@yahoo.com> wrote in message
    news:2s36q7F1fe528U1@uni-berlin.de...
    >
    > "Gemini" <spam@nospam.org> wrote in message news:25957$415c5cce$d89e2d68
    >> >
    >> I could never get MOB_ACCESS to work - at least as far as I could tell.
    >> Maybe I missed its purpose...
    >>
    > Never been in a game with it, but here's its purpose
    >
    > http://makeashorterlink.com/?Q53C31A69
    >
    > Mark
    >
    >
    Let me tell you how it really works though...

    Normal : OK, my cav unit will get 60 mob points at the update, let me see
    how far he'll be able to attack. Do some calculations. Plan an attack.
    Come back for the update.

    With MOB_ACCESS: OK, in 72 minutes, my cav will have enough mob to attack
    one sector. I'll check back in then and do it. Then, after that attack.
    OK, now the cav will have enough mob in 216 minutes. I'll set my alarm and
    wake up to get that one more sector. This is a tough game, and every sector
    counts...

    Of course, you could just ignore the MOB_ACCESS part and pretend that mob
    goes up at the updates. But if you were that kind of person, you probably
    wouldn't be playing empire in the first place...

    Tim
  23. Archived from groups: rec.games.empire (More info?)

    Tim & Tracy Burnett wrote:

    > "Mark Stokje" <mst_dont_spam_me@yahoo.com> wrote in message
    > news:2s36q7F1fe528U1@uni-berlin.de...
    >
    >>"Gemini" <spam@nospam.org> wrote in message news:25957$415c5cce$d89e2d68
    >>
    >>>I could never get MOB_ACCESS to work - at least as far as I could tell.
    >>>Maybe I missed its purpose...
    >>>
    >>
    >>Never been in a game with it, but here's its purpose
    >>
    >>http://makeashorterlink.com/?Q53C31A69
    >>
    >>Mark
    >>
    >>
    >
    > Let me tell you how it really works though...
    >
    > Normal : OK, my cav unit will get 60 mob points at the update, let me see
    > how far he'll be able to attack. Do some calculations. Plan an attack.
    > Come back for the update.
    >
    > With MOB_ACCESS: OK, in 72 minutes, my cav will have enough mob to attack
    > one sector. I'll check back in then and do it. Then, after that attack.
    > OK, now the cav will have enough mob in 216 minutes. I'll set my alarm and
    > wake up to get that one more sector. This is a tough game, and every sector
    > counts...
    >
    > Of course, you could just ignore the MOB_ACCESS part and pretend that mob
    > goes up at the updates. But if you were that kind of person, you probably
    > wouldn't be playing empire in the first place...
    >
    > Tim
    >
    >

    An interesting fix to that would be if you could assign movement orders
    - then when the unit had enough MOB, it would move to the next sector in
    the path - providing its able.

    Gemini
  24. Archived from groups: rec.games.empire (More info?)

    "Gemini" <spam@nospam.org> wrote in message
    news:9cc2b$415c7bdb$d89e2d68$28798@dcanet.allthenewsgroups.com...
    >
    > An interesting fix to that would be if you could assign movement orders -
    > then when the unit had enough MOB, it would move to the next sector in the
    > path - providing its able.
    >
    > Gemini

    Order doesn't exactly work like that. Order can't attack. Also, order is
    going to do it's thing at the update. Even with MOB_ACCESS on. Otherwise,
    it would imply that the game (client?) is smart enough to recognize when you
    went to enough mob, or it would have to randomly issue the command every so
    often to see when it will happen.

    Tim
  25. Archived from groups: rec.games.empire (More info?)

    Tim & Tracy Burnett wrote:

    > "Gemini" <spam@nospam.org> wrote in message
    > news:9cc2b$415c7bdb$d89e2d68$28798@dcanet.allthenewsgroups.com...
    >
    >>An interesting fix to that would be if you could assign movement orders -
    >>then when the unit had enough MOB, it would move to the next sector in the
    >>path - providing its able.
    >>
    >>Gemini
    >
    >
    > Order doesn't exactly work like that. Order can't attack. Also, order is
    > going to do it's thing at the update. Even with MOB_ACCESS on. Otherwise,
    > it would imply that the game (client?) is smart enough to recognize when you
    > went to enough mob, or it would have to randomly issue the command every so
    > often to see when it will happen.
    >
    > Tim
    >
    >
    No, I meant something new. A new order command on the server that would
    check on each ETU or whatever, or once a minute or however it would be
    done that says, "OK, for this unit, are there order? ok, yep, he wants
    to move 1 sector that way, now, does he have enough MOB? Oops, nope" and
    then goes on to the next unit.. On the next cycle, it repeats until the
    MIN MOB is achived, then executes the order.
  26. Archived from groups: rec.games.empire (More info?)

    In article <9cc2b$415c7bdb$d89e2d68$28798@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >Tim & Tracy Burnett wrote:
    >> Let me tell you how it really works though...
    >>
    >> Normal : OK, my cav unit will get 60 mob points at the update, let me see
    >> how far he'll be able to attack. Do some calculations. Plan an attack.
    >> Come back for the update.
    >>
    >> With MOB_ACCESS: OK, in 72 minutes, my cav will have enough mob to attack
    >> one sector. I'll check back in then and do it. Then, after that attack.
    >> OK, now the cav will have enough mob in 216 minutes. I'll set my alarm and
    >> wake up to get that one more sector. This is a tough game, and every sector
    >> counts...
    >>
    >> Of course, you could just ignore the MOB_ACCESS part and pretend that mob
    >> goes up at the updates. But if you were that kind of person, you probably
    >> wouldn't be playing empire in the first place...
    >>
    >> Tim
    >>
    >>
    >
    >An interesting fix to that would be if you could assign movement orders
    >- then when the unit had enough MOB, it would move to the next sector in
    >the path - providing its able.
    >

    Doesn't work when your next move depends on the results of the last move.

    -Geoff
  27. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:
    > In article <9cc2b$415c7bdb$d89e2d68$28798@dcanet.allthenewsgroups.com>,
    > Gemini <spam@nospam.org> wrote:
    >
    >>Tim & Tracy Burnett wrote:
    >>
    >>>Let me tell you how it really works though...
    >>>
    >>>Normal : OK, my cav unit will get 60 mob points at the update, let me see
    >>>how far he'll be able to attack. Do some calculations. Plan an attack.
    >>>Come back for the update.
    >>>
    >>>With MOB_ACCESS: OK, in 72 minutes, my cav will have enough mob to attack
    >>>one sector. I'll check back in then and do it. Then, after that attack.
    >>>OK, now the cav will have enough mob in 216 minutes. I'll set my alarm and
    >>>wake up to get that one more sector. This is a tough game, and every sector
    >>>counts...
    >>>
    >>>Of course, you could just ignore the MOB_ACCESS part and pretend that mob
    >>>goes up at the updates. But if you were that kind of person, you probably
    >>>wouldn't be playing empire in the first place...
    >>>
    >>>Tim
    >>>
    >>>
    >>
    >>An interesting fix to that would be if you could assign movement orders
    >>- then when the unit had enough MOB, it would move to the next sector in
    >>the path - providing its able.
    >>
    >
    >
    > Doesn't work when your next move depends on the results of the last move.
    >
    > -Geoff
    >
    >

    True, but sometimes you know you need to move 5 sectors in one
    direction, and can issue orders to move to that location, which will be
    issued as MOB becomes availible. Much like chess, one muct be thinking
    many moves ahead, and has his orders in mind, but you can still modify
    that strategy as the situation changes. Obviously one would check in a
    couple of times a day, or so, and modify things as needed. There would
    be stipulations, such as "halt on enemy fire" or "detection" etc. The
    idea being that, in a 1 update/day game 90% of the activity happens just
    before and just after the update. Giving orders that are executed over
    time - i.e, you can't move a unit, or supplies many sectors in an
    instant, reduces the penalty of simply not being able to be online the
    moment an update fires. It seems that makes the game less playable, that
    even though I might have a good strategy, the other guy might have a
    better script or be a faster typer and can move more units in those
    couple of minutes. It just seems a little lop-sided that an entires
    day's worth of time that an update lasts, comes down to a couple of minutes.

    Again, I hope I articulated my point.

    g
  28. Archived from groups: rec.games.empire (More info?)

    "Geoff Cashman" <theobviousgcashman@theobviousindiana.edu> wrote in message
    news:cjem0c$4ln$1@hood.uits.indiana.edu...
    > In article <8fd1f87.0409290726.b6829ad@posting.google.com>,
    > James Calivar <amheiserbush@yahoo.com.au> wrote:
    >>There should be a way to increase a sector's visibility numbers by
    >>parking a zeppelin in a sector. Of course that sector would need to
    >>have fuel and maybe bombs and guns, but it should give any sector
    >>(even an 0% wilderness) view numbers something like 157% of a fully
    >>improved sector to represent the increased distance to the horizon.
    >>Doing so would be a big improvement in realism (and isn't that the
    >>whole point?) and lower micromanagement with only a minor increase in
    >>code complexity. Just my .02 USD.
    >
    > He found it! The holy grail! A change in the code that is a minor
    > increase, improves realism, and reduces micromangement!!! OH MY GOD!!!!
    > CALL GUINESS!!!!!
    >
    > :)
    >
    > How does this *lower* micromanagement?

    Geoff:

    WTF do you have against "micromanagement"? What exactly is your bitch, when
    Empire as a game is nothing if not "micromanagement" intensive? It seems like
    every post, you go off on some addition to "micromanagement" that would somehow
    grind the mighty Empire game servers and their players to a halt. At the same
    time, you get all goo-goo over "retro Empire" - where you have to assault an
    island with individual troops (no units, recall), and at least in the last retro
    game must have posted over 200 in-game annos - talk about "micromanagement"!!

    You keep exhorting new and old players with suggestions, to submit their ideas
    in code, with the tacit expectation that noone will do so. I think this is your
    key defense mechanism. I'm guessing it's based in your expectation that nobody
    will take the time to code something up in C to add to a game that's well over
    30 years old. You're probably right. Hell, even Bungie operates a pre-compiled
    Windows server. Why should anyone go to the effort to tweak a dinosaur?

    All this said, the one game I played on any of your servers was absolutely
    frought with "micromanagement". Not because of the game - but because as deity
    you couldn't get it together enough to assure that an update would fire within
    the allotted timespace, and not elsewise. I personally got f**ked by your
    server because of updates happeneing 5 minutes after the window, or because of
    accidental updates, or updates NOT happening, and then rollbacks, and your
    complete unwillingness to post the server time in friendly terms. "Read the
    MOTD!" you would say, yet when doing so, the motd would be 48 hours old, and
    contain no information relevant to why the current update was missed or hosed.
    Can you say "maddening?" Can you say "micromanagement"???

    I'm not a seasoned Empire player, although I've participated in several "big
    guns" games. After these games, I have developed a distaste for the current
    regime, with you supposedly at the helm. As long as there are egotistical
    a**holes like you running things, I won't participate, and I'm willing to wager
    that you'll not be getting too many newbies coming in, either.

    So, congratulations, Geoff - you have earned my coveted "Jerkoff of the Year"
    award, with its accompanying Pearl Necklace insignia. I bet you will wear it
    well.

    James
  29. Archived from groups: rec.games.empire (More info?)

    "James Calivar" <amheiserbush@yahoo.com.au> writes:

    > You keep exhorting new and old players with suggestions, to submit their ideas
    > in code, with the tacit expectation that noone will do so. I think this is your
    > key defense mechanism. I'm guessing it's based in your expectation that nobody
    > will take the time to code something up in C to add to a game that's well over
    > 30 years old. You're probably right. Hell, even Bungie operates a pre-compiled
    > Windows server. Why should anyone go to the effort to tweak a dinosaur?

    My-oh-my, and I trusted these frauds did the St@r W@rs and the 2K4
    patches themselves! Must have been some industrious pet dwarves of
    theirs then. Oooooh, I let the truth slip out! Okay, time to
    confess. I keep a cave full of dwarves hacking on the code for me,
    since nobody else can be bothered, and I certainly can't. They're
    cheap; I only have to feed them a troll once in a while, which I can
    readily find on Usenet.

    Talk's cheap. Show me the code.
  30. Archived from groups: rec.games.empire (More info?)

    In article <2D37d.39$7K5.8946@news.uswest.net>,
    Scott Zielinski <scottz@websagacity.com> wrote:
    >True, but sometimes you know you need to move 5 sectors in one
    >direction, and can issue orders to move to that location, which will be
    >issued as MOB becomes availible. Much like chess, one muct be thinking
    >many moves ahead,

    Except in chess, you don't get interdicted moving P-K4. The analogy
    fails, sorry. Any number of things can happen while enroute. A sector
    along the way could be damaged, changing how much total mob it's going
    to take to get to your end point. If you know the sector's damaged,
    you might want to send an engineer in to fix it up first before having
    the unit costed so much mob to move into it. You could be interdicted.
    The unit could be needed somewhere else on changing priorities. All
    manner of things could happen.


    >and has his orders in mind, but you can still modify
    >that strategy as the situation changes. Obviously one would check in a
    >couple of times a day, or so, and modify things as needed. There would
    >be stipulations, such as "halt on enemy fire" or "detection" etc. The
    >idea being that, in a 1 update/day game 90% of the activity happens just
    >before and just after the update. Giving orders that are executed over
    >time - i.e, you can't move a unit, or supplies many sectors in an
    >instant, reduces the penalty of simply not being able to be online the
    >moment an update fires.

    There's just too many variables here. You're talking about a very
    complex command to initiate. In fact, I'd venture to guess it'd be
    twice as complex as 'order' (or even more so).


    >It seems that makes the game less playable, that
    >even though I might have a good strategy, the other guy might have a
    >better script or be a faster typer and can move more units in those
    >couple of minutes. It just seems a little lop-sided that an entires
    >day's worth of time that an update lasts, comes down to a couple of minutes.
    >
    >Again, I hope I articulated my point.
    >

    You have, but the solution is using a screwdriver as a table saw.

    The importance of updates as a problem has existed for a long time.

    Many intelligent minds have worked at solving this conundrum. It
    isn't easy. One of the Wolfpack members recently used some analysis
    tools to get a rough idea of the value of the coding effort that
    has been made on Empire. That figure exceeds $2,000,000 dollars.
    In all of that, we've yet to come up with a good solution for
    reducing the importance of updates.

    There is no simple solution. If you find it, you've found the
    holy grail of Empire.

    -Geoff
    aka Mithrilien
  31. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:
    > In article <2D37d.39$7K5.8946@news.uswest.net>,
    > Scott Zielinski <scottz@websagacity.com> wrote:
    >
    >>True, but sometimes you know you need to move 5 sectors in one
    >>direction, and can issue orders to move to that location, which will be
    >>issued as MOB becomes availible. Much like chess, one muct be thinking
    >>many moves ahead,
    >
    >
    > Except in chess, you don't get interdicted moving P-K4. The analogy
    > fails, sorry. Any number of things can happen while enroute. A sector
    > along the way could be damaged, changing how much total mob it's going
    > to take to get to your end point. If you know the sector's damaged,
    > you might want to send an engineer in to fix it up first before having
    > the unit costed so much mob to move into it. You could be interdicted.
    > The unit could be needed somewhere else on changing priorities. All
    > manner of things could happen.

    Man. This is brutal. My chess analogy was for the *strategy* not the
    actual play - so the analogy doesn't fail. All that can happen, which is
    why you have to check a couple of times a day. Units would have certain
    default settings, like, if I'm attack do I stand and fight or retreat.
    If uinexpected events happen, do I clear my orders queue, or resume when
    possible. I know its seems like infinite possiblities, but, all the
    permutations boil down just a few types of events that need reaction to.
    many war games have them that could be borrowed from. To use your
    example of a sector losing eff, there could be a server default that
    says, "if it takes more than X MOB to enter a sector, find an alt route
    to get to that sector", or "halt and cancel the rest of the orders"
    mayeb an engineer unit could be stacked that says "if a sector in my mvt
    queue is less than X% eff, try to rebuild it"

    >>and has his orders in mind, but you can still modify
    >>that strategy as the situation changes. Obviously one would check in a
    >>couple of times a day, or so, and modify things as needed. There would
    >>be stipulations, such as "halt on enemy fire" or "detection" etc. The
    >>idea being that, in a 1 update/day game 90% of the activity happens just
    >>before and just after the update. Giving orders that are executed over
    >>time - i.e, you can't move a unit, or supplies many sectors in an
    >>instant, reduces the penalty of simply not being able to be online the
    >>moment an update fires.
    >
    >
    > There's just too many variables here. You're talking about a very
    > complex command to initiate. In fact, I'd venture to guess it'd be
    > twice as complex as 'order' (or even more so).

    Not really. I guess if you have to type the command line, yes, but not
    if there are default settings. I could be as simple as "move 1 5,-2".
    The server, using its path finding, would queue that into a series of
    single sector moves, and, as MOB became availible, they would be
    executed. I for one would happily take a command that's 2x as complex to
    initiate, if it allows me have standing orders - doing away with the
    flurry during an update. Especially now that we have GUIs, that can
    simplify the command by using check boxes. There are actually only a few
    things that need to be considered that najorly affect an order. Things
    like units appearing in range, or interdiction, taking fire.

    >
    >
    >>It seems that makes the game less playable, that
    >>even though I might have a good strategy, the other guy might have a
    >>better script or be a faster typer and can move more units in those
    >>couple of minutes. It just seems a little lop-sided that an entires
    >>day's worth of time that an update lasts, comes down to a couple of minutes.
    >>
    >>Again, I hope I articulated my point.
    >>
    >
    >
    > You have, but the solution is using a screwdriver as a table saw.
    >
    > The importance of updates as a problem has existed for a long time.
    >
    > Many intelligent minds have worked at solving this conundrum. It
    > isn't easy. One of the Wolfpack members recently used some analysis
    > tools to get a rough idea of the value of the coding effort that
    > has been made on Empire. That figure exceeds $2,000,000 dollars.
    > In all of that, we've yet to come up with a good solution for
    > reducing the importance of updates.
    >
    > There is no simple solution. If you find it, you've found the
    > holy grail of Empire.
    >
    > -Geoff
    > aka Mithrilien


    I don't think its a screwdriver as a tablesaw. I have played RealTime
    Strategy (I'm *NOT* referring to games like Age of Empires or Command
    and Conquer etc) games that used orders. Yes, the downside is that you
    can't account for all the things that will happen, but, currently units
    just sit there and do nothing the entire time you're offline. I guess
    the biggest problem is that it probably is a huge coding project, since
    it is so far removed from the current scheme.

    I'm not saying its simple or easy, and I'm no coder; but these ideas are
    possible - quite possible. There really aren't that many variables when
    you look at the cause/effect aspect of what happens. Certainly the
    permutations of possible events on an individual basis might be
    staggaring, but most can all be attributed to one of just a few groups
    that need different reactions to.

    Of course, there is the possibility that the community is quite happy
    with the update structure, rendering this whole thread meaningless
    anyway. It just seems to me that updates, as they currently are, make
    the game less playable. Nothing personal, I still love the game, but its
    really aggravating sometimes to be at the mercy of an update. I dunno,
    maybe to start you could have micro-updates that run every 10 minutes,
    but are scaled down so you still get the same amount of activity in a
    day.....or something....I dunno. AM I the only one that doen't like the
    current update scheme?

    Scott
  32. Archived from groups: rec.games.empire (More info?)

    In article <d757d.6598$ls6.5043@newsread3.news.atl.earthlink.net>,
    James Calivar <amheiserbush@yahoo.com.au> wrote:
    >
    >So, congratulations, Geoff - you have earned my coveted "Jerkoff of the Year"
    >award, with its accompanying Pearl Necklace insignia. I bet you will wear it
    >well.
    >

    I'll take the time and effort to respond to your points when you can
    feel bothered to put together a post that isn't so unabashedly insulting
    without basis. I've done nothing to insult you. I'd appreciate it if you
    would show a modicum of maturity.

    I'll remain in hope that you do this. In the event that you do not,
    you might take the time to educate yourself on the dangers of
    micromanagement. You may start your education here:
    http://tinyurl.com/3lwfl

    Take note; there's 493 posts in that list. None of them are by me.

    -Geoff
    aka Mithrilien
  33. Archived from groups: rec.games.empire (More info?)

    theobviousgcashman@theobviousindiana.edu (Geoff Cashman) writes:

    > In article <2s2t9cF1gi2heU1@uni-berlin.de>,
    > Mark Stokje <mst_dont_spam_me@yahoo.com> wrote:
    >>
    >>"Markus Armbruster" <armbru@pond.sub.org> wrote in message
    >>
    >>> For every new feature, I'd like to see at least two misfeatures fixed
    >>> or taken out.
    >>
    >>Ohh, Ohh can I pick some?
    >>Lets start off with yanking out BTUs and the anti command. :-)
    >>
    >
    > ...and here's the other side of the "what do you do first" coin;
    > Esentially, anything that you do with the Empire code that is NOT
    > a bug fix has ramifications (often substantial) on the game. It
    > is quite often the case that you can not predict all the ways in
    > which a change can impact the game.
    >
    > Empire is a very complex environment, with a whole slew of properties
    > and variables interacting with each other to produce a game playing
    > environment. The dependencies within the system are oftne obscure,
    > and apparently unrelated.
    >
    > It's kinda like attempting weather control at this stage of human
    > technological development. Can we attempt it? Yep. In fact, we have.
    > But, the unintended results are too widespread and variable to imagine.
    > Bird flaps its wings in China, rain falls in Iceland. Remove BTUs in
    > Empire, and who the knows what the hell will happen.

    True, but there's a way to find out: run games with it and see what
    happens. Not nearly as risky as screwing with weather control :)

    In fact, there have been a few games with anti disabled. As far as I
    know, results were decidedly not disastrous. The last che tend to
    hang around forever, which is a continued minor source of annoyance
    and micro-management. How to get rid of them without anti and without
    security units is not obvious. So just disabling anti seems not to be
    quite sufficient.

    2K4 has no anti, except for Informants, but plenty of security units.
    We'll see how that works out.

    Some people say that che should be redone completely. Possibly true,
    but `needs to be redone' is not a useful design. So, until we know
    how to do it perfectly right, we can at least try to do it a little
    bit better.

    > I've come up with some amazing solutions to long term problems
    > that plague Empire. I've spent hours honing the solution into
    > a workable form. Then, I put it in front of another set of Empire
    > eyes and the whole thing gets shot down faster than a sparrow with
    > a .30-06 shell in it's head (or what's left of it's head).
    >
    > Scoping the impact of changes in Empire is *very* difficult.

    I'm not advocating willy-nilly experimentation. Empire is too complex
    and the number of games much too small to make that work. Most bad
    ideas can be shot down by analysis. The remaining, promising ideas
    can and should be tested in practice.
  34. Archived from groups: rec.games.empire (More info?)

    In article <87y8iqfx13.fsf@pond.sub.org>,
    Markus Armbruster <armbru@pond.sub.org> wrote:
    >
    >I'm not advocating willy-nilly experimentation. Empire is too complex
    >and the number of games much too small to make that work. Most bad
    >ideas can be shot down by analysis. The remaining, promising ideas
    >can and should be tested in practice.
    >

    Agreed, with the caveat that we shouldn't be using every game
    to test new features. The baseline code being played is a useful
    control group on which to compare results.

    -Geoff
    aka Mithrilien
    Winner of the 2004 Jerkoff of the Year with Pearl Necklace insignia
  35. Archived from groups: rec.games.empire (More info?)

    "Geoff Cashman" <theobviousgcashman@theobviousindiana.edu> wrote in message
    news:cjjnp4$u1c$3@hood.uits.indiana.edu...
    > In article <87y8iqfx13.fsf@pond.sub.org>,
    > Markus Armbruster <armbru@pond.sub.org> wrote:
    > >
    > >I'm not advocating willy-nilly experimentation. Empire is too complex
    > >and the number of games much too small to make that work. Most bad
    > >ideas can be shot down by analysis. The remaining, promising ideas
    > >can and should be tested in practice.
    > >
    >
    > Agreed, with the caveat that we shouldn't be using every game
    > to test new features. The baseline code being played is a useful
    > control group on which to compare results.
    >
    > -Geoff
    > aka Mithrilien
    > Winner of the 2004 Jerkoff of the Year with Pearl Necklace insignia
    >
    Bah! Variety is the spice of life.

    Mark
    Who has not yet played in a "stock" game.
  36. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman <theobviousgcashman@theobviousindiana.edu> wrote:
    > -Geoff
    > aka Mithrilien
    > Winner of the 2004 Jerkoff of the Year with Pearl Necklace insignia

    Darn, I'm jealous... What do I have to do to win it next year ?

    Zlo
  37. Archived from groups: rec.games.empire (More info?)

    In article <2s57d9F1gran2U1@uni-berlin.de>,
    Mark Stokje <mst_dont_spam_me@yahoo.com> wrote:
    >
    >"Geoff Cashman" <theobviousgcashman@theobviousindiana.edu> wrote in message
    >news:cjjnp4$u1c$3@hood.uits.indiana.edu...
    >> In article <87y8iqfx13.fsf@pond.sub.org>,
    >> Markus Armbruster <armbru@pond.sub.org> wrote:
    >> >
    >> >I'm not advocating willy-nilly experimentation. Empire is too complex
    >> >and the number of games much too small to make that work. Most bad
    >> >ideas can be shot down by analysis. The remaining, promising ideas
    >> >can and should be tested in practice.
    >> >
    >>
    >> Agreed, with the caveat that we shouldn't be using every game
    >> to test new features. The baseline code being played is a useful
    >> control group on which to compare results.
    >>
    >> -Geoff
    >> aka Mithrilien
    >> Winner of the 2004 Jerkoff of the Year with Pearl Necklace insignia
    >>
    >Bah! Variety is the spice of life.
    >
    >Mark
    >Who has not yet played in a "stock" game.
    >

    Bit of a redefinition...

    Retro was a 'stock' game, in so far as it did not introduce any new
    features that have not been played before. The LOTR series is similar,
    though that argument may seem a bit stressed.

    The different environments that deities can construct using existing
    code are all variants of the base code. When deities begin to change
    the code to create custom environments, ala Star Wars and TW-2K4, then
    we're getting a non-stock environment.

    -Goeff
  38. Archived from groups: rec.games.empire (More info?)

    In article <cjjp7q$k5n$1@news.tue.nl>,
    Marc Olzheim <zl{}@rec.games.empire.experimental.net> wrote:
    >Geoff Cashman <theobviousgcashman@theobviousindiana.edu> wrote:
    >> -Geoff
    >> aka Mithrilien
    >> Winner of the 2004 Jerkoff of the Year with Pearl Necklace insignia
    >
    >Darn, I'm jealous... What do I have to do to win it next year ?
    >

    I'm not sure what the criteria is. I think I won it because I tried
    to do my best in my various roles in Empire, and managed to piss
    off the judge in the process through some opaque transfer mechanism.

    -Geoff
    aka Mithrilien

    PS: This pearl necklage really clashes with my zebra print strapless
    number. Can I trade it in?
  39. Archived from groups: rec.games.empire (More info?)

    "Scott Zielinski" <scottz@websagacity.com> wrote in message news:2D37d.39$
    >
    > Again, I hope I articulated my point.
    >
    > g

    You did a fine job of articulating! The problem is, you are proposing
    things that far out strip what the game currently is. The concept of giving
    the game a set of commands that will run at later times, when you aren't
    there, is amazing. Your idea for how to use it in this one example is
    great. The problem is, we're all empire players. If this feature could
    somehow be implemented, we would immediately go about using it to our
    maximum advantage. In ways that the original implementer (you) probably
    didn't think about. Then, you end up changing the way the whole game works,
    when all you wanted to do was make one small change.

    The thing that comes to mind from your idea to me is this...In LOTR II, Mark
    Stojke and I had a fierce war going on for quite a while. The key to
    controlling the front was the placement/usage of artillery. I would try to
    use scripts to pound his border sectors immediately before, and after the
    update to badly damage anything he moved up there, then to kill the sector's
    mob after. If I had the ability to, through the game itself, have a firing
    run happen at times I specified, but didn't have to be logged on for, I
    would have done it. I knew he was playing from work during the day, and he
    could check in some, but not truly devote hours to playing. So, I would
    have told the game to do something, firing, maybe a fly over, at random
    times throughout the day, just to drive him crazy. And this is just what I
    (a decent, but certainly not great player) thought of in a short period of
    time. I'm sure that other players would come up with things that completely
    unbalance the way the game is played. This might not be a bad thing. The
    game may turn out better because of it, but it would almost be a "starting
    over" or sorts for large portions of game play...

    Tim
  40. Archived from groups: rec.games.empire (More info?)

    "Tim Burnett" <tburnett2@cinci.rr.com> wrote in message
    news:gme7d.165290$787.95263@fe2.columbus.rr.com...
    >
    > "Scott Zielinski" <scottz@websagacity.com> wrote in message news:2D37d.39$
    > >
    > > Again, I hope I articulated my point.
    > >
    > > g
    >
    > You did a fine job of articulating! The problem is, you are proposing
    > things that far out strip what the game currently is. The concept of
    giving
    > the game a set of commands that will run at later times, when you aren't
    > there, is amazing. Your idea for how to use it in this one example is
    > great. The problem is, we're all empire players. If this feature could
    > somehow be implemented, we would immediately go about using it to our
    > maximum advantage. In ways that the original implementer (you) probably
    > didn't think about. Then, you end up changing the way the whole game
    works,
    > when all you wanted to do was make one small change.
    >
    > The thing that comes to mind from your idea to me is this...In LOTR II,
    Mark
    > Stojke and I had a fierce war going on for quite a while. The key to
    > controlling the front was the placement/usage of artillery. I would try
    to
    > use scripts to pound his border sectors immediately before, and after the
    > update to badly damage anything he moved up there, then to kill the
    sector's
    > mob after. If I had the ability to, through the game itself, have a
    firing
    > run happen at times I specified, but didn't have to be logged on for, I
    > would have done it. I knew he was playing from work during the day, and
    he
    > could check in some, but not truly devote hours to playing. So, I would
    > have told the game to do something, firing, maybe a fly over, at random
    > times throughout the day, just to drive him crazy. And this is just what
    I
    > (a decent, but certainly not great player) thought of in a short period of
    > time. I'm sure that other players would come up with things that
    completely
    > unbalance the way the game is played. This might not be a bad thing. The
    > game may turn out better because of it, but it would almost be a "starting
    > over" or sorts for large portions of game play...
    >
    > Tim

    Likewise, I'd be looking from my swimming sabatour in 15 second increments
    for a new bridge to blow up. Other things that come to mind are along the
    same idea as you. 20 probes every hour just to keep you running back to your
    computer :-) (Because dang it, it seemed like you were on or around that
    thing 24/7)

    Mark
  41. Archived from groups: rec.games.empire (More info?)

    Tim Burnett wrote:

    > "Scott Zielinski" <scottz@websagacity.com> wrote in message news:2D37d.39$
    >
    >>Again, I hope I articulated my point.
    >>
    >>g
    >
    >
    > You did a fine job of articulating! The problem is, you are proposing
    > things that far out strip what the game currently is. The concept of giving
    > the game a set of commands that will run at later times, when you aren't
    > there, is amazing. Your idea for how to use it in this one example is
    > great. The problem is, we're all empire players. If this feature could
    > somehow be implemented, we would immediately go about using it to our
    > maximum advantage. In ways that the original implementer (you) probably
    > didn't think about. Then, you end up changing the way the whole game works,
    > when all you wanted to do was make one small change.

    yeah, all true. I guess such is life....no one can think of everything.
    Once its implemented, the failures rise to the surface, like fat
    rendering....

    > The thing that comes to mind from your idea to me is this...In LOTR II, Mark
    > Stojke and I had a fierce war going on for quite a while. The key to
    > controlling the front was the placement/usage of artillery. I would try to
    > use scripts to pound his border sectors immediately before, and after the
    > update to badly damage anything he moved up there, then to kill the sector's
    > mob after. If I had the ability to, through the game itself, have a firing
    > run happen at times I specified, but didn't have to be logged on for, I
    > would have done it. I knew he was playing from work during the day, and he
    > could check in some, but not truly devote hours to playing. So, I would
    > have told the game to do something, firing, maybe a fly over, at random
    > times throughout the day, just to drive him crazy. And this is just what I
    > (a decent, but certainly not great player) thought of in a short period of
    > time. I'm sure that other players would come up with things that completely
    > unbalance the way the game is played. This might not be a bad thing. The
    > game may turn out better because of it, but it would almost be a "starting
    > over" or sorts for large portions of game play...
    >
    > Tim

    I know many ppl dont like it when you compare Empire to real life, but,
    that's often what militaries did. They called it harrassment. This was
    especially effective when several small skirmishes occured over a large
    area; which caused the lines to get spread out thin, since they didn't
    know where the enemy was, and they didn't know if each engagement was
    the "real" one. The situation you described above is a great example of
    how strategy is done. Sometimes you don't have to beat the enemy's
    entire army, just the heart of its leadership. While the tactics above
    had no real effect in game, they may cause the opponent adjust his
    strategy to a flawed one - and that is just as important as destroying
    his units. So I don't see that as being abusive of the rules.
  42. Archived from groups: rec.games.empire (More info?)

    Mark Stokje wrote:

    > "Tim Burnett" <tburnett2@cinci.rr.com> wrote in message
    > news:gme7d.165290$787.95263@fe2.columbus.rr.com...
    >
    >>"Scott Zielinski" <scottz@websagacity.com> wrote in message news:2D37d.39$
    >>
    >>>Again, I hope I articulated my point.
    >>>
    >>>g
    >>
    >>You did a fine job of articulating! The problem is, you are proposing
    >>things that far out strip what the game currently is. The concept of
    >
    > giving
    >
    >>the game a set of commands that will run at later times, when you aren't
    >>there, is amazing. Your idea for how to use it in this one example is
    >>great. The problem is, we're all empire players. If this feature could
    >>somehow be implemented, we would immediately go about using it to our
    >>maximum advantage. In ways that the original implementer (you) probably
    >>didn't think about. Then, you end up changing the way the whole game
    >
    > works,
    >
    >>when all you wanted to do was make one small change.
    >>
    >>The thing that comes to mind from your idea to me is this...In LOTR II,
    >
    > Mark
    >
    >>Stojke and I had a fierce war going on for quite a while. The key to
    >>controlling the front was the placement/usage of artillery. I would try
    >
    > to
    >
    >>use scripts to pound his border sectors immediately before, and after the
    >>update to badly damage anything he moved up there, then to kill the
    >
    > sector's
    >
    >>mob after. If I had the ability to, through the game itself, have a
    >
    > firing
    >
    >>run happen at times I specified, but didn't have to be logged on for, I
    >>would have done it. I knew he was playing from work during the day, and
    >
    > he
    >
    >>could check in some, but not truly devote hours to playing. So, I would
    >>have told the game to do something, firing, maybe a fly over, at random
    >>times throughout the day, just to drive him crazy. And this is just what
    >
    > I
    >
    >>(a decent, but certainly not great player) thought of in a short period of
    >>time. I'm sure that other players would come up with things that
    >
    > completely
    >
    >>unbalance the way the game is played. This might not be a bad thing. The
    >>game may turn out better because of it, but it would almost be a "starting
    >>over" or sorts for large portions of game play...
    >>
    >>Tim
    >
    >
    > Likewise, I'd be looking from my swimming sabatour in 15 second increments
    > for a new bridge to blow up. Other things that come to mind are along the
    > same idea as you. 20 probes every hour just to keep you running back to your
    > computer :-) (Because dang it, it seemed like you were on or around that
    > thing 24/7)
    >
    > Mark
    >

    You wouldn't be able to do 20 probes an hour, or blow a bridge in 15
    second increments; everything costs MOB, and MOB is accrued slowly over
    time; you still would only have access to the same amount of MOB in a
    day as any other game - and the movement isn't instant, which is the
    whole point of having the real time system. You might only be able to
    move a unit 1 sector an hour, and if it did a probe, might take several
    hours to regain it. Unless you dedicated a lot of units to allow you to
    constantly probe - it would take a lot, and it would only be for a small
    area. So to probe all over the place would take an enormous amount of units.
  43. Archived from groups: rec.games.empire (More info?)

    In article <c1ea2$415d7f63$d89e2d68$2396@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >
    >I know many ppl dont like it when you compare Empire to real life, but,
    >[...good stuff...]
    >

    Personally, I think realism in Empire is fantastic. I think it's
    important for conceptualization purposes for the players. I do
    think we need to stick to the rule of thumb though that when
    realism and playability come into conflict, playability must win.

    -Geoff
    aka Mithrilien
    Winner of the 2004 Jerkoff of the Year award with Pearl String insignia
  44. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:

    > In article <c1ea2$415d7f63$d89e2d68$2396@dcanet.allthenewsgroups.com>,
    > Gemini <spam@nospam.org> wrote:
    >
    >>I know many ppl dont like it when you compare Empire to real life, but,
    >>[...good stuff...]
    >>
    >
    >
    > Personally, I think realism in Empire is fantastic. I think it's
    > important for conceptualization purposes for the players. I do
    > think we need to stick to the rule of thumb though that when
    > realism and playability come into conflict, playability must win.
    >
    > -Geoff
    > aka Mithrilien
    > Winner of the 2004 Jerkoff of the Year award with Pearl String insignia

    I agree...I mean with the playability must win when reality conflicts....

    However, you neglected to mention how micromanagement is affected by the
    realism/playability dichotomy.
  45. Archived from groups: rec.games.empire (More info?)

    In article <37405$415d7c31$d89e2d68$2297@dcanet.allthenewsgroups.com>,
    Gemini <spam@nospam.org> wrote:
    >
    >Man. This is brutal. My chess analogy was for the *strategy* not the
    >actual play - so the analogy doesn't fail. All that can happen, which is
    >why you have to check a couple of times a day. Units would have certain
    >default settings, like, if I'm attack do I stand and fight or retreat.
    >If uinexpected events happen, do I clear my orders queue, or resume when
    >possible.

    The problem here isn't just a single state scenario. Whether or
    not that unit progresses could be entirely dependent on whether
    a supply unit that's coming down a different path, and carrying
    the shells that unit needs to be effective when it reaches there,
    can get there too. There's multiple interdependent criteria that
    could evolve with an automatic progress of a unit as you suggest.

    I'm not saying this is all impossible. I'm just saying it's difficult,
    and likely to be a very unintuitive command for players to issue.


    >I know its seems like infinite possiblities, but, all the
    >permutations boil down just a few types of events that need reaction to.
    >many war games have them that could be borrowed from. To use your
    >example of a sector losing eff, there could be a server default that
    >says, "if it takes more than X MOB to enter a sector, find an alt route
    >to get to that sector", or "halt and cancel the rest of the orders"
    >mayeb an engineer unit could be stacked that says "if a sector in my mvt
    >queue is less than X% eff, try to rebuild it"

    Great!

    Test: Show me an example command structure to make this happen.


    >> There's just too many variables here. You're talking about a very
    >> complex command to initiate. In fact, I'd venture to guess it'd be
    >> twice as complex as 'order' (or even more so).
    >
    >Not really.

    Ok. Show an example command syntax.


    > I guess if you have to type the command line, yes, but not
    >if there are default settings. I could be as simple as "move 1 5,-2".
    >The server, using its path finding, would queue that into a series of
    >single sector moves, and, as MOB became availible, they would be
    >executed. I for one would happily take a command that's 2x as complex to
    >initiate, if it allows me have standing orders - doing away with the
    >flurry during an update. Especially now that we have GUIs, that can
    >simplify the command by using check boxes. There are actually only a few
    >things that need to be considered that najorly affect an order. Things
    >like units appearing in range, or interdiction, taking fire.

    I'll await your sample command structure before commenting further.


    >I don't think its a screwdriver as a tablesaw. I have played RealTime
    >Strategy (I'm *NOT* referring to games like Age of Empires or Command
    >and Conquer etc) games that used orders. Yes, the downside is that you
    >can't account for all the things that will happen, but, currently units
    >just sit there and do nothing the entire time you're offline. I guess
    >the biggest problem is that it probably is a huge coding project, since
    >it is so far removed from the current scheme.

    I'd have to agree with that :)


    >Of course, there is the possibility that the community is quite happy
    >with the update structure, rendering this whole thread meaningless
    >anyway.

    I don't think we are happy with it.


    >It just seems to me that updates, as they currently are, make
    >the game less playable. Nothing personal, I still love the game, but its
    >really aggravating sometimes to be at the mercy of an update. I dunno,
    >maybe to start you could have micro-updates that run every 10 minutes,
    >but are scaled down so you still get the same amount of activity in a
    >day.....or something....I dunno. AM I the only one that doen't like the
    >current update scheme?

    No. I think there's only a small minority that enjoys the current
    update scheme and thinks it does not need adjustment.

    Micro-updates will virtually guarantee massive amounts of micromanagement.
    (trying desperately here to hang on to my 2004 Jerkoff of the Year award.
    Hope I'm succeeding!)

    -Geoff
    aka Mithrilien
  46. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman wrote:

    <snip>


    > Great!
    >
    > Test: Show me an example command structure to make this happen.
    > Ok. Show an example command syntax.
    >
    > I'll await your sample command structure before commenting further.

    Well, I'm an idea guy, not an implemention guy. I ramble off ideas in
    hopes that an implementor type will hear my ideas and find a way to
    implement them. But here's kinda what's swimming in my head:
    Lets use current Empire conditions, found from retreat, I only see one
    for navy, so I will make some assumptions about lands....and I will add
    some...

    I = Injured
    B = Bombed
    H = Helpless
    E = Enemy Detected
    S = Shelled

    Not sure if there are others that apply to lands, but you get the idea

    Then there would be the actions category.

    D = Defend (attack, but don't persue)
    A = Attack and persue
    R = Retreat
    H = Halt
    F = Fortify
    N = No Change

    I'm sure this list isn't completely exhaustive, but gives a good idea,
    anyway, each condition would already have a default action - i.e

    I = D
    B = F
    H = R
    E = A
    S = F

    There cuold also be after effect orders, which would only be 2

    X = Clear queue
    O = Continues with orders (movement or whatever)

    Lets say the default is O

    Or whatever seems to be the most common orders. So, if I want my unit to
    have a different standing order from the default, I issue the following
    command (lets call it sorders for Standing Orders)

    sorders <UNIT> <cond> <action> <after>....

    Issuing the command w/o cond action would show standing orders for the
    unit(s)


    i.e.

    sorders 1 B N O<--Modify default orders for when hes bombed
    march 1 3,4 maybe the command could be "queue march 1 3,4" - that might
    make it easier to add to the current code....i dunno, this is all theory
    right now.

    Lets say 3,4 is 5 sects away, then, the orders queue would have that
    march command in its list- on the next ETU iteration, MOB is checked to
    see if the unit can go to the next sector in the path, using the
    *current* best path calculation.

    Now, lets say he moves 2 sects, and gets bombed by a plane - if it was
    the default, then the unit would the use MOB to fortify itsself, and
    then queue would be cleared - however, I issed a N action, which means
    this particular unit will continue to its destination. Now, if on the
    next iteration, he is attacked, this unit will then be issued an attack
    command on that unit...since the default action for (I)njured is to
    (D)efend. Essentially what would happen, is the attack command would be
    placed in the queue above the current movement order - that way, when he
    has enough MOB, he will then issue an attack. Maybe when he was
    initially attacked, he was low on MOB, and the attacking unit left visib
    range, the server would "know" that there was an attack command in the
    queue, but that unit isn't there, so the commmand would be dropped, and
    the next command in the list would be executed, which is our MARCH
    command. If he causes the attacking unit to retreat, he will then
    continue on his march order where he left off. If he was given the
    persue order, then if the enemy retreated, he would attempt to follow.

    This whole process was able to take place by simply with pretty much a
    march command, and an sorders command, which was optional. Once the
    march order matches the destination, the command is then removed from
    the queue.

    I know this is quite a simplified example, but, I think you should get
    the gist - its also off the cuff, I wrote it as it popped into my head,
    so, I may have missed a few things here and there. I'm sure I didn't get
    every reaction to an event down, but, the ones I gave should constitute
    the majority of situatuions, with just a few needed to be added. There
    will always be room for tweaking. I wish I know C or I would work on it
    myself, but, alas I am a lowly VB guy. :-(

    Anyway, I hope that was what you were looking for.

    Scott


    <snip>
  47. Archived from groups: rec.games.empire (More info?)

    >I'd rather have an air radar satellite type, which is a balloon-carried
    >radar. It can also be deorbited and relaunched at player's leisure time.

    >But still we need an aircraft detection radar first.

    Another idea, since Israel proved the effectiveness of the security fence, is
    to make forts so strong defensively that they are a kind of "wall" or security
    fence that basically cause a stalemate on the front where you build them.

    This is assuming fort-fire is off.

    So building a long wall becomes a kind of master weapon for a phase of the
    game, until artillery comes along which is powerful enough to knock it down.
  48. Archived from groups: rec.games.empire (More info?)

    Geoff Cashman <theobviousgcashman@theobviousindiana.edu> wrote:

    > Take note; there's 493 posts in that list. None of them are by me.

    That's unfair. You're using X-No-Archive ;)
    So you aren't on any list produced by google. :)

    > -Geoff
    > aka Mithrilien


    --
    Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
    Email: romm@empire.tau.ac.il http://www.nasa.proj.ac.il/
    Phone/Fax: +972-(0)3-6405205 (work), +972-(0)50-734-18-34 (home)
    ----------------------------------------------------------------------
    The economy depends about as much on economists as the weather does on
    weather forecasters.
    -- Jean-Paul Kauffmann
  49. Archived from groups: rec.games.empire (More info?)

    Akorps666 <akorps666@aol.com666> wrote:
    > >I'd rather have an air radar satellite type, which is a balloon-carried
    > >radar. It can also be deorbited and relaunched at player's leisure time.

    > >But still we need an aircraft detection radar first.

    > Another idea, since Israel proved the effectiveness of the security fence, is
    > to make forts so strong defensively that they are a kind of "wall" or security
    > fence that basically cause a stalemate on the front where you build them.

    I'd rather call wall another sector infrastructure.
    If you make a wall around the sector, the che in it do not move out,
    the che outside do not move in.

    --
    Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
    Email: romm@empire.tau.ac.il http://www.nasa.proj.ac.il/
    Phone/Fax: +972-(0)3-6405205 (work), +972-(0)50-734-18-34 (home)
    ----------------------------------------------------------------------
    The economy depends about as much on economists as the weather does on
    weather forecasters.
    -- Jean-Paul Kauffmann
Ask a new question

Read More

Games Video Games