I love just blitzing oats, carrots, onions as a base and then throwing in anything else like kidney beans or courgettes. Makes great veggie burgers you can just cook in the oven. Takes no time at all and less effort to cook than a beefburger.
OP here. I posted an earlier version of PipeDream about month ago, I’ve just released v0.3.0 which attempts to improve visual-consistency.
PipeDream is a CLI utility that wraps the stdout of terminal games (like Frotz/Zork or Colossal Cave) and generates visualisations using the Gemini API.
The early version just generated isolated images, which felt disjointed. I built a state-aware navigator and an AI director that attempts to solve this by mapping out physical paths and cardinal directions. When you use the new --img2img flag, PipeDream uses the previous scene as a structural guide. If you walk North, the new room maintains the lighting, style, and architectural geometry of the previous room. It makes exploring feel a bit more cohesive than a slideshow.
I also added aggressive smart-caching. If you backtrack to a previously visited room, it bypasses the LLM entirely and loads the cached state, which keeps API costs down per session.
To try the built-in demo (API key required, free tier works fine):
pip install pipedream-fiction
export GEMINI_API_KEY=YOUR_GEMINI_API_KEY
pipedream-gui --img2img
If you want to try it with a real game, you can install Colossal Cave via uv tool install adventure and run pipedream-gui --img2img adventure.
You can find more examples of usage on the repo: [github.com/cpritch/pipedream]
I recommend running it with the --img2img flag enabled. It costs slightly more per generation, but the visual consistency is entirely worth it. I’d love to hear your thoughts, feedback or suggestions.
OP here. I built a simple CLI wrapper that pipes the stdout of text adventures into real-time image generation.
It uses a state-machine so the visuals stay somewhat consistent as you traverse. It's fully playable now but not validated against many games. It generally costs in the cents/pennies per session thanks to caching.
Sounds like you don't have a good process for handling scope changes. I should know, the place I'm at now it's lacklustre and it makes the job a lot harder.
Usually management backs off if they have a good understanding of the impact a change will make. I can only give a good estimate of impact if I have a solid grip on the current scope of work and deadlines. I've found management to be super reasonable when they actually understand the cost of a feature change.
When there's clear communication and management decides a change is important to the product then great, we have a clear timeline of scope drift and we can review if our team's ever pulled up on delays.
I feel like some people in this thread are talking about estimates and some are talking about deadlines. Of course we should be able to give estimates. No, they're probably not very accurate. In many industries it makes sense to do whatever necessary to meet the estimate which has become a deadline. While we could do that in software, there often isn't any ramifications of going a bit overtime and producing much more value. Obviously this doesn't apply to all software. Like gamedev, especially before digital distribution.
I think it's obvious that all software teams do some kind of estimates, because it's needed for prioritization. Giving out exact dates as estimates/deadlines is often completely unecessary.
The real problem is software teams being given deadlines without being consulted about any sort of estimates. "This needs to be done in 60 days." Then we begin trading features for time and the customer winds up getting a barely functioning MVP, just so we can say we made the deadline and fix all the problems in phase 2.
OK, so that sounds fine. Software delivers value to customers when it's better than nothing some of the time. Even if it barely functions then they're probably happier with having it than not, and may be willing to fund improvements.
Have you thought about leaning into some of the fintech space? They'd happily pay for the sorts of features they need to stream financial data (which is usually bazillions of data points) and graph it efficiently.
Off the top of my head, look into Order Book Heatmaps, 3D Volatility Surfaces, Footprint Charts/Volatility deltas. Integrating drawing tools like Fibonacci Retracements, Gann Fans etc. It would make it very attractive to people willing to pay.
No problem :) I asked a friend who's a bit closer to the space and he agrees, definitely Order Book Heatmaps. The speed you're getting would make this a killer feature.
Competitors typically have to snapshot/aggregate because their graphing libraries are heavily CPU bound. Being able visualise level 2/3 data without downsampling is a big win. Also being able to smoothly roll back through the last 12hrs of tick-level history would be really neat too.
I'd say the bare minimum feature set outside of that is going to be:
- Non linear X axis for gaps/sessions
- Crosshairs that snap to OHLC data
- Logarithmic scales, Candlesticks, Heikin-Ashi, and Volume profiles
- Getting the 'feel' nice so that you can quickly scale and drag (people are real sticklers for the feel of these tools)
- Solid callbacks for events for exchange integration, people hate leaving their charts to place an order eg (onOrderModify etc)
- Provide a nice websocket data ingestion pipeline
- Provide an api so devs can integrate their own indicators, some sort of 'layers' API or something.
Sorry if I can't be of more help as I'm just a hobbyist in this area!
hunter that's why your licensing is super important. If you don't lock it down you are doing free R&D for giant firms who have the money to make you, but will just rip you off if they can. I speak from extensive OSS experience. The feelgood of giving away wears off, make the right choices with regard to IP and you can capture the value you are creating for people who use it.
This is a really good point. Competitors in this space have a lot of resources so there's a tightrope to walk if you go the OSS core route. Any of these competitors could leverage your core and provide many more features than you could reasonably implement.
BSL/BUSL seems like a good fit for licensing here. It's technically source available instead of open source but just adds the layer that a competitor can't be built using your core. Otherwise the core is free to modify and fork. AGPL might be an option but I fear it would scare off a lot of companies in the space who have policies against AGPL licensed code but you'd get to keep advertising as OSS.
I'm sorry but this is factually incorrect and I'm not sure what experts you are referring to here about there being concensus on this topic. I would love know. Geoffrey Hinton, Demis Hassabis, and Yann LeCun all heavily disagree with what you claim.
I think you might be confusing creation ex nihilo with combinatorial synthesis which LLMs excel at. The proposed scenario is a fantastic testcase for exactly this. This doesn't cover verification of course but that's not the question here. The question is wether an already known valid postulate can be synthesized.
I've literally never gotten a promotion without taking on the additional responsibilities first. I wouldn't expect a promotion for just doing time at a company like a prison sentence. If they didn't promote me then I would have immediately moved on.
reply