Sign in with
Sign up | Sign in
Your question

Improving a sector's visibility

Last response: in Video Games
Share
Anonymous
September 29, 2004 12:26:08 PM

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
Anonymous
September 29, 2004 5:06:09 PM

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?
Anonymous
September 29, 2004 5:19:26 PM

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.
Related resources
Anonymous
September 29, 2004 7:57:00 PM

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
Anonymous
September 29, 2004 11:24:01 PM

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
Anonymous
September 29, 2004 11:24:02 PM

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.
Anonymous
September 30, 2004 1:35:49 AM

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
Anonymous
September 30, 2004 2:32:20 AM

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
Anonymous
September 30, 2004 6:36:11 AM

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
Anonymous
September 30, 2004 12:15:25 PM

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.
Anonymous
September 30, 2004 5:10:28 PM

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
Anonymous
September 30, 2004 6:54:05 PM

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
Anonymous
September 30, 2004 6:54:06 PM

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
Anonymous
September 30, 2004 6:57:32 PM

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
Anonymous
September 30, 2004 9:07:54 PM

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
Anonymous
September 30, 2004 10:00:16 PM

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
Anonymous
September 30, 2004 11:41:36 PM

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.
Anonymous
September 30, 2004 11:41:37 PM

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!
Anonymous
September 30, 2004 11:41:38 PM

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
Anonymous
September 30, 2004 11:41:39 PM

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][
Anonymous
September 30, 2004 11:41:40 PM

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
Anonymous
October 1, 2004 12:12:40 AM

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
Anonymous
October 1, 2004 1:21:20 AM

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
Anonymous
October 1, 2004 1:21:21 AM

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
Anonymous
October 1, 2004 2:03:01 AM

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
Anonymous
October 1, 2004 2:03:02 AM

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.
Anonymous
October 1, 2004 2:49:00 AM

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
Anonymous
October 1, 2004 2:51:02 AM

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
Anonymous
October 1, 2004 8:34:17 AM

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
Anonymous
October 1, 2004 12:20:52 PM

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.
Anonymous
October 1, 2004 5:44:17 PM

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
Anonymous
October 1, 2004 5:44:18 PM

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
Anonymous
October 1, 2004 5:52:21 PM

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
Anonymous
October 1, 2004 6:22:32 PM

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.
Anonymous
October 1, 2004 6:22:33 PM

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
Anonymous
October 1, 2004 6:22:34 PM

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.
Anonymous
October 1, 2004 6:22:50 PM

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
Anonymous
October 1, 2004 6:51:42 PM

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
Anonymous
October 1, 2004 6:53:32 PM

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?
Anonymous
October 1, 2004 7:04:44 PM

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
Anonymous
October 1, 2004 7:04:45 PM

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
Anonymous
October 1, 2004 7:04:45 PM

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.
Anonymous
October 1, 2004 7:04:46 PM

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.
Anonymous
October 1, 2004 10:12:38 PM

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
Anonymous
October 1, 2004 10:12:39 PM

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.
Anonymous
October 1, 2004 10:18:34 PM

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
Anonymous
October 1, 2004 10:18:35 PM

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>
Anonymous
October 4, 2004 2:02:27 PM

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.
Anonymous
October 10, 2004 3:23:47 PM

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
Anonymous
October 10, 2004 3:29:57 PM

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
!