https://futureofcoding.org/ logo
Join Slack
Powered by
1. Are games more robust than other kinds of end-u...
# thinking-together
g
1. Are games more robust than other kinds of end-user software? Why? 2. Are games in 2023 more robust than games in 1980? Why?
e
1. 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)
1. 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.
g
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?
e
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
c
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?
i
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.
c
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.
6 Views
Open in Slack
PreviousNext
Powered by