Re:How I make graphics for retro systems and retro-styled games
by bitwize on Tuesday March 16, 2021 @04:09PM
(#26482157)
Nice!
I use GrafX2 and GIMP to make my game graphics, then when I want them munged into some exotic, export them to pnm or xpm and use some tool (often written in Guile) to do the munging of the source image.
There is also something to be said for in-engine asset generation. This especially works well for retro style games that run on powerful computers, it's probably less useful for actual retro games. For example, I'm developing a retro platformer mechanically based off of one you've all heard of (but with a new main character and premise). I thought it might be useful to have smooth rotations of character and other sprites for an advanced modern graphical effect... but a goal for me is to write the game as if it were the actual 90s, using C and Xlib, which doesn't offer a native image transform primitive. Then I realized... what if I were to precompute the rotated images on initialization, cache them in X pixmap atlases and use a simple XCopyArea to draw the rotated sprite when I need one, making it look like the engine is doing dynamic rotation (with enough precomputed rotations)? Ohohoho! Delightfully devilish, bitwize!
Another thing I've experimented and had great success with in another game of mine is something I call greeblization: procedurally generating interesting looking backgrounds from a few different tiles by having a few basic tile types that are the same mechanically but vary in appearance. A long narrow strip of "ground" tile types could become a bridge, for instance. So the level is a JSON file that describes blocks of a certain tile type, and the engine generates the tile map by filling in details with variants of the tile type for the block. I don't claim credit for this concept, however; the way ground tiles work when you place them in Super Mario Maker was an inspiration.
I use GrafX2 and GIMP to make my game graphics, then when I want them munged into some exotic, export them to pnm or xpm and use some tool (often written in Guile) to do the munging of the source image.
There is also something to be said for in-engine asset generation. This especially works well for retro style games that run on powerful computers, it's probably less useful for actual retro games. For example, I'm developing a retro platformer mechanically based off of one you've all heard of (but with a new main character and premise). I thought it might be useful to have smooth rotations of character and other sprites for an advanced modern graphical effect... but a goal for me is to write the game as if it were the actual 90s, using C and Xlib, which doesn't offer a native image transform primitive. Then I realized... what if I were to precompute the rotated images on initialization, cache them in X pixmap atlases and use a simple XCopyArea to draw the rotated sprite when I need one, making it look like the engine is doing dynamic rotation (with enough precomputed rotations)? Ohohoho! Delightfully devilish, bitwize!
Another thing I've experimented and had great success with in another game of mine is something I call greeblization: procedurally generating interesting looking backgrounds from a few different tiles by having a few basic tile types that are the same mechanically but vary in appearance. A long narrow strip of "ground" tile types could become a bridge, for instance. So the level is a JSON file that describes blocks of a certain tile type, and the engine generates the tile map by filling in details with variants of the tile type for the block. I don't claim credit for this concept, however; the way ground tiles work when you place them in Super Mario Maker was an inspiration.