In my experience this just makes them lose confidence in you and the company. So when it eventually is right, they're resistant. Worst case you lose the contract.
One floppy holds 176KB per side. One full screen of bitmap graphics is 8KB+1KB color, but the game fills only about 2/3 of the screen, so lets say 6KB w/o any compression.
I don't think it's a problem. The game is static enough I think it'd even be viable to hide most loading time even from a real floppy w/behind animation (e.g. slow down door opening and a fade long enough for a decent fast loader to load 6KB)
On my screen that doesn't match videos of actual C64's on actual CRT's. (It also doesn't match my memory of them, but that's a whole lot less reliable)
Videos of actual C64's on actual CRT's are pretty consistent other than brightness, though, so if it doesn't at least somewhat match those, the model is broken.
The large scenes looks like about 4 screens wide? But they're not full height - looks like about 2/3, so let's say ~24KB total including color data. I don't think it should be a problem. The walk + scroll is slow enough that if you had to (and I don't think you do) you ought to be able to time things so you can load the next screen while the player is walking.
Similarly, e.g. slow down the door animation, and a fade, and you ought to have enough time for a decent fast loader to load the next screen (~2-3 seconds assuming you're loading 2/3 of the screen)
You really benefit from the low amount of action on screen here.
If you want to actually compress the data to reduce the number of floppies, you'd slow it down quite a bit. If you were doing it for a real C64 or cartridges constrained to what was viable at the time, that might well be preferable to more floppies. If you're doing it for a modern cartridge or an emulator, it won't matter.
For a game like that, while I agree with the Amiga version looks good, frankly the Amiga port still feels like a good example of why there were lots of complaints about "lazy" ports for the Amiga that didn't take proper advantage of what it could do.
For a relatively static display like that EHB would've not been a problem, and the amount of gradual changes would've made it easy to exploit in the palette. Using the copper to modify the palette a few places would've also allowed for more, and switching to 640x200 below the graphics to make the text smoother would've been outright trivial. Even HAM might've been reasonably feasible.
If it is fast enough, and cheap enough, people would very happily reroll specific subsets of decisions until happy, and then lock that down. And specify in more details the corner cases that it doesn't get just how you want it.
People metaphorically do that all the time when designing rooms, in the form of endless browsing of magazines or Tik Tok or similar to find something they like instead of starting from first principles and designing exactly what they want, because usually they don't know exactly what they want.
A lot of the time we'd be happier with a spec at the end of the process than at the beginning. A spec that ensures the current understanding of what is intentional vs. what is an accident we haven't addressed yet is nailed down would be valuable. Locking it all down at the start, on the other hand, is often impossible and/or inadvisable.
Agreed; often you don’t know quite what you want until you’ve seen it.
Spec is an overloaded term in software :) because there are design specs (the plan, alternatives considered etc) and engineering style specs (imagine creating a document with enough detail that someone overseas could write your documentation from it while you’re building it)
Those need distinct names or we are all at risk of talking past each other :)
"brief" also has a similar meaning in English, in (several) alternative meanings of "brief" to mean a precis, summary, position paper of various kinds. Both are derived from latin breve/brevis - "short".
You'll find variants with one or other of those meanings all derived from latin in a number of other languages too, e.g. "brev" in Norwegian (letter).
I think the automation makes a significant difference though. I'm building a tool that is self-improving, and I use "building" for a reason: I've written about 5 lines of it, to recover from early failures. Other than that, I've been reviewing and approving plans that the system has executed itself. Increasingly I'm not even doing that. Instead I'm writing requirements, reviewing high level specs, let the system generate its own work items and test plans, execute them, verify the test plan was followed. Sometimes I don't even read past the headline of the plan.
I've read a reasonable proportion of the code. Not everything is how I'd like it to be, but regularly I'll tell the system to generate a refactoring plan (with no details, that's up to the agent to figure out), and it does, and they are systematically actually improving the quality.
We're not quite there yet, but I plan to build more systems with it that I have no intention of writing code for.
This might sound like "just" vibe coding. But the difference to me is that there are extensive test plans, and a wide range of guard rails, a system that rewards gradually refining hard requirements that are validated.
reply