One thing that is missing is most Pico-8 consoles focus on the play aspect of Pico-8, not the creation aspect of Pico-8 which is just as important to me if not more so. The TLDW of the talk is that he explicitly tried to built a "cozy" game development environment with enough constraints in place to encourage creativity without the stress of starting from a completely blank canvas.Īt the end Scott Hanselman has a footnote about building or buying a physical Pico-8 console. I'm a huge Pico-8 fan and suggest that anyone that is interested in Pico-8 watch Joseph White's (the creator) Practice (NYU game designer conference) talk about the design philosophy of Pico-8. You could even choose encodings for the new ops such that they would look like NOPs to old GBA emulators, making PICO-16 "GBA+" ROMs gracefully degrade into regular GBA ROMs when run on a regular GBA emulator-very much like how Gameboy Color games work, or how SNES ROMhacks and homebrew support the MSU-1 audio chip.) Such an approach would come with the benefit that you could build a PICO-16 runtime by just starting with a GBA emulator and adding features. (Even if all it is, come to think of it, is the GBA's ARM7TDMI ISA extended with some more hardware registers and instructions, and a PICO-8-like IDE for building those "GBA+" ROMs. Everything!)Ī viable PICO-16 platform, to me, would have to offer a clear improvement over the "GBA homebrew in Rust" solution. In other words, for my needs, TIC-80 is still entirely dominated by just using to write GBA homebrew in Rust. I can't even build a Tamagotchi with this ) Sure, you can write more than 8K of Lua and the display resolution is a bit wider, but you don't get a dedicated DSP+sequencer for audio, multiple graphics layers with affine transforms/color math, SRAM(!), a real-time clock, etc. It's not really "less constrained" in any way that matters, though. Since I made the foolish decision to support 3D cores it's taken a while to get a renderer going, though, and I finally decided to speed things up by releasing with 2D first and adding more later. The fixed spec approach makes it harder to make each part really distinctive and not just another "tiles and sprites and chiptunes" doddle. "Diversity" has become one of those things: you will have some ability to swap out graphics and sound cores, and use a variety of programming languages. So with my own fantasy console I'm prioritizing other things beyond size/retro aesthetic, while still thinking about limitations. One of the things I found myself doing with PICO-8's setup was prematurely optimizing code for size, which presented a new kind of puzzle(how to express things in fewer Lua tokens) but didn't feel good in terms of authoring finished work(I made a nice 3D maze wireframe renderer - and then stopped there). If you have all the processing power in the world but only a 256x256 space to draw in and a limited number of commands to draw with, you still have an interesting constraint. I'm working on something like this, but as time has gone on I've made technical constraint less of a priority and focused more and more on the I/O and "bus" model itself, because that's where the ultimate bottlenecks lie. Maybe the "platform" could even come in a few separate "profiles", where games could be either targeted to a specific minimum profile, or could respec themselves to the highest profile supported (sort of like how Z-Machine games work in detecting the VM's multimedia capabilities.) Take it far enough and PICO-8 could just be the base PICO-16 profile! (They're actually usually as powerful as the original PSP, but only have the GPU capabilities of the GBA, making these consoles into a sort of unique alternate-history blend of 2001-2004 era gaming.)īut no games are being written directly for these devices, because they're all slightly-differently specced: different screen-sizes different amounts of RAM etc.Ī hypothetical PICO-16 "platform", in my mind, would basically be an abstraction over the cross-section of native capabilities of these devices (with maybe some additional tasteful constraints on top), while still allowing to take advantage of the full hardware in a way you can't by just e.g. There are tons of these little "retro console" devices lately-the Bittboy, LDK-game, etc.-that people just treat as emulation devices, when they actually have hidden potential for running native game software as well, with more power than you can get out of them through an emulator. resolution, sound channels) and reduced in others (e.g. I'd love a PICO-16: a fantasy console almost-but-not-quite like a GBA, extended in some ways (e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |