Does the NES homebrew scene suffer from Platfom-a-lotis too. From looking around it seems to me that there is a new kickstarter and oh look its another platform game where you walk through doors and collect the things?
What other game types would people be interested in?
Some nice Contra like run'n'gun would be great ~
Do you refer to eskimo bob? I think the door mechanic is really a "place where you're allowed to swap character" mechanic. That's pretty neat, i think.
FrankenGraphics wrote:
Do you refer to eskimo bob? I think the door mechanic is really a "place where you're allowed to swap character" mechanic. That's pretty neat, i think.
No title specificity just more a blanket observation of a trend... (a cross platform trend, the C64 scene also suffers from platform-a-lotis)
I love a good platformer as much as the next person
I see. I haven't noticed it, but it might be that straightforward platformers are easy to explain and sell. You can focus on the theme or identity in your salespitch, rather than getting 'nerdy' with mechanics, designs and elements. Compare with, say hypothetically, a stealth-based top-down cooperative escape game for two. It might bring more variety to the platform, but will it attract enough people?
I also got this impression, though I discounted it on me hating platformers and so them sticking out to my eyes.
Even the latest compo had 38% platformers, with the top 5 being entirely platformers.
Well,
Betelgeuse, aside for being the name of one of the biggest known stars is also a nice single screen Contra-like game.
I have to agree that there are a lot of platformers, but in my own an not-so-significant opinion that's fine.
It seems to be the easier way to tell a simple story and if well done, it just becomes great.
I can't complain, I love platformers.
But look how far the scene has come. Years ago, it was
single screen-osis.
One thing making platformers the flavor of the year for
Action 53 volume 3 is that a platformer fits easily in the technical requirements.
- Game size: 512 kbit
Platformers' level geometry constraints make it more practical to compress more gameplay into a smaller space without making maps as repetitive as those of the first Legend of Zelda. (If only Cat Quest hadn't been canceled...) In addition, side view allows storing only those cels needed for one facing direction. - Work RAM: Not available
In a platformer, a four- or eight-way scrolling engine and long-term memory of destroyed areas are less necessary. - Input: Standard NES controller
Simulations are more convenient with a mouse, and interactive fiction is more convenient with a keyboard, but platformers are more convenient with a controller. - Save type: Password
Platformers don't usually have a lot of state to save from one play session to the next. In an overhead adventure or RPG, you have to save things like cash in wallet, inventory, event flags, and experience. - Effort scale: Hobby, not day job
It takes time to draw animation cels. A side view game needs only one set of animation frames, not three or five sets, one for each facing direction.
Even games released outside the competition still feel some of these requirements. To make development practical, a game has to target the intersection of those features available in debugging emulators and those features available in reproduction cartridges that are affordable to manufacture. "
Intersection" means that if a feature isn't available in both, it can't be used. Last I checked, battery-backed WRAM was fairly expensive to add to a cartridge, prompting a
search for alternatives, and save to the first flash sectors (as in
RetroUSB's 4 Mbit oversize UxROM) wasn't in FCEUX. Has this changed since 2010 or thereabouts?
TmEE wrote:
Some nice Contra like run'n'gun would be great ~
Except:
- A run-and-gun game would still be a "platformer".
- Look at how detailed the animations in popular 1990s run-and-guns like Gunstar Heroes and Metal Slug are. I get the impression from Espozo and others that some of those would have trouble fitting in the Super NES, let alone the NES.
- And some people just aren't big fans of violence.
I'm not trying to throw shade on your preferences. I'm just trying to find the factors that led to the present situation.
We made a deliberate choice to target the NES rather than just making a PC game, whether due to nostalgia or other reasons, so those reasons probably affect the games we make. I wouldn't be surprised if people who came here after a childhood of playing famous games like Mario, Mega Man, Metroid, Contra and such ended up taking inspiration from those sorts of games.
tepples wrote:
Look at how detailed the animations in popular 1990s run-and-guns like Gunstar Heroes and Metal Slug are. I get the impression from Espozo and others that some of those would have trouble fitting in the Super NES, let alone the NES.
The cartridge sizes of the GBC era (up to 8MB) are enough to make room for tons and tons of animation frames. And if you went with today's 64GB SD cards, that's enough for 38 hours of 2bpp uncompressed video.
My much bigger gripe was how difficult it would be to fit everything in vram on the SNES, which is why I devised my idea of having every sprite have its own slot and identical sprites using the same slot for basically perfect space usage. However, you don't even have to deal with this on the NES.
I guess platformers are generally easy to pick up and play, without the need for manuals or complex strategies, so it's no surprise it's one of the most popular types of game.
Also, the NES is particularly well suited for this kind of game, with its blocky NT/AT design and limited number of sprites that basically requires them to be scattered around vertically.
Dwedit wrote:
tepples wrote:
[Detailed run-and-guns] would have trouble fitting in the Super NES, let alone the NES.
The cartridge sizes of the GBC era (up to 8MB) are enough to make room for tons and tons of animation frames.
By "trouble fitting", I was also referring to inability to fit "tons and tons of animation frames" across the bus to the PPU.
- CHR RAM loading slowdown
Tons of animation frames might get stuck in the PRG ROM because of limited bandwidth to the PPU. The NES can copy about eight tiles to the PPU per frame, plus OAM and whatever map updates are required for scrolling. Unlike the NES, the GBC has HDMA to CHR RAM at one tile per scanline. - CHR ROM juxtaposition lockout
You might work around lack of CHR RAM bandwidth by using CHR ROM instead. But tons of animation frames might get stuck in the CHR ROM because frames for four other objects being displayed are already switched into PPU $1000, $1400, $1800, and $1C00. Unlike the NES, the Neo Geo has more than 8 sprite tile number bits in each OAM entry and many more address lines for CHR ROM. - Sprite flicker
The NES allows sprites to cover 25% of a scanline. The PPU will refuse to touch tons of animation frames if other large sprites are in front of them. Unlike the NES, the GBC has 50% sprite coverage.
Animating many distinct, large, horizontally aligned sprites without flicker would require hardware compositing of tile data to the background CHR stream fed to the PPU. That'd be the NES counterpart to a SuperGrafx second VDC or a Super FX GSU. If you think such a compositor would fit in an affordable CPLD, I'd be interested to read your new topic explaining how. In addition, the developer would have to hire programmers who know, or train programmers in, several technologies: C++, FCEUX's code base, Verilog, the obsolete Xilinx IDE used to develop PowerPak mappers for daily play testing on hardware, and an up-to-date CPLD IDE used to develop the production mapper. This is probably far beyond "Effort scale: Hobby, not day job".
And a run-and-gun would still be...
a platformer!
Seems like just as many if not more non platformers upcoming.
;-------------------------
C64 platformers
;-------------------------
Sam's journey
Soulless II
Steel Ranger
Knight & Grail
Hyperion
;-------------------------
C64 non platformers
;-------------------------
Argus
Cruiser X-79
Citadel 2
Caren 2
Cilvilization
Galencia
Organism
Planet Golf
Crimson Twilight
Unkown Realm
Planet X2
tepples wrote:
And a run-and-gun would still be...a platformer!
Is Super Smash Bros also platformer?
Super Smash Bros. series are platform fighting games, as is
PlayStation All-Stars Battle Royale. The adventure mode of
Melee and "The Subspace Emissary" mode of
Brawl are platform beat-em-ups, as is
Cartoon Network Punch Time Explosion.
The Curse of Possum Hollow for NES is also a platform beat-em-up.
If
Mega Man is a platformer, then so is
Contra, as the biggest differences I can see between the two are multidirectional fire in the latter and a life bar and weapon acquisition from bosses in the former.
I don't think it's fair to call platforming a genre, in the same way game music or anime are poor genres for their corresponding media. Those are more like attributes. Game music can be done in a classical style, or reggae, or whatever else. A game that features platforming can have RPG elements, or a rhythm component, or shmup-like shooting and dodging features. To have to lock it in to one of those descriptors does a disservice to the game's diversity. However, from the start of different types of games following Pong, games have been categorized this way, so it's hard to represent a game in a short and sweet fashion without doing so.
Oziphantom wrote:
Does the NES homebrew scene suffer from Platfom-a-lotis too. From looking around it seems to me that there is a new kickstarter and oh look its another platform game where you walk through doors and collect the things?
Here's the NES games that I can remember crowd funding campaigns for:
- Eskimo Bob - Platformer
- Twin Dragons - Platformer
- Spook-O-Tron - Robotron
- The Banketh - Zelda
- Super Russian Roulette - Light Gun?
- Mystic Searches - Zelda
- Lizard - Platformer
So, yes if you're going by Kickstarter there's maybe an imbalance of platform games, slightly, but when you're talking about 7 games it's not a very good statistical sample. (Maybe there's also Dreamworld Pogie to add to this list, but I'm omitting it because the game was actually made in 1992.)
If you look at
RetroUSB's homebrew section or
InfiniteNESLives', there are a few platform games but there's a lot of other stuff in comparison. Same with the
Action 53 collections. I do think there's a slight bias toward platform games across the
NESDev Compo entries in aggregate.
I think there's a platformer bias on the NES as a whole, really. It might be a bias that applies to games in general, especially when using sprite graphics instead of 3D polygon projection. There's never been a shortage of platformers, on any system I can think of.
Oziphantom wrote:
What other game types would people be interested in?
If you're asking about the NESDev crowd, well really the question is what type of games are individual NES developers interested in. I don't think much else matters besides the individual person. These tend to be rather personal projects, based on what that person is interested in, not people at large.
Personally, I keep a list of ideas for games that I'd like to make. There's about 10 serious entries on this list, and I think 2 of them are platformers. When I had the means to start a project, the one I was most interested in happened to be a platformer, so that's what I'm making right now. I've got two other NES games I'd like to make if I can manage, and both of them would fit in other categories... so I mean, right now statistically it looks like I'm 100% interested in making platformers on the NES, but if I had a chance to make more games it would look more like 33% or 20%, eh?
tepples wrote:
If Mega Man is a platformer, then so is Contra
Except if you take out the gunfire in Contra, none of the platforming is remotely challenging? Does this look like a typical platformer level?
https://www.spriters-resource.com/fullview/33820/
I suppose it's a platformer if there's platforms and gravity? So green beret/rush n attack would be a platformer, although a very rudimentary one. You can't fall to your player characters' death (if you don't fall on a mine). Same with moon patrol (a bit more deadly, but very rudimentary).
Contra is a 3d room shooter
Something that gets on my nerves with homebrew NES games is the lack of moving platforms. How about some infinitely spawning platforms going up into a spiked ceiling, or going down into a spiked floor that you have to quickly dodge? Also, how about some power ups, instead of just coins.
About making a run'n'gun on the NES, the fact that the NES is limited in sprites onscreen makes it easier to animate them. Also, isn't there a mapper that lets 8x16 sprites use 512 CHR patterns while backgrounds use another set of 256?
psycopathicteen wrote:
isn't there a mapper that lets 8x16 sprites use 512 CHR patterns while backgrounds use another set of 256?
Yeah, MMC5 supports eight banks for sprites when they're 8x16.
Of course, then you have the normal 8x16 problem with consuming your very limited overdraw on sprites that aren't full-height.
Interactables overall are easily overlooked (probably because of map complexity?) What could happen when you step on/push/shoot/jump on/into a block? A lot.
lidnariq wrote:
psycopathicteen wrote:
isn't there a mapper that lets 8x16 sprites use 512 CHR patterns while backgrounds use another set of 256?
Yeah, MMC5 supports eight banks for sprites when they're 8x16.
Of course, then you have the normal 8x16 problem with consuming your very limited overdraw on sprites that aren't full-height.
I think that could be fixed by arranging the OAM a certain way that empty halves of sprites get dropped out. If you have a 8x16 sprite but only the top half is used, every sprite that exists on the same line as the bottom half can have priority over it.
I guess that's a SNES-ism? NES drops sprites left to right.
calima wrote:
I guess that's a SNES-ism? NES drops sprites left to right.
Wait? Then how do NES games alternate between what sprites get dropped out first?
NES drops out sprites from end of OAM first, by which I mean the first 8 matches from lowest-index sprite to highest-index sprite get shown and the rest don't.
I'm not sufficiently familiar with the SNES to explain exactly how this differs from the SNES.
psycopathicteen wrote:
calima wrote:
I guess that's a SNES-ism? NES drops sprites left to right.
Wait? Then how do NES games alternate between what sprites get dropped out first?
Not "left to right" in every sense but it's priority goes low index to high index. Sprite 0 has the highest priority and is never dropped, sprite 63 has the lowest and will get dropped out first on any line with more than 8 sprites. It doesn't matter where they are horizontally on the line.
NES games make them alternate with software that changes the order of the sprites as they appear in OAM. (I don't know how it's done on SNES.)
Edit: lidnariq was answering at the same time. Redundant again, I guess. :*
I don't think there's anything wrong with what psycopathicteen said about sprite priorities. If you follow the convention of leaving empty space at the bottom of the sprites, you can sort them so that sprites with higher Y coordinates have higher priority over sprites with lower Y coordinates, so that the empty spaces always lose the PPU's priority fight. This will impact the sprite cycling though, since you'll only be able to shuffle sprites horizontally. There's also the overhead of sorting by Y coordinate.
Quote:
I'm not sufficiently familiar with the SNES to explain exactly how this differs from the SNES.
SNES allows 32 sprites per line, and they can be much bigger sprites (up to 64x64)
You can also rotate priorities on SNES by simply changing the value at...I think...register 2102 every V-blank.
(With ...set bit 7 of $2103)
Edit: added details
And what do these registers do/control?
It sets an address in the OAM for the top priority sprite. The official document describes it. Page 2-20-2
dougeff wrote:
SNES allows 32 sprites per line, and they can be much bigger sprites (up to 64x64)
Yes, yes, "time over" and "range over", but that doesn't explain drop-out order, which was the entire question.
dougeff wrote:
The official document describes it. Page 2-20-2
Not interested enough to go looking for the information myself, I thought you had volunteered to explain the relevant details of SNES sprite priorities, since you replied to rainwarrior.
All he's talking about is that if you set a certain bit, you set any of the 128 sprites as the first sprite from front to back, but it always drops the front most sprites regardless of which sprite is set to be first. It's not really all that important because when it's not set, it acts like the NES's OAM only it drops the front instead of the rear most sprite.
Official doc says...
Write $80 to $2103
Write top priority object # (0-127) to bits d1-d7 of $2102
(That is sprite # << 1)....during v-blank.
Priority will wrap once they pass 127.
So, if you write (1 << 1) = 2 to 2103, the #1 sprite will have top priority, and the #2 next, then #3...and #0 sprite will have lowest priority.
Interesting that the SNES drops front most sprites rather than the back most ones. Does this have to do with the fact the SNES uses a line buffer to render sprites, so it has to draw them back to front to respect the layering, and when the time is up it's the front most ones that get axed since they're drawn last?
Anyway, what does "high priority" mean in SNES terms? On the NES, "high priority" means that the sprite has higher chances of being rendered (a high priority sprite is picked for drawing before a low priority one) AND that it's displayed in front of lower priority sprites. But if I understand what you're saying, "high priority" can't mean both these things in the SNES, right?
I think you're misunderstanding my example. Normally, sprite #0 would have top priority. That means it gets evaluated first.
Doing some voodoo with 2102 changes which sprite gets evaluated first.
tokumaru wrote:
"high priority" can't mean both these things in the SNES, right?
Yes. Sprites have two priority bits (I really wish one of these was another size bit...), along with each background tile having one. The order for each BG mode is here:
https://wiki.superfamicom.org/snes/show/BackgroundsI thought this except was odd:
wiki.superfamicom.org wrote:
FirstSprite ends up on top of all other sprites, regardless of the priority bits in OAM. FirstSprite+1 is on top of FirstSprite+2 is on top of FirstSprite+3 and so on until FirstSprite+127 (wrapping of course from sprite 127 to sprite 0). Note that only the priority of the topmost sprite is considered relative to the backgrounds. Thus, if FirstSprite+3 and FirstSprite+4 are identical except FirstSprite+3 has priority 0 and FirstSprite+4 has priority 3, they will both be hidden by any backgrounds that hide priority 0 sprites. This may seem counter-intuitive, since FirstSprite+4 would normally go in front of these BGs, but many games depend on this behavior.
From this forum...
https://www.smwcentral.net/?p=viewthread&t=23281Quote:
From what I've tested, sprite <-> sprite overlap depends on the OAM order.
The lower in the OAM table, the higher the sprite <-> sprite priority.
[Lower # sprites will show up in front]
The PP bits in YXPPCCCT don't seem to have any effect in sprite <-> sprite overlap at all. Their effect goes into layer <-> sprite. (And here, the order in OAM doesn't matter, again.)
The higher the value of the PP bits, the higher the priority of sprites over [BG] layers.
[Bracket = my addition]
Isn't it like that on the NES and Genesis where you can have conflicting sprite priorities. Heck, I wouldn't be surprised if the Sega Saturn is like that.
Quote:
CHR RAM loading slowdown
Tons of animation frames might get stuck in the PRG ROM because of limited bandwidth to the PPU. The NES can copy about eight tiles to the PPU per frame, plus OAM and whatever map updates are required for scrolling. Unlike the NES, the GBC has HDMA to CHR RAM at one tile per scanline.
16 tiles, if not much else in the PPU is happening. You could probably still use forced blank to get a little bit more.
So, to summarize, is this correct?
1. Sprites get layered in order according to a "first sprite" parameter, which can change per-scanline, lowest index on top. (Like NES but with a movable "index 0".)
2. If there are more than 32 sprites on a scanline, the highest index drops out first. (Like NES.)
3. Breaking the 32 sprites into 8-pixel wide slivers, if there are more than 34 slivers, slivers from the lowest indexed sprite will drop out first; within a single sprite its 1-8 slivers will drop out from right to left. (No equivalent on NES, because it only has 8-pixel wide sprites.)
4. After the visible sprite for a pixel is selected via steps 1-3, its priority bits are used to interleave it with the background layers. (Like NES but with more layers, e.g. you can use a lower index "background" priority sprite to mask off a "foreground" sprite.)
Edit: amended with information from below.
Some of this sounds wrong to me.
Quote:
Like NES but reverse?
Who said reverse? I think it is the same as NES. (?)
EDIT, psychopathic teen said it. I don't know then.
I wish bazz or byuu would chime in, but this topic isn't in in SNES DEV, so they probably won't read it. I really don't feel qualified to do any more than regurgitate tech. documents.
EDIT2 - reading further on...
https://wiki.superfamicom.org/snes/show/SpritesQuote:
1) Range: Starting with the FirstSprite, determine the first 32 sprites on this scanline. Only those sprites with -size < X < 256 are considered in Range. If there are more than 32 sprites on the scanline, set bit 6 of register $213e.
2) Time: Starting with the last sprite in Range, load up to 34 8x8 tiles (from left-to-right, after flipping). If there are more than 34 tiles in Range, set bit 7 of $213e. Only those tiles with -8 < X < 256 are counted.
So, my interpretation is...take the first 32 sprites (on that scanline) in order of priority... then, with that subset, in reverse order, get the LAST 34 8x8 tiles. So...it's complicated.
Ah! So there is a 32-sprite limit that works like the NES, and then a second limit of 34 8-pixel slivers which is the part that might seem "reversed"? (Edited my attempted summary.)
Edit, retracted. I think you have it right.
I would like to take this moment to award TmEE with a trophy of "stayed on topic and answered the question"
As to what is a platformer, for me, a platformer is a game where platforming makes up a large part of the experience.
So Green Beret/Rush'n'Attack is a run and gun.
Mario Bros is a platformer.
Super Smash Bros Brawl/Melee are fighting games, and the adventure mode is getting borderline between platformer and beat-em-up
In that you have Platfromers and games with platfoming elements
@Tepples "single screen-osis" love your work. see also Flip-Screenis although probably not an issue in NES land as you actually have char scroll in hardware
Often people also contract Collect-a-lot-us at the same time as Flip-Screenis
And yes I'm fully aware of the reason for said conditions ( hell, Qwak is a single screen platform game, Squid jump is a platformer, so I'm in the same boat ) and I'm not trying to call out or point out peoples failings because of said things.
What I'm trying to do is get people have a general roundatable discussion on musing of other types of games they would enjoy, for example
nesboy1 wrote:
I loved Eye of the Beholder and would like to see a new game in that style
or
nesweebYaoiGirl wrote:
JRPGS are the best, something cutsy like Kingdom hearts would feel right at home on the NES
or
hotGunner wrote:
I have a zapper that doesn't get used, I want to shoot me something, like maybe the shuriken bonus game in Shinobi only I fire with my gun
oziphantom : Switchs platforms to board the other trainDoes the SNES 32 sprites mean 32 sprites or 32 8x8 pieces of sprites?
On every scanline: 32 sprites ("range over"; the sprite evaluation only has space to remember 32 sprites) and 34 8-pixel wide pieces of sprites ("time over"; the PPU's data bus only has time to fetch 68 16-bit words per scanline)
I actually thought the original topic of this thread was very interesting! Especially considering how large a part of the NES/Famicom library was originally platformers in the first place. And probably an even larger percentage if you filter only the most popular titles on the platform.
The way I see things, "Platformer" part would mean only how you traverse stages, but that is usually not the objective of the game. You often have to collect stuff (sometimes a lot of stuff), occasionally you got to satisfy some conditions to pass the stage (some cases elaborate ones), and sometimes you just got to shoot around, and oftentimes such objectives are even combined. Of course there are many more types of objectives, but personally I am most fond of the whole shooting side of thing, with or without the platformer part
-----
Do the sprites on SNES that are further down the list appear on top of earlier ones or not ?
In case of MD the sprites are rendered in the order found in the list and earlier sprites appear on top of ones further down the list. Sprite pixel is put into linebuffer only if that particular pixel hasn't been written to yet, so you get the first on top rather than last on top (and it allows easy sprite overlap bit setting too). Dropout happens only for the last thing to be rendered.
psycopathicteen wrote:
Something that gets on my nerves with homebrew NES games is the lack of moving platforms.
Try
Haunted: Halloween '85. After getting through a particular section of the Neighborhood level, you'll be grateful that more homebrew games don't have tricky lift mazes.
Quote:
Also, isn't there a mapper that lets 8x16 sprites use 512 CHR patterns while backgrounds use another set of 256?
MMC5, but good luck replicating that on a CPLD.
Oziphantom wrote:
see also Flip-Screenis although probably not an issue in NES land as you actually have char scroll in hardware
But you can't have the left and right halves of the screen using different sets of 256 tiles without MMC2/4 or MMC5. (Again, good luck replicating that on a CPLD.) Nor can you have different sides using different sets of four palettes. CHR and palette conflicts are probably why
A Boy and His Blob and
Battle Kid are flip-screen. They're also why
Haunted: Halloween '85 has right side exits between level sections.
nesboy1 wrote:
I loved Eye of the Beholder and would like to see a new game in that style
How easy would it be for a 1- or 2-man hobby project to develop a new Product Identity (that is, fictional universe) around the d20 3rd or 5th edition mechanics? Does the
Open Game License even apply in a clear way to video games?
nesweebYaoiGirl wrote:
something cutsy like Kingdom hearts would feel right at home on the NES
I thought the appeal of
Kingdom Hearts was its crossover among over half a century of well-known Walt Disney Pictures fictional universes. What comparable fictional universes could a 1- or 2-man hobby project license or create?
hotGunner wrote:
I have a zapper that doesn't get used
It'll get used even less after your CRT dies. But if you have a CRT and want to use your Zapper for something not commonly done, try ZapPing (from
Action 53 volume 1). Grab a friend, plug in two Zappers, and avoid missing the ball.
Can we direct the comparison of various retro platforms' sprite capacity to
another topic?
With the MMC5 with 8x16 mode, you can probably flicker sprites when you need more than 8 banks at one time.
This General Stuff, not Nes Dev.
The point is not lets make a list of games 1 man and a dog could make?
This topic is water cooler, chew the fat, dream the dream...
A talk of what game styles people liked, that aren't platformers because those are covered
A shout out to Shoot-em fans, or RC Pro AM like Isometic racing games..
and TBH I'm not actually sure of the appeal of Kingdom Hearts 1 1.5 1.6 2 2.2 2.8 3.14159
tepples wrote:
nesboy1 wrote:
I loved Eye of the Beholder and would like to see a new game in that style
How easy would it be for a 1- or 2-man hobby project to develop a new Product Identity (that is, fictional universe) around the d20 3rd or 5th edition mechanics? Does the
Open Game License even apply in a clear way to video games?
The trick with RPGs isn't difficulty, it's content generation. So it's not a question of "how easy", it's a question of "how much time and dedication", and how much content do you want. (a "dumb" rpg with random mazes, no story or script, few monsters, few unique spells, etc, would be pretty easy for a small team)
Quote:
The point is not lets make a list of games 1 man and a dog could make?
This topic is water cooler, chew the fat, dream the dream...
I think in competitions you get more different types of games because single-screen games are just (usually) quicker and easier to make. But once you get beyond single-screen games, yeah, it seems like a lot of homebrew games are platformers. Maybe because they're fun to make? But also, like others have said, there's so much variety in types of platformers. A puzzle-style platformer (Eskimo bob) is very different from a jump/run game (like Nebs n Debs) or from a metroidvania/adventure. (Lizard? I dunno)
I'm still toying with the idea of making a NES sequel to my Anguna series (zelda-like), so that would be something. (although I've got another game, a platformer, in the works first, and I'm SLOW)
psycopathicteen wrote:
Something that gets on my nerves with homebrew NES games is the lack of moving platforms.
Nova the Squirrel has moving platforms too but I don't use them much. I am using the code I figured out for that for riding on top of certain projectiles though.
tepples wrote:
psycopathicteen wrote:
Also, isn't there a mapper that lets 8x16 sprites use 512 CHR patterns while backgrounds use another set of 256?
MMC5, but good luck replicating that on a CPLD.
Altera's 10m02 FPGA has over twice the number of logic elements as the PowerPak's FPGA (which has MMC5 implementations) and is
pretty cheap, so the only concern left is how pricey it is to translate the voltages.
Relevant Twitter thread.
A good way (i think) to indie an RPG would be to gather a few friends/family/colleagues/flatmates and do some improv pen and paper. Take notes or better yet, record everything. There are pen and paper games built to encourage and strengthen improvised narration, like the many "powered by the apocalypse" systems out there. They work well. Take that content, and reshape it to fit a homebrew.
Example: SyFy's tv show "the expanse", adapted from books, are in turn based on role playing sessions. I think an indie adventure or rpg can be a lot smaller than that and still feel satisfactory.
But there's still work to be done with practical content creation. It's one thing to muse plots around a table and another thing to draw baddies and monsters.
FrankenGraphics wrote:
A good way (i think) to indie an RPG would be to gather a few friends/family/colleagues/flatmates and do some improv pen and paper. Take notes or better yet, record everything. ... SyFy's tv show "the expanse", adapted from books, are in turn based on role playing sessions. I think an indie adventure or rpg can be a lot smaller than that and still feel satisfactory.
I have also play Dungeons&Dragons and GURPS game and then put into computer. You can do too if you like to do. I do try to record everything.
I don't know possibly computer game can use a few of these ideas too, but maybe is not everything.
Quote:
But there's still work to be done with practical content creation. It's one thing to muse plots around a table and another thing to draw baddies and monsters.
Drawing the pictures is more difficult I think. (It can be why making many computer game that do not have the pictures.)
psycopathicteen wrote:
Something that gets on my nerves with homebrew NES games is the lack of moving platforms.
In the last compo, more platformers had moving platforms than not. Twin Dragons, Lala, Cheril...
Then you should make (and release) moving platform platformers
My Clip notes on how to get a solid RPG with a 1/2 person team... Also given more fulltime or all out fulltime
1.) use 6502BDD to do all your I kill boss X which gives me Drop Y to let me do Z plot points
2.) use a 6502 simulator + Genetic Algortihm to run 1000s of battles and balance monster numbers/rates etc
3.) palette swap to the max
doing this should limit the amount of time spent on balance, code and leave you more time to make story and special effects. The game can be done with just place holder graphics and then you can farm out the designs etc, to people to get them done till you reach your ROM limit.
Speaking of balance, a good rule of thumb could be that without specific tactical input from a human player, the player characters should be statistically losing (over the course of several battles or just the one, depending on the tone of the game) in an area where monster and party levels match. This will help ensure that battles require the active attention of the player and keep them involved. The battle system should be built to support and reward involvement.
Encounters in which the party is significantly higher levels could be avoidable at the players' option (if random encounters are even used. I think it's a dated concept).
Oziphantom wrote:
My Clip notes on how to get a solid RPG with a 1/2 person team...
farm out the designs
"How to do it with a 2-person team: hire more people"?
Also, I think you meant
Cliff's Notes.
Myask wrote:
"How to do [a substantial RPG] with a 2-person team: hire more people"?
I fail to see how the market for NES games in 2017 would support a large paid team. The compo prize isn't big enough for more than a hobby project. And which authors of homebrew NES games sold on a single-game cartridge since 2010 have released sales figures?
Well you get the game done with 1/2 people and then when the game is done just needs blue square made look nicer, one could
optionally bring on more people to just pixel stuff
as its not in the "notes" section. A few people use old skool art as a fun thing to escape the tedium of their art jobs, but don't have time to make a full thing, if they just do 2~5 monsters with 1 ~ 4 frames each that is a nice little fun project that won't take them long, couple of nights, a weekend etc. Or having a complete game one could line up some pixel artists and hit kickstarter with it.
Never heard of Cliff Notes... Clip Notes to me means means a list of things you put on the Clipboard. Back in the day when we used them and would carry notes on them. One also might make some "clippings"
Cliff's Notes (usually with 's, though I see the company now goes by cliffsnotes) are study aids. It's a condensed version of a large book, used by people who don't want to read the big book, but want to get a good grade on a book report in school.
People sometimes say "give me the Cliff's notes version" when they want a shorter explanation.
Oziphantom wrote:
1.) use 6502BDD to do all your I kill boss X which gives me Drop Y to let me do Z plot points
What is 6502BDD?
tepples wrote:
Myask wrote:
"How to do [a substantial RPG] with a 2-person team: hire more people"?
I fail to see how the market for NES games in 2017 would support a large paid team.
That was my point.
Or instead of hiring twice the people, take twice the time. (assuming everyone on your team has the necessary skill sets). I mean, for most of us, this is a hobby. Who cares how long it takes if you're enjoying yourself.
gauauu wrote:
I mean, for most of us, this is a hobby. Who cares how long it takes if you're enjoying yourself.
Hobby means you need to feed yourself otherwise.
tepples wrote:
gauauu wrote:
I mean, for most of us, this is a hobby. Who cares how long it takes if you're enjoying yourself.
Hobby means you need to feed yourself otherwise.
Yes..... But I'm not sure how that's relevant.
For the vast majority of us for whom this is a hobby, we choose how much time to devote to it. For me, it's a small percentage of my time, which is why my games take years to write. But if I want a game with more content, I can spend more years. (Without increasing the percentage of time I spend per week)
What I do with the rest of my time (work, family, etc), and how I feed myself, is irrelevant.
zzo38 wrote:
Oziphantom wrote:
1.) use 6502BDD to do all your I kill boss X which gives me Drop Y to let me do Z plot points
What is 6502BDD?
BDD is Behaviour Driven Design, its a evolution of TDD ( Test Driven Design ). The idea is you test the actual desired behaviour, not the internal logic. 6502BDD is the system hooked up to a 6502 emulator. It uses the Gerkin script implementation of BDD.
For example, on Squid Jump, the platform collision logic is complex ( I was trying to see if I could squeeze it into 4K, and I need every clock I can get ) so I could easily brake it.
Code:
Feature: Test how Squid interacts with Platforms
Check squid against a bunch of platform types and make sure the right things happen
Scenario: Simple Solid
Given I have a simple overclocked 6502 system
And That does fail on BRK
And I load prg "squid.prg_test"
And I load labels "squid.acme"
And I load bin "testLevels\simpleCollision.bin" at LevelData
And Joystick 2 is NONE
When I execute the procedure at $810 for no more than 800000 instructions until PC = GFSM_Game
And I write memory at playerY with 158
And I continue executing until $403 = 150
Then I expect to see playerY less than 200
Then I expect to see playerY greater than 158
So this basically loads in my code, loads in the labels so I can reference things by label. Then I inject a test level, clear the joystick input, run the game set up which will plot the level etc for a while, then I move the player to 158, then I run the engine for 150 frames, then I make sure the player has hit the platform ( which is a little above the bottom of the screen), and I also make sure that the player fell under gravity.
Thus testing the player collides with a platform.
Then I have another one to test that a conveyer will a.) collide and b.) move the player to the right,
Code:
Scenario: Simple Convayer Right
Given I have a simple overclocked 6502 system
And That does fail on BRK
And I load prg "squid.prg_test"
And I load labels "squid.acme"
And I load bin "testLevels\simpleConRight.bin" at LevelData
And Joystick 2 is NONE
When I execute the procedure at $810 for no more than 100000 instructions until PC = GFSM_Game
And I write memory at playerY with 158
And I continue executing until $403 = 150
And I expect to see PlayerData_onGround equal 1
And I expect to see playerX greater than 154
And I expect to see playerY greater than 158
Then I also want to make sure that a player can't move right when on a normal platform
Code:
Scenario: Can't move when on a platform R
Given I have a simple overclocked 6502 system
And That does fail on BRK
And I load prg "squid.prg_test"
And I load labels "squid.acme"
And I load bin "testLevels\simpleCollision.bin" at LevelData
And Joystick 2 is NONE
When I execute the procedure at $810 for no more than 800000 instructions until PC = GFSM_Game
And I write memory at playerY with 158
And I write memory at playerX with 152
And I continue executing until $403 = 150
And I write memory at $403 with 0
And Joystick 2 is R
And I continue executing until $403 = 25
And I expect to see playerX equal 152
It takes about 12 seconds to run all my tests (the system is in JAVA ) but it lets me
code fearlessly
Oziphantom wrote:
For example, on Squid Jump, the platform collision logic is complex ( I was trying to see if I could squeeze it into 4K, and I need every clock I can get ) so I could easily brake it.
Wait... This?
Well not actually detecting if there is a platform or not, although there are char platforms, sprite platforms and pickups to detect, each with there own data structures to walk though. Its how the player has to react to said platforms, in that some will move them, some cause them to have a fixed momentum, some accelerate the player, some force you into a jump, which may or may not need to reset the jump counter. As I was tring to get it into 4K I was looking at making equations CanJump = OnPlatform OR (HasDoubleJump and NumJumps=1) OR (Not OnPlatform AND CanJumpTimer < 5) to keep the IF THEN cont down and squeeze out the bytes.These equations were very brittle. So to control the Physics FSM each platform needs to set the right flags, but to keep code down any shared settings are grouped into a single function, but I would change the settings which would work for 3 but then the 4th would need the flag not set etc. BDD6502 would find such cases in seconds.
I'm going to be judgmental and say you've added a lot of complexity to your little 4k game by adding all of that.
You've also added complexity to your description of it.
Well its not a 4K game, its a 16K game I was trying to cut down to 4K, so yeah complexity was increased by me going for extreme optimisations. Doing it the normal way and its not very hard at all.
why do all of your scenarios start with this?
Code:
Given I have a simple overclocked 6502 system
And That does fail on BRK
pubby wrote:
I'm going to be judgmental and say you've added a lot of complexity to your little 4k game by adding all of that.
You've also added complexity to your description of it.
I'm thinking that the idea is actually to reduce complexity, by writing
more generic subroutines?
My own 4KB game does this, with a single subroutine for updating every "object" used in the game. (player/monsters/items)
The code is small, cycle-efficient, and only omits bullets, that instead use crude angle calculations.
mikejmoffitt wrote:
why do all of your scenarios start with this?
Code:
Given I have a simple overclocked 6502 system
And That does fail on BRK
I would assume that this has to do with the fact that the 6507 (a feature-cut 6502), has no interrupts. (No pins for NMI/IRQ)
Espozo wrote:
Oziphantom wrote:
For example, on Squid Jump, the platform collision logic is complex ( I was trying to see if I could squeeze it into 4K, and I need every clock I can get ) so I could easily brake it.
Wait... This?
What the heck system is that? I counted about 40 tiles accross.
Wait nevermind, I looked it up and its a minigame in Splatoon.
psycopathicteen wrote:
What the heck system is that? I counted about 40 tiles accross.
C64
The screen is 320 pixels so 320/8 = 40 chars/tiles
psycopathicteen wrote:
Wait nevermind, I looked it up and its a minigame in Splatoon.
I mean, it originally was. However, it looks noticeably different (for some reason, I couldn't find any native resolution images, but the Wii U Gamepad's 854x480 resolution is stupid anyway):
OmegaMax wrote:
The screen is 320 pixels so 320/8 = 40 chars/tiles
Yeah, he must have not been thinking there... I would make a list if there weren't 10's (probably over 100 including arcade boards) that used this resolution.
I see that a video was made for this demo:
https://www.youtube.com/watch?v=TfQGcfEFOJk (this is the original Wii U version if anyone is curious:
https://www.youtube.com/watch?v=sb0uezlTpxA)
I don't mean to be a jerk, but was the change in physics due to the reduced code size, because you couldn't figure out how to get the physics right regardless of size, or do you just not see anything wrong with it? You appear to hang in midair for a second in the C64 version.
mikejmoffitt wrote:
why do all of your scenarios start with this?
Code:
Given I have a simple overclocked 6502 system
And That does fail on BRK
1.) because I'm too lazy/stupid to remember the Background: clause which would allow me to do it once per file.
2.) because the 6502 part of the BDD is implemented on top of BDD, and my Java is not good enough to understand how to subclass it into a new jar file that I can then tell the BDD engine to use instead of the normal 6502BDD, and I would rather just copy-paste it than deal with Java.
3.) The original Java 6502 emulator used by 6502BDD did its best to run at 1Mhz for Accuracy, to which I made a mod. So you have
Given I have a simple 6502 system and
Given I have a simple overclocked 6502 system. Ideally I would also add a complex 6502 with VIC-II, or complex 6502 with CIA 1 that emulate various logic features. There is also another type of 6502 system build in with the emulator that has 6445( 48? I think it, something like that ) text CRT controller chip
4.) BRK is a standard 6502 opcode and hence it is from an emulators point of view, safe to do. However in 99.9% of cases you don't want to BRK and since RAM is filled with 00 in the emulator if I get a wrong index into my "On X" code then it will end up in BRK land, to which the emulator will just happily enter a infinite BRK loop. So I have this to say as soon as it happens, stop.
Alp wrote:
pubby wrote:
I'm going to be judgmental and say you've added a lot of complexity to your little 4k game by adding all of that.
You've also added complexity to your description of it.
I'm thinking that the idea is actually to reduce complexity, by writing
more generic subroutines?
My own 4KB game does this, with a single subroutine for updating every "object" used in the game. (player/monsters/items)
The code is small, cycle-efficient, and only omits bullets, that instead use crude angle calculations.
When you compress inline actually saves you memory, is some cases. as
JSR Thing <- 3 bytes
JSR Thing <- 3 bytes
Thing
RTS <- 1 byte
If you inline you save the 2 JSRs and the RTS, to which the compressor will notice the duplication and generally store it in less bytes. I've also done really backwards things like
LDX #4
STA Thing,x
STA Thing+4,x
STA Thing+8,x
STA Thing+16,x
because
STA Thing,x
STA Thing+4,x
STA Thing+8,x
STA Thing+16,x
is used a lot else where, so it compresses smaller than doing it the "right" way.
In this particular case the collision/physics FSM is utterly unique to the Squid player and the logic routines are basically unique or in that annoying unique where they are just one byte different here or there.
Alp wrote:
mikejmoffitt wrote:
why do all of your scenarios start with this?
Code:
Given I have a simple overclocked 6502 system
And That does fail on BRK
I would assume that this has to do with the fact that the 6507 (a feature-cut 6502), has no interrupts. (No pins for NMI/IRQ)
6507? VCS? I'm writing code for a 6510.
Espozo wrote:
psycopathicteen wrote:
Wait nevermind, I looked it up and its a minigame in Splatoon.
I mean, it originally was. However, it looks noticeably different (for some reason, I couldn't find any native resolution images, but the Wii U Gamepad's 854x480 resolution is stupid anyway):
OmegaMax wrote:
The screen is 320 pixels so 320/8 = 40 chars/tiles
Yeah, he must have not been thinking there... I would make a list if there weren't 10's (probably over 100 including arcade boards) that used this resolution.
I see that a video was made for this demo:
https://www.youtube.com/watch?v=TfQGcfEFOJk (this is the original Wii U version if anyone is curious:
https://www.youtube.com/watch?v=sb0uezlTpxA)
I don't mean to be a jerk, but was the change in physics due to the reduced code size, because you couldn't figure out how to get the physics right regardless of size, or do you just not see anything wrong with it? You appear to hang in midair for a second in the C64 version.
Indeed it is 320x200 from a Commodore 64.
Player controls are usually balanced at the mid way to the end depending on the game. So at the start I wanted to see the rough cost of doing the parabolic movement, but I didn't want to make it hard to play, I want to be able to zoom around and test quickly. Hence why you can do those little hops, good for testing the ends of a platform and getting your self in position. The "hover" also makes it really easy to land on anything you want, keeping my engine testing and speed test iteration speed high.
In other games you have other things to tweak to adjust the game play, enemy patterns, number of enemies, time limits, firing speed. Squid jump the game is basically judging how far you need to jump and how far the animating sprite is telling you are going to jump. So the levels,player movements and player animation speeds need to be designed and tweaked hand in hand. Since the "stolen" "crack" that video was made from, the player controls have progressed to having a "physicsy" FSM with a concept of momentum, i.e you slide off the ice platform and you don't just sink like a rock
If you land on the conveyor belts of the opposite direction, you keep sliding in your original direction and slow down before getting thrust the opposite way.
If you made this a c128 game,you could release this with entirely different handling,physics and this would be their reaction.
Trying to swing back to topic:
I've read that some versions of Contra had pits, such as the NES version, and others didn't. Wikipedia's article states that the pits near the end of stage 1 aren't in the arcade version. Because addition of pits pushes it more toward platformer, perhaps this difference is part of the confusion about the extent to which run-and-gun overlaps platformers. People who grew up with Contra for NES consider the run-and-gun genre to incorporate those platforming elements seen in Contra for NES, whereas those who grew up with Contra arcade and Metal Slug might not.
I don't think so. The main difference between the arcade and NES versions of Contra (aside from improved controls in the latter) is that the NES version is much longer with every stage expanded, where in the arcade version they merely servered as simple gauntlets taking you to the next boss battle. Several individual stages on the NES were just different parts of a single stage on arcade. On the other hand, the over-the-shoulder "3D" stages were much bigger in the arcade, built sort of like little mazes.
Of course that also results in more actual platforming in the NES version, but the arcade definitely had platforming - including the iconic vertically scrolling stage which has you constantly jumping up from platform to platform. Even if no other stage has bottomless pits, there are platforms aplenty.
The much more simple explanation (Occam's Razor, really) for why people identify Contra as a platformer is because of the control scheme, which is simply straight up classic platform controls. And the same goes for Metal Slug, for that matter, and most other run'n'gun games in that vein.
I don't have a problem classifying Contra as a platform game for this reason, but if that's the only term you're using, most people will of course think of the classic Mario-style platformer focused almost entirely on platforming. If you talk about "run 'n gun" people will be more likely to know what you're talking about. Except that term also tends to cover the classic top-down Ikari Warriors/Commando style shooters. Genres are fun like that.
There are also plenty of games that are much more "borderline", too. Games like Ghosts 'n Goblins and Castlevania are definitely platform games too, and very far from the Contra style run 'n gun formula. But again they are much more action and combat focused than your typical cutesy Mario platformer. I think the fact that the platform game concept allows so much variation is exactly why it's not a bad thing that we are seeing a lot of them made.
...as long as you're not one of those people calling every game a "sidescroller" :3
Espozo wrote:
OmegaMax wrote:
The screen is 320 pixels so 320/8 = 40 chars/tiles
Yeah, he must have not been thinking there... I would make a list if there weren't 10's (probably over 100 including arcade boards) that used this resolution.
My first impression was that it looks like an NES game, but then I noticed it looks a little too widescreen for an NES game. Then I counted the tiles, and I got 40 so I was thinking it must be a Sega Genesis game. But, then I saw talk about 6502 ASM and I was confused by it.
Something that threw me off was the fact that most C64 games run at 160x200.
If you don't think Metal Slug counts as a platformer, look at how many "platforms" are in the first stage.
http://www.vgmaps.com/Atlas/Neo-Geo/Met ... ssion1.png
Contra/Gyrzor is probably near the borderline. Were Rush'n'Attack is run'n'gun while something like Mega Man is platformer. There is no clean cut, its all sliding scales, with various levels of game play elements being combined. Where each of us draws the line will differ. Then you end up with some complete mash-ups like ActRaiser or Henry Hatworths...
Henry Hatsworth is just two completely separate games, both implemented extremely poorly, mashed into one. I like the idea, but I would probably have preferred just one of the two games done right.
Maybe another way to look at it is what gives the game difficulty.
So Contra you basically die from a bullet or from falling done some stupid pit, which makes it 50/50
Mega man you basically die from some platform disappearing from you or some enemy you can't kill on a platform
Metal Slug bullet to the head
Mario because you hit a thing, missed a jump, fell down a pit, platformer