Hello

Just be online 24/7, easy.

Reminding me of a phrase I've been hearing lately, "terminally online"

Do devs in bigger companies keep the documentation up to date with the software?

not always

seldom

maybe never

well, in game companies anyway

I bet RBC has their documentation up to date

Yeah.

I've been writing code for this software for the past 10 years and sometimes I get to code I wrote 7 years ago and I'm like "WTF is this mess" and I wonder if the answer could be more quickly answered if I had written complete and decently retrievable doc...

Maybe if you had you would have missed the deadlines and would not be working on it anymore.

@Vaillancourt Comments/docs seldom stay in step with the code.

the code you're describing could benefit from docs

I find that since I comment so seldom in my code, the few times I do I manage to keep them up to date

so maybe documenting something really hairy like that is worth doing

Sometimes I think unit tests are relatively good at showing off functionality, better than a list of functions and their descriptions because you have self-contained compilable working examples including setup code.

Yes, I'm thinking primarily about a "higher level" documentation. Per-function document is most of the time irrelevant...

Unit tests is good, although I wonder how much it would apply in my situation

@Vaillancourt This is what I came up with...

@Vaillancourt In my experience, we try to in the early phase of the project, fall behind by about halfway, and say "f*** it, the game is its own documentation" in the last year or so. 😅

@Vaillancourt In my own experience, this is very true. The signature already tells me what the Foo function eats & the fruits it yields. Why the farm I planted it is another story & hard to capture using the standard documentation practices I was taught.

@DMGregory That makes some sense. In the early stage, devs may not be fully comfortable with the architecture yet, and it's a moment where the architecture is subject to changes, and as the project progresses, everyone is able to find their way around without the doc, and things change less...

@nwp Also agree. Future me is so very thankful when past me took the time to craft such things. 90% of the time said unit tests & demo examples become boilerplate of copy pasta for getting stuff done.

@Vaillancourt Your 'turned corner text blocks' (annotations?) are a good example of what I should do more of.

It would be sweet if there was some sort of UML format that could be nicely diff'ed in a way the was visually meaningful &/or played nice with version control.

^ opportunity for the internet to tell me I've been coding under a rock for too long & ignoring obvious advances in the craft ;)

I know the diff tool we use can diff images; I think it overlays the newer image over the older

That sounds useful. Which revision system does it work with?

Ah, I meant the "review tool". We're using SmartBear's Collaborator.

@Pikalek

There is a slider that lets the user change the transparency of the "new" file.

Nice!

It looks like my system of choice did add support for something similar at some point.

Cool!

Yeah. I suspect that file size may still be an issue, but space is relatively cheap. Thanks for pointing me toward it!

@Pikalek the software calls those "notes"

In my ECS, the AI behaviour is kind of stored as functions and state in a Component. It's not exactly "data"...

I need to search more about it to see if it's an appropriate way to do. (I know it is because "it works", but I wonder what other alternatives are in use.)

Put the functions in an array and store the index of the function in the component. There, you have pure data 🤡

Yeah, that's the philosophy, although I'm using behaviour trees; nodes of the trees are stateless, the state is stored in the component (essentially)

The "code" is technically stored along the "Systems", although the instances are stored in the components. /shrug