Never say never but I think it's unlikely. Our motivation was to restore pinball to Windows (with modern updates) so every Windows user could enjoy it. Any other form of distribution wouldn't have the same coverage or impact. It would have been great to not only please the fans of the old game but to introduce a new generation to pinball just as Space Cadet once did.
> I'd be bold to ask why would you even need their blessing to release an updated or new version
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.
> Would you ever consider going back to the drawing board in an attempt to produce an official follow-up to Space Cadet Pinball?
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.
I looked at it today and it is more fleshed out but still incorrect. For example:
> 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 was CEO of Cinematronics (to be clear, we were a tiny startup so a CEO title didn't mean much - everyone pitched in wherever they could help.)
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 one of the original authors of Space Cadet Pinball and I just want to say it is absolutely wonderful there are people who love our old pinball game enough to keep it alive. You made my day.
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.
"We've uploaded a fruit fly. We took the @FlyWireNews connectome of the fruit fly brain, applied a simple neuron model (@Philip_Shiu Nature 2024) and used it to control a MuJoCo physics-simulated body, closing the loop from neural activation to action."
Scaling from a small-format store with limited item selection (where the tech worked well) to a large grocery format would come with many challenges. A previous comment touches on a couple of them:
I don't know how the store clerk staffing changed over time but they were not directly involved with the underlying tech (that is, clerks did not annotate data.) Stores had to comply with state laws for certain kinds of items (e.g., a live person must verify ID and age for alcohol) so the store automation had the ability to summon a clerk when needed. And there were the usual things all stores must do: restocking, cleaning, safety, and customer relations. I expected customer relations to decrease over time as people became accustomed to the just-walk-out shopping experience.
The first iteration of the tech reached the accuracy needed to support just-walk-out for a small-format store. It did achieve that goal. I left the project before it went further.
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.
I don't have insight into what ultimately transpired at Amazon Go so take the following as speculation on my part.
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.
I left the following comment some months ago, duplicating it here:
[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.
It's a wonderful problem for optimizing code. Michael Abrash hosted a performance contest for word counting back in... 1991? (If my memory serves.) The article and code can be found here:
There Ain’t No Such Thing as the Fastest Code:
Lessons Learned in the Pursuit of the Ultimate Word Counter
[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.
I don't think you're missing anything. Years ago, I made the same observation, and ran a test to compare independent hash functions vs salting. It showed no difference. I would be interested if someone here has a different opinion and a rationale to explain what I might have missed.
This memory goes back almost thirty years. In 1993, most products still shipped on floppy disks, and costs were increasing as products grew in size. Shrinking a popular product by even one disk could save over a million dollars. Publishers were using data compression but the tools were of the same class that were intended for regular users. That is, compression and decompression required roughly similar compute resources. I noted a few things:
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.)