4 ms·

The question is why not? On my free time I'm working on a monster rpg (something like pokemon). I also opted for a pixel look and a bitmap font. It has its c

by lampe3 5y ago

The question is why not? On my free time I'm working on a monster rpg (something like pokemon). I also opted for a pixel look and a bitmap font. It has its charm to work on this old style games. The graphics are simple and easy to understand and read for the player. Also something like pokemon gen 3 still looks good. Or SNES games like Terranigma, Secret of Evermore and so on. And even younger people like to play them.

boomboomsubban 5y ago
I can understand making a retro style game, most of the games I play look like they're from the SNES era. Why add the additional barrier to entry that is needing to set up an emulator or own the ancient hardware and a flash cartridge? The only benefit I see it adding is the developer may enjoy working through the hardware's limitations, but even then couldn't you arbitrarily set yourself comparable limitations?
- rtpg 5y ago
  While existing consoles basically program "like a PC", older hardware has different programming models that you might simply be more comfortable in. It's like its own game engine, not just "slower CPU" or "less colors" and "less memory".
- Drakim 5y ago
  One advantage is that your game can work on any device that can support an emulator. An electron app aint got nothing compared to the portability of a NES or Gameboy game. Secondly, simply imposing limitations on yourself is not the same as having real limitations from the hardware. With real limitations, I spend hours upon days upon weeks trying to figure out the most clever ways working around limitations to create crazy effects. It's feels like a real personal achievement for myself as a developer if I pull something off that should normally be considered impossible. Working around your own self-imposed limitations is just...lame and arbitrary.
  - wk_end 5y ago
    Plus, some limitations are impossible to correctly self-impose without just embracing the gestalt of the hardware. A few examples: Using the standard MBC1 mapper, the Game Boy can only address two 16KB chunks of ROM at a time (one “home bank” that’s always accessible and one swappable one), and figuring out how to work with that limitation cleanly is fundamental to the structure of your engine for larger productions. How can you reproduce that on a modern machine? Even if you committed to only accessing data in the original GB formats, in 16KB chunks, the code itself is never going to be the same size, and code faces the exact same restrictions. You’d need to self-impose the restriction of only writing GBZ80 code - at which point you’re developing for the real thing! Likewise, the GBZ80 processor has very limited addressing modes, even compared to many of its contemporaries; to compensate, a well-designed engine is going to focus on organizing data into 256 byte “pages” (because you can index them by manipulating a single byte of a pointer), focus on linear data (to take advantage of the auto-increment/decrement addressing modes), and avoid indexing that would require multiplication (i.e. prefer “structs of arrays” rather than “arrays of structs”). And if you do need indexable non-byte sized data, you of course would prefer data that’s power-of-two sized so you can do that multiplication using shifts, and ideally 16-byte sized so you can use the SWAP instruction to go from index to pointer in one cycle. Also, the Game Boy video hardware locks you out of VRAM while it’s drawing the screen - that is, almost all the time. Any VRAM updates need to run during Vblank or less commonly Hblank, usually in ridiculously tight interrupt handlers. Again, your engine needs to be organized around doing these updates as quickly as possible; consider that even something like drawing a fresh column of tiles to the screen is much harder than drawing a row (since you can’t use the CPU’s auto-increment addressing) and might be too slow if care isn’t taken. There’s no real way to reproduce this on a different system - all of the timing is off. Challenges like this are the “fun” of developing for the platform and can’t really be correctly captured without just developing for the platform.
- lampe3 5y ago
  You can make them game boy only but also compile to another target like windows or macos. It will just look strange full screen on a 27 inch display for example. You can also target phones were you upscale the img by 4 times or so and it becomes pretty playable. Also you don't have to stick to hardware limitations but you can. For some its fun. But you can also learn a lot about hardware programming because these old consoles like the game boy are pretty simple and 8-bit. So its also great for learning.
- mysterydip 5y ago
  I've been working off and on on a DOS game using the rise of the triad source and the tools of the time (map editor, deluxe paint, etc), as well as some conversion utilities I wrote myself to help with modern-to-ancient quality of life stuff. It's "missed nostalgia" for me: while I played games from that era at the time, I was oblivious to how professional gamedev worked at the time (most I did was QBasic). So it's like people doing blacksmithing or woodworking that isn't required anymore.
- duskwuff 5y ago
  > Why add the additional barrier to entry that is needing to set up an emulator or own the ancient hardware and a flash cartridge? Counterpoint: targeting your game to the SNES platform (for example) means it will run on any system with a functional SNES emulator -- including ones that don't exist yet! -- and is less likely to require maintenance as those systems evolve.
goblinux 5y ago
Have a blog or updates or anything for the game? I love me a good monster battle rpg

by lampe3 5y ago

boomboomsubban 5y ago

I can understand making a retro style game, most of the games I play look like they're from the SNES era. Why add the additional barrier to entry that is needing to set up an emulator or own the ancient hardware and a flash cartridge? The only benefit I see it adding is the developer may enjoy working through the hardware's limitations, but even then couldn't you arbitrarily set yourself comparable limitations?

rtpg 5y ago
While existing consoles basically program "like a PC", older hardware has different programming models that you might simply be more comfortable in. It's like its own game engine, not just "slower CPU" or "less colors" and "less memory".
Drakim 5y ago
One advantage is that your game can work on any device that can support an emulator. An electron app aint got nothing compared to the portability of a NES or Gameboy game. Secondly, simply imposing limitations on yourself is not the same as having real limitations from the hardware. With real limitations, I spend hours upon days upon weeks trying to figure out the most clever ways working around limitations to create crazy effects. It's feels like a real personal achievement for myself as a developer if I pull something off that should normally be considered impossible. Working around your own self-imposed limitations is just...lame and arbitrary.
- wk_end 5y ago
  Plus, some limitations are impossible to correctly self-impose without just embracing the gestalt of the hardware. A few examples: Using the standard MBC1 mapper, the Game Boy can only address two 16KB chunks of ROM at a time (one “home bank” that’s always accessible and one swappable one), and figuring out how to work with that limitation cleanly is fundamental to the structure of your engine for larger productions. How can you reproduce that on a modern machine? Even if you committed to only accessing data in the original GB formats, in 16KB chunks, the code itself is never going to be the same size, and code faces the exact same restrictions. You’d need to self-impose the restriction of only writing GBZ80 code - at which point you’re developing for the real thing! Likewise, the GBZ80 processor has very limited addressing modes, even compared to many of its contemporaries; to compensate, a well-designed engine is going to focus on organizing data into 256 byte “pages” (because you can index them by manipulating a single byte of a pointer), focus on linear data (to take advantage of the auto-increment/decrement addressing modes), and avoid indexing that would require multiplication (i.e. prefer “structs of arrays” rather than “arrays of structs”). And if you do need indexable non-byte sized data, you of course would prefer data that’s power-of-two sized so you can do that multiplication using shifts, and ideally 16-byte sized so you can use the SWAP instruction to go from index to pointer in one cycle. Also, the Game Boy video hardware locks you out of VRAM while it’s drawing the screen - that is, almost all the time. Any VRAM updates need to run during Vblank or less commonly Hblank, usually in ridiculously tight interrupt handlers. Again, your engine needs to be organized around doing these updates as quickly as possible; consider that even something like drawing a fresh column of tiles to the screen is much harder than drawing a row (since you can’t use the CPU’s auto-increment addressing) and might be too slow if care isn’t taken. There’s no real way to reproduce this on a different system - all of the timing is off. Challenges like this are the “fun” of developing for the platform and can’t really be correctly captured without just developing for the platform.
lampe3 5y ago
You can make them game boy only but also compile to another target like windows or macos. It will just look strange full screen on a 27 inch display for example. You can also target phones were you upscale the img by 4 times or so and it becomes pretty playable. Also you don't have to stick to hardware limitations but you can. For some its fun. But you can also learn a lot about hardware programming because these old consoles like the game boy are pretty simple and 8-bit. So its also great for learning.
mysterydip 5y ago
I've been working off and on on a DOS game using the rise of the triad source and the tools of the time (map editor, deluxe paint, etc), as well as some conversion utilities I wrote myself to help with modern-to-ancient quality of life stuff. It's "missed nostalgia" for me: while I played games from that era at the time, I was oblivious to how professional gamedev worked at the time (most I did was QBasic). So it's like people doing blacksmithing or woodworking that isn't required anymore.
duskwuff 5y ago
> Why add the additional barrier to entry that is needing to set up an emulator or own the ancient hardware and a flash cartridge? Counterpoint: targeting your game to the SNES platform (for example) means it will run on any system with a functional SNES emulator -- including ones that don't exist yet! -- and is less likely to require maintenance as those systems evolve.

goblinux 5y ago

Have a blog or updates or anything for the game? I love me a good monster battle rpg