![]() No editor graphics stored in the spritesheet, so entire area will be available to users.Export function for converting strings directly into binary data to store in spritesheet or map area.(2-3 bytes per object, with room for optimization via lookup tables) Variable-length encoding of objects for minimized level size.User definable object properties including size variability and repeating tile patterns.Support for levels up to 256 screens in size(!), with user-definable width and height.As merwok said, the people here should be capable of optimizing and adapting it for their needs, so I guess I don't have to plan for every possible use. I've pretty much finalized the feature set of the initial version of the editor, and simplified things with a more straightforward and open-ended system than I was trying for. My current build has more storage-efficient level formatting, is way easier to make levels for, and makes game interactivity much easier, but the basic idea is very straightforward. It only has a chunk of Level 1-1 which I repeated a few times because I had to code each object in by hand in hex, but it's capable of full levels. Here's a super-compact version of the core idea that takes just 135 tokens and (besides the data strings) uses fewer characters than a single tweet. With some trial and error I figured out how to make levels this way, with the map data area serving as a sort of scratchpad, or palette of objects that can be mapped wherever I want. I wondered if this could be used for individual objects in a level like trees and blocks. I actually got the core idea from watching a tutorial from Doc Robs on YouTube in which he used the map() function multiple times at once to make a scrolling background. ![]() I think my approach is simpler than others largely because I haven't learned to code using elaborate scripting and OOP, but very basic stuff (including tinkering a bit with actual BASIC). Hopefully people will like and use my editor once it's released, as I'd like to see more games that don't require devs to invent a new custom compression system or cut resolution or active screen area in half to fit much content on a cart. I know others have worked on metatile-type systems before, I just wanted to push things further with a really efficient system that lots of people can use. Thanks, (oh, and btw, I do really like your small Mario sprite =) This demo was built entirely in Pico-8, using an early version of my PicoMap system, the latest version of which you can find here: For example, all the level maps from the original Mega Man fit in less than 6KB. level could fit on the cart! By my estimates, This should be more than enough to store the worlds of many NES-era games, with space left over for the extra graphics and sound assets. This means that while leaving the majority of compressed data capacity and token count unused, 3 copies of every Super Mario Bros. ![]() ![]() Instead of storing the nearly-incompressible level data in strings, I instead store the spritesheet in a string because it compresses over 2:1, leaving a full 12KB of potential level storage space. The big thing is the last point on the list.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |