I have an idea of the mechanic, and trying to find an approach to prototype it without spending month of developing tooling and engine just to realize it does not work. I am aware of the idea of Miminum Viable Product, but not sure how to approach it for NES.
My issue is that NES being limited hardware, and having limited software support. I can't really write bad and fast code, because don't have enough CPU, neither I can use sorting and big amount of variables for sates and collisions because I don't have enough RAM.
I want to have top-view game with 4-way scroll that I can theoretically put on cart. With structure of something like that
And I already have an issue of how should I store the data, and automatically load background and metadata. Cheap and fast way is just to have NxM arrays of background tiles, collision tiles, enemies etc, but it will obviously won't fit.
So now I start thinking about the of:
1. Storing maps (uncompressed nametables with ID, global x and global Y, because I didn't came up with a way to uncomress lines/columns without unpacking whole kilobyte of data into the ram)
2. Creating maps, as generic NES tools (like NESST) only cover 1 screen (probably just by hand, because trying to adapt "Tiled" editor to convert to what I need, will be even harder)
3. Storing collisions (probably parallel arrays of sorted x,y,type objects)
And all of this looks like a lot of work for a prototype (not saying as it shouldn't, as I am trying to develop for NES, and NES is not modern engine created to be easy).
My question is not about specific approach (although any hints/links would be appreciated), but more about how can one start developing the game and not burn out before seeing anything viable? What could or should be stripped off technically or nor in order to be able to progress?
My issue is that NES being limited hardware, and having limited software support. I can't really write bad and fast code, because don't have enough CPU, neither I can use sorting and big amount of variables for sates and collisions because I don't have enough RAM.
I want to have top-view game with 4-way scroll that I can theoretically put on cart. With structure of something like that
Code:
_
__| |_
| |
--|___|
__| |_
| |
--|___|
And I already have an issue of how should I store the data, and automatically load background and metadata. Cheap and fast way is just to have NxM arrays of background tiles, collision tiles, enemies etc, but it will obviously won't fit.
So now I start thinking about the of:
1. Storing maps (uncompressed nametables with ID, global x and global Y, because I didn't came up with a way to uncomress lines/columns without unpacking whole kilobyte of data into the ram)
2. Creating maps, as generic NES tools (like NESST) only cover 1 screen (probably just by hand, because trying to adapt "Tiled" editor to convert to what I need, will be even harder)
3. Storing collisions (probably parallel arrays of sorted x,y,type objects)
And all of this looks like a lot of work for a prototype (not saying as it shouldn't, as I am trying to develop for NES, and NES is not modern engine created to be easy).
My question is not about specific approach (although any hints/links would be appreciated), but more about how can one start developing the game and not burn out before seeing anything viable? What could or should be stripped off technically or nor in order to be able to progress?