I'm very fond of this idea of a fantasy console, and I'm enjoying Pico 8 a lot. Every so often, I think, gee, I'd like one with fewer constraints.
But then something dawned on me: There must be a point beyond which, if constraints are relaxed too far, the point of being a fantasy console evaporates and you may as well be simply using a more generic game framework.
I imagine this has been discussed many times before. But it explains to me why we will probably not see an extremely large proliferation of fantasy console software, the reason being that it is the constraints that make it unique as a console. If we make something as powerful as say protected mode DOS and make it a fantasy console, users may as well either use Dosbox or just write a game with a modern game framework, because the constraints are so relaxed relatively speaking. The craft of fitting a game idea into constraints is gone.
I'm aware of Liko 12 and PixelVision 8 and TIC-80 and so forth. The point of my discussion here is just a thought experiment about how much folks would value something that's a lot more powerful---where at that point there's really no need to have it be a console.
I really like PICO-8 because of both the restrictions and the well-integrated tools.
It's not just a platform for retro games, there's no shortage of that, it really is a fantasy console.
And it's a fantasy console that harkens back to a very particular time in computing history. A point in time where even a child could pick up coding in an weekend, but it was possible to make amazing things.
A fantasy 286 or something wouldn't have the same magic to me. The complexity would go up dramatically, and using it would start to feel too much like work.
... but at the same time PICO-8 manages to integrate some modern touches that keep the spirit of the 8-bit era but eliminate frustrations of that era. LUA instead of BASIC, for example.
Lexaloffle has done an amazing job isolating the essence of what made the 8-bit era a golden age of people having fun while coding, but also not getting bogged down in pointless realism.
Yeah! I think it's fun that they force everything to capital letters with the Lua integration and that Lua actually has one or two, vague similarities to BASIC such as IF .... THEN. Obviously the rest of it is not too similar. But the lack of syntactical ceremony makes it similar to BASIC, and I imagine very approachable by beginners. It's kinda like Python (I'm new to Lua), I think.
There's a lot to love in Pico-8, but at this point, I think it's ultimate strength is that the community has hit a critical mass. This will make it very, very hard for any other console to catch up. Pico-8 has so many games to enjoy and learn from. There have been some zine issues, some podcasts, even a book in progress! I think any other product similar enough to scratch the itch that Pico-8 scratches would be too similar for the majority of people to bother switching over.
The "feature" of Pico-8 that stands out to me, and what I always point out when preaching to others, is how quick you can get started and see a result.
You don't have to setup folders or assets or libraries or anything like that. You just start programming and you get an immediate result. That direct (manual) programming can be a hurdle, I suppose, but it's a lot easier to explain (and copy from snippets) than it is watching a 20-minute video on how to setup your environment.
That quick feedback is a huge reason I keep coming back to make games. I can get into actually making my game very quickly...which is a huge sell when showing people too.
Computing had lost that simplicity! Back when people had an Apple 2 or a Vic-20, they could start coding about three seconds after turning on their machine.
The problem is, those machines were terrible.
Somehow Pico-8 gives us the simplicity, but not the terribleness.
I love the feels, But am also torn about what extensions, Whether to our LUA toolkit or the restrictions themselves, Would do to our beloved console and then had an idea..
Looking at older systems in the physical world, Sometimes the carts themselves or parts of the hardware had mods that could be done or special roms or cpus added to the cartridges or expansion modules that would increase the functionality, Some would take advantages of tweaks in the hardware that were undocumented, Others would lower or remove one feature of the system and free up resources for a hardware sound or graphics trick..
Still other developers themselves found tricks in the hardware to pull off uncanny feats of software wizardry or tweaks with the code.
We already have tweaks and clever wizards about the Pico-8 community, But what if we had those people in ADDITION to the option of picking one or two 'expansions' when booting up a cartridge?
Extra 'ram' for your tiles or maps or sprites.. Maybe a graphics 'hack' that would use the map or other space to pull off more 'colors' sort of like the existing software 'flicker' trick?
This way Pico-8 could still be a unique fantasy console and yet offer expansions without ruining it by being too 'open'.
EDIT: In software terms, Think of people using the extended LUA toolkit to write 'expansion roms' sort of like DLL libraries.
EDITEDIT: Think third-party modules for the C64 and AMIGA you'd see in magazines from clever hardware people making expansions in their garages. X3
The problem there is that checkboxes in a configuration utility are free, unlike real real after-market hardware. There's little reason for anyone not to use the full possible feature set.
It's, like... PSP emulators offer a CPU overclock, which mostly works because the clock rate wasn't a constant on a PSP and so emulating cycle-for-cycle doesn't lock you down like it would on a C64 emulator. So everyone turns on the overclock, because... why wouldn't you? :)
The only time such a limit would work well for pico-8 is in a jam/compo where there were specified requirements for entering, just like we've done for 140-character source code in tweetjams.
@Felice This is why you limit the expansions as well as the amount of them active. If it weren't attractive to people as an option, The.. COUGH.. Other vc's out there wouldn't also have the option to impose limits themselves.
Either way, There are other options I mentioned that had rl counterparts that would disable one feature entirely to double the output of another.
Just some ideas that would satisfy both crowds, Not to mention people who aren't up to designing a full game could thereby develop 'technologies'' that other people could use n' pass around just as you would the carts themselves.
Edit: For instance you might build a ridiculously complex dungeon-building engine with autotile function and end up using 90% of your tokens.. A dungeon engine on a 'rom' would lessen the data use but still allow the creator to focus on their game and assets.
I suppose that's true, but I'm not sure we're talking about the same kinds of add-ons, so we're probably talking at cross-purposes then.
BTW for a rather interesting take on limited resources as an actual gameplay gimmick, I recommend taking a look at NieR: Automata. It wasn't the best game, honestly, but I quite liked how they handled upgrades and how the system actually blurred the lines between game and gamer.
Log in to post a comment