Hacker News Reader

Comment by duxup | Hacker News Reader

I 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 think I figured out how to explain it:

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.

I like the aesthetic, but 16:9 and 90s computing together is just wrong.

The back breaking not quite square trinitron monsters were the best.

I chose 320 x 180 because of Animal Well. In fact, the whole app was originally conceived as a way for me to make an Animal Well style game, but more conveniently than using Pico8 (Billy Basso implied once that he used Pico8 to prototype Animal Well before moving to C++). I still think 320 x 180 is the right size for both games and game makers.

For example, here's a very early (mostly broken) prototype of 90s.dev

https://90s.dev/v1/

Because of 320x180, it can fit the code editor and the mapmaker or spritemaker on the screen at once, and each tab is big enough to be usable.

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.

Show examples of things built with it?

So far, only the built-in apps are made with it.

You can click them on the desktop-thing when you open the app.

So far the only finished app is fontmaker: https://90s.dev/os/#sys/apps/fontmaker.app.js

Their source code for all built-in apps are in https://90s.dev/os/helloworld.zip (found on https://90s.dev/getting-started/download-sdk.html)

It really is. It’s almost harder than building the thing. Every time I try explaining my side project, I end up just saying “you know…it’s easier if I just show you”

Yep, that's why I decided to make the pages able to have interactive demos. Though only the hello world tour and the refs guide use it so far.

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 with examples.

Thanks, I'll definitely consider using that in the next launch.

Is 320x180 generally enough for anything interesting?

Animal Well uses 320 x 180

https://en.wikipedia.org/wiki/Animal_Well

(In fact I partly made this app so I could make an Animal Well clone.)

I'll check it out.

Would it technically be possible, without too much difficulty, to increase 320 x 180? Just wondering!

Technically it is possible right now. If you create usr/config.jsln (sample file is in sys/default/) and set its size, the screen automatically resizes to it.

I didn't document this because I'm not sure it's the right decision. Allowing screen resize does make it more flexible, but also leads to decision paralysis for most users, who 320 x 180 is probably perfectly sufficient for.

That was one of the genius moves of pico8, which tic80 failed to capture: offering the perfect set of orthogonal parameters for you, so you can just make stuff.

Oh, that is interesting. I think it could be worthwhile to document it for "advanced" or "power" users / developers perhaps, it is good to know that there is no such limitation, as I assumed there would be, meaning it is more flexible than I thought it to be!

You can't both honor a constraint and give an out for it.

Remember OG twitter and someone complained about the 140 character limit. Imagine the reply was "ok fine we'll let you use more than 128 characters, but you have to click an 'advanced' tab." instead of the "be clever" retort we really got from Jack Dorsey. Immediately there'd be no constraint at all, just an annoying step where you had to click an annoying checkbox.

Point being - if the design is intended to be constrained, then it's perfectly reasonable to own that.

I think your example is different, because we are talking about something that would be only my code, should it not be up to me? And even if it was not feasible right now, someone else would write the code to make it possible, for their own project. Twitter is not your product, you are only using it. And it is also possible to do it, so why not document it? That makes no sense. That is akin to security through obscurity.

Also he said "but also leads to decision paralysis for most users", but it does not have to be the case. Default can be whatever you want.

I think you're both right. It's tricky to know when to make something a default and when to make it a constant. Especially when it comes to users, who cannot all be pleased.

I think it would just kill flexibility, making it the default makes more sense to me, and you should leave it up to the developers using your product, but it is entirely up to you, of course. If I were to turn this into a constant, I would document it at the very least in the git commit message.

I think a fun solution to this, and the one I adopted, is to leave these power features in here as easter eggs, so that devs are rewarded for finding them. At least for me, it gives me a sense of the fun and excitement of learning GUI dev during the 90s. The screen resizing functionality can be found by anyone who digs into the code a little.

That sounds fair to me!

Keep going, you'll get there. Yeah, explaining is hard.

As someone who is not involved in game development I admit I didn't really understand your description about it being an API but not a game engine. But keep going, you're doing a great thing here.

Reply on news.ycombinator.com