Love it, and congrats on shipping! I might be missing something but your pitch would be a 10x better launch if I could find some basic demo games developed with the engine, unless I just didn't look in the right place. Looking forward to the next update!
Show HN: 90s.dev – Game maker that runs on the web
21–30 of 115 posts
Re: Show HN: 90s.dev – Game maker that runs on the web
#22I can't say I fully understand what this is / the capabilities, but man I love the aesthetic. It's interesting how an aesthetic can make an emotional impact and draw a lot more interest.
I basically wanted to make a much more usable pico8 for game prototyping. Hence the 320x180 design, and this prototype: https://90s.dev/v1/ But I also wanted the full convenience of VS Code, including full type checking and autocompletion support for TypeScript. So I designed it to be a platform that can be used to make and publish the things that pico8's tabs contain.
Now I see that I released this much too soon.
Re: Show HN: 90s.dev – Game maker that runs on the web
#23Thank you everyone for the feedback. It's clear that I launched this far too soon.
I'll work on the pain points you all noted, and come back in a few months.
Re: Show HN: 90s.dev – Game maker that runs on the web
#24Hi, author here. Thank you everyone for the feedback. It's clear that I launched this far too soon. I'll work on the pain points you all noted, and come back in a few months.
Definitely launch often.
10,000 iterations. One down. 9,999 more to go.
Re: Show HN: 90s.dev – Game maker that runs on the web
#25Earlier quoted context omitted.
Thanks! Explaining stuff is so hard! In fact, this entire article is just me trying to explain what this is in the shortest way possible. Maybe the shortest version is: 90s.dev is an API around a 320x180 web canvas, designed specifically for making games and game maker tools, with sharing capabilities built-in, and an innovative GUI for making game maker tools quickly and easily. No, that's still too vague. I give up…
I would put your text under "Welcome to 90s.dev." If possible, I would further simplify it. I took a stab at it below but I am no marketer (or a game maker), 90s.dev simplifies making games and tooling for game creators via: - an expressive API around a 320×180 web canvas, - built-in sharing capabilities, - an innovative GUI. Each bullet would link to a relevant part of the documentation. I think you also need a page…
Re: Show HN: 90s.dev – Game maker that runs on the web
#26Looking forward to your WC2 clone!
Re: Show HN: 90s.dev – Game maker that runs on the web
#27Hi, author here. Thank you everyone for the feedback. It's clear that I launched this far too soon. I'll work on the pain points you all noted, and come back in a few months.
Re: Show HN: 90s.dev – Game maker that runs on the web
#28Hi, author here. Thank you everyone for the feedback. It's clear that I launched this far too soon. I'll work on the pain points you all noted, and come back in a few months.
Re: Show HN: 90s.dev – Game maker that runs on the web
#29Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL? Looking forward to your WC2 clone!
Re: Show HN: 90s.dev – Game maker that runs on the web
#30Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL? Looking forward to your WC2 clone!
Actually I am planning on shifting it towards importing 'https://' URLs directly.
Honestly, the main difficulty I have is keeping full TypeScript support of remote modules. It's actually easier to do this if I import https:// modules directly, though it's not as convenient as it could be[1].
But I'm also trying to figure out whether I should continue to compile TSX to JS in the service worker[2], which requires no special dev-time setup and allows publishing raw .tsx files anywhere on the net such as github, or require users to compile TSX -> JS ahead of time, which would require a build step.
On top of that, I'm considering going further and making it so packages can import bare-specifiers like `import "somelib"` and publish a plugin to compile this into an https:// import specifier.
[1] https://stackoverflow.com/questions/79628025/is-there-a-way-...
[2] I currently use a service worker to map imports like `/os/fs/{ghb,npm}/...` to `jsdelivr.net/{gh,npm}/...` and compile them and return with the right content-type.