SITREP

[Kram747]

no offense, but, is this ever going to get done? doesn't feel like it.

 

[Kram747]

Hmmmm Guy if really you mean ‘no offence’ I suggest you try to be a little more constructive ) in my experience the ‘dark arts’ of programming can bring lesser men/women to tears )) a big thumbs up from me Dave

 

[Guy Miller]

if you check the AAR's from EIGHT years ago, you will see that I played this game a lot and loved it. But, it's been a long, long time. I know Dave is alone in programming this game, and respect for his skills, but...it's been almost a decade. it's always, "we're getting closer....oh, wait, no we're not." I'm just tired of it, just being honest. If this is as good as the game is going to get, then so be it!

 

[jimcarravallah]

if you check the AAR's from EIGHT years ago, you will see that I played this game a lot and loved it. But, it's been a long, long time. I know Dave is alone in programming this game, and respect for his skills, but...it's been almost a decade. it's always, "we're getting closer....oh, wait, no we're not." I'm just tired of it, just being honest. If this is as good as the game is going to get, then so be it!

Yes, the current update is testing everyone's patience, but if you had been following the game and adapting the public Beta-release improvements that were offered over the past eight years you'd see there was progress.

It was when those public Beta offerings were to be rolled into a permanent update that the new coding to address attack organization got started.

What's happening is programming changes that address issues with the attack sequencing impact other aspects of the game, and the programming gets bogged down in addressing those anamolies as well.

The other is availability of programmer resources -- the assistant Dave groomed on a part time basis who wrote the public Beta offeringsfor artillery operations and a GIS system interface to make maps more accurate, first got side tracked when moving his parents to safety in the Ukraine immediately after the Russian attack and then lost his young wife to cancer.

Posting discontent here isn't going to speed up resolution of any of those issues.

 

[Arkadiy]

i don’t think anyone questions your fondness for the game - it’s just that the phrasing is not helpful at all.
Suppose my colleague was working on a software project, but I had no control over it, nor was I aware of any timelines/deadline - if I asked “will you ever finish? Does not look like it!”, all I would achieve is annoying said colleague. Instead, one could ask “what else remain to be done?”, “what are some of the issues you are running into that slow you down?”, “do you have an estimate of when we can expect the project finished?” All of those are much more likely to get the answer you were looking for.

 

[Guy Miller]

they've all been asked before, many times.

Anyway, to show I am not trying to sow discontent for the game, I will try to post an AAR of my current game, The Stolberg Corridor.

 

[zardoz]

Not a terribly productive question, is it? Suppose, the developer answers “Yes, it will get done” - it will not change the pace of work, hence nothing will change. Suppose he says, “not sure, taking a while so far” - again, nothing changes. I am not considering a straight “no” - makes no sense, given the ongoing efforts.

I read Mr. Miller´s post. The question wasnt supposed to be productive nor to change anything.
I would interpret the question as of a rethorical one.
I don't think Dave would be presenting all the reports about his work like this if he wasn't convinced that the project would be completed well. The decisive factor is probably the annex “it doesn’t feel like it”. The author is simply expressing his subjective doubts. Such doubts seem not entirely unreasonable, especially since a lot of time has already passed. My own doubts, however, are still small. I also don't think this posting would negatively affect Dave in any way. The vast majority of statements here are highly benevolent, patient, understanding and sometimes a little submissive. After all, everyone wants it to succeed. On the other hand, hardly anyone can really contribute anything constructively. All we have left is the positive encouragement. However, in a forum there should always be room for criticism and doubt.

 

[Dave 'Arjuna' O'Connor]

I do appreciate people's frustrations with how long this has taken. I too am frustrated at that. But life is complex, and this is not the only area of frustration I am trying to deal with at the moment. All I can say at this stage is that I am still working on the game; I do intend to complete this overhaul and get a new version to you, and I do intend to release the Bradley at Bay scenarios. Please be patient.

 

[Dave 'Arjuna' O'Connor]

SITREP Wed 6 Mar 24.

Hi all,

My routine of autotesting and bug fixing turned up ate last week a case where a coordinated complex attack involving two battalion sub attacks ended up not being coordinated - ie one battalion started its assault while the other was still moving to its FUP. It took me a long time to get to the bottom of this but it uncovered some holes in the slippage code.

Specifically, A.51 Coy is heading to its FUP but needs more time. So, he asks his boss for more time through a function call to GetMaxSlippage(). This function is supposed to tell him how much slippage his boss can give him. His boss is the 35th Tk Bn and he is doing a basic attack as part of the CCA complex attack. A.51 didn't request any HHour slippagebecaue he's just doing a Move task. He does request the generic slippage which applies to all timings except those that are no longer active and to any HHour where a specific HHourSlippage is required. The 35th Tk Bn says no worries and slips all his times except his end because he reckons he can accommodate the slippage within his plan and so doesn't ask CCA for more time. Trouble is he doesn't have authority to slip the HHour because it's been assigned to him by CCA.

I thought this will be an easy fix but then I realised that the existing code wasn't handling other cases where we were passing in a required HHour slippage amount but had set the slipHHour separately flag to true. So, I have had to redesign this code after doing a proper case analysis. I'm in the throw of working up the changes for this now. It will probably take me the rest of the week to finish.

I'm sharing this with you so you can gain an appreciation for the complexities involved. Now, this bug has been in the slippage code forever, well a long time. I was tempted to do a quick patch, but I opted not to because it's responsible for a lot of cases where a complex attack goes in piecemeal and fails. It cobbles to varying degrees the offensive capability of forces.

 

[jimcarravallah]

SITREP Wed 6 Mar 24.

Hi all,

My routine of autotesting and bug fixing turned up ate last week a case where a coordinated complex attack involving two battalion sub attacks ended up not being coordinated - ie one battalion started its assault while the other was still moving to its FUP. It took me a long time to get to the bottom of this but it uncovered some holes in the slippage code.

Specifically, A.51 Coy is heading to its FUP but needs more time. So, he asks his boss for more time through a function call to GetMaxSlippage(). This function is supposed to tell him how much slippage his boss can give him. His boss is the 35th Tk Bn and he is doing a basic attack as part of the CCA complex attack. A.51 didn't request any HHour slippagebecaue he's just doing a Move task. He does request the generic slippage which applies to all timings except those that are no longer active and to any HHour where a specific HHourSlippage is required. The 35th Tk Bn says no worries and slips all his times except his end because he reckons he can accommodate the slippage within his plan and so doesn't ask CCA for more time. Trouble is he doesn't have authority to slip the HHour because it's been assigned to him by CCA.

I thought this will be an easy fix but then I realised that the existing code wasn't handling other cases where we were passing in a required HHour slippage amount but had set the slipHHour separately flag to true. So, I have had to redesign this code after doing a proper case analysis. I'm in the throw of working up the changes for this now. It will probably take me the rest of the week to finish.

I'm sharing this with you so you can gain an appreciation for the complexities involved. Now, this bug has been in the slippage code forever, well a long time. I was tempted to do a quick patch, but I opted not to because it's responsible for a lot of cases where a complex attack goes in piecemeal and fails. It cobbles to varying degrees the offensive capability of forces.

I don't know if it would make correcting the problem any easier, but keep in mind even the most meticulously planned operations in RL proceed despite obvious disconnects.

It's a case where a few minutes difference in coordination don't halt the progress on relatively small efforts and even up to an hour wouldn't stop a major operation.

Some element of surprise may be lost, but the ultimate goal is to bring a diverse force to bear on the poimt of attack. possibly along multiple axes of advance.

It is akin to operating knowing there is the fog of war.

 

[Dave 'Arjuna' O'Connor]

Good point Jim. Thanks. In the case I'm dealing with the second Bn launches its attack almost two hours after the first. So, something needs to be done about that. When it plays out the first attack fails and so does the second. In effect, they are defeated in detail, whereas a coordinated attack succeeds.

 

[jimcarravallah]

Good point Jim. Thanks. In the case I'm dealing with the second Bn launches its attack almost two hours after the first. So, something needs to be done about that. When it plays out the first attack fails and so does the second. In effect, they are defeated in detail, whereas a coordinated attack succeeds.

That's the case where I was thinking a few minutes delay wouldn't harm. The goal is to keep the defensive force off balance and guessing. Two hours gives it time to adjust, perhaps not as well to an attack on a second axis, but definitely enough to settle into a solid defense alerted to any new danger.

 

[MarkShot]

As a customer, I can understand the frustration. As an alumni, I know what all connected have given ... the most of anyone Dave. He has gone far beyond what I myself would do for a passionate hobby. For Dave, this game is a life's creation of art. You will never find him at dinner with Gates, Bufet, Bezos, Musk, Zuckerberg, Soros, etc... (from CO2's balance sheet).

For customers, I would say, I cannot be the only one owning multiple quality titles. Just play something else, and wait knowing that each year on average the game which is compute bound will ultimately run faster on newer hardware.

For Dave: (as a retired software engineer):

* The practice of coding is a struggle against entropy. Over the years, there have been many best practices to slow code entropy. However, eventually every code base will reach a point where the correction of a bug has a probability of greater than 1.0 of introducing a bug. When that threshold is reached, the code become cancerous and corporations will start to consider the very costly and risky new development over maintenance.

* In 2000, when we met, the idea of a game made up of delegating agents was cutting edge and is still cutting edge for most game companies which essentially have a flat view (not hiearchical) of game AI. However, the generative AI-LLMs is doing precisely that in real life now. We are soon going to see AI-LLMs applied to games. Given that there are corporate models of non-human intelligent teams and hierarchies being spawned off by AI-LLMs, there is a chance that we are 1-2 years from such happening in games too (beside AI-LLMs are doing game coding, game art and realtime game generation). My point is if you don't release soon, you may never release as AI-LLMs will the take paradigm which you pioneered and do it faster and better ... nothing specific to you ... you will be one of millions of humans to which this happens in 2024.

 

[jimcarravallah]

As a customer, I can understand the frustration. As an alumni, I know what all connected have given ... the most of anyone Dave. He has gone far beyond what I myself would do for a passionate hobby. For Dave, this game is a life's creation of art. You will never find him at dinner with Gates, Bufet, Bezos, Musk, Zuckerberg, Soros, etc... (from CO2's balance sheet).

For customers, I would say, I cannot be the only one owning multiple quality titles. Just play something else, and wait knowing that each year on average the game which is compute bound will ultimately run faster on newer hardware.

For Dave: (as a retired software engineer):

* The practice of coding is a struggle against entropy. Over the years, there have been many best practices to slow code entropy. However, eventually every code base will reach a point where the correction of a bug has a probability of greater than 1.0 of introducing a bug. When that threshold is reached, the code become cancerous and corporations will start to consider the very costly and risky new development over maintenance.

* In 2000, when we met, the idea of a game made up of delegating agents was cutting edge and is still cutting edge for most game companies which essentially have a flat view (not hiearchical) of game AI. However, the generative AI-LLMs is doing precisely that in real life now. We are soon going to see AI-LLMs applied to games. Given that there are corporate models of non-human intelligent teams and hierarchies being spawned off by AI-LLMs, there is a chance that we are 1-2 years from such happening in games too (beside AI-LLMs are doing game coding, game art and realtime game generation). My point is if you don't release soon, you may never release as AI-LLMs will the take paradigm which you pioneered and do it faster and better ... nothing specific to you ... you will be one of millions of humans to which this happens in 2024.

With background in project management (we always viewed software engineers as working for us whether they admitted it or not ;-) ), there's a poimt where you commit because what you now have is better than what you started with, even with a few warts.
Particularly with software, there's never the perfect solution, but in pursiong the perfect you reach a point where everything you've done is better than what you started with.

I monitor the feedback loop in both this forum and the Steam forum. While there are some dilletantes in Steam (largely playing the free version) some of the more serious players who have invested in the game with their purchases are gettinng frustrated with promises of improvements that don't emerge on schedule.

Of course there will be complaints on a new update release, but that doesn't necessarily mean that what was released didn't improve on what was available to that point.

Facrt is. there are some people simply like to complain.

Baspcally, there's a lot more thinking and analysis going into making the AI an efficient game player than many users than what bother to put into managing their game play to begin with.

It's commendable, but not necessarily going to result in any more marketability from fixing the more grevious of problems even with a few warts remaining.

 

[MarkShot]

Well, Jim,

My background spans programming to CTO of startups to SVP of US fortune 500s.

Dave has always been a perfectionist. This manifests itself in three ways:

* When he runs across a bug, he will not simply put it on the list, but usually soon initiate coding efforts to correct. This continuously pushes deliverables out.

* Dave is very prone to feature creep. If something cool and useful is suggested, again rather than going on a list of future features, he will begin to roll it into the current base.

* Thus, it is not in Dave's nature to say 04/01/24 is the release date. The code will be frozen on 03/01 and permitted to open beta; only game breaking issues will be addressed. On 02/01, internal beta testing will begin. On 01/01, coding and unit testing will be done. The cycle begins anew on 04/01, and Panther will do three of four releases per year.

---

I have been with the series, since RDOA. There have always been bugs. One I remember was that on ATTACK, the FORCE would EXPLOIT beyond the OBJECTIVE. Then, the FORCE would REGROUP/DEFEND on the OBJECTIVE. HQ being the first to have the next phase ORDER would be first to regroup and by default take the FASTEST not the SHORTEST PATH which often would get it in to trouble, since the SHORTEST would have been cleared. But you learn to work around it.

ARTILLERY as part of a FORCE did not not manifest its own ROF. You would not get that type of control until the DETACHED GUNS control window would appear in a later game. Which led to players like me to create Vietnam style fire bases in WWII.

The game is not perfect. There are no national or service doctrines. There are only side sighting databases as opposed to UNIT/FORCE sighting databases like combat mission.

But still there is no game that comes close ... even to the original release of RDOA. Yes, Dave, you need to learn how apply hard project phases to the work cycle. Players (from what I have seen on Steam) like regular patches provided that they don't break existing games or happen sporadically so that people cannot plan for them. It is already a big win that you are not selling bug fixes bundled into DLCs; those are simply free.

Well, good luck, Dave. Nice chatting with you, Jim.

 

[jimcarravallah]

Well, Jim,

My background spans programming to CTO of startups to SVP of US fortune 500s.

Dave has always been a perfectionist. This manifests itself in three ways:

* When he runs across a bug, he will not simply put it on the list, but usually soon initiate coding efforts to correct. This continuously pushes deliverables out.

* Dave is very prone to feature creep. If something cool and useful is suggested, again rather than going on a list of future features, he will begin to roll it into the current base.

* Thus, it is not in Dave's nature to say 04/01/24 is the release date. The code will be frozen on 03/01 and permitted to open beta; only game breaking issues will be addressed. On 02/01, internal beta testing will begin. On 01/01, coding and unit testing will be done. The cycle begins anew on 04/01, and Panther will do three of four releases per year.

---

I have been with the series, since RDOA. There have always been bugs. One I remember was that on ATTACK, the FORCE would EXPLOIT beyond the OBJECTIVE. Then, the FORCE would REGROUP/DEFEND on the OBJECTIVE. HQ being the first to have the next phase ORDER would be first to regroup and by default take the FASTEST not the SHORTEST PATH which often would get it in to trouble, since the SHORTEST would have been cleared. But you learn to work around it.

ARTILLERY as part of a FORCE did not not manifest its own ROF. You would not get that type of control until the DETACHED GUNS control window would appear in a later game. Which led to players like me to create Vietnam style fire bases in WWII.

The game is not perfect. There are no national or service doctrines. There are only side sighting databases as opposed to UNIT/FORCE sighting databases like combat mission.

But still there is no game that comes close ... even to the original release of RDOA. Yes, Dave, you need to learn how apply hard project phases to the work cycle. Players (from what I have seen on Steam) like regular patches provided that they don't break existing games or happen sporadically so that people cannot plan for them. It is already a big win that you are not selling bug fixes bundled into DLCs; those are simply free.

Well, good luck, Dave. Nice chatting with you, Jim.

Hi Mark,
My professional background involving software development is primarily with the military.
This game intrigued me because later in my career I was an advisor to a training wargame being developed bt Sandia Labs for the program I supported. My logistics functional office was tasked with providing support that integrated realistic logistics dynamics and management ytasks into officer level combat training software.

This is the first game where I saw those dynamics were being considered as part of gameplay, so I offered to help. and Dave accepted.

Prior to the Sandia effort, I had first managed and later advised on the development of vehicle level troubleshooting software and on my last program a software support suite being developed by Honeywell designed to use diagnostics software to support vehicle manintnance, feed data into vehicle and soldier health evluations before and during combat and using that feedback to plan and execute logistics support activities in real time.

We were basically communicating field logistics information and providing decision matrices for a range starting with a single soldier through all echelons of command requiring logistics awareness in their planning back to depot operations to quantify and facilitate longer term materiel support down to a soldier's ration and ammunition distribution in near real time.

What was frustrating is we'd get to the point where we had a much better product than what was currently available and during final testing someone of management importance would say . . . "What if we . , . ?" and the release would be delayed.

It was a case of "This Volkeswagon will do, but we could get a Cadillac" and we'd start the whole cycle over again.

All that's to say if I was managing the world we'd push the better things out early and then look at perfecting them.

Might have worked if I was writing and distributing the software, but I didn't and couldn't so I'd speak my two cents worth and (usually) wait.

Take care,

jim

 

[MarkShot]

Jim,

In 2-3 years, software will be developed by AIs. So, I don't know what is used for project design and planning in 2020 and it doesn't really matter.

The 70/80s mainly featured large phased projects. There were many problems with this approach such that one or two lines in the requirement spec might expand into years of work. Words were cheap early in the project, and you only found out much later what a mess (true cost) had been made of things. At the time, this was known as the Waterfall Model.

Starting around the 90s, I transitioned to rapid prototyping and the Spiral Model. Unlike the above which was very top down, the Spiral Model was some bottom up and some top down. The idea with the rapid prototyping was to address mission critical aspects first. So, if you had to be able to process peaks of 10,000K transactions per second, then you focused on the hardware, networking, and database servers to demonstrate that could reach that level of performance. Since no matter what the screens or work flow looked like, the project would fail if it would max out at 3000K/second. So, you identified critical points of failures and prototypes. (this was often bottom up)

At the same time, you defined short less than complete system development cycles. The idea was to hit core functions in a cycle that ran for maybe just 6 months; deliver; and begin a new cycle of extending features. (this was often more top down) But rather than running a multi-year massive project where if you didn't reach year #5, you had nothing to show for it, in the Spiral Model, you could assume funding might be cut at any point. But in any case, on average, the most which was wasted was 3 months of budget, and no matter when the plug was pulled, you had something in production of true value.

The Spiral Model has less of a glorious day of grand completion, and came to a slow end when all involved realized it was good enough, and new priorities were beginning to assert gravitational attraction to pull the team away to apply themselves to something now more urgent.

When I did code I started working in assembly, micro code, embedded real time processing ... and was mainly a systems programmer on Wall Street working on database implementation (not the data, but coding the internals and locking algorithms, compilers, and operating system queuing tasks). It was only later that I got involved with fundamental data and exchange transaction traffic and trading floors.

I must say I am glad that I got to live through the evolution of CS from punched cards, RJEs, and magnetic tape to AI agent coding. The general public think that modern AI (meaning post 2015) is sub-branch of CS. But modern AI is pure alchemy with the experimentalists having no idea why it works. AI has no relationship to the engineering and formal discipline of CS; they are separate fields. But still I find AI developments and unexplained emergent properties fascinating. (As I have an RTX 4090, built the PC last year, I do a little open source AI education on my own.)

 

[jimcarravallah]

Jim,

In 2-3 years, software will be developed by AIs. So, I don't know what is used for project design and planning in 2020 and it doesn't really matter.

The 70/80s mainly featured large phased projects. There were many problems with this approach such that one or two lines in the requirement spec might expand into years of work. Words were cheap early in the project, and you only found out much later what a mess (true cost) had been made of things. At the time, this was known as the Waterfall Model.

Starting around the 90s, I transitioned to rapid prototyping and the Spiral Model. Unlike the above which was very top down, the Spiral Model was some bottom up and some top down. The idea with the rapid prototyping was to address mission critical aspects first. So, if you had to be able to process peaks of 10,000K transactions per second, then you focused on the hardware, networking, and database servers to demonstrate that could reach that level of performance. Since no matter what the screens or work flow looked like, the project would fail if it would max out at 3000K/second. So, you identified critical points of failures and prototypes. (this was often bottom up)

At the same time, you defined short less than complete system development cycles. The idea was to hit core functions in a cycle that ran for maybe just 6 months; deliver; and begin a new cycle of extending features. (this was often more top down) But rather than running a multi-year massive project where if you didn't reach year #5, you had nothing to show for it, in the Spiral Model, you could assume funding might be cut at any point. But in any case, on average, the most which was wasted was 3 months of budget, and no matter when the plug was pulled, you had something in production of true value.

The Spiral Model has less of a glorious day of grand completion, and came to a slow end when all involved realized it was good enough, and new priorities were beginning to assert gravitational attraction to pull the team away to apply themselves to something now more urgent.

When I did code I started working in assembly, micro code, embedded real time processing ... and was mainly a systems programmer on Wall Street working on database implementation (not the data, but coding the internals and locking algorithms, compilers, and operating system queuing tasks). It was only later that I got involved with fundamental data and exchange transaction traffic and trading floors.

I must say I am glad that I got to live through the evolution of CS from punched cards, RJEs, and magnetic tape to AI agent coding. The general public think that modern AI (meaning post 2015) is sub-branch of CS. But modern AI is pure alchemy with the experimentalists having no idea why it works. AI has no relationship to the engineering and formal discipline of CS; they are separate fields. But still I find AI developments and unexplained emergent properties fascinating. (As I have an RTX 4090, built the PC last year, I do a little open source AI education on my own.)

We were largely working the spiral model in the early 2000 until I retired in 2009.
We were on the edge of AI with the system diagnostics -- basically monitoring system feedback from digital controls and inserted mechanical function monitors to detect anomalies in operation and trace those to a maintenance fix.

The difficulty was we were working with mechanics who wanted something to break before they took action to fix it, and we were looking for symptoms of performance which were a precursor to a catastrophic break. Then when we were able to trace to a single cause of a break (an ambiguity 1 detection) the mechanics didn't believe the findings from the monitors and wanted to retrace the troubleshooting by looking at system schematics.

My last projects effort to merge the maintenance feedback to the supply system was more AI-ish because it offered choices of action for a commander's decision process. Once the decision was made by a human, the administration effort to perform the task was automated through all the echelons of command responsible for addressing the corrective action to replenishing the supplies.

AI to me still seems like the machine making decisions more quickly than the human mind may ponder it. Each goes through a stepdown process from most likely to least likely defined by the programmer, but the computer sorts through all the options more quickly.

My best friends in the software development arena were the guys who'd take the time to explain their thinking in terms of what I could understand. My worst ones were those who hid behind jargon and the concept "my skills are so rare you'd never understand them."

Sounds like if we would have had a chance to work together, you'd be numbered among my best friends.

 

[john connor]

Not sure if any of that is what is happening when Dave is coding this patch. As I understand it, he is actually trying to implement one set of changes in a focussed way, throughout all this time, but each time he tweaks it the thing ends up, relatively speaking, broken (in a different way each time) such that the game would not actually be 'better' if he released it then, but actually much worse. So he continues. That's been my understanding of his reports, at any rate.

 

[zardoz]

Not sure if any of that is what is happening when Dave is coding this patch. As I understand it, he is actually trying to implement one set of changes in a focussed way, throughout all this time, but each time he tweaks it the thing ends up, relatively speaking, broken (in a different way each time) such that the game would not actually be 'better' if he released it then, but actually much worse. So he continues. That's been my understanding of his reports, at any rate.

Well, probably that is about what MarkShot has been describing as digital entropy in post #1,413.
The point when each correction of a code´s bug results in a rate of probability of causing another bug due to that very process becomes 1 or higher.

Meanwhile it seems that our fellow generals are digging themselves in details about their profession and current or expected development of (game)coding and the role of AI in terms of that subject.