FoG(U) v1.8.04.359 development build report

[cothyso]

Hello guys,

First of all, I know we should post updates more often as many of you are interested in how the development goes with the new FoG, and I am offering you my apologies for not doing it so often as I should. The fault is entirely mine, and I ask you guys to bear with me as the only reason for this is not the lack of care or will, but the fact that I am not only working as project manager, but also as a lead programmer and designer, so I do not have too much time these months for browsing the forums (as you can very well imagine).

Yesterday we've reached the eight milestone, and we've provided the v1.8.04.359 development build. There are mostly good news to share, but there are some bad news too: the build is looking good, and we've reached (and actually got into) gameplay systems implementation. The Editor, the DAG and the PBEM systems are almost completed, and functional at almost 100% capacity.Which also means a closed beta stage is close enough

At this point, we've also added (some) code support for the following new gameplay features (they are functional at this point):
- double sized BGs (DS BG)
- multiple BGs in the same hex
- partial postponed BG moves (BG's doing a part of their movement, then re-selected after dealing with other BGs movements (fully or partial) and moved again, fully or partial, for the remaining of their movements)
- multiple sides/multiple players
They will not be fully developed/activated in FoG(U) new version, but they might be at some point in the future

The bad news would be that we're somewhat behind the development schedule. Nothing critical, but the fact is still there: we're not quite were we've predicted and should have been (with the development) at this point. The four main reasons for this are the game's complexity and the sheer amount of hard work needing to be done (there are LOTS of game systems, and only listing them would bring up a demoralizing list), combined with a somehow over-enthusiastic development period estimate and some internal problems.

These being said, I also want to bring up into discussion with you some FoG(RB) (old) version design flaws we've encountered until now. As at this point we're mostly replicating the behavior of the existent FoG (and only doing minor modifications to the existent gameplay functionality), they were implemented as is in the new FoG(U) (new) version. Yet, we can still have a little debate about them.

The following are today's culprits:
- // DESIGN FLAW 001 - enemy BG ZOC does not cosiders BG's facing (ie is spread on all 6 neighbors)
- // DESIGN FLAW 002 - leader BG area of command does not considers the enemy BGs or enemy BG's ZOC (is acting even behind enemy's battle line)
- // DESIGN FLAW 003 - a BG can turn multiple times on its movement path (even if theoretically a BG can not turn more than once)
- // DESIGN FLAW 004 - a BG's movement area/front arc is not recomputed even when changing facing, no matter if the change facing is manual or automatic

[stockwellpete]

The bad news would be that we're somewhat behind the development schedule. Nothing critical, but the fact is still there: we're not quite were we've predicted and should have been (with the development) at this point. The four main reasons for this are the game's complexity and the sheer amount of hard work needing to be done (there are LOTS of game systems, and only listing them would bring up a demoralizing list), combined with a somehow over-enthusiastic development period estimate and some internal problems.

Thanks very much for the update, Dan. I think a lot of us realised that it might take a bit longer to do than was originally suggested. As far as I am concerned that is not a problem at all. I am just pleased that FOG has a long and exciting future ahead of it and I would say that the main thing is to ensure that the new system is very stable when it goes live.

There is a very interesting thread that the development team should read (if you haven't already) called "I feel like cheating". It is mainly about the distribution of dice rolls in the game and how melee casualties are calculated . . .

viewtopic.php?f=84&t=34862

[cothyso]

I've saw the thread, and read it on fast forward. If you remember, I had some posts about the subject a year ago or so. Anyway, this is not the point to debate about the dice distribution, as we're not there yet . One step at a time

[ianiow]

- double sized BGs (DS BG)
Are we talking phalanx's of pike and hoplites to make them less manuverable?

- multiple BGs in the same hex
Perhaps LF archers units can attach to HF Legion units aka Late Romans? Or two pike units join for extra depth? Bigger deeper warbands?

- partial postponed BG moves (BG's doing a part of their movement, then re-selected after dealing with other BGs movements (fully or partial) and moved again, fully or partial, for the remaining of their movements)
I'm not sure how this will play out yet. Perhaps moving up 1 hex to act as support for a fighting unit, then moving a further 1 hex into combat if the supported unit routs?

- multiple sides/multiple players
Whoo hoo!

Very much looking forward to seeing your ideas in action Dan !

[deeter]

Really great news about the new features. I'd to know more about how they will be implemented as Ianiow suggested above. Regarding the 4 design flaws, I always just considered them part of the game.

Deeter

[ericdoman1]

- double sized BGs (DS BG)
Or does this mean that now in say a 500 pts game. Armies will have 44 bgs and so to break the army you would need to inflict 44 bps. If there ared ouble sized bgs, does this mean that now the army can potentially be 22 BGs and so only requies 22 bps to break

- multiple BGs in the same hex
How would you be able to know what bgs are in the same hex?



- partial postponed BG moves (BG's doing a part of their movement, then re-selected after dealing with other BGs movements (fully or partial) and moved again, fully or partial, for the remaining of their movements)
At the moment if you move bg A let's say 1 hex, you have 2 more hexes to move, then go to bg B and move that one, you can not go back to BG A and move it. So what you are stating is this can be done in the updates.

- multiple sides/multiple players
Whoo hoo! I second that emotion.

So you could have 4 players or more playing the same game. In many pc games you have online multiplay which allows x amount of players to play.

Just wondering there will prob be a specific order of movement. SO when we start make sure you haven't booked a 2 week holiday:)

Well looks as if there are going to be far greater changes than I thought. Also it proves that we would most certainly not be able to paly any comps until it is sorted.

Possibly best to say Jan or Feb 2013, just to make sure, even March. Always found that good when somebody over forecasts, you accept it and are then chuffed to find out it has arrived earlier?

[TheGrayMouser]

Thanks for the update Dan
double sized BGs (DS BG) droooool.....
- multiple BGs in the same hex droooool........
- partial postponed BG moves (BG's doing a part of their movement, then re-selected after dealing with other BGs movements (fully or partial) and moved again, fully or partial, for the remaining of their movements)
Not sure about this , seems would give WAY too much control, too gamey
- multiple sides/multiple players droool....


Can your explain this though?
// DESIGN FLAW 004 - a BG's movement area/front arc is not recomputed even when changing facing, no matter if the change facing is manual or automatic

You cant charge into something you arnt facing prior to moving in any way , so where is the flaw?

[cothyso]

it is not about charging, but about movement area shape. there were situations in which I was changing the facing of a unit before moving it at all, and the shape of the movement area was modifying (as I've already had the our of frontal arc movement penalties code added). that's how I've noticed that I had to add special code to prevent this, as it wasn't happening in FoG(RB) neither. but it is an artificial restriction, which doesn't feels right.

just to be clear, the DS BGs are BGs sitting on two hexes, which have 3 front and 3 rear hexes (besides the left and right ones), and have a special changing facing movement: rather than rotating in their own hex, as the normal BGs, their rotation is rather a special movement, in which one half of DS BG's pivoting around the other half, which is fixed in its place. and it also counts as a move. Games like GBCE had them, and they simulated very well the clumsiness of large solid battlegroups (as the phalanx for example).

and just to be crystal clear, do not get excited on the support code we've added in for those above mentioned extra features: the code is not complete, we were just laying the base for it as we went on with the FoG(RB)'s features. They will not be completed for FoG(U), and most probably will remain as they are atm until the FoG 2.0

[stockwellpete]

and just to be crystal clear, do not get excited on the support code we've added in for those above mentioned extra features: the code is not complete, we were just laying the base for it as we went on with the FoG(RB)'s features. They will not be completed for FoG(U), and most probably will remain as they are atm until the FoG 2.0

Understood. I think we can still be a little bit excited though because you are giving us a preview of how the game might develop in the future.

[deeter]

Please take a look at the changes in FoG TT 2.0 as you code.

Deeter

[keyth]

Thanks for the update - sounds good!

[amenofi64]

Any news about rhe release?

[Adraeth]

This might be a silly question but, do the system requirements for FOG digital will change with this version?

Concerning that "wolves from the sea" will be released after this update is it planned to produce some other army lists like "oath of felty"?

thank you in advance

[IainMcNeil]

I doubt they will change but if they do it will almost certainly be downwards rather than upwards. The only possible exception is the graphics card but we need to get it done and then test it to see.

[Legatvs020]

Did FOG developers ever consider to do something about disproportionate rolls appearing too frequently ? Apart from the fact that roll should be counted, the amount of time disproportionate rolls appear should be also considered. What are the chances that one suffers 250 while other suffers 10 casualites, in equal penalties and equal units (impact foot/armored for example). ? Very rare, more often, casualties should be close when we are talking about 50%-50% fights. What number you roll, plays far too big role, then it should. Sometimes even perfect strategy betrays you because your rolls suck.

The following are today's culprits:
- // DESIGN FLAW 001 - enemy BG ZOC does not cosiders BG's facing (ie is spread on all 6 neighbors)
- // DESIGN FLAW 002 - leader BG area of command does not considers the enemy BGs or enemy BG's ZOC (is acting even behind enemy's battle line)

Good points indeed. Heres another one: ZOC not being available while general is fighting - you should use your general in fight only as an ace in the sleeve if you desperately need to hold the line.

edit: considering General UNIT has few men, not 300 as regular unit.

- // DESIGN FLAW 003 - a BG can turn multiple times on its movement path (even if theoretically a BG can not turn more than once)

As far as i know, you cannot turn BG more then once a turn, then when you want to turn it around again, you have to wait another turn spent facing same direction

- // DESIGN FLAW 004 - a BG's movement area/front arc is not recomputed even when changing facing, no matter if the change facing is manual or automatic

I do not know if it is computed or not, but atm, movement area/front arc works in pretty realistic manner.

[JocaRamiro]

Hi,

Would it be possible to provide an update - even the briefest - on progress?

Mead Walker

[CaptainHuge]

I second that. Any information would be appreciated.