Unit per Hex...will it change?

[Maktaka]

I think they do this so you can't have 2 units end their turn on the same tile. Lets say your warrior ended his turn in the city. When you buy a unit that newly purchased unit won't be able to move and the your warrior who ended his turn in the city can't move. So you wind up with a stack. When you build a unit both units have movement points available because units are built before any unit can move.

However this problem could be easily solved by only not allowing to purchase units in a city where the garrisoned unit doesn't have any movement points left. Theoretically this could still cause problems if the garrisoned unit has movement points, but can't move because the city is surrounded so you'd still be stuck with a stack somewhere.

This mechanic is annoying and I bet it was put in to solve lazy programming.

You just spent you whole post explaining why the mechanic was necessary and could not be avoided, then somehow draw the conclusion it was a lazy programming hack. Huh?

 

[WeaselSlapper]

You just spent you whole post explaining why the mechanic was necessary and could not be avoided, then somehow draw the conclusion it was a lazy programming hack. Huh?

It's lazy programming because instead of trying to overcome the difficulty of the situation of unit purchasing (others were insinuating that it would have been easy) they just took the easy way out and prevented the purchasing given the situation.

I'm a programmer and I know lazy programming when I see it.

 

[Louis XXIV]

What difference does it make whether they let you purchase a unit and then force you to move the other unit or they force you to move the other unit and then let you purchase a unit? At least with the second option, they guarantee there aren't situations where you can't move the unit.

 

[shaglio]

What difference does it make whether they let you purchase a unit and then force you to move the other unit or they force you to move the other unit and then let you purchase a unit? At least with the second option, they guarantee there aren't situations where you can't move the unit.

If I have a Catapult garrisoned in my city for defense and I wanted to build a Swordsman for offense, I’d rather be forced to move the Swordsman out into the open after purchasing it than have to move the Catapult out undefended for a turn so I could purchase the Swordsman.

EDIT: they could also make it so that you can't purchase a unit in a city that has a garrison if there is no open tile to move the new unit into (i.e city is surrounded).

 

[Louis XXIV]

But you can't move the swordsman. Units purchased can't be moved the same turn.

 

[shaglio]

But you can't move the swordsman. Units purchased can't be moved the same turn.

I thought you were asking what the difference was if they implemented a new system were you could build a new unit and move it out of the city on the same turn or how it currently is where you have to move the first unit out of the city before building the new unit. Maybe I misunderstood oyur previous post (#43)?

EDIT: rereading your post and applying it to my example (#44), it would appear that you meant you could build the Swordman and be forced to move the Catapult out (rather than moving the Swordman out like in my example).

 

[Louis XXIV]

Yeah, I was responding to the claim that it was lazy program to require you to move the catapult out first rather than after. I don't think it was lazy to prevent you from moving the swordsman, it was intentionally done for balance reasons.

 

[WeaselSlapper]

Yeah, I was responding to the claim that it was lazy program to require you to move the catapult out first rather than after. I don't think it was lazy to prevent you from moving the swordsman, it was intentionally done for balance reasons.

As someone else stated simply don't have a purchased unit appear until the start of the next turn and all problems are solved. With very little thought the players on this forum were able to come up with a better solution then what was implemented in the game.

I stand by my comment of lazy programming.

 

[Zaimejs]

That was my simple solution. I don't know why it has to be this difficult. I think... correct me if I'm wrong... that when you purchased a unit in older Civ games, it was like when you hurried a wonder with an engineer. Maybe I'm wrong, but it always seemed like the unit appeared at the beginning of the next turn, which makes sense. You can't use it anyway.

 

[Louis XXIV]

^ The difference is gold rushing was hurrying units before, this is straight up buying. It doesn't impact the production of whatever you are building.

As someone else stated simply don't have a purchased unit appear until the start of the next turn and all problems are solved. With very little thought the players on this forum were able to come up with a better solution then what was implemented in the game.

I stand by my comment of lazy programming.

I could see the posts now: "Help. I click 'buy' but no unit appears. What am I doing wrong?"

 

[Gucumatz]

^ The difference is gold rushing was hurrying units before, this is straight up buying. It doesn't impact the production of whatever you are building.



I could see the posts now: "Help. I click 'buy' but no unit appears. What am I doing wrong?"

Well respectively just clicking next turn would fix that.

 

[Louis XXIV]

While I agree, you'd be surprised what kinds of things people start threads on.

 

[Camikaze]

Louis' point is that it wouldn't be intuitive, even if you'd easily figure out what's going on through playing on.

I'm not sure I get the 'lazy programming' angle, seeing as it strikes me as a balance decision, rather than a programming one.

 

[Maktaka]

It also shifts balance even further towards city defense. Got a unit coming out next turn? Buy another one, and get twice the number of unexpected attacks on the city's attackers without needing to make any sacrifice in your defense. Love it when the opponent pops out a unit from their city that you couldn't see coming? Now that can happen every single turn! This myopic focus on "fixing" an easy to explain and observe game design decision (not a programming decision) in favor of a mechanism less obvious is being done in absence of any kind of consideration of balance, which is a terrible way to design a game.

 

[Zaimejs]

I'm confused by your apparent sarcasm. What is the difference?