• Are games more robust than other kinds of end-user software? Why?

Not sure if this counts as “robust” — but I think games usually need to be “explainable” and easy(ish) to understand in a way that other software isn’t. The biz logic of some industry program can become complicated beyond the point of reason, as long as it still “works,” whereas a game, at some level, always has to make its logic known. Known to both devs and folks playing the game.

(also, love love love this line of questioning! learning to QA games I think totally changed the way I approached software design/dev/and testing — it influences a lot of what I do these days for work)

• Are games in 2023 more robust than games in 1980? Why?

Thinking of your second question — can you define a bit more what you mean by “robust?”

At first blush, I’m want to say “no, not really” — but I think I’m conflating “robust” and “resilient”

Modern games are rife with dependencies on external systems, beefy hardware, other folks, whereas games from the 80s got to be shipped “done.” No updates for a cartridge.

My MacBook laughtop starts acting weird if I don’t give it a weekly preventative reboot. Wasting my time and effort and destroying my carefully set up environment.

I consider myself to be completely ignorant of gaming and production of game software. But, I get the impression that gamers don’t experience an annoying UX.

If so, then FoC can learn something from game software design and development and production.

By “robust” I guess I mean anything that affects the UX. You’ve already stretched my knee-jerk thoughts about this.

What does “QA” of games mean in practice? Any other revelations about the development of games?

Observation: “Modern games are rife with dependencies...“. This seems to say that “more type checking” won’t help as much as “getting rid of dependencies” will. Does that mean rethinking of packages, package managers, make, the structure of software apps, etc, etc?

But, I get the impression that gamers don’t experience an annoying UX.

Alas, this isn’t true — many games are rife with bad UX. There are many reasons for this, but one of the biggest reasons I see for bad UX in games is when a game is ported from 1 system to another, and the input methods aren’t well considered. You see this especially for a lot of games that start out life on desktop, but that then move to consoles. The UI elements end up being filled with small text, and tiny touch targets that are difficult to find or navigate through using a controller.

…but this isn’t like every game by any means.

Something that I think many moderns games get “right” is how they lead a player through an even open-ended environment through well crafted spaces.

Lots of modern software can be difficult to navigate for the first time, and doesn’t always do heaps to suggest a way through — many games are able to lean on tools provided by classical art and expanded throughout art history to suggest a path through a space.

What does “QA” of games mean in practice? Any other revelations about the development of games?

Once upon a time, I used to approach QA tasks by strictly comparing some finished thing to the spec./requirements.

Sort of like deconstructing a finished cake by magically un-baking it, extracting all of the flour, sugar, eggs, milk and oil to ensure that the recipe was followed to the “T.”

Learning to QA games, I realized that everything is state . And that another approach is to not focus on the ridged bits of the program (what you built, and what is spec’d) but to focus instead on all the ways state flows through that thing you built…because state is what is often harder to control, and difficult to reason about.

I think Rich Hickey would say it is to be avoided, but in my experience state is unavoidable — what needs to be done instead of avoiding it is to realize you don’t always control it, and make sure your program can deal with totally unforeseen types of state

Observation: “Modern games are rife with dependencies...“. This seems to say that “more type checking” won’t help as much as “getting rid of dependencies” will. Does that mean rethinking of packages, package managers, make, the structure of software apps, etc, etc?

The dependencies are usually external from the programming systems. In the 1980s a game was a game was a game. When you loaded a cartridge into a nintendo it started what was on that cartridge and you were off.

Today, when you start a game many of them have to connect to a web service, or are thin clients to a thing running on a server somewhere, or exist in a world that is contingent on the actions of other player factions at the level of a “season.”

What I say “dependencies” in this context, i mean stuff like hardware and services, not so much other people’s code

Are games in 2023 more robust than games in 1980? Why?

Generally speaking I think not. As entertainment, the stakes tend to be lower. Add in the economics around how games are developed and sold and the immense complexity of modern AAA titles, and you wind up with an intensely challenging testing story.

Are games in 2023 more robust than games in 1980? Why?

Almost surely not. It's a matter of complexity and scale. The average Atari 8 bit home computer video game cartridge is 8k . That's not just 8k code, that's 8k code, assets, the whole enchilada. Compare and contrast with No Man's Sky which clocks in at 6 gigabytes! Admittedly the majority of this is assets, but I can only imagine the code size is quite a bit bigger than 8k.

How can a creature of such size and complexity possibly be more robust than < 8k of lovingly hand crafted 6502 assembler?

Are games more robust than other kinds of end-user software? Why?

Depends how you define robust? The potential actions that can be taken are planned in advance for a game. so if robust = no. of features / functionality then no. OTOH, the development process for games tends to focus on shipping a complete product rather than MVPs and continuous improvements in other software. So if robust = complete then yes.

Are games in 2023 more robust than games in 1980? Why?

This is harder to answer because there's such a big gap between indie and AAA in 2023. Modern progress and expectations have given game studios more opportunity to shoot themselves in the foot. I don't think that's a good enough argument for modern games being less robust. Hardware and tools are more robust than in 1980. Some of that, as performance always does, gets wasted and some of it goes into making better games.

Another thought for the second question is, I'm not sure to what degree 1980s game did not have bugs and glitches versus YouTube not being around to make them go viral. I imagine the total number is lower than today, but much higher than we'd guess.

There was no Youtube, but as someone who lived through that era I can assure you there was community 🙂 There were dial-up BBSes and messaging networks like FIDONet and WWIVNet so larger distributed communities were a thing, and we discussed all the games of the time down to the most minute detail! Even if we couldn't post streaming video showing each glitch.

I’ve had great experiences with codemirror. It allows you to describe a syntax with a package called Lezer. It can be a bit of a nut to crack but the creator is incredibly responsive.

Thanks for that, Greg. Hadn't heard of Lezer, so I will check it out. I've been playing with ProseMirror a little further, and it looks really promising. People have been working on automating generating ProseMirror configurations (partly) from XML schema documents, which is an enormous upside for me, so I'll probably dig deeper. Do you know if they are related to each other other than in name? The prosemirror system has a very syntax-centric method of configuring it, so it wouldn't totally surprise me.

Looks like it’s the same developer!

The above pattern is visible in other, older professions, such as building construction. Software might re-use these ideas and re-purpose them for creating electronic machines.

Note, too, that more-established professions use diagrams to augment the use of written words when communicating designs (blueprints, schematics, molecular diagrams, etc.).

do you think that software development has any actual similarities to construction in the arc of it's actual praxis when removed from business contexts?

By this question I mean: it seems that a lot of folks readily reach for architectural/engineering analogs when talking about software dev., but, when I think it through I struggle to see the actual similarities outside of how projects are run...and how projects are run, to my mind, has little to nothing to do with producing good outcomes and everything to do with leaning on known business processes.

What if a software team was run more like a kitchen, or software dev was thought of as being more akin to weaving at a loom?

Note, too, that more-established professions use elements that are completely isolated and decoupled from one another. This assumption (of inherent non-coupling) is violated by most popular programming languages.

I think this bit is true, but missing some nuance in that a lot of software that is developed isn't developed exclusively by programmers using programming languages -- there are designers using design tools, there may be researchers using various research methods, etc.

Those different roles tend to rely on elements that are wholly (or at least mostly) isolated and decoupled from one another.

Yes, I believe that software development should be like The Film Industry (or Construction, or ...)

But, I believe that software development - in its current form - cannot be easily stratified into layers. The wrong questions are being asked, emphasis is not being placed on layered processes and technologies.

Engineering processes were not created by business. Engineering processes were created by Engineering. Business capitalized on this structure, later.

” ... Those different roles tend to rely on elements that are wholly (or at least mostly) isolated and decoupled from one another. ...”

Software libraries, though, are not wholly isolated. This limits growth and prevents a Moore’s Law for Software from existing and prevents Christopher Alexander-like Patterns from being applied (easily).

I think the follow-up question is how to create these layers or different roles, rather than just that they should exist. Because your posts are more a question than an answer.

My first concern is that people will blur the boundaries between roles. For example, my day job is in deep learning and we have this somewhat defined separation that engineers build deep learning frameworks in C++ and then research scientists use them from Python. But too many people cross the boundaries where scientists need to change libraries that I'm not sure this separation was good for the field. As another example, front end engineers might contribute to designs and back end engineers might contribute to the architecture. So while these separations should probably exist, I would rather them be a soft separation rather than a hard one.

One part of my own work that might be relevant is this piece I call choice. The goal was to separate correctness from optimization and it can be used to separate say implementers and engineers from production engineering. But it also makes it easier to build layers that combine with greater possibilities. Do you see something like this as helping in creating some level of separation of layers or roles?

You've likely read this already, but Hillel Wayne wrote a good series titled Are We Really Engineers ? interviewing many engineers-who-became-programmers comparing the fields — though, upon glancing at it again, I thought he had discussed the layers that other professions have (i.e. architect, engineer, construction, etc.) and I don't see it. Still a good read.