Supply Question for 3.4 (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III >> Scenario Design



Message


ralphtricky -> Supply Question for 3.4 (11/7/2008 7:56:03 PM)

Here's a question. How much would allowing an event to set the supply percent through a hex to be set from 0 to 1000% help with scenario design?

That is, with the current build, editing the supply hexes is done by saveing as XML, editing the XML, and reloading the XML.

Another way to do this would be to add events into the editor to allow the designer to set the percent of the sides supply that goes through each of the supply hexes.

Adding in an event is a bit convoluted because of the number of places it needs to be added, but this is a fairly simple event that's easily testable.

What do people think? Is it worth the effort? I think it might open up a couple of new scenarios, and I'm sure that the purists like the idea since you'd be able to model better things like beach landings and pockets, I'm sure. But I'm not sure how much of that is chrome and how much is actually helpful in scenario design.

Ralph




jmlima -> RE: Supply Question for 3.4 (11/7/2008 10:02:23 PM)


quote:

ORIGINAL: ralphtrick
...

That is, with the current build, editing the supply hexes is done by saveing as XML, editing the XML, and reloading the XML.
...


Not sure I'm following, do you mean just the supply sources hexes , or -every- single hex?

In light of the previous discussions, if we are discussing making the supply source hexes variable, and editable, by event, I'm all up for it. These could even allow to simulate a port increasing capabilities with time, or the opposite. My view, it's not chrome.

Even though I still believe it needs to be done also something regarding a maximum distance to avoid ridiculously infinite supply lines.




Telumar -> RE: Supply Question for 3.4 (11/9/2008 12:24:48 PM)

Definitely worth it!




Curtis Lemay -> RE: Supply Question for 3.4 (11/9/2008 4:40:10 PM)


quote:

ORIGINAL: jmlima


quote:

ORIGINAL: ralphtrick
...

That is, with the current build, editing the supply hexes is done by saveing as XML, editing the XML, and reloading the XML.
...


Not sure I'm following, do you mean just the supply sources hexes , or -every- single hex?

In light of the previous discussions, if we are discussing making the supply source hexes variable, and editable, by event, I'm all up for it. These could even allow to simulate a port increasing capabilities with time, or the opposite. My view, it's not chrome.

Even though I still believe it needs to be done also something regarding a maximum distance to avoid ridiculously infinite supply lines.


Let me translate it from Ralph-speak. He means that any given supply point can be edited to some percentage of the force supply level other than the current 100%. So if the force supply level is, say, 35 and a supply point has been set to, say, 43%, then it would function as if it had 15 force supply. It's similar to the work-around we have now of placing the supply point in a distance hex, but without the need for the distance hex (and its drawbacks).

It's working now, with a few quibbles. As of yet, the editing can only be done in an XML editor. No event effect to change it dynamically during the game has yet been done.




ColinWright -> RE: Supply Question for 3.4 (11/9/2008 8:21:53 PM)

More options are always good options, but I don't see this as addressing the issues that most concern me.

Moreover, if I understand what he is proposing aright, I already have workarounds to get muc of the effect described.

It won't matter whether one division or ten divisions is drawing supply from the given point -- and that's the essence of the problem.




golden delicious -> RE: Supply Question for 3.4 (11/10/2008 8:33:55 PM)

The real programming challenge is not in getting the programme to generate variable levels of supply at the source- but to get it to recognise that 1/4 of 50 is better than 1/2 of 20 when it comes to supply at the destination.

A good step if it can be done- but still not easy.




ColinWright -> RE: Supply Question for 3.4 (11/11/2008 12:33:00 AM)


quote:

ORIGINAL: golden delicious

The real programming challenge is not in getting the programme to generate variable levels of supply at the source- but to get it to recognise that 1/4 of 50 is better than 1/2 of 20 when it comes to supply at the destination.

A good step if it can be done- but still not easy.


Well, if we can get some quantified volume of supply available in a given hex, then we can set a 'supply priority' for each unit in the same way we choose a losses setting. That can control how the supply is distributed.

The main point is to get away from that 'percentage of supply.' It's a virtually nonsensical concept. The implication is that it's irrelevant how many troops there are using the supply.





ralphtricky -> RE: Supply Question for 3.4 (11/16/2008 4:38:32 AM)

quote:

ORIGINAL: golden delicious

The real programming challenge is not in getting the programme to generate variable levels of supply at the source- but to get it to recognise that 1/4 of 50 is better than 1/2 of 20 when it comes to supply at the destination.

A good step if it can be done- but still not easy.

I don't think it will be that bad, but it's only going to be available for the new supply method. It's next on my list. The hardes part is that I'm using integers, so I'm going to have to be careful not to have the integers overflow or underflow.

I'm keeping an array with the nearest supply point for each location, so I can either do the lookup each time, or keep another array with the supply provided by that point. I'll need to look at the code and see which way is going to be easier.

A* works by my adding all the supply units into a list, and then the adjacent hexes, each time it's taking the closest uninvestigated hex and investigaint it and it's neighbors. That means with the proper weights, it shouldn't be too difficult.

Doing discrete supply can possibly use a similar algorithm, it might do something like generate an array of needs and an array of supply, then play with it to get the proper distribution. Another simpler option would be to grab a random unit weighted towards those with the greatest need and tracing to the nearest supply point, lather, rinse, repeat. I haven't given it a lot of thought. It needs to make sure that no units starve. I know that Norm wrote something for air supply, I need to see how he did that.

I also want to make sure that the interface is kept simple enough that beginners and Elmer have a chance to do a reasonable job with most scenarios while giving an advantage to people that know the system. That balance is going to be very tough

Ralph





ColinWright -> RE: Supply Question for 3.4 (11/16/2008 8:03:23 PM)

quote:

ORIGINAL: ralphtrick

quote:

ORIGINAL: golden delicious

The real programming challenge is not in getting the programme to generate variable levels of supply at the source- but to get it to recognise that 1/4 of 50 is better than 1/2 of 20 when it comes to supply at the destination.

A good step if it can be done- but still not easy.

I don't think it will be that bad, but it's only going to be available for the new supply method. It's next on my list. The hardes part is that I'm using integers, so I'm going to have to be careful not to have the integers overflow or underflow.

I'm keeping an array with the nearest supply point for each location, so I can either do the lookup each time, or keep another array with the supply provided by that point. I'll need to look at the code and see which way is going to be easier.

A* works by my adding all the supply units into a list, and then the adjacent hexes, each time it's taking the closest uninvestigated hex and investigaint it and it's neighbors. That means with the proper weights, it shouldn't be too difficult.

Doing discrete supply can possibly use a similar algorithm, it might do something like generate an array of needs and an array of supply, then play with it to get the proper distribution. Another simpler option would be to grab a random unit weighted towards those with the greatest need and tracing to the nearest supply point, lather, rinse, repeat. I haven't given it a lot of thought. It needs to make sure that no units starve. I know that Norm wrote something for air supply, I need to see how he did that.

I also want to make sure that the interface is kept simple enough that beginners and Elmer have a chance to do a reasonable job with most scenarios while giving an advantage to people that know the system. That balance is going to be very tough

Ralph



Couldn't the current system just be kept -- with what you are talking about as an add-on at the scenario designer's discretion? That would deal with the difficulties you mention. In principle, it might even be possible to have the P.O. use one algorithm for supply, and the human player another.

What you are talking about sounds great. Obviously, what the end result looks like has yet to be seen -- but it's good to see movement on this issue.

As to air supply, you may find the following observations useful. Whatever Norm did, it works -- sort of. Only airborne-capable units can receive it. Perhaps most pertinently, the unit is still listed as 'unsupplied' -- but each turn such supply is available, its supply level has jumped.




ralphtricky -> RE: Supply Question for 3.4 (11/16/2008 9:44:37 PM)

quote:

ORIGINAL: ColinWright
Couldn't the current system just be kept -- with what you are talking about as an add-on at the scenario designer's discretion? That would deal with the difficulties you mention. In principle, it might even be possible to have the P.O. use one algorithm for supply, and the human player another.

What you are talking about sounds great. Obviously, what the end result looks like has yet to be seen -- but it's good to see movement on this issue.

As to air supply, you may find the following observations useful. Whatever Norm did, it works -- sort of. Only airborne-capable units can receive it. Perhaps most pertinently, the unit is still listed as 'unsupplied' -- but each turn such supply is available, its supply level has jumped.


I'm doing my best to keep compatibililty by adding switches. For one thing, I think that people have PBEM games that have been going on for years, and it would be nice if they could upgrade without restarting! Right now, the old supply rules still work. Once I look at discrete supply, I'll see what can be done. I don't want to turn TOAW into some uber complciated supply simulation, so everything needs to be able to work under the hood for the people that want it. The AI will probably 'cheat' if necessary by getting additional supplies at certain levels, that should help even out the human's strategic grasp.

I know that internally the air supplu has a definite system of requesting supplies and providing them. It doesn't ahve the complications of distance or supply sources, but it may have something useful.

Ralph




ColinWright -> RE: Supply Question for 3.4 (11/16/2008 10:42:23 PM)


quote:


I know that internally the air supplu has a definite system of requesting supplies and providing them. It doesn't ahve the complications of distance or supply sources, but it may have something useful.





Maybe you need to talk to Luigi about snatching Norm off the sidewalk sometime, taking him into a secluded basement somewhere, and 'helping' him to answer your questions.

It could save a lot of time.




ralphtricky -> RE: Supply Question for 3.4 (11/17/2008 2:44:17 AM)

quote:

ORIGINAL: ColinWright
Maybe you need to talk to Luigi about snatching Norm off the sidewalk sometime, taking him into a secluded basement somewhere, and 'helping' him to answer your questions.

It could save a lot of time.

It might... Actually, Norm wrote remarkably readable code. The problem is that he started writing this code in the DOS days, there are references to GEM, and coding standards have changed so much that it's like reading Latin at times.

Ralph




cesteman -> RE: Supply Question for 3.4 (11/17/2008 8:43:35 PM)

LOL it might only take a few minutes to solve some small issues that would go in the next update.
quote:

ORIGINAL: ColinWright








Maybe you need to talk to Luigi about snatching Norm off the sidewalk sometime, taking him into a secluded basement somewhere, and 'helping' him to answer your questions.

It could save a lot of time.






noxious -> RE: Supply Question for 3.4 (11/18/2008 6:37:55 PM)

quote:

It might... Actually, Norm wrote remarkably readable code. The problem is that he started writing this code in the DOS days, there are references to GEM, and coding standards have changed so much that it's like reading Latin at times.


I feel your pain. Deeply :)




Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.65625