1914 development

classic Classic list List threaded Threaded
66 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

1914 development

frogg
I've been looking at the code and working on some of the 1914 features, and submitted a few patches:

Add Sea Battle Rounds property
Call EndTurn from Revised Test
Move unit clean-up to EndTurn

I'll likely be making a few more changes as I have opportunity and will post here if I have design questions or the like. See this post for updates on the map creation, which I am also working on.

Let me know if there are any design constraints I should be considering along the way. My thoughts for next steps are:

- Fix a bug in getProductionPotentialOfTerritory that doesn't take into account unlimited originalOwner factories (currently causing an annoying dialog every turn telling you you have nowhere to place your units)
- Support for air units landing on newly-attacked territories (I currently have this working, but you get a warning every time telling you they will die, when they really don't)
- Contested territories currently produce income for the last owner - make it so it produces no income.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

Veqryn
Administrator
hi Frogg,

glad to see you taking some initiative and doing this

i'll be happy to review the patches, although I will say that for the next 1 month i may not have time because i am changing jobs, moving, and traveling


about the development,

some thing to keep in mind is that TripleA supports not just all the different A&A versions (Classic, Revised, LHTR, AA50/Spring1942, Global/Pacific/Europe 1940 1st Edition, Global/Pacific/Europe 1940 2nd Edition, 1942 2nd edition, 1941), but also we have a LOT of user created games

and many times these user created games take TripleA quite a bit further or more complexity than the A&A games, often utilizing various things that TripleA allows but are not part of the A&A rules

so for example, I know of a couple maps that let you move 2 combat moves before doing a noncombat move, or other weird things like that

therefore moving things from one delegate to another delegate is pretty risky

i think perhaps a better way might be to use "step properties", and have a step property for each of the things you want to change (such as a step property for resetting movement points, etc).  Keep the defaults in such a way that no maps are broken, but allow flexibility where the step properties exist in the xml.  An example for you to follow would be the post turn properties in the end turn delegate.

Other things to consider are to, whenever you want to change the rules, to make a new "game option property" (constants & properties files) for the rules change.  So for example, changing whether a contested territory makes income should have a new game option, with the default being whatever the current situation is.

Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
Thanks for the advice, Veqryn.

I updated some of my patches based on your advice. I wasn't really sure what you meant by "step properties". I do see these being used in a few places, but it's not clear to me how to use this to achieve the cleanup without having a non-combat step. I don't see it being used in EndTurnDelegate. Instead what I did was to add a game property. It seems a bit strange to do it that way, but it does work. The other option I considered was to make a special delegate that only cleans this stuff up, and then add that as a step in my xml.

I also had a bit of a design question. Do you have any thoughts on how to do the air superiority rules? One option is to do something similar to the existing "isArtillery" and "isArtillerySupportable", but I'm not really a fan of that approach, and I was thinking of making a more general kind of attachment that can serve both the air superiority use case and the artillery use case. Maybe something like this?

<attatchment name="supportAttatchment" [...] javaClass="games.strategy.triplea.  attatchments.UnitSupportAttachment">
    <option name="supportingUnit" value="artillery"/>
    <option name="supportedUnit" value="infantry:tank"/>
    <option name="supportingQuantity" value="1"/>
    <option name="supportedQuantity" value="1"/>
    <option name="attackBonus" value="1"/>
</attatchment>

<attatchment name="supportAttatchment" [...] javaClass="games.strategy.triplea.  attatchments.UnitSupportAttachment">
    <option name="supportingUnit" value="fighter"/>
    <option name="supportedUnit" value="artillery"/>
    <option name="supportingQuantity" value="*"/>
    <option name="supportedQuantity" value="*"/>
    <option name="attackBonus" value="1"/>
    <option name="defenseBonus" value="1"/>
</attatchment>

The supportingQuantity option indicates the number of supporting units that cause a bonus, and the supportedQuantity option indicates the number of supported units that get the bonus (for each supportingQuantity supporting units). So in the examples here, every artillery gives a bonus to either one infantry or one tank, and one or more fighters give a bonus to all artillery.

You could do other things with this like supportingQuantity=1,supportedQuantity=*, which means all artillery get a bonus for every fighter present.

I'm not entirely sure what it would attach to though...

I could see this being extended in the future to potentially add a relationship type, which, combined with a negative bonus, could be used to weaken some units in the presence of enemy units of a certain type. It could also be extended to add new kinds of support (such as giving more movement points).

Anyway let me know your thoughts. Maybe you had something totally different in mind.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

Veqryn
Administrator
This post was updated on .
for the cleanup, i would not use a game option

step properties are definitely better, as this is more of a property about a delegate rather than a game option

basically, what i would do is the following: make a list of all the differences between "noncombat" and "combat" moves.   since they use the same delegate, you can probably find where this gets set and look at all references to that (and all references to those references, etc), until you have all spots where this difference is read.  

then for each difference, separate them by making 1 property for each difference

then make sure that the defaults = the current behavior

and replace all instances of noncombat/combat move with attempt to use the step property (or the default if none exists)


in this way, you are atomizing the engine, allowing the greatest level of flexibility while still keeping the defaults the same, and not affecting any existing games




on the issue of support, I am not sure I totally understand the rules for 1914

is what you are trying to accomplish that IF one side has ANY air left, all units of XXX type get YYY bonus?

that should be able to be accomplished right now without any changes, just by setting the number of units supported to some stupidly high number (like 10000)


however, a problem comes into play if those units are supposed to get this bonus even IF that last air unit dies.  in that case, we will need to think about how to carry over information that the air battle was won by which side, and how to give that support.

Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
This post was updated on .
I'll have to look some more into the step property thing. Do you have an example of an XML that uses it?

I was not at all aware of the UnitSupportAttachment class until now. I had only seen the "isArtillery" and "isArtillerySupportable" unit attachment options being used before so I thought that was the extent of the support featureset available. As it turns out the UnitSupportAttachment class is very similar to the design I had in mind for this, and it already exists. I was able to get the 1914 Air Superiority rules to work using the existing code.

Another design question I had was regarding the minor/neutral powers. In short, there are certain territories on the board, that when a unit moves into them, units are placed there. Some territories are aligned to one power, and when a unit moves into these territories, the units placed there are always of the power that territory is aligned to (no matter who moved in there). For example Romania is aligned to Russia, so as soon as any unit moves into Romania for the first time, Russian units are added there.

Other territories are neutral. These work the same as the minor powers, but they are not aligned to a particular power. When a unit moves in there for the first time, units are added there for one of the powers opposing the unit moving (the opposing side is supposed to decide which power's units will be added there).

I can add some national objectives to make this work. I have the minor aligned powers working. What I did is place the units there at the start, but made them neutral. Then when a unit moves in, a national objective triggers that changes the ownership of the territory and units. It's a bit tricky for two reasons:

1. The units involved in a battle are determined during move phase, so simply replacing the units with a post-move trigger didn't work (the battle was set up for the neutral units which are now gone). I had to do some trickery to convert the minor units into aligned units after the combat occurs.

2. This code didn't really make a lot of sense to me, and prevented me from changing the ownership of the territory when it is neutral:

                for (final Territory terr : territories)
                {
                    final PlayerID currentOwner = terr.getOwner();
                    if (currentOwner == null || currentOwner.isNull() || TerritoryAttachment.get(terr) == null)
                        continue; // any territory that has null owner or has no territory attachment should definitely not be changed
                    if (oldOwner != null && !oldOwner.equals(currentOwner))
                        continue;
                    aBridge.getHistoryWriter().startEvent(
                                MyFormatter.attachmentNameToText(t.getName()) + ": " + newOwner.getName() + (captured ? " captures territory " : " takes ownership of territory ") + terr.getName());

I will submit a patch changing that first if condition to this:

                    if (TerritoryAttachment.get(terr) == null)

The idea is if oldOwner is "any", then it allows conversion from a neutral as well.

This was the way I could implement it with the smallest engine code change. Do you have other suggestions to meet this feature?

Also I'm pretty stumped about how to do the pure neutrals. My current approach will only work if I put "neutral" units from both sides, and then use triggers to remove one side or the other depending on who attacks. But then the two sets of units will want to fight each other each time. So my best idea so far is to have neutral units of the side opposite whoever's turn it is, and at every end turn where the side changes, I need triggers to replace those units with opposing units.

Hopefully you have a better suggestion.

Thanks a lot for your help.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
So I found a way to do the neutrals using a player called Neutrals and giving it units. The only trouble is my xml would have been 6000+ lines... I made a small change which I'll upload that allows multiple "when" tags. Then a single rule can trigger after every player's turn to check for movement, replace units, etc. rather than duplicating it all 8 times.

Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

siparo
How's the development of 1914 coming along? I can't wait to play it on TripleA.

Thanks again for your hard work!
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
Between the engine work and the map I've created, most of the core functionality is done, but there are still a lot of rules to implement and bugs to fix. I've submitted a bunch of patches to sourceforge but I'm sort of waiting for some feedback/uptake from the devs before I do any more. I don't want to do a ton of development and then have it all rejected.

Also I'm waiting for more info on this step properties suggestion veqryn made to properly do the support for a single move delegate. I really can't figure out what design he has in mind as the only use of step properties I could find seemed to be using it in a totally different way.

I do have some more features that I haven't submitted patches for. I'll upload those and see what shakes out when veqryn has a chance to review. I understand he's been busy so I'm not sure what his timetable for this is.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
It's also getting confusing because I have about 10 separate changes, often in overlapping files, and it's getting difficult to manage them all. Once some of them get committed it will be easier to create patches, etc. for the remaining changes.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

blumb
In reply to this post by frogg
I should have read this a few day's ago... I will check out the patches.
I'd like having sea zone battle rounds easier for sure ;)

I think a property for using contested zones is something that the engine needs.

I agree with Veqryn about the step thing some.
I'll get my thoughts together and try to explain it.... after some coffee

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

blumb
In reply to this post by frogg
The Step condition....

Creation of a delegate:


                <delegate name="Reinforce" javaClass="games.strategy.triplea.delegate.MoveDelegate" display="Reinforcement Movement"/>

And the corresponding code to make the delegate only allow for movement into contested zones by units with movement left.

You'd put it in the xml for each player like this:

<step name="Austria-HungaryTech" delegate="tech" player="Austria-Hungary"/>
                        <step name="Austria-HungaryTechActivation" delegate="tech_activation" player="Austria-Hungary"/>
                        <step name="Austria-HungaryCombatMove" delegate="move" player="Austria-Hungary"/>
                        <step name="Austria-HungaryBattle" delegate="battle" player="Austria-Hungary"/>
                        <step name="Austria-HungaryNonCombatMove" delegate="move" player="Austria-Hungary" display="Non Combat Move"/>
<step name="Austria-HungaryReinforce" delegate="move" player="Austria-Hungary" display="Reinforcement Movement"/>
                        <step name="Austria-HungaryPlace" delegate="place" player="Austria-Hungary"/>
                        <step name="Austria-HungaryEndTurn" delegate="endTurn" player="Austria-Hungary"/>

There would need to be the code and properties for contested zones for it all to work.

This would make the implementation relatively simple and allow for future flexibility for any map.

Not sure how to put the sea zone combat round patch in the engine.
Is there a way to just put it in a folder or something?
When searching "install java program patch" everything I get roughly translates into "learn to code in java, via installing a patch with a really long list of steps" lol

I don't know java. I'm starting to understand xml Triplea style pretty good though...
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

blumb
Neutrals can be handled with triggers all in all. Ownership of the minors and everything.
I think a window for choosing the side that new troops is even possible with the current engine and a bunch of triggers ect.

The board has the empty spaces, there could be all the possible troops in "press boxes" until placed.
They'd watch the Great War unfold until they join... just a thought.

What does someone with the ability and authority think about updating the unstable @ sourceforge to include sea zone battle rounds?
Seems like it could be a quick task with the right know how.
And there is no real unstable at this point anyway...
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
In reply to this post by blumb
I'm not sure what OS you are running but in linux you can just use the patch program:

navigate to the top level of the source (where build.xml is) and run:
 
patch -p0 < patchfile.patch
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
In reply to this post by blumb
I don't understand what you mean about the reinforcement move. It looks like you're suggesting having 3 movement phases? I'm trying to get it so there is one movement phase, like it is in the 1914 rules. I don't think that's what veqryn was suggesting when he was talking about step properties...
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

blumb
I did misinterpret the rules.

Still though, LH's rules say that if you offloaded units from transports into a contested territory (an amphibious reinforcement), you may conduct combat there, but it is not required that you do so.

That means there needs to be a after battle movement phase that includes contested territory movement.

Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
No. There is only one movement phase. Your example is no different from an amphibious assault, where the movement occurs in one phase, and then during the combat resolution phase, you need to first resolve the sea battle and then the amphibious assault. In this case you resolve the sea battle and then surviving land units reinforce the territory. The decision to move those units is done during the movement phase.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

blumb
As I read it.

You can choose to do battle or not when reinforcing contested zones.

If you choose not to to do land battle it is impossible to reinforce a contested zone after the sea battle without a movement phase after the sea battle .
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
Yes it is possible. You move the sea units and unload the land units in the movement phase. Then you resolve the sea battle during the combat resolution phase, and at that point the reinforcement is already done. It's the same as an amphibious assault where you unload the units into the territory during the combat movement phase, even though this technically does not happen until after the sea battle.

If a transport dies in the sea battle, the land units that were on it need to be removed.

Really this is no different from any other contested territory. You can choose to do battle or not in any contested zone, whether you reinforce it or not. So the way it works is you move all your units where you want them to be in one phase. Then for every territory that was previously contested, you need to declare whether you are doing battle there or not. This decision is made before any combat resolution.

Then in the combat resolution phase all combats (ones that are mandatory because they were previously owned by the enemy, and optional ones that were declared) are resolved, and the turn ends.

With your proposal, the decision to reinforce or not is after the results of the battles, which is not right since you are supposed to declare the reinforcement movement before the combat resolution.

I already have all this working in my latest xml (provided you have the necessary engine changes). Every territory that was contested at the start of the turn you get a prompt asking if you want to battle there or not (whether it was reinforced over land, amphibiously or not at all).

I can't remember if units that unload but are then lost on transports are removed when the transport dies, though... that may be a bug.
Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

blumb
This post was updated on .
 Thanks for sending me the extra files Frogg.
I don't think that you are aware the zip has no xml in the games folder.
All the folders are empty in the zip like it was a zip copy of that directory level.
                                                                                                     
I put together the necessary dependency folders for the map to load (units, flags, tiles,ect) but could still not get the movement working.

It was very buggy for me.
Perhaps I'm doing something wrong and this was because I only swapped out the jar and didn't do a "real" patch?
                                           
Regardless, I've been playing with movement. And tried to make a map with no non combat move. I replaced it with a land based "airborne" move attached to a field commander.

Fail.

No matter how I do the cleanup phase the movement never resets without non combat, this is my experience.

Is there currently a way around this? This is the BIG problem for the 1 move concept if not.
Bigger than the clean up. Clean up is easy just don't aircheck at all.
                                                                                                         
Maybe I'm wrong but it seems to me what the engine needs is at least one new step delegate.

   

StrikeDelegate

      a battle delegate that also resets movement values of all the attacker's units
      and is only triggered by the presence of isStrike units in conflict zones.

Then build property options off this starting with battle rounds.

If things where rewrote making Special Move Delegate not have limitations regarding air/land/sea units being transports/transportable, a StrikeDelegate was put in the engine and options about conflict zones in the properties section...
   
                                           

That's a bunch of flexibility


It could be used with any map it a multitude of ways.


By taking non combat out and having a strike phase put in after the special move, it'd create a 1mpr game and make a big map with multiple moves have an all new dynamic.

Also you could have a player with "normal attack" and high rolling expensive units and a player with spam units and 2 strike steps. Or both/more per faction if balanced balanced...

Most players only use non combat when the have to. Why not make the option for the "non combat move" to become a useful combat step instead via special move.

And at the same time make 1914 rules work.


If not directly what Veqryn probably meant, it's of the nature of his comment, flexibility ect.
 ( Veqryn your 2 cent's and elaboration ? )

Seems like the majority of the code that you have already wrote could fold into this... I don't know java though.

Reply | Threaded
Open this post in threaded view
|

Re: 1914 development

frogg
Sorry about the zip. I fixed it now so it should include all the map elements, flags, etc.

http://frogg.ca/aa1914/latest/World%20War%20I%201914.zip

You're right. Movement resets during non-combat only in the engine. I submitted this patch to allow movement to reset at end of turn instead of non-combat:

http://sourceforge.net/p/triplea/patches/71/

This is the change that veqryn felt could be better implemented using step properties, but I've yet to see exactly what he means by that, so I haven't been able to change the code accordingly.

This patch is in the .jar I sent you, so if you are using that, it should work to reset movement at end of turn, provided you have this game property set:

                <property name="Reset Unit Movement At End Of Turn" value="true" editable="false">
                        <boolean/>
                </property>

(this is set in the xml in the zip linked above)

If it's still not working for you after replacing the .jar and using that xml property, maybe there's something wrong with the way you replaced the .jar? Like your triplea is really running out of a different directory or something. It's also possible that I built the .jar wrong... I've been running it out of my source tree so I'm not sure if there are extra steps I missed in building the .jar.

The alternative is to download the source, apply my patches and build it yourself.

I considered using a new delegate for the one-combat-move concept. Veqryn didn't like it (and I agree with him now) because almost all the code would just be taken from the existing MoveDelegate, and significant re-factoring would be needed to make them share code. Since it's really just this one step that is the problem (resetting unit movement and transport capacity), it's better to use the existing move delegate.
1234