working backwards: A 2D platformer game?...
(started writing a post, but not sure if this makes much sense as a post...).
currently, I have a 3D game (FPS style), but also a bit of a problem:
it kind of sucks, pretty bad;
I don't think anyone really cares.
I also have a few drawbacks:
not very good at 3D modeling;
I am worse at map-making (hence... why I ended up mostly using voxels...).
but, I can do 2D art "acceptably".
I was recently thinking of another possibility:
I instead do something "simpler" from a content-creation POV, like a platformer.
the core concept would be "basically rip-off something similar to the MegaMan games".
the next thought is how to structure the worlds.
I was initially thinking of using single giant PNG images for content creation, but ran into a problem: to represent the whole world as a single giant graphics image (with a 1:1 pixel density mapping with current monitors) would require basically absurdly large resolutions, and the graphics editor I am mostly using (Paint.NET) doesn't really behave well (it lags and stalls and uses GBs of RAM with a 65536 x 8192 image). note that it would probably need to be carved up by a tool prior in-game use (so that it can be streamed and fit more nicely in RAM).
another strategy would be basically to compromise, and maybe build the world as a collection of 1024x1024, 2048x2048, or 4096x4096 panels. each panel would then represent a given segment of the world, and is also a more manageable resolution.
if using 4096x4096 panels, it would probably still be needed to carve them up, mostly to avoid obvious stalls if demand-loading them.
the drawback: mostly having to deal with multiple panels in the graphics editor.
partly it has to do with world pixel density, as my estimates showed that a 16-meter tall visible area, with a close to 1:1 mapping to screen pixels (and a native resolution of 1680x1050 or 1920x1080), would use around 64 pixels per meter.
alternatives would be targeting 32 or 16 pixels/meter, but with the drawback of a lower relative resolution.
or, alternatively, using tiles instead of panels (but, for this, I would probably need to go write a tile-editor or similar, or use the trick of using pixel-colors for panel types). could consider "frames" to allow for larger items if needed.
if using tiles, 1 meter is most likely, or maybe 4 meters as a compromise between tiles and larger panels.
not sure if there are any standard practices here...
as for gameplay/logic, probably:
character walks left and right, can fire a gun, optionally with up/down aiming, and can also jump;
enemies will probably walk back and forth, fire projectiles if the player is seen, or other behaviors, probably with anim-loop driven logic.
unclear: if using a client/server architecture makes sense for a platformer, or if it is more sensible to do it with gameplay directly tied to rendering? (does anyone actually do network multiplayer in platformers?...)
more likely I could just start out by having partially disjoint render-entities and game-entities, with the option of switching over to client/server later if needed.
could consider this time writing the game-logic primarily in my script-language.
does still seem a bit like "more of the same...".
can't say if this will go anywhere.