3,480 karma · joined December 7, 2009
https://www.linkedin.com/in/davidwstafford
https://x.com/davidstafford
https://facebook.com/davidst
My Cinematronics co-founders and I do not own the rights to any of the games we created. Cinematronics was acquired by Maxis, and Maxis was later acquired by Electronic Arts (who are being acquired, as well.) The rights would have to be untangled which was, I suspect, part of the hesitation Microsoft had in moving forward.
We reached out to Microsoft a few years ago and offered to create a new version at no charge if they would restore it to Windows but they turned us down. There appeared to be no interest on their part.
Source: https://en.wikipedia.org/w/index.php?title=Full_Tilt!_Pinbal...
> In 1994, the company began development of a port of Doom.
No, we were never porting Doom and we used none of Doom's code or resources. And I didn't propose to tone down the violence. The game was intended to be a fun first-person shooter in the same spirit as Doom but that was the only connection.
Microsoft was involved in a high-profile antitrust suit with the Department of Justice at the time. They were understandably sensitive about the potential PR impact of this type of game shipping with Windows and proposed gameplay design changes to reduce the violence.
I negotiated the contract with Microsoft. My engineering contribution was not in the gameplay itself but in the game's memory manager and low-level rendering code. That was all performance-critical X86 assembly. I doubt any of that code lives on today.
Yes, there were a lot of anecdotes and the story on Wikipedia is both incomplete and incorrect in some ways. One day, I'll get around to editing it.
My memory is of promising it would be ready in time for Windows 95's launch, working excessively long hours, and focussing hard to make it fast enough so it would be fun to play on the minimum hardware requirement for Microsoft Plus.
I am forwarding this post to my Cinematronics co-founders and friends, Mike Sandige (lead engineer) and Kevin Gliner (designer and product manager). They will enjoy seeing this as much as I did.
Additional description here: https://x.com/michaelandregg/status/2030764512488677736
I imagined, at the time, future goals would be to scale store size and product variety while reducing the cost of the technology, but I have no insight into how that progressed. I am sorry to learn it's been shut down.
It is unlikely the tech would be frozen when an acceptable accuracy threshold is reached:
1. There is a strong incentive to reduce operational costs by simplifying the hardware infrastructure and improving the underlying vision tech to maintain acceptable accuracy. You can save money if you can reduce the number and quality of cameras, eliminate additional signal assistance from other inputs (e.g., shelves with load cells), and generally simplify overall system complexity.
2. There is business pressure to add product types and fixtures which almost always result in new customer behaviors. I mentioned coffee in my prior post. Consider what it would mean to add support for open-top produce bins and the challenge of complex customer rummaging. It would take a lot of high-quality annotated data and probably some entirely new algorithms, as well.
Both of those require maintaining a well-staffed annotation team working continuously for an extended time. And those were just the first two things that come to mind. There are likely more reasons that aren't immediately apparent.
[Disclaimer: Former Amazon employee and not involved with Go since 2016.]
I worked on the first iteration of Amazon Go in 2015/16 and can provide some context on the human oversight aspects.
The system incorporated human review in two primary capacities:
1. Low-confidence event resolution: A subset of customer interactions resulted in low-confidence classifications that were routed to human reviewers for verification. These events typically involved edge cases that were challenging for the automated systems to resolve definitively. The proportion of these events was expected to decrease over time as the models improved. This was my experience during my time with Go.
2. Training data generation: Human annotators played a significant role in labeling interactions for model training-- particularly when introducing new store fixtures or customer behaviors. For instance, when new equipment like coffee machines were added, the system would initially flag all related interactions for human annotation to build training datasets for those specific use cases. Of course, that results in a surge of humans needed for annotation while the data is collected.
Scaling from smaller grab-and-go formats to larger retail environments (Fresh, Whole Foods) would require expanded annotation efforts due to the increased complexity and variety of customer interactions in those settings.
This approach represents a fairly standard machine learning deployment pattern where human oversight serves both quality assurance and continuous improvement.
The news story is entertaining but it implies there was no working tech behind Amazon Go which just isn't true.
There Ain’t No Such Thing as the Fastest Code: Lessons Learned in the Pursuit of the Ultimate Word Counter
Article: https://www.phatcode.net/res/224/files/html/ch16/16-01.html
Code: https://www.phatcode.net/res/224/files/html/ch16/16-05.html
I worked on the first iteration of Amazon Go in 2015/16 and can provide some context on the human oversight aspects.
The system incorporated human review in two primary capacities:
1. Low-confidence event resolution: A subset of customer interactions resulted in low-confidence classifications that were routed to human reviewers for verification. These events typically involved edge cases that were challenging for the automated systems to resolve definitively. The proportion of these events was expected to decrease over time as the models improved. This was my experience during my time with Go.
2. Training data generation: Human annotators played a significant role in labeling interactions for model training-- particularly when introducing new store fixtures or customer behaviors. For instance, when new equipment like coffee machines were added, the system would initially flag all related interactions for human annotation to build training datasets for those specific use cases. Of course, that results in a surge of humans needed for annotation while the data is collected.
Scaling from smaller grab-and-go formats to larger retail environments (Fresh, Whole Foods) would require expanded annotation efforts due to the increased complexity and variety of customer interactions in those settings.
This approach represents a fairly standard machine learning deployment pattern where human oversight serves both quality assurance and continuous improvement.
The news story is entertaining but it implies there was no working tech behind Amazon Go which just isn't true.
Description: https://www.phatcode.net/res/224/files/html/ch18/18-01.html
Code: https://www.phatcode.net/res/224/files/html/ch18/18-03.html
Hashlife is far superior so while Qlife was interesting it wasn't the best implementation.
1. Software products would be compressed just once but decompressed millions of times.
2. It should be possible to create an asymmetric codec that expended tremendous resources on compression but still kept decompression light.
3. Publishers didn't care how much compute compression would require as long as it was still tractable and would save them money. If they had to buy an expensive computer and let it run overnight it would be fine.
I didn't know anything about compression at the time but the premise seemed strong. I took unpaid time off to tackle this problem and in a few months (after a lot of trial-and-error learning) I began to have a workable product.
Borland, Novell, and Microsoft (for the .CAB files) were the first licensees. The compressor was called Quantum and was typically 20-30% better than PkZip. My sales technique was to take a product, recompress it with Quantum, and show the company how much money they could save. (As I recall, I was able to demonstrate reducing Windows for Workgroups by two disks.)
Tanj Bennett created our original 8087 floating point emulator. It was real mode, 16-bit code, that kept an 80-bit float in five 16-bit CPU registers as a working value during its internal math calculations. If you ever coded for the PC you will appreciate just how precious register space was on the 8086/8088.
It's been a few decades and my memory is fuzzy but I don't recall any critical places where the registers had to be saved and restored. He choose math algorithms and code paths specifically to keep all five live at all times. Tanj's code flowed with an economy of motion that brought to mind the artistic performance of a professional dance troupe. I did not have the math skill and could not have ever created it as he had. It brought me genuine pleasure just to read his code.
Eventually, it came time to port it to 32-bits (real and protected modes.) I wrote new exception handlers and replaced the instruction-decode logic with a nice table-driven scheme but did not touch the core math library. It still ran in 16-bits under the hood exactly as Tanj designed it.
Tanj, if you happen to see this, I have fond memories of your emulator. It was beautiful.
We should think very carefully about adding a multiplication command because it introduces a failure mode that may be unanticipated by the client. Code that previously worked could begin to fail after this command goes into use.
Specifically, if the client needs to revert a series of operations on integers, and if the operations are transitive, there is no need for a mechanism to ensure they occur in any particular order (the usual caveat about working within the limits of precision applies.) This holds true for addition and for multiplication, in isolation, but is not true if they are combined. Change the order and the end result will change. Adding multiplication puts a burden on the client to understand this risk and be explicit in the ordering.
Some people may argue that the client should already understand it and they have a point. We can't defend against every possible misunderstanding. I think there is a good discussion to be had on this question and if the candidate were to go there, it would be a favorable sign of experience on their part.
Microsoft, if you're reading this, we would be glad to provide assistance in getting 3D Pinball running again on the latest Windows OS.
There were a couple of interviews with gaming magazines years ago. They would be hard to find today and didn't cover the topics you mentioned. Mike, Kevin, and I, really need to get together to tell the story some day.
You should post your code when you get a chance.