This is just a curiosity rather than a project, but I figure this would be a great place to get input from programmers on the feasibility. That and it could sort of be seen as a response to Tepples' comment about 'if I have an idea for an NES game, write up a design document and share it', but this contains no ideas, rather a question.
As the title might imply, this thread will basically ask if it would be at all possible to create the best NES game the hardware can allow, and the best game a programmer's own limits allow. Most games released for the NES during it's heyday were made by a team of professionals, usually an average of 6 people. Some games were made by bigger teams (most commonly Nintendo's own games), some games were made with tiny teams (Battle City was allegedly ported by three people), and some games were made by one person (Super Turrican). Additionally, some games did not receive a great budget, and some games were made without any approval or pay from the publisher, such as Mega Man 2. So obviously, the 'best' game would not be entirely possible by one person, much less one who isn't being paid anything. Rather, a team of hobbyist programmers would be needed, and they would need to be paid. This leads us to the first two questions of my post; what is the ideal size of a development team, and how big would the budget be? This just covers the development, advertising would be another question entirely.
Secondly (even though it's the third question, I know), would the NES' hardware pose a limit in how 'good' a game could be? The most commonly cited flaw of the NES would be the scanline limit of 8 sprites, with the NES' relative lack of horsepower being a close second; you can only do so much without extreme flicker or slowdown, and a game is not enjoyable if either of those problems are incredibly persistent. There are tricks that could be done to hide flicker as much as possible, such as making a vertically oriented game (IE Star Soldier) as opposed to a horizontally oriented game (IE Gradius) to prevent the chances of sprites occupying the same scanline(s), in turn preventing flicker. On a related note, I've made a topic addressing why slowdown was so common on the NES, and I've learned that it could be possible to optimize the programming in such a way to make it near nonexistent.
Should this game push any technical innovations, or should it just be 'another' game that's rather derivative? Some people have commented that Shovel Knight has animations that are 'too smooth' for an NES game, when the NES has had a few games (Moon Crystal) that had very fluid animations. Should this hypothetical game push the aging hardware (or create proprietary cartridge hardware) even more than professionals have been able to, assuming there's anywhere left to go?
Finally, how can this game be marketed? I've noticed that some faux-retro games feature appearances from celebrity composers, possibly to get fans of their work to buy said game. But I think that wouldn't be helpful, especially since this is (primarily) targeted at a VERY niche market. That and it adds a huge price tag to the overall budget. I was also thinking that this game could be given to certain YouTube celebrities such as the AVGN or Game Grumps to bring this game's attention to the mainstream public, increasing sales potential. Of course, the NES game will be targeting a niche market, so I was thinking about also releasing a version for a digital distribution service such as Steam or Nintendo's eShop, which will further increase sales and revenue. Speaking of the devil, would Nintendo have any objections to a plan like this? I've read that they weren't exactly accepting of Grand Theftendo, as it was once C&D. When it became Retro City Rampage, Nintendo only offered him a license to publish the game in exchange of him removing his NES development documentation. Would there be any way to bribe Nintendo, such as by buying a 'license' from them, or would we have to avoid them entirely? If the latter, would there be any legal issues regarding a game, made for Nintendo hardware, being available on competitor's stores?
As you might've guessed, I don't have the money, but if I did I would fund it. So this thread could be used for future reference, if anyone crazy enough was willing to invest almost a million dollars for a miniature return for such a trivial concept. Thank you for reading, and I hope this sparks some interesting discussion.
Quote:
what is the ideal size of a development team, and how big would the budget be?
There is no ideal development team size. There is just advantages and inconvenients.
The advantage of a team of 1 person is that there is no communication problems or fight between members of the team, and there is no risk of having an important member leave on anger. However, if the sole member is uninspired, he cannot count on anyone else to help him with ideas, and if he looses interest in the project for a while, the project is frozen. It also takes longer to develop the project.
As for the budget, this makes no sense, since we're hobbyist we're doing this for free by definition. However, you will have to pay for the material to build the games (cases, PCB, ROMs, ROM programmer, artist to design labels etc...) and this, in low quantity, certainly costs high enough to make a single game pak cost largely enough. If you want to pay the programmers for their effort, this will make the cost too high and not enough will buy the game.
Of course I'm assuming no profit in all cases.
Quote:
Secondly (even though it's the third question, I know), would the NES' hardware pose a limit in how 'good' a game could be?
Simple answer - it does not. You can make games as amazing as imaginable on the NES.
Quote:
Should this game push any technical innovations, or should it just be 'another' game that's rather derivative?
What game are you talking about ?
In all cases, the hardware has almost no correlation with how good a game is. For example, those Koei simulator sucks pretty much, but they use the MMC5, the best mapper made by Nintendo. However, there is amazing games with just use NROM (no mapper). However, there is also amazing games that uses advanced mapper, and shitty game that uses no mappers. There is really no correlation in my opinion, all cases are possible.
You seem to be trying to approach this as making a game about the NES platform. I don't know if this is a useful approach. The NES, like most computers, is very general purpose and can be programmed to do just about anything. Its limitations aren't much of a guide to the form of a game, at least not on the high level. There's not enough there to suggest a form.
When you get to lower level decisions, the platform you're one certainly does have a say, for instance, as I make my game, the 4-palette limitation is having a huge influence on what creatures I put together, or what tiles I can use in a room. The NES is certainly shaping the details of my game as I run against its limitations, but the high level design has almost nothing to do with the NES. Sure, it helps to go in with an idea of how the platform works and what it can do, but I really doubt it will be the source of inspiration for a great game.
Gimmick isn't about the NES, it's about platform jumping, star riding, responsive enemies, secret rooms, etc.
Startropics is about grid-based action, finding invisible switches, a repeating rhythm of exploration-dungeon-boss, a tropical island theme, etc.
These games were made for the NES, but on a high level the same ideas could have worked on any game platform (well, maybe not the Magnavox Odyssey).
rainwarrior wrote:
The NES, like most computers, is very general purpose and can be programmed to do just about anything. Its limitations aren't much of a guide to the form of a game, at least not on the high level. There's not enough there to suggest a form.
Other than the lack of graphics hardware that would support exploration of a large world with the ability to see both up close and far away. That use case really needs a behind-the-player or first-person view. That and the fact that player 2 is very limited, with no Select or Start on the majority of Japanese units, no left-and-right scroll split, and usually not enough video memory for a top-and-bottom scroll split with a status bar between 4-way-scrolling areas.
Quote:
as I make my game, the 4-palette limitation is having a huge influence on what creatures I put together, or what tiles I can use in a room.
The 4-color limit is why
Dr. Mario and
Tetris 2 have three species. Lack of a 4-color limit on Game Gear is part of why Sega managed to score
Columns instead of a Nintendo licensee.
rainwarrior wrote:
Its limitations aren't much of a guide to the form of a game, at least not on the high level. There's not enough there to suggest a form.
Well, actually I guess you could say
Attribute Zone is a game based on the NES/Famicom PPU; there the limitations are precisely what suggests the form (and "high-level design") of the game.
Yes there are such thing as
Dr.Mario having only three colors, and yes the other thing can also be making various suggestions. If you think eight sprites per scanline is not enough for making a horizontal fighting game, you can try making a vertical fighting game, for example.
If you do like to sell a game, it is not necessary to sell (only) on a cartridge; you can make the cartridge and also DVD and so on (which could include emulator, and if you are on an unusual system you can provide your own emulation).
Bregalad wrote:
In all cases, the hardware has almost no correlation with how good a game is. For example, those Koei simulator sucks pretty much, but they use the MMC5, the best mapper made by Nintendo. However, there is amazing games with just use NROM (no mapper). However, there is also amazing games that uses advanced mapper, and shitty game that uses no mappers. There is really no correlation in my opinion, all cases are possible.
I agree; use whatever mapper feature you like. But remember that use of simpler mappers will simplify implementation (both software and hardware implementations; hardware implementation will in addition be less expensive).
zzo38 wrote:
If you think eight sprites per scanline is not enough for making a horizontal fighting game, you can try making a vertical fighting game, for example.
Or sacrificing part of the background and drawing one of the fighters using background tiles. The Sega Master System has the exact same sprite limitations of the NES (64 sprites total, 8 per scanline), and games like Street Fighter or Mortal Kombat draw the fighters entirely on the background, but since each tile can have 16 colors instead of just 4, those games can get away with simplifying the backgrounds instead of completely eliminating them.
I believe that you should keep the overall limitations of the target platform while designing a game, but only think of precise implementation details later. You will probably have to make some compromises, but that happens during the development of any game. Some planned features are always abandoned/modified during the development of any game, so it's perfectly normal that this happens with the NES as well.
tepples wrote:
Other than the lack of graphics hardware that would support exploration of a large world with the ability to see both up close and far away. That use case really needs a behind-the-player or first-person view. That and the fact that player 2 is very limited, with no Select or Start on the majority of Japanese units, no left-and-right scroll split, and usually not enough video memory for a top-and-bottom scroll split with a status bar between 4-way-scrolling areas.
The 4-color limit is why Dr. Mario and Tetris 2 have three species. Lack of a 4-color limit on Game Gear is part of why Sega managed to score Columns instead of a Nintendo licensee.
There is a large list of things that the NES is not very good at doing. Some of these things are merely hard (e.g. 2 player), and some are more or less impossible (horizontal split screen), but in the space of what's possible I don't think it offers much constraint at all to suggest a high level form. If I said "make a game, but you can't use the colour red", would this be a stimulating source of ideas for games? What if I just said "you can use red, but it will be difficult"? This is kind of what this line of inquiry looks like to me.
If you want two players, it can be done. The NES' limitations will have a huge impact on how you implement it speficially, but on a high level it's not off the table.
Columns' play field is 6 x 16 pixels wide. You could easily get 9 different colours on the playfield, it just wouldn't be as pretty as you could do it on other systems, but this is exactly what I mean by details. How pretty something will be isn't what I would refer to as "high level", though I do realize this is an arbitrary term with very fuzzy boundaries.
Dr. Mario could have had more species if the playfield was 16x16 tiles, perhaps horizontal even. The game could have worked with more species, but 3 was convenient. It could easily have been 6 species with an inverted colour scheme (black on the inside with colour outside), or some other way.
zzo38 wrote:
Well, actually I guess you could say Attribute Zone is a game based on the NES/Famicom PPU; there the limitations are precisely what suggests the form (and "high-level design") of the game.
Yes, you can get some ideas by considering something that matches some facet of the platform exactly, yes. It's worth considering ideas like this for sure, and you may come up with some interesting ones, but what I am saying is that probably not a very good source of direction on how to make "the best possible NES game".
Actually, this seems kind of funny, since there are plenty of old games that are highly dependent on some very technical implementation. Something like Pole Position / Hang On / Rad Racer is based on a scanline scrolling technique, for example. I tend to think the way these tend to come about is from the opposite approach. You don't ask "what can I do with per-scanline scrolling", you ask "can I make a road with perspective" and then think about how you might do it. Maybe you can think of a way, and maybe you can't, but ask yourself a bunch of these ideas, and sooner or later you think of a way to make it work, and that's the idea you go with.
What I am saying is that I think you'll get more by bringing outside ideas and seeing how they might interact with the limitations, than you would be trying to come up ideas that begin and end within the limitations. If you find the latter fruitful, though, by all means use those ideas. I just think it's a less productive approach (for me, at least), and probably shouldn't be the primary approach when looking for game ideas in this context.
rainwarrior wrote:
There is a large list of things that the NES is not very good at doing.
Thank you for reminding me about
that list.
rainwarrior wrote:
If I said "make a game, but you can't use the colour red", would this be a stimulating source of ideas for games? What if I just said "you can use red, but it will be difficult"? This is kind of what this line of inquiry looks like to me.
If the game is make for system without color displays (mono GameBoy, PC with Hercules graphics, Texas Instruments graphing calculators, etc), then you can make something that does not require colors. It isn't a particularly stimulating source but certainly some games require colors, other can use colors but don't need it (such as, color only for decoration), and more others might be not using colors at all.
Quote:
If you want two players, it can be done. The NES' limitations will have a huge impact on how you implement it speficially, but on a high level it's not off the table.
Two players simultaneously is easily possible, although it depend what kind of game. There is no hidden information (such as cards in your hand), but you can still do such things as, for example select which attack you want a pokemon to use by pushing up, down, left, right and it won't display until after both players have selected their action for this turn. (If you are using DPCM, you also have to avoid interference with DPCM.)
Quote:
Yes, you can get some ideas by considering something that matches some facet of the platform exactly, yes. It's worth considering ideas like this for sure, and you may come up with some interesting ones, but what I am saying is that probably not a very good source of direction on how to make "the best possible NES game"....What I am saying is that I think you'll get more by bringing outside ideas and seeing how they might interact with the limitations, than you would be trying to come up ideas that begin and end within the limitations. If you find the latter fruitful, though, by all means use those ideas.
I think both ways are useful, and can be combined.
zzo38 wrote:
If the game is make for system without color displays (mono GameBoy, PC with Hercules graphics, Texas Instruments graphing calculators, etc), then you can make something that does not require colors.
Between the number of people who are colorblind, and from personal experience using a pair of greyscale monitors on my desktop machine for more than a decade, the vast majority of games don't need—and really oughtn't ever rely on—color. As a culture, we like signaling lots of things using red vs green, which is unfortunately also the most common kind of color-deficient vision.
Anyway, that's a wild tangent, and not particularly applicable to the NES, since its source palette is so limited in greys.
Wow, I'm actually surprised to see discussion taking place over my question. To clear up one thing, this was about a hypothetical NES game, a game that would hopefully aim to be as good of a game as possible, also hoping to match or even supersede professionally made NES games. But that's one of the questions, would a game's quality determine it's popularity? Most faux-retro games are popular thanks to either being derivative of popular NES games (such as Shovel Knight being a Duck Tales and Zelda 2 mix at heart) or have homages to popular culture and other NES games (such as the entirety of Retro City Rampage), so maybe those faux retro games could serve as a guideline for 'what people want'. They also seem to represent 'how people remember NES games', which is quite literally the definition of rose tinted glasses; NES had some solid titles, but most games were mediocre and very few were actually 'advanced' like modern games. This hypothetical NES game should strive to emulate all of the good aspects of the NES' library, maybe even exaggerate how NES games actually were by having the music being stereotypical bleep-and-bloop music with constant arpeggios.
That said, I'm not too surprised on how some NES games came to be because of hardware limitations. Dr. Mario looks like it was built around the NES' limitations, as I believe Tepples implied that the playfield was sprite-rendered, which explains why it's so small. And as someone else once said, limitation breeds creativity, so the NES limitations could be more or less game guidelines; you aren't going to fill the screen up with random objects as this would not only cause significant flicker and slowdown, it just wouldn't be good design.
OneCrudeDude wrote:
Dr. Mario looks like it was built around the NES' limitations, as I believe Tepples implied that the playfield was sprite-rendered, which explains why it's so small. And as someone else once said, limitation breeds creativity, so the NES limitations could be more or less game guidelines; you aren't going to fill the screen up with random objects as this would not only cause significant flicker and slowdown, it just wouldn't be good design.
That's not what Tepples was implying. Dr. Mario's playfield is entirely 8x8 background, except the currently moving pill. All he was saying is that three colours is convenient for doing it in 8x8 background tiles, because that's the size of a palette (3 colours + background) and you can only have one palette per 16x16 region, so unless you group things into 16x16 blocks you can't make arbitrary combinations beyond 3 colours. As I said, using 16x16 tiles would easily have let Dr. Mario work with more colours.
If you want to see for yourself what is in a game's background, open FCEUX, go to Debug > Name table viewer (this is probably the best way to start getting a sense of how NES graphics work).
tepples wrote:
Lack of a 4-color limit on Game Gear is part of why Sega managed to score Columns instead of a Nintendo licensee.
um... Grid-aligned 16x16 tiles do let you pick any possible background color palette... Unless you're referring to the monochrome game boy.
True, Magic Jewelry and Mystic Pillars clone Columns for Genesis, which uses 16x16 pixel tiles. Its 6x12 or 6x13 tile playfield is about the same size as that of Puyo Puyo or Pac-Attack or Puzzle League or Wario's Woods or Puzzle Fighter II. But Columns for Game Gear has a taller playfield that won't fit in the NES picture without using a scanline-counting IRQ to cut off the bottom 4 scanlines of each 16x16 pixel tile like the bottom half of Klax. (Columns Crown and Puyo Pop and Luminesweeper for GBA use a similar technique using the GBA's HDMA to allow 12 rows.) Columns III for Genesis has a 5-player mode that uses 8x8 pixel tiles, and an NES clone of that using a Four Score would have to find some way to represent more than 3 species with 3 hardware colors.
Quote:
To clear up one thing, this was about a hypothetical NES game, a game that would hopefully aim to be as good of a game as possible
Sorry but this makes absolutely no sense. Every NES game ever released was made as good as possible from the possibilities of it's creator(s).
I doubt many people made games that sucked on purpose... Even games that really suck like Action 52 were probably made by totally incompetent people with ridiculous deadlines and bad communication among the team so that's while the result is disastrous. But I don't see a company do something like, "ok, we could make this game perfect, but we'll introduce flaws in it in order to give other games a chance".
There is not one perfection, but multiple ones. Also, every one has different tastes about games. Personally there's quite a few NES games which are already "perfect" in my opinion.
tepples wrote:
But Columns for Game Gear has a taller playfield that won't fit in the NES picture without using a scanline-counting IRQ to cut off the bottom 4 scanlines of each 16x16 pixel tile like the bottom half of Klax.
Would you really need IRQs in a puzzle game where little to no action takes place? Sound to me like cycle counting would suffice.
Bregalad wrote:
But I don't see a company do something like, "ok, we could make this game perfect, but we'll introduce flaws in it in order to give other games a chance".
Flaws are not introduced, but they are left unfixed if time and budget won't allow.
Not every game is made to be the best possible. I make websites for a living and although I'm a perfectionist and pretty competent at what I do, the quality of the websites I make depend heavily on how much my bosses charge the clients and how much time I'm given to work on each project. Those things dictate the level of quality that's being expected, and sure enough I deliver accordingly. I'm pretty sure the same thing has always happened with games.
tokumaru wrote:
Flaws are not introduced, but they are left unfixed if time and budget won't allow.
And, I like to release source codes so that it is potentially fixed later even if it cannot be made perfect at first (or in case someone likes to make other changes too, or just to learn how it is working). But, it is still a good idea to fix it as much as possible at first if you can do so. (If you do not like to release source-codes right away for any reason, you could "time lapse" them.)
tepples wrote:
But Columns for Game Gear has a taller playfield that won't fit in the NES picture without using a scanline-counting IRQ to cut off the bottom 4 scanlines of each 16x16 pixel tile like the bottom half of Klax. (Columns Crown and Puyo Pop and Luminesweeper for GBA use a similar technique using the GBA's HDMA to allow 12 rows.) Columns III for Genesis has a 5-player mode that uses 8x8 pixel tiles ... an NES clone of that using a Four Score would have to find some way to represent more than 3 species with 3 hardware colors.
MMC5 is one way (and so is cycle counting, with or without mapper support), but other way could be that state of PA8 while PA13 is low is saved and then the saved PA8 state is output to CIRAM A10 (I don't know if it will work; I didn't test it). Combining with sprites (based on the odd/even column positions), it could then give you twelve colors with a single 16x8 or 8x16 playfield if 8x8 tiles are used.
tokumaru wrote:
tepples wrote:
But Columns for Game Gear has a taller playfield that won't fit in the NES picture without using a scanline-counting IRQ to cut off the bottom 4 scanlines of each 16x16 pixel tile like the bottom half of Klax.
Would you really need IRQs in a puzzle game where little to no action takes place? Sound to me like cycle counting would suffice.
It would suffice in
Klax because only four such cutoffs are needed. The game logic can run above and below the bottom bin. But in
Columns, the cutoffs would stretch throughout the height of the screen. If the program does nothing else in the loop, that would leave little time for pattern detection (whether or not the correct number of pieces have made a row) and preparing background update data while pieces are falling after a line clear. If the program tries to squeeze game logic into the wait loop, most of the game logic would have to be carefully written to use a constant number of cycles. Programmer time costs money too, be it in wage payments from the producer (for a professional) or in how long the programmer has to work at a day job to support development before the program is usable (for a hobbyist). Installing a scanline counter IC on the cart PCB might be cheaper than trying to shoehorn game logic into a stable raster, and one that just asserts /IRQ every 12 triple-reads shouldn't take too many macrocells in a CPLD.
tepples wrote:
But in Columns, the cutoffs would stretch throughout the height of the screen.
All 240 scanlines? What about the portions hidden in NTSC TVs?
Quote:
If the program does nothing else in the loop, that would leave little time for pattern detection (whether or not the correct number of pieces have made a row) and preparing background update data while pieces are falling after a line clear.
From looking at gameplay videos, the game appears to be slow enough (the pieces don't even move smoothly) to run at 30fps or even less, in which case you could alternate the use of VBlank for different tasks.
Quote:
If the program tries to squeeze game logic into the wait loop, most of the game logic would have to be carefully written to use a constant number of cycles.
Timed game logic is hell to program, I wouldn't recommend that to anyone.
tokumaru wrote:
tepples wrote:
But in Columns, the cutoffs would stretch throughout the height of the screen.
All 240 scanlines? What about the portions hidden in NTSC TVs?
If you're trying to make the 6x18-cell Game Gear playfield with 16x12 pixel cells, you end up with a 216-pixel-tall playfield.
Quote:
From looking at gameplay videos, the game appears to be slow enough (the pieces don't even move smoothly) to run at 30fps or even less
Even when pieces are falling after a line clear in 2-player mode? Or are you recommending doing something like the notoriously slow update routine of
Dr. Mario that blits only 1 playfield row on each side per frame?
The 'best possible' NES game was Super Mario 3, by the way, if you were wondering.
tepples wrote:
If you're trying to make the 6x18-cell Game Gear playfield with 16x12 pixel cells, you end up with a 216-pixel-tall playfield.
There you go... 24 scanlines + VBlank should be enough to do a decent amount of calculations.
Quote:
Even when pieces are falling after a line clear in 2-player mode? Or are you recommending doing something like the notoriously slow update routine of Dr. Mario that blits only 1 playfield row on each side per frame?
VBlank time would still be a problem even if you used IRQs, right? Anyway, let's do the math: 6 x 18 x 4 that's 432 tiles. Since you'd already be in full control of the vertical scroll during the entire screen, you could use a trick to cut the number of tiles you have to update in half: Arrange your pattern tables so that $0000 contains the top half of the blocks and $1000 contains the bottom half, in the same positions. Then, during rendering, after the top 8 pixels have been displayed, you move the scroll back to the same row of tiles and switch to the second pattern table. This will get you the bottom half for free.
You can also arrange the pattern tables so that the right side tile index is always the left side tile index plus 1, so you can INX/INY the value instead of loading it. Of course, this will require you to update the background in row mode, meaning you'll have to set the VRAM address more times. I'm too lazy to calculate right now whether columns (2 loads per block, set address 12 times) or rows (1 load + 1 increment per block, set address 36 times) would be better in this case.
Anyway, columns or rows don't matter, as you can safely write 216 bytes to VRAM during VBlank with time to spare. If you're into forced blanking you might even squeeze updating BOTH playfields in a single frame. Otherwise, you can alternate between processing P1 and P2, and alternate between game logic and full playfield updates and each side would run at 15fps. Would that be acceptable?
rainwarrior wrote:
The 'best possible' NES game was Super Mario 3, by the way, if you were wondering.
I hope you don't mean it as a technical achievement, because the attribute artifacts that show up when scrolling (for example) is a pretty annoying flaw.
tokumaru wrote:
I hope you don't mean it as a technical achievement, because the attribute artifacts that show up when scrolling (for example) is a pretty annoying flaw.
Definitely, also, the lack of passwords is another pretty annoying flaw. Otherwise, yes I agree SMB3 is the best Mario game ever, and one of the best games on the NES.
Before I was going to say some titles, but I refrained to avoid this thread end up in "what's your favourite games" thread. But, come on, Mega Man 2 really is perfection
tokumaru wrote:
Arrange your pattern tables so that $0000 contains the top half of the blocks and $1000 contains the bottom half, in the same positions. Then, during rendering, after the top 8 pixels have been displayed, you move the scroll back to the same row of tiles and switch to the second pattern table. This will get you the bottom half for free.
The background and border would need to be arranged the same way for this to work. Not that this isn't possible though.
Quote:
Anyway, columns or rows don't matter, as you can safely write 216 bytes to VRAM during VBlank with time to spare.
"Time to spare" including an OAM DMA for the other player's falling piece? Or perhaps it could alternate OAM and nametable updates in separate frames, causing a bit of lag when pieces get
real fast.
But then how would one do the four player mode without an MMC5?
I was just being tongue-in-cheek when I mentioned SMB3, but it is also relevant to the discussion about what form the "best possible" game might take. Looking hard at the best extant NES games should give you ideas about what the NES can do well.
w.r.t. the attribute glitch, as a professional graphics programmer it's the kind of thing that I would pull my hair out over in development (if I had any left) but looking at it from the outside, I doubt the game lost even a single sale over it. It's also easy to forget how often televisions of the time had a very wide bezel covering the edge of the screen (not all did, but it was very common; mine did).
While Mario 3 is an impressive game, I don't think it can be seen as the pinnacle of NES technology; it looks like it was designed for something far greater or the ideas were too ambitious, but the programmers or the hardware wasn't up to the task. This also completely goes against the notion that Yamauchi originally envisioned, he wanted the NES to live for almost a decade before a successor was introduced. It was half true, as the NES was on the market for 9 or so years before finally being discontinued; allegedly the Famicom was for sale up until 2003. Hell, some of Nintendo's later NES games just look like they didn't even care at that point, such as Wario's Woods giving Wario a purple hat.
Speaking of making a game for a vintage Nintendo console as well as making it available for Nintendo's eShop, there appears to be this game, Justice Beaver, that aims to do exactly that.
http://www.nintendolife.com/news/2014/0 ... r_nintendoWhether Nintendo will go along with it or not is up for debate, but if Nintendo does give them the okay to do so, what does that have in store for homebrew programmers? Will we finally have our chance in the limelight?
Quote:
Rather, a team of hobbyist programmers would be needed, and they would need to be paid . . . what is the ideal size of a development team, and how big would the budget be? This just covers the development, advertising would be another question entirely.
Great questions - although I think that your second question - that of a budget - needs to take into account how much harder it is to develop an NES game than an NES-looking game. It is so much easier, and therefore faster, and therefore
cheaper to develop an NES-looking game in a modern language for a modern system. This approach would save all that time that would otherwise be spent (a) teaching your programmers 6502 assembly, (b) your artists the best practices of the RP2C02, and (c) hammering home the necessities of keeping everything in 2kb or 10kb at every step along the way. Hayato Tsuru and his team at
Inti Creates obviously felt this way when developing Mega Man 9.
The same possibilities which would push a modern team away from the NES on the basis of a budget change the calculus of your first question as well. Modern programming languages and interfaces allow the rapid development of tools that allow much faster world building and A.I. scripting than the tools available to the original NES developers. Whereas - back in the eighties - you might be designing not even screens worth of the world at a time, but mere rows[1] - today you could easily design a development tool which could show a 16000 x 16000 world map at once, change palettes on a whim, and design sprites as easily as dragging and dropping different tiles from VRAM manifests. I know it's possible - I designed a tool like this for my own - sadly stalled - NES project.
Interestingly, the reason I stopped working on the NES is because of the limits. I love retro software. I love learning about old hardware. But writing software in the assembly is frustrating. Having to retool my sorting routine because I realized that I needed a few more bytes to determine which frame of a sprite definition to display for an actor is frustrating.
And the worst of it is that there's not a market for retro development on retro hardware. Sales of the
best NES game ever might top out at 20,000 buyers - because that's the entire market for the NES today.
By comparison, an indie team could write NES-looking software (a) in a much easier to use language, (b) with no limits on the data output by their tools, (c) and as much fudging as might be required on the two worst limits on NES development, the 8-sprite limit and the 4-palette limit, (d) for much less money, and (e) faster.
NES development is a hobby. It's an awesome hobby. But NES development is not where you're going to find or fund the best NES-looking game. Development of a modern indie retro game on the .NET framework, in Mono, or the equivalent iLanguage (objective-c? Swift?) would take much less time, and with much less limits, than actual development on an NES. And as a side benefit, if your game is actually good, the installed market of the Xbox, Playstation, iDevices, and the PC is millions upon millions upon millions of users.
[1] Think of the way that Zelda 1 data is laid out in the ROM.
One way to work around the need to develop the game (physics, AI, level design) and the program (6502 assembly) at the same time is to develop the entire game in a "modern" language and then port it to NES. It worked for STREEMERZ, which was originally written in a language that targeted SWF.
In practice, Xbox, PlayStation, and the like are closed to you unless your company has previous PC or touch screen games or your developers have years of experience working for a mainstream studio. Android and iOS aren't suitable for the same genres, as a touch screen alone can't do more than point and click, one or two button runners, and shmups. It has serious problems, for example, with any platformer requiring the player to move both forward and backward. This leaves PC.
I am aware the NES is a niche market, and why I suggested there to be an eShop version of the game in addition to the cartridges. As Tepples put it, developing your game on quicker software and then downporting it would work, and you will have developed two similar games for the cost of one. I think that's how Retro City Rampage was meant to turn out, until he abandoned the NES port; ROM City Rampage states that it is an incomplete work in progress, so it might not be entirely out.
As for the programmers, I reckon a few NESDev regulars would be willing to make some money to hone their skills further; I really like Shiru's simple games, especially Zooming Secretary, who knows what he might do with funding or a team.
In my experience, no one will pay for this, though.
I get PMs every now and then on a pixel art forum asking me if I want to make an NES game. And everyone is scared off by a reasonable expectation of payment. I'd be happy to make "some money" doing this, as long as "some money" is worth getting out of bed for, and incentive enough to not just work on my own project instead. My own project where I don't have to answer to anyone.
Edit: And the fact is, I could always just make an NES-Like game as well. It's in my skillset. And that'd cost less solely because it'd take less time. Which is why (basically) no one will pay for an authentic one. You pay a bunch of extra money to feel good that the game works on NES, when that version of the game is not even what will be making the cost of the project back as you've said.
OneCrudeDude wrote:
When it became Retro City Rampage, Nintendo only offered him a license to publish the game in exchange of him removing his NES development documentation.
This piques my curiosity(/censorship annoyance). Is there a record of this offer? Is his documentation still available somewhere?
Kasumi wrote:
I get PMs every now and then on a pixel art forum asking me if I want to make an NES game. And everyone is scared off by a reasonable expectation of payment.
As a ballpark figure, I would suggest that a professional quality NES game should have a development budget of $10,000 at bare minimum, for a relatively small game (e.g. Donkey Kong). I would imagine that even this very lowball offer would scare away most. Not many people would put that much money on the line for an NES game.
A few years ago, I worked on a rather small action game for XBox 360 and PC. We made the game on a budget of about $1,000,000. The people working on it were being paid about 1/4 of industry standard wages (i.e. lower wages in return for a stake in the company). This is for a game that takes about 30 minutes to play through.
I doubt Mega Man 9 or 10 was made for any less than $1,000,000, so it's kind of ridiculous to think of it being used as an example as something that was "easier" to make than an NES game because of the reduced limitations.
I was anticipating a budget for this game to be around $250,000 to $500,000, depending on how big the game will be and how big the staff would be. Maybe $750,000 if we want to push the budget over, and possibly give this game some unique hardware to work as intended. While those are huge numbers, they're still rather small for industry standards. Maybe the price doesn't even need to be above $200,000 for all I know, I wish I was a financial expert.
I tried really hard to avoid making a real post in this topic...
rainwarrior wrote:
I doubt Mega Man 9 or 10 was made for any less than $1,000,000, so it's kind of ridiculous to think of it being used as an example as something that was "easier" to make than an NES game because of the reduced limitations.
Sure, game budgets are huge. If you've got a large staff working full time, you have to pay them all. I'd imagine whatever their budget was is still less than what it would be if they made an actual rom, though.
Budget is a topic I think a lot on since recently my NES game turned 5. I can't say I've worked on it full time for all those years, but eh... pretty much all my free time goes into it that isn't spent drawing. If I were paying myself, I dunno. It'd be... maybe 2-3 full time years? Could even be 4. And y'all can decide what the annual salary for 6502 programming/pixel art would be, I ain't posting a figure.
I'm doing that thing I discourage everyone from doing. I'm finishing the thing on NES, despite that fact that I will likely not make cartridges. And it's easy to figure out why. Those won't even get me close to breaking even on the time I've spent at this point. I'll have to reprogram it in C if I want it on Steam or whatever.
And what's done?
The game engine is done, minus music playback. Supports slopes, Co-op, shooting, all sorts of neat object interaction, cutscenes, text compression and display.
There's one "finished" tileset.
Main character (8 direction shooting, grabbing and throwing objects in eight directions, close to "sonic-style" physics with slopes, rather than "if-on 45 degree slope move at slower fixed rate".)
3 Objects. (A ball to throw around, a single fully animated enemy, a spring. Up to you if the player character's projectile counts ¯\_(ツ)_/¯ )
3ish other objects that are pretty much fully animated but not programmed. (Because... more important stuff needed to be done.)
And what's not?
... 98% of actual content.
All the levels. There's just one "actual" level. (With 40 or so test levels I've got to test water/slopes/whatever)
All the tilesets. Kinda want at least one per world, probably more since the same set for every level in a world is kinda boring.
All the cutscenes.
All the music.
All the sound effects.
All the bosses.
As it stands, I'll be lucky if I finish before the game turns 6, but I think I'm out of the woods as far as truly difficult programming is concerned.
The real kick in the head about NES programming is stuff players take for granted... stuff that's REAL EASY on a modern platform is totally frightening to program on NES. I hate sharing screenshots and things about my games in progress (unless they're nearly ready), but there's a fun one:
(The game has good graphics, I promise. This was a test to make sure attributes were properly restored)
In C, the above textbox appearing and disappearing (And restoring the level underneath) would have taken me... a half hour? Maybe two? Maybe a whole day?
Guesses for how long it actually took?
3 weeks. I guess I'm not the best guy for the job at this, I'm sure many of you could get it done quicker. But I'm sure it would still take orders of magnitude longer than the same person doing it in C.
More fun! I actually got text compression and display done in 3 days. (After... a long time planning out a good, feasible compression scheme.) On a modern platform, I wouldn't have to compress the text.
Slope collision? Hah, you know what was hard about this? Getting it fast enough. Making sure the player could not get inside of walls while checking the fewest amount of points. On a modern platform, I could check every point my character is drawn on.
What the folks here call 8 way scrolling took me a long time as well. And would be free on a modern platform. In fact, I'd bet a lot of money I could write scrolling code from scratch faster on a modern platform than I could PORT WHAT I HAVE IN 6502 TO ANY OTHER PROJECT!
I'm not sure people who want to get into the NES homebrew business know where the time really goes... Pixel artists think partnering with me will save me a lot of time, but art is not where the time goes. And maybe people who make famitracker music may think partnering with a person will save them lots of time, but this is also not where the time goes.
And this is why there are many, many, many NES-looking games and very, very few quality NES homebrew games. And honestly, when I see topics like this one it just makes me angrier and angrier every year.
The reason I post all this here is because this topic is about the "best possible" NES game. I have no doubt I could make a simple game in a week. I have no doubt I could make a slightly more complex non scrolling game in a few months. And this is what I tell everyone who wants to make a homebrew NES game (with me or anyone else.) Don't scroll. Don't do slopes. Don't be ambitious with it.
But the game I'm working on now (which I'm trying very hard to make as good as I possibly can) could not be made without a large budget, or people willing to work for free. (And I hope no one would want to work on a project like this for free, unless they started it.) And Tokumaru would still say it's not technically impressive because I didn't hide scrolling attribute stuff. (I did end up doing
this, and there aren't wrong tiles at the edge of the screen like in SMB3, though.)
And I'd agree with Tokumaru, it won't be technically impressive. No parallax scrolling or other scanline effects, no variable width font, no nothing. Just code optimized enough to get enemies on screen (with slopes no less!) while slowing down less than Kirby's Adventure hopefully. Just a fun game. And it'd have cost you all a lot to make.
For what it's worth, if I had any idea I'd still be working on the game now when I started I would not have started. I'd have just made a modern game. That's why I discourage people from doing this, despite doing it myself.
A final point: You may be thinking, "But Kasumi, it must be possible to get done much faster if I find someone better than you." I have no doubts you could find someone better than me, but you would have to pay them more because they are more skilled. Funny thing about that. And if you want to pay more people to get it done faster, that's fine too. It adds to your budget.
That's a pretty melancholic view of the whole thing, Kasumi. I can see where you're coming from though, seeing as I've been working on the same handful of projects for several years (NES platformer, NES raycaster, Atari 2600 metroidvania) and have made even less progress than you. That used to bother me a lot, but I guess I learned not to care so much. I never planned on turning game making into actual work, because pressure and deadlines tend to ruin hobbies for me, and I really don't want to ruin this hobby. I find the fact that it's easier to complete a game for modern PCs pretty pointless, because more than half of my fun comes from seeing the programs running on these limited platforms.
I've recently accepted that the chances of me ever finishing a game are extremely low, specially now that I have a 1-year-old daughter to raise. Having a little girl actually helps a bit with the frustration of never finishing any projects, because she gives me a sense of accomplishment that I doubt I could get any other way. If I ever manage to finish anything, great, but I gave up on setting unrealistic deadlines that just result in frustration.
I guess I do sound a bit extreme when I'm judging other people's works, but I'm actually pretty flexible. I can forgive a few flaws (e.g. scrolling artifacts) if the product as a whole offers more good points than bad. I do feel a general indifference towards very simplistic games will straightforward graphics and dull music, because there's absolutely nothing that stands out. Unfortunately there are a lot of homebrews like that. Maybe if the people responsible for such releases stuck around longer, the quality of their releases would increase, but I guess that more often than not the difficulty of programming for the NES drives people away.
Kasumi wrote:
rainwarrior wrote:
I doubt Mega Man 9 or 10 was made for any less than $1,000,000, so it's kind of ridiculous to think of it being used as an example as something that was "easier" to make than an NES game because of the reduced limitations.
Sure, game budgets are huge. If you've got a large staff working full time, you have to pay them all. I'd imagine whatever their budget was is still less than what it would be if they made an actual rom, though.
The thing about this is that you can scope any game plan to fit your budget (you sort of hit on this with your time-vs-scope estimates). They could have targeted an NES ROM if they wanted, for the same budget, it would have just been a more restrained game. The reason they didn't is because there's no reason to expect the game to sell any better if they made it as an NES ROM, and the game wouldn't be as good.
There are situations where I think it's actually a reasonable risk to make a commercial game for the NES (and I'm taking this risk myself), but I don't think it was ever on the table for MM9; not at the scale they needed to target.
OneCrudeDude wrote:
I was anticipating a budget for this game to be around $250,000 to $500,000, depending on how big the game will be and how big the staff would be. Maybe $750,000 if we want to push the budget over, and possibly give this game some unique hardware to work as intended. While those are huge numbers, they're still rather small for industry standards. Maybe the price doesn't even need to be above $200,000 for all I know, I wish I was a financial expert.
Well, going back to SMB3 as an example, I'm sure they spent more than $1,000,000 on just the marketing for that game, completely aside from the development cost. There are NES games you could get for $200,000 or any budget you choose, right down to $0, but that seems awfully low for a "best possible" game, even in 1988.
More recently, even the rather turnkey
Cheetahmen II project was asking for $65,000 for something that probably didn't require more than a day's worth of software engineering.
tokumaru wrote:
I guess that more often than not the difficulty of programming for the NES drives people away.
Making games is hard, on any platform, always.
Quote:
The thing about this is that you can scope any game plan to fit your budget (you sort of hit on this with your time-vs-scope estimates).
It's true, a less ambitious game is doable.
But this topic is specifically about the BEST POSSIBLE GAME, which assumes the game is NOT scaled to fit the budget. The reverse in fact!
Quote:
That's a pretty melancholic view of the whole thing, Kasumi. I can see where you're coming from though, seeing as I've been working on the same handful of projects for several years (NES platformer, NES raycaster, Atari 2600 metroidvania) and have made even less progress than you.
Maybe it's melancholic because I hate this sort of hypothetical thing. People are always all, "Hey wouldn't it be cool if..."
And I'm like, "It'll never happen." Like a true killjoy.
Maybe it's melancholic because I think people really, really don't know what they're getting into when making any sort of game. Kickstarter budgets make me laugh on a regular basis. I imagine if I had tried to kickstart this game back when I started. And how damn off I'd have been on the estimate of delivery/budget.
Want to know a secret, Tokumaru? I used to worry about you "beating me to the market" so to speak, as you seem to be the only other one who has even tried a Sonic style thing on NES, at least... good Sonic Style. And not like... Somari. (I keep saying Sonic style, but I ain't got no loop-de-loops or running up walls. Just the slopes affect your movement in a more than basic way. And that I can have totally arbitrary slopes, but don't very often because there's only 256 tiles in CHR at once and storing non basic stuff uses a lot more unique tiles...)
These days the only game I "worry" about is Super Bat Puncher.
Make no mistake, I LOVE my game. I've spent probably literal weeks just running around in a big test level I have, and I'm still not bored of it. But the fact is, it's very unlikely for me to even break even on the time I spent on it. And even though the game making profit is not the only reason I work on it, it's still a factor I do consider. I could have made the same game faster on a modern platform. And since people buying my game won't have the choice for a rom, well, why didn't I?
I wonder this, and so should anyone. Is your love of retro seriously worth EXTRA YEARS? Mine is not, but it's too late for me. If anyone reading this post loves NES that much, cool. I just don't want anyone to start not really knowing what they're getting into like I did.
Just know.
Just know...
For what it's worth, Kasumi -- my own feelings mimic many of your own. So don't feel alone in things like laughing at Kickstarter budgets, or the lot of idealists who have no actual skill set to achieve what they propose (or the finances to do so -- or more importantly, even knowing the people who can make those realities happen (i.e. they know nobody)), as well as being frustrated by "simple things" like drawing + erasing a "window" on the NES (I absolutely can see how that would take 3 weeks. Hell, it'd probably have taken me more like 2-3 months -- it's really not a simple task, there's a lot that has to be tracked internally).
Kasumi wrote:
And what's not [done]?
... 98% of actual content.
All the levels. There's just one "actual" level. (With 40 or so test levels I've got to test water/slopes/whatever)
All the tilesets. Kinda want at least one per world, probably more since the same set for every level in a world is kinda boring.
All the cutscenes.
All the music.
All the sound effects.
All the bosses.
[...]
Pixel artists think partnering with me will save me a lot of time, but art is not where the time goes. And maybe people who make famitracker music may think partnering with a person will save them lots of time, but this is also not where the time goes.
It wouldn't have YET saved you time, perhaps, but it certainly appears that it WOULD save you time. At this point, you have a WORKING GAME! Isn't that pretty cool? Longer,
It seems like your game has quite a lot of its programming done, by your list. Remaining would be the music and boss (maybe enemy?) AI, and maybe a few more objects, such as a level exit (if you have discrete levels) and a checkpoint (even if you don't). Possibly making some tools to make level creation easier, and possibly some codecs for data if you think you need more space.
However, the level design can almost wholly be done independently of the remaining programming, at least until one side decides more new objects are desired, and they may not be. Perhaps your game is going to be Sonic meets Glover, and doesn't need a whole lot of complicated objects. Even then, boss rooms aren't even always stored in the same format as the rest of the game, though obviously boss rooms and boss graphics and boss programming all need to be coordinated.
Similarly, the graphics and sound are a bit more dependent on level design and "programming" considerations (animation, banking, space) and "hey we want graphics/music for a forest level". Level design might mix a bit with either (if you want to have a neat setpiece at the beginning with some dramatic riff timed to when you go over a jump with some nice background, say), but again...
My impression of small game projects is that there is almost always a programmer, a sound person, and a graphics person. One of these usually is the designer of the concept. Occasionally you get wizards like the man behind Super Turrican.Similarly, I don't think people get into it for the money. They just create things, and if, at the end of the day, they can sell what they've enjoyed making, that's a bonus.
This certainly makes me want to get to my own finished-product stage more.
@Kasumi: I understand wholehartedly where you are coming from, and your post raises a few issues; specifically the implementation of more complex stuff. They do take a long time to create, so why shouldn't the effort be split between several people? One guy does the scrolling, the other does the dialog boxes, something like that. It might be difficult to merge the 'games' together as they both might've altered the game's core code to make them work, and be ultimately incompatible with each other. In some NES games, it seems like it wasn't uncommon for the credits to list certain people with seemingly arbitrary tasks; I wouldn't be surprised if there's an NES game that credits some "Erasher Shigami" for being responsible for the "scroll engine".
I agree, Super Bat Puncher does appear to be the best possible game a homebrewer can come up with. Then there's the impressive, near pixel-perfect port of STREEMERZ by thefox, and the Japanese-made Blade Buster or Kira Kira Starry Night. What's to stop me from, hypothetically speaking, hiring Miau to make the base game, and hiring that Japanese guy to program the overhead shooter stages? Probably memory constraints, or data sharing, or both.
As for the primary topic at hand, it's a damn shame that, of all of the PPU's VRAM, you can't farm out the palette data.
For the "Best Possible NES game," you could get away with having the CPU just run code that could fit in RAM to update the APU, the palette data and other PPU registers, and I guess an OAM DMA. (ed: and controller input, duh...though one might also theoretically have EXT-controllers, so...) Everything else, you can just have the cart do all the game logic (at a much higher speed), manipulate CHR and name/attribute tables according to where on the screen the PPU is drawing...if you added a cycle-timed loop for updating vertical scroll every line, you could even bring the attribute restrictions down to merely only each 8-pixel-wide slice of each scanline having 4 colors (plus 3 more when there's a sprite--and why not have them, if you're diddling the scrolling and CHR every line?)
(fake-edit: Actually, need one even update scrolling, one can just change the attribute tables between scanlines of a tile.)
You need not actually have the CPU pull instructions from a ROM, or obey interrupts. You can just ignore what address it's trying to read (more or less) and feed it the instructions YOU want to feed it. Probably mix some JMP $8000 in with your NOPs when you haven't got anything for it to do to keep the PC from overflowing into RAM.
You wouldn't even have to fiddle with the nametables, since you're basically pulling an Oeka Kids mapper writ large, so you could just have 0-FF (or 0-1F, with others for sprites) repeated over and over.
This seems like an ideal setup for "movie" carts.
OneCrudeDude wrote:
What's to stop me from, hypothetically speaking, hiring Miau to make the base game, and hiring that Japanese guy to program the overhead shooter stages? Probably memory constraints, or data sharing, or both.
Hypothetically indeed. What makes you think either of them 1) have time for such a thing, 2) want to involve money (e.g. want to be paid)?
For example, speaking personally, I would refuse #2 in every way/shape/form because what that would do is turn a hobby/something for fun into basically a job/form of work, and I segregate those two things. I promised myself back in the early 90s I would
never turn any kind of hobbyist gamedev into a line of work or involve money in any way, and I've stuck to that promise (and I know quite a few people who did go into gamedev professionally and now regret it; "it no longer has the same feel to it"). There are a lot of people who keep hobbies as hobbies for a reason: because they don't like the pressures of time, deadlines, needs, or worries along the lines of "oh crap I won't get paid this month / cannot eat unless I finish up that graphics routine".
I have no idea what miau's up to these days, but Hally et al is usually quite busy (I follow many folks involved in Kira Kira Star Night on Twitter) from what I can discern. I get the impression he's already involved in some other unspoken project since he recently prodded Jake Kaufman (Virt), which means there may be something he's working on that requires Famicom music composition. That's purely speculation on my part, so take it with a grain of salt.
I guess my point is this: even if you had an unlimited amount of funding to throw at a game, it doesn't guarantee that any of the people you'd like to be involved (meaning people with the skill sets you desire) would a) want to be involved, or b) have any interest in it (including for monetary compensation). Absolutely no offence intended nor am I intending to rain on your parade at all (honest), but I mean we are talking about a classic console here, which means in a lot of cases the driving force is personal interest; you may have a 10/10 level of interest, but the person(s) you might want/hope have the same level of interest might turn out to have 2/10. Kira Kira Star Night is an amazing example of collaboration on multiple levels and I cannot even begin to fathom how Hally et al got everyone involved -- my gut feeling is that there is a significantly different vibe/feeling/social situation going on in Japan with Famicom things compared to here or Europe.
koitsu wrote:
I promised myself back in the early 90s I would never turn any kind of hobbyist gamedev into a line of work or involve money in any way, and I've stuck to that promise (and I know quite a few people who did go into gamedev professionally and now regret it; "it no longer has the same feel to it").
The problem comes when a hobbyist can't get a game designed for two to four players onto TVs because the traditional "hobbyist gamedev" platform (that is, the PC) is stuck on a desk with a monitor sized for one person. True, it's been possible to use a TV as a monitor for PC gaming ever since TVs started including VGA and HDMI inputs circa 2007, and it was possible even before that with VGA-to-SDTV scan converters. And PCs have supported multiple USB game controllers through a hub since 1999. But other Slashdot users tell me that almost nobody actually does that. This lack of hobbyist platforms in the living room forces some developers into the industry.
Myask wrote:
It wouldn't have YET saved you time, perhaps, but it certainly appears that it WOULD save you time.
Maybe you're assuming I don't actually know what goes into making pixel art. You're right to assume that since I have nothing good posted publicly. But I've taken advantage of the time spent on this game to get good at it. You'd be right that I know nothing about music, though. If I break and hire a person for something, it'd be that.
The pixel artist I've talked to said an NES tileset takes him like three hours. Dude makes his living that way, I trust him. Just fully animating an enemy takes about that long for me, tilesets are 3 days to a week. And sure, 3 to 7 days is huge compared to three hours, but all of it's negligible compared to code/design. Consider that 5 years has gone mostly to code/design. I am unconvinced the graphics/sound will take even a quarter as long in this case. For the latest Mass Effect? Sure. For an NES style retro game? Nah.
Let's say that pixel artist lied to me, and it really takes him 8 hours for a set. He could probably still have got ALL the sets I'd potentially need (probably 16?) for the game done before I was done with just getting textboxes to display if we started at the same time. I'm not saying it's not time. I'm saying it'd be a small percentage of the time in a "best possible" NES game. Even if the dude was maxing out 256KB of CHR ROM... I'd beat him on just textboxes, but yo... we wouldn't be close on the rest. The gap between time spent is MUCH smaller when coding in C, but keeping the graphics NES-authentic. I wouldn't be totally surprised if coding suddenly became the easier job, actually.
There's also that even if some other dude was doing art for me, I'd still have to put it into the game. And this is actually harder than you might expect for some things.
Quote:
Possibly making some tools to make level creation easier, and possibly some codecs for data if you think you need more space.
You mean like this? (Again, I promise my game has good graphics. These are test graphics.) This tool to make level creation easier is another thing that makes an NES game take more time. Because if I weren't making an NES game, I wouldn't need to worry about all these layers of metatiles. I wouldn't need a custom tool to make and compress maps. I could use Tiled. Even if I did write a custom tool, it would not be as
hard to write. I couldn't even like... re-use this tool on another game. Everything it does is very rigidly linked to my current game's structure.
Quote:
Isn't that pretty cool?
Like I said, I'm not pessimistic about my actual game. I LOVE it! If anything, I'm pessimistic about the process. I just think NES homebrew glamor wears off once you really start, and am providing what this is like as a dude who has done it for a while. This topic needs some realism.
Quote:
It seems like your game has quite a lot of its programming done, by your list. Remaining would be the music and boss (maybe enemy?) AI, and maybe a few more objects, such as a level exit (if you have discrete levels) and a checkpoint (even if you don't).
Realistically, that's a lot! A "few" more objects will end up being at least 40. (Probably even more than that.) Count the different enemies in Kirby's Adventure. In the average Megaman game. Add things like the star Kirby rides, and robo dog spring powers in Megaman. These are not enemies, but they are objects. There's a lot you may not be considering.
There will probably be at least 8 bosses. That need graphics. (Well, one boss is partially animated.) And code! Cutscenes to lead the worlds into each other I need to program. Dialogue needs to be written. Even though I think time spent on not code is tiny compared to the time spent on code for this game, it's still stuff that has to be done.
Last month, I'd have said, "There's still no end in sight." for my game, even with all that stuff done. This month, there's an end in sight since soon I will have my first levels and the beginnings of my first boss. But the end is still very fuzzy way out there by the horizon line.
tl;dr when your game engine is done, you're not NEARLY done. Even when your game is playable from start to finish, you're not really done. Those statements are true for all games, NES or not.
Quote:
However, the level design can almost wholly be done independently of the remaining programming,
Designing without the whole is usually not a great idea. The one level I have? Its flow is broken because I recently changed the player physics. (They're now final, though. That one level confirmed my suspicions about something that needed changing.) If I made a level designed without the objects contained within, adding them would break the flow. I don't want an enemy in the way to halt the player until they kill it like Megaman or a Beat 'em up screen lock. I want my game to have a platforming flow the way a Mario game does. This is why I have so many test levels, before I commit to real ones.
Quote:
Similarly, the graphics and sound are a bit more dependent on level design and "programming" considerations (animation, banking, space) and "hey we want graphics/music for a forest level".
Music can go in its own bank, because nothing but the music player ever needs to access it. Sound is cool because I can make the entire game without it and add it at the end and that's fine. It's the easiest thing to edit, update and replace. (Not saying it'd be easy to make a replacement song, but once a replacement song is made it'd be in the game on the next export. No change of code, or even script.) It's the reason I haven't bothered yet. It's true that occasionally one times a cutscene to music. If I needed that, I'd make a control code in the song that causes a cutscene event. The new song would just need to put that control code in the place where the event is meant to trigger. Even TEXT will generally be harder to change than music for this particular project. Enemy animations are behind music and text. Deciding a tileset needs to be changed after levels are built can be really, really tricky because you need the same structures, and you need to update all your metatiles. (and in my case, my meta-metatiles.) This can be easy, but for me on this project, it's hard.
My level editor already handles banking mostly automatically. If I run out of space in a bank, I have to copy the sets it uses to a new one, which only takes like 10 seconds. But all 46 of my test levels, fit in slightly more than 8KB. One level is 3840x2304 and another is 16128x256. Most are smaller, but I am very unconcerned. It took forever to write an editor that conveniently exports this data, but that's all behind me. Like I said, I'm pretty sure most of the truly difficult programming stuff is behind me. That doesn't mean there's still not a lot of game to make.
The game will absolutely get done. There may be better ways to do what I'm doing, but I'm certainly no slouch at this.
Quote:
My impression of small game projects is that there is almost always a programmer, a sound person, and a graphics person. One of these usually is the designer of the concept. Occasionally you get wizards like the man behind Super Turrican.
I'm not the only one-person dev team.
My favorite one. Check out The Iconoclasts demo.
He made a tweet I identify with about that game. You might actually be surprised just how many solid games are made by one person. But this topic does not deal with small game projects. Not in the least.
OneCrudeDude wrote:
@Kasumi: I understand wholehartedly where you are coming from, and your post raises a few issues; specifically the implementation of more complex stuff. They do take a long time to create, so why shouldn't the effort be split between several people?
I must be bad at stating the key points I want to make. If you pay one person full time to do something in 5 years, you're down that much in cash. If you pay two people to do something in 2.5 years, it costs the same amount of money, sure. My point is that no matter how many people you get, the money would go further on a faux-not-real NES game. My posts are not saying, "What I'm doing is not cost effective, but it would be if I had more people to get done faster" They're saying, "This is not cost effective."
Quote:
One guy does the scrolling, the other does the dialog boxes, something like that. It might be difficult to merge the 'games' together as they both might've altered the game's core code to make them work, and be ultimately incompatible with each other. In some NES games, it seems like it wasn't uncommon for the credits to list certain people with seemingly arbitrary tasks; I wouldn't be surprised if there's an NES game that credits some "Erasher Shigami" for being responsible for the "scroll engine".
For the record, this is still true in C. Easier in C because it's significantly easier to avoid overlapping RAM. There's no fighting for fixed bank space... which woah, I never thought about as a solo developer. But man... it would not be fun trying to make new stuff with another person on the team when the fixed bank was nearly out of space.
OneCrudeDude wrote:
What's to stop me from, hypothetically speaking, hiring Miau to make the base game, and hiring that Japanese guy to program the overhead shooter stages? Probably memory constraints, or data sharing, or both.
Your total lack of money, realistically speaking. I understand the sentiment, I do. If someone wanted to pay me to make something I'd be pretty down if it was a fair wage. But if you have nothing to offer, everyone who is good at this has their own thing they may as well work on if they're not going to be paid anyway. Plus all of Koitsu's points. (Both he and Tepples AND you responded as I writing this epic. I was originally just responding to Myask
. )
If you're really into this, and win the lottery tomorrow to fund it, I'm not saying don't do it. I'm just saying here be dragons, take note.
I don't want to be the rain cloud, nor have it all be about my game. It just seemed a good idea to post about it so people could get an idea of what could be done in how long by someone who is actually pretty good at this. That's what was asked for.
koitsu wrote:
For example, speaking personally, I would refuse #2 in every way/shape/form because what that would do is turn a hobby/something for fun into basically a job/form of work, and I segregate those two things. I promised myself back in the early 90s I would never turn any kind of hobbyist gamedev into a line of work or involve money in any way, and I've stuck to that promise (and I know quite a few people who did go into gamedev professionally and now regret it; "it no longer has the same feel to it").
Hah, this pretty much resonates with me. My goal with this game is more personal than "become a professional game dev", but the idea that it might sell does keep me on track.
There are many thoughts related that I suppose I won't post. But video games are already ruined for me, the way becoming an animator ruins animation the average person sees no problem with. I do wonder if becoming "professional" could possibly make it have even less of a "feel" that it already does, heh. At the moment, I feel held back mainly by NES. It might be fun to join some small indie game team using C++ and be amazed at how I can just... GO! As opposed to my game crashing right now because I added tile animation to the map editor. So the NMI changes which bank is being written to. So if a frame takes too long it will swap a prg bank index into CHR instead of PRG and then crash when trying to go to a routine mapped in that PRG. Yeah... I know how to fix it, it's easy, but I haven't.
One of the cool things about being solo... if I get frustrated with programming, I just move on the graphics. If I was a career programmer... nope, couldn't do that. And all of the bad things about being solo: When I'm not doing it, it's not getting done. Can't take a nap, and see some progress on a tileset for your pixel art guy. But now I'm very far off topic.
Sorry for the book. That's why I didn't want to post at all.
Edit: For the final point... A lot of my points become non points if you are not making something so damn ambitious. Fighting for fixed bank space is not an issue when you're making an NROM game. If you don't scroll/update the background during gameplay this removes a significant amount of coding hassle.
With none of the above, it's only slightly harder to make the game on NES than PC. BUT! The hardness increases an EXPONENTIAL amount for NESdev above the non exponential regular hardness step increase of a PC game for each of those things you might want.
It was more a "saves you time" in that someone else is spending the time and you don't.
I'm not familiar with Kirby's Adventure's programming, but I expect the warpstars are a whole set of objects/scripts, since they do so many different things (getting blown away in Grape Garden) and have so many paths.
This seems a bit offtopic.
I guess you guys raise some points regarding hobbyists turning to 'professional' programmers. I would say this hypothetical game would be a one-off project and not an entry into mainstream game development. Think of it as finding staffers who are capable and willing to fulfill the project, and receive something in return.
For an even more ambitious example, there's this series of cross platform games, all titled "Sydney Hunter", where they seem to find programmers who are specialized in their respective consoles; it will come to the NES, SNES, and even Intellivision, and they mentioned they found a Genesis programmer. I doubt the programmers are doing it for free, and I doubt they will be forced to operate as a real development team, with crunch times or due dates or what have you. You guys know what I'm talking about?
Bottom line, it's all about the programmer's own will if they wish to be compensate for their specialized skills, I can't force anyone to work for me if they don't want to. I'll be disappointed, but I'll respect their freedom. Worst case scenario is that the game is not made. Best case scenario is that the game is made, period.
The Sydney Hunter game is more ambitious than the hypothetical game you planned to do? With no 8 way scrolling? No scrolling at all? No slopes? Single Screen rooms that probably reload all objects like Battle Kid does? This does not strike me as ambitious.
When you speak in general terms like "best possible", I'm thinking of a game including all the hardest stuff to do imaginable.
"I want to really stress the fuck out of the NES and do mid-scanline buttwiping while riding snakes, naked, around Ohio"
kinda thing.
Edit: I'm thinking Battletoads. Maybe it isn't obvious to the average player, but Battletoads is the most ambitious NES game that comes to mind right now. It ain't perfect, I personally don't care much for the gameplay. But I respect those programmers... there's some junk in that game I wouldn't want to code on my best day. Super Mario Bros. is pretty ambitious/impressive too, considering its lack of mapper.
If your game isn't that, let's talk about real stuff and not hypotheticals. Design the game you want and we'll tell you what would be involved. And you can dumb down the design based on that feedback.
If there is no such design as your first post states directly, I've probably said everything I can about a hypothetical best game. If you have something you can post that you want real, it might be more doable than you think. Also easier to find a programmer who might like your idea enough to do the spec work. (This programmer is not me.)
But also consider what you are actually bringing to the table, as hypothetical as this situation might be. If you are paying your collaborators, you're bringing money to the table. If you're not, why should they make the game with you/share any profit with you? "The idea" is not the answer to this question.
The other thing worth saying is that a good design or idea for a game is worthless without a good implementation of the game itself to realize it. Every good idea for a game can be ruined by a poor (i.e. not fun) implementation. The converse is sort of true as well; if you give a bad idea to a good implementer, they will likely straighten it out and make something decent out of it.
Games are made good not by having good ideas to start with, but by iterating on those ideas. Building something out of them, investigating what's wrong, adjusting things day by day until they start to fit together correctly. It takes time and patience, analytical skill for seeing what's not working and what it could be, and the technical skill to rebuild it better.
Ideas are cheap. They're not hard to find, and everybody has them. Working professionally in games, I came to realize that nearly everyone who works in games has probably 5 great game ideas that they're dying to make and have been thinking about for years. If you don't have cash in hand to pay someone, I guarantee you that person already has another idea they are more interested in. (For the record, I'd gladly do NES dev for pay, but it would have to be a good enough wage to convince me to preempt my own projects.)
Another thing to know is that the time needed for a project is not in a linear scale with manpower. Some things do scale well, like music or graphics; two people will get it done nearly twice as fast, though you need a leader with direction to keep these things coherent (this is why it's only nearly twice as fast). Programming, on the other hand, does not scale very well at all this way. There are a few technical areas that can be separated and worked on in parallel (e.g. sound, rendering, tools), but almost everything a programmer does affects many parts of a complex system which means there is a lot of discussion and negotiation with other programmers involved. Two programmers might work only a little faster than one. Twenty programmers might paradoxically seem to work three times as slow as a single programmer. The reason this happens is that programming is extremely error prone, and the errors (i.e. bugs) affect everyone working on the project. A bad piece of music doesn't stop anyone else from working, but a bad line of code checked in might mean that nobody at the company can test their new work for 3 days until somebody figures out what went wrong. As you add more programmers, you increase the frequency of errors, and it accumulates almost exponentially. This is a big part of why at least 50% of commercial game projects fail and are never released.
Movie license games are a good case example. Lots of these have a great starting idea and strong concept. In general they have a healthy budget to work with, but not very much time, and this almost inevitably turns the whole project sour. There's just not enough time to make this good idea into a good game. Working on it until it's done is not an option, and failure to release is not an option either, so the broken unplayable piece of crap goes to market anyway. This is what happens when time and scope are inflexible.
Kickstarter has been kind of good for exposing these problems. If a publisher is paying you, when the project fails it's easy to quietly let it go; nobody knows, and you at least got paid while you worked on it, the publisher has to eat the loss. If it was a Kickstarter, thousands of people are watching you fail, and it's a rather horrible position. Not only is it awful socially, you're obligated to return Kickstarter funds, as the risk was on you the whole time.
@Kasumi: While it's hardly technically impressive, Sydney Hunter is quite 'ambitious' in that they are planning on making multiple variations of the game for different consoles. I don't think you could say that for most homebrew efforts. And now that you mention it, I don't think there are many, if any, homebrew games that scroll. I've come across a post criticizing Tepple's Concentration Room for being 'yet another single screen puzzle game'. STREEMERZ scrolls a little, which is to compensate for the original game's 320x240 screen size while the NES only has 256x224, but I can't think of many others. Kinda funny that something as arbitrary as scrolling is a huge deal to implement, but it's also not surprising given the age of the hardware.
And reading back at some posts that were linked in other threads, which linked to other threads, it seems like to do even the most trivial of things on the NES requires an absurd amount of work, no matter how much documentation may have been harvested in the 30 years the console existed. Then again, older consoles were even crazier; Atari 2600 games relied almost entirely on mid-scanline writes for anything, and this continued well up to the 7800.
When I said ambitious, I didn't explicitly mean technically sound, just very polished. Games hardly sell themselves on something not readily visible like technical prowess, instead focusing on their visuals. This was true when the NES was out, and this is true today. As Rainwarrior said in this very thread, I doubt that Mario 3 would've sold more (or been more popular) if the scrolling artifacts were fixed. I doubt people even cared the game scrolled in four directions in the first place, especially considering that there's only a few stages where you can make the camera follow you.
OneCrudeDude wrote:
Kinda funny that something as arbitrary as scrolling is a huge deal to implement, but it's also not surprising given the age of the hardware.
Like I said in an earlier post, a lot of things that players take for granted are SUPER difficult to implement on NES. There
are people who have seen my game, and every one of them thinks something is impressive that took like two seconds. I don't think anyone has told me that something that was actually hard is cool, ever. (Except Koitsu in this very topic about that text box.)
Edit: Tepples' Variable Width Font comes to mind. He's certainly better at this than I am, but there's no way that wasn't a lot of work. And it's a thing most people won't notice unless it's pointed out to them. In fact, Tepples' whole native graphics editor with zooming is super impressive in a way that no one who doesn't do this would get. Heck even his (now removed from site) Tetris clone does things I wouldn't want to touch, personally. Tepples for
President. My game is ambitious in its own way, but Tepples does some crazy stuff. He's high on the list of guys a person wanting to make something like this should consider hiring before they hire me. But of course, I'm still open to making things for pay!
Yes, there's a reason many games don't scroll. If you don't scroll, (or just scroll in one direction at a time) everything becomes much easier. Any kind of background update is "the hardest thing" on NES. Plan your game knowing this, if this is a thing you actually want to do.
For a very polished game without scrolling, the answer is however long Battle Kid took. Sydney Hunter Mayan Revenge NES will no doubt take less time because that's basically the Battle Kid engine, worked on the by the guy who made Battle Kid.
I could make a Battle Kid engine in less than a few months, for what that's worth. But an engine is not a game, and certainly not a polished one.
Edit: No matter how you slice it, you still need details of the game to make this kind of estimate. *restate dislike for hypothetical questions and ninja vanish from the topic*
You know, I'm kind of a different opinion on that. I don't find doing things on the NES hard, specifically. Once I had my head around all of the things it does, I find writing code for it fairly straightforward. Tedious, not difficult. The word I used before was "restraint". The needs your game has will run up against limitations of the NES, and one side or the other will make sacrifices somewhere. You'll make graphical concessions, or you'll make game design concessions somewhere.
However, I am doing this by developing the game in C++ in a framework that enforces NES rules, and then porting. So, the task that I'm saying is tedious is being a human compiler. Doing this is not something I find more difficult than other cross platform development situations I've been in. My assembly coding is not very error prone when the algorithm is already worked out in C++ beforehand. Even counting cycles is not hard when you've got a great modern debugging emulator to work with (though it can still be done reliably without, just more slowly).
I do, on the other hand, find game development in general tremendously difficult. I've never been part of any game project that I thought was even remotely easy. Planning and building and rebuilding and iterating and making the thousand little parts of your game design work together, and finding the time, and finding the will, and finding the means. All of this is hard as hell, but is not in any way specific to the NES.
I think it would be harder if I was making the game for the NES only, simply because developing algorithms and iterating over logical errors is monumentally slower when you're doing it in assembly. I've avoided this, though, by doing the hard work in an easier language, just keeping the NES rules in mind, and merely porting to the NES. If I didn't have this process, I might consider it more difficult. It wouldn't really matter if I was planning to release the PC native version or not, having the C++ as a "scratch pad" to do the development part has made me so much more productive that I would do it anyway. (I think Miau has talked about a similar way of doing things in the past on his blog.)
On the other end of the spectrum, I've seen people here say that they prefer to use a hex editor to hand assemble a romhack instead of learning to use an assembler. I can't imagine trying to get anything done on the NES this way. I mean, it's technically possible to do, but I know I wouldn't have enough stamina to do anything worthwhile this way.
As for scrolling, having or not having it is an important design choice. There are things you can do with static screens that you can't do with scrolling, and vice versa. It doesn't have to be about technical feasibility. There is that aspect of it, but there are lots of consideration outside that. Scrolling isn't by itself a better game, but offers great design opportunities for certain kinds of games. Static screens do a very interesting thing with how information is revealed to or hidden to the player, for instance... Looking back all the scrolling stuff on the NES seems a fad from the era. The NES could do scrolling really well compared to its predecessors, and after a hit or two, everybody wanted to have it. We went through the same with first person shooters, et cetera.
I actually saw your Lizard game on YT and read about it's development process, specifically the 'human compiler' part. I also like how you made the snow stop at the 'roof' instead of falling through, nice attention to detail. And didn't the Retro City Rampage guy say that's how he was planning on making the game; program the hard stuff on PC, and then translate it to 6502? I could've SWORN I read it on his blog, but I can't seem to find it now.
And is he still doing NES related stuff, or did Nintendo's contract strip him of this right? Or did his game, to paraphrase bunnyboy, turn his hobby into a paycheck? Despite being incomplete, ROM City Rampage uses black magic compared to most NES homebrew games. Not only is he using MMC5, not only is he using ExAtt, he can also make it scroll in all directions almost seamlessly. I've been told that ExAtt and scrolling don't work well together, though my sources are disputable. That said, I reckon that something like RCR would be 'the most ambitious NES game possible', which turned out to be too ambitious for the hardware given. You could scale back a few things (do you really need dozens of pedestrians wandering around?) to make it work, but we don't know if it would work in the end. I obviously won't count Shovel Knight as they broke the confines of the hardware so much, it looks like a Genesis game with an identity crisis. Jesus, that game is a MESS with it's mishmash of colors and style. I should mod the PC version to look more like an NES game should; I have a good idea how the NES works, I just don't know any programming.
OneCrudeDude wrote:
And now that you mention it, I don't think there are many, if any, homebrew games that scroll.
https://www.youtube.com/watch?v=zEV6HN88mV8
OneCrudeDude wrote:
And didn't the Retro City Rampage guy say that's how he was planning on making the game; program the hard stuff on PC, and then translate it to 6502? I could've SWORN I read it on his blog, but I can't seem to find it now.
He wrote a a thing that let him use if statements and such. See here:
http://neshla.sourceforge.net/ There's also actual ways to compile C for NES, but then code size is a constant problem. (And as far as I know, no way to take advantage of banking.)
Quote:
And is he still doing NES related stuff, or did Nintendo's contract strip him of this right?
Better to ask him all of that than us. He's not hard to find. Maybe he can't answer about the contract, but everything else, sure.
Quote:
That said, I reckon that something like RCR would be 'the most ambitious NES game possible', which turned out to be too ambitious for the hardware given.
Things like this are hard to quantify. It's certainly in no shortage of ambitiousness, but I don't think it's too ambitious for the hardware. It's a thing I've actually considered trying, just because the ROM City Rampage rom (when run outside the emulator inside Retro City Rampage) drops a lot of frames (Yes, I realize it's designed to run at only 30 FPS, but it's frequently slower than that, even). I'm curious how well I could do. I really have no doubt an open world game like that can be made on the NES (nor did he, or he'd not have started), but it's a time-payoff thing. My probably less ambitious game has taken a long time, and I can see why the time might start to not be worth it for him.
Edit: I'm reminded of
this post on a totally different forum.
https://www.youtube.com/watch?v=po69zgqyFWM This was ambitious.
And this:
http://neotoxin.moccamagic.com/And this:
https://www.youtube.com/watch?v=3yAYANeSRboAnd this:
https://www.youtube.com/watch?v=q6jlek8P4MkAnd I could swear there's some 3Dish tank game around, but I can't find it.
I've also always found myself super impressed by this:
https://www.youtube.com/watch?v=1oMfpLiFyJE Because of behind the scenes stuff.
Ah, and since a reply was made while writing this with just ONE game that scrolls...
Hiatus Ward (linked above) scrolls arbitrarily.
Everyone knows Super Bat Puncher which also scrolls arbitrarily:
https://www.youtube.com/watch?v=SAEl6BjnQwYThere a game called S.T.I.N.G which you can find in the list here:
http://www.nesworld.com/article.php?sys ... eshomebrewThis game scrolls arbitrarily:
viewtopic.php?p=75399#p75399Assimilate:
http://nessylum.wordpress.com/Blade Buster:
http://hlc6502.web.fc2.com/Bbuster.htmAnd many more™
Edit3: For the record there are definitely homebrew NES games that both compete with and soundly beat commercial NES games, that are made by one person in their spare time. Edit4: In fact, proof of this is precisely what made me think you were talking something technically stupid, and not just "solid game." Battle Kid 1 and 2. Blade Buster. I assumed these weren't good enough because they're certainly not hard to find, and if they exist, why ask? What you propose means you have to have money to drag these people away from their own projects, though. Or a really compelling other kind of proposal.
We'll see what the world thinks of my game in like 20 years when it's done.
Before I clicked your link, I guessed it was Joakim Sandburg, and I was totally right. That guy is a wizard.
Kasumi wrote:
There's also actual ways to compile C for NES, but then code size is a constant problem. (And as far as I know, no way to take advantage of banking.)
Banking is very possible with C. The only problem is that the C compiler may insert calls into its runtime functions anywhere in the generated code, so you'd have to make sure the runtime routines are banked in at all times (or replace them with trampolines to banked routines, further slowing them down).
Scrolling isn't inherently hard on the NES, specially if it's only horizontal. Anyone that can understand the difference between world coordinates and screen coordinates and how they relate to each other (i.e. anyone who has programmed scrolling levels in any other platform) can do it with their eyes closed. The problem is that most newbies can only understand screen coordinates, and that makes the whole thing freakishly hard.
Vertical scrolling, and worse yet, 4-way/8-way scrolling is significantly harder because of the height of the name tables (30 tiles - not a power of 2) which, in addition to complicating conversions between world coordinates and screen coordinates, complicates the processing of color attributes. Other consoles like the SNES, Genesis or Game Boy have tile maps that are nicer to work with, because their dimensions are powers of 2.
This problem isn't impossible to solve if you stop for a while to think of all the math that's involved. Programmers should be somewhat good with math, because guessing is a terrible way to code for the NES. Other platforms are a bit more forgiving, and changing math in high level languages is easier than in assembly.
Kasumi wrote:
Music can go in its own bank, because nothing but the music player ever needs to access it.
Except when you actually have to trigger a musical cue or a sound effect. Do you make a far call into that bank? Or do you just place values in a part of RAM that the sound code picks up?
Quote:
Sound is cool because I can make the entire game without it and add it at the end and that's fine. It's the easiest thing to edit, update and replace.
But when you replace the sounds, you might have to come up with new logic to trigger the replaced sounds. For example, if you decide to add a "5, 4, 3, 2, 1" countdown, you need to add the logic to compare the timer to those values. And if you want to make the numbers sound different, as
Rampart does with the "1", you need to change your logic for that too.
Quote:
Fighting for fixed bank space is not an issue when you're making an NROM game.
Of course it is. I ran out of space in
RHDE, and now I have to postpone features to a sequel using UNROM.
rainwarrior wrote:
Working on it until it's done is not an option
The obvious exception being
GoldenEye, which wasn't intended to come out simultaneously with a theatrical or home video release.
OneCrudeDude wrote:
While it's hardly technically impressive, Sydney Hunter is quite 'ambitious' in that they are planning on making multiple variations of the game for different consoles.
So it's about as ambitious as
Tetris or
Klax or
Zoop or one of those other massively multi-platform releases.
Quote:
I've come across a post criticizing Tepple's Concentration Room for being 'yet another single screen puzzle game'.
That was probably
this one.
Kasumi wrote:
Tepples for President
Now that I have an actual idea for a game to go with that engine, and now that
Flight Minigames is canceled, I might end up actually making something I've wanted to make since the air date of the "Dogmother" episodes of the animated series
Garfield and Friends, which was 20 years ago. This game was originally planned to be on Apple II, for cricket's sake. (
Related)
OneCrudeDude wrote:
I've been told that ExAtt and scrolling don't work well together, though my sources are disputable.
As I understand it, ExGrafix works fine with scrolling so long as the screen with ExGrafix has single-screen mirroring. Thus you can have a playfield with ExGrafix and nametable 0, and a status bar with normal graphics. You get the same artifacts at the right side as any other single-screen mirrored game, which in the case of ExGrafix doesn't have to be
any because the seam completely fits in the windowed-off leftmost 8 pixels.
tepples wrote:
Or do you just place values in a part of RAM that the sound code picks up?
That one.
Quote:
But when you replace the sounds, you might have to come up with new logic to trigger the replaced sounds. For example, if you decide to add a "5, 4, 3, 2, 1" countdown, you need to add the logic to compare the timer to those values.
If I'm following that's not a strict replace, right? You're ADDING the extra unique sounds. If you were just replacing, the logic is already there. But it's also not difficult. You can't possibly think I meant that if I make say... a new skid sound or jump sound when there wasn't one before, I wouldn't have to add logic for it right? It's just really easy. If the character can already jump, you already have logic that detects whatever makes him jump. And from that you can add the 6 or 8 bytes for a load/ora/store to make the new sound play. I'm sure you could come up with 7 cases where it ain't that easy, I can too. But yo... even the timer thing can be done in 17 bytes with the way I'd have set up the timer in the first place. Edit: Actually it'd be less than 17 bytes more, because we're presupposing the timer already did play a sound effect, it just didn't play a unique one for each value, right?
Quote:
Of course it is. I ran out of space in RHDE, and now I have to postpone features to a sequel using UNROM.
I say that's more a symptom of bad scope. i.e. your game was too ambitious for NROM. I'd also say running out of space is different than running out of fixed bank space. If I run out of space in a data bank for instance, that's an easy fix. There are different shades of running out of space. I'd further say the fight I mentioned was between multiple developers. I've got around 300 bytes free in the fixed bank, and that's fine. That's the road. Imagining tetrising code in there with other developers is what I meant, not the fight for space in general, which yes, is always present. Edit: Usually I'd assume that the fight for space at the end of a well scoped NROM game would be for data, not code, though.
tepples wrote:
Now that I have an actual idea for a game to go with that engine, and now that
Flight Minigames is canceled, I might end up actually making something I've wanted to make since the air date of the "Dogmother" episodes of the animated series
Garfield and Friends, which was 20 years ago. This game was originally planned to be on Apple II, for cricket's sake. (
Related)
I apologize for that hold up. I didn't truly understand the consequences of that PM I sent log ago at March. In fact I forgot about it altogether. That and I severely overestimated my skills at that time.
Allow me to interject quickly for a moment here. I would like to ask (and know) how much more difficult would NES game development be if you were to make your game for a more advanced mapper? I don't think any homebrew games go above anything higher than UNROM, and if they do, they must be relatively few. Is the reason why more advanced mappers are ignored is because the games don't need them, or they're harder to work with? What about something as grand as the MMC5, would that be tricky to work with? And while on the subject, would it be possible to combine features of mappers? For example, making an MMC5 derivative where it uses Namco-163 audio instead of two extra squares and a PCM channel?
More advanced mappers don't usually make things too much easier or harder. The reason you don't see many is because a lot of homebrew developers would like to make carts of their game without destroying old games, and stuff like MMC5 isn't hardware cloned and easily available to buy, unlike the simpler mappers. (Could be wrong about MMC5. If I am, I'd love to hear about it.)
Also, if you're making cartridges cost is a factor. More advanced mappers cost more.
Edit: And it's possible to combine features of mappers, or make custom mappers sure. Several carts one can buy or could have bought on retrousb use/used custom mappers.
Edit2: NTRQ is MMC1, as is Super Bat Puncher and Assimilate.
Blade Buster is MMC3, as is Chu Chu Rocket and Hiatus Ward and Neotoxin.
My game used to target MMC1, solely because it was available to buy on retrousb. Now I'm using MMC3 because it's hardware cloned and available on infiniteneslives.com. (Though I'm currently using no actual features I wouldn't have on a simpler mapper. But the scanline counter is attractive for when I get to cutscenes. If I REALLY wanted to keep costs down, I'd probably roll with whatevers cheapest that does the other kinds of swapping I need with no scanline counter.)
Edit3: So it follows that yes, if you want scanline counting, life is easier with a mapper that supports it. And there are mappers with features that are hard to use, I'm sure. But you're not obligated to use those features. You choose the mapper based on the scope of project and what you need/what you're willing to pay for. I'd say in most cases, mappers don't make things easier. They just make them possible in the first place. You can't use extended audio without one. You can't use extra RAM without one. (Well... I guess on some emulator you probably could...) You can't have 256 KB of PRG without one. Scanline stuff CAN be done without one, it's just harder.
I'm really starting to like INL as a hardware manufacturer, he could probably make an MMC5/N163 hybrid, after he's done engineering a mass producible version of MMC5. I chose the 163 simply by virtue of it's sound channels being incredibly flexible. Do you want an extra square, an extra triangle, a sawtooth, etc. Doesn't the FDS do something similar, or is it entirely different?
Speaking of scanline stuff, supposedly the DPCM channel could be used as a makeshift scanline counter, or something to that extent. Maybe it was an IRQ counter. Did any games ever do that, or was it a mostly unused feature/trick? Would that even be useful when you finally get it to work?
OneCrudeDude wrote:
Speaking of scanline stuff, supposedly the DPCM channel could be used as a makeshift scanline counter, or something to that extent. Maybe it was an IRQ counter. Did any games ever do that, or was it a mostly unused feature/trick? Would that even be useful when you finally get it to work?
Bee 52, an unlicensed game from Codemasters, uses the DPCM IRQ as a wannabe scanline IRQ. IRQ happens during scanlines 162..164, and a sprite 0 hit is used at Y=167 (scanline 168) to stabilize the timing. Inbetween those scanlines they read the controller, presumably because it's the one place where they know DPCM samples can't corrupt the controller reads.
OneCrudeDude wrote:
Is the reason why more advanced mappers are ignored is because the games don't need them, or they're harder to work with?
Some of each? As far as I can tell, the more sophisticated the mapper, the greater the quandary of figuring out how to use the features you've been given.
Quote:
And while on the subject, would it be possible to combine features of mappers? For example, making an MMC5 derivative where it uses Namco-163 audio instead of two extra squares and a PCM channel?
As far as "what's possible", the limits have never been really reached:
Expansion audio can be arbitrary, so long as it's monaural.
For backgrounds, each 8Hx1V strip of pixels can have any one of the 4 palettes, so it's close (although short of) a 13 color bitmap.
However, sprites can't really be improved beyond the MMC5's "8KB of CHR for 8x16 sprites and 4KB of CHR for background" mode.
In practice, the real constraint is bandwidth.
Quote:
Doesn't the FDS do something similar, or is it entirely different?
The FDS is a single channel, with controllable automated vibrato. Nice, and actually much more distinctive of a sound than the 163's simple wavetable synthesizer, but, well, not polyphonic.
lidnariq wrote:
However, sprites can't really be improved beyond the MMC5's "8KB of CHR for 8x16 sprites and 4KB of CHR for background" mode.
I was thinking about this the other day, and I guess the main problem for extending the tile addressing capabilities for sprites is that when the PPU is fetching sprite tiles, you don't really know what sprite the tile belongs to (so even if you had extended tile number bits somewhere, you wouldn't know which ones to use).
Maybe it would be possible to reuse some of the existing OAM bits, say the bottom 6 bits of tile number, to expose the sprite index to the mapper (via PPU address lines), and use that to index into mapper's internal memory that would have more bits for the tile number. Just a random thought, haven't thought this one through yet.
thefox wrote:
Maybe it would be possible to reuse some of the existing OAM bits, say the bottom 6 bits of tile number, to expose the sprite index to the mapper (via PPU address lines), and use that to index into mapper's internal memory that would have more bits for the tile number.
Slightly more efficient to use the uppermost 6 bits of tile number instead, so that you can share a few address lines with standard background banking. This basically becomes 4-tile banks for specific use of sprites. By allocating two bytes for a tile, it allows us to address 1-2MB (8x8 or 8x16) of sprite tiles ... and for sprites, unlike for background tiles, the overhead of writing that isn't so bad.
I'm not certain whether we get anything particularly useful by being able to change the effective sprite tile number in the middle of rendering...
If the mapper monitors the writes the CPU makes, it hypothetically could recognize writes to 2003/2004, and capture the unused three bits of the attribute byte (the third of every four bytes), and use that as 3 extra bits for the non-ID tile number.
Kasumi wrote:
Edit2: NTRQ is MMC1, as is Super Bat Puncher and Assimilate.
Super Bat Puncher could probably have used UNROM + WRAM.
Quote:
You can't use extended audio without one.
You can't use extended audio on an unmodified NES anyway.
Quote:
You can't use extra RAM without one. (Well... I guess on some emulator you probably could...)
To put this in hardware terms, the common discrete mappers can be made to have RAM by adding a 74*20 to decode a 6264 at $6000, as Nintendo did to NROM in
Family BASIC.
Drag wrote:
If the mapper monitors the writes the CPU makes, it hypothetically could recognize writes to 2003/2004, and capture the unused three bits of the attribute byte (the third of every four bytes), and use that as 3 extra bits for the non-ID tile number.
How would the mapper know which sprite index mapped to when the tiles were fetched?
As was suggested beforehand, the sprites use 6 bits of the tile number to identify themselves, and I think the idea was to write 64 more bytes to the cart after that. However, I think the core idea behind this is to just have every 4 tiles of the pattern table be individually swappable. With just the extra bytes written to the cart, you could choose a group of four tiles out of 256 unique groups (1024 tiles total), and with the 3 extra bits, it'd be 2048 groups (8192 tiles total).
The first use of this that comes to mind is a game that has 16x16 objects. You'd use the mapper writes to select the character you want to display, and the attribute bits can select 8 poses or animation frames, which'd be great because this information would be part of an ordinary sprite DMA, so it costs nothing extra.
It's important to note that, using this scheme, the page-select bits in the attribute byte have nothing to do with the sprite itself. Sprite 0's attribute byte controls tiles 0-3, sprite 1's controls tiles 4-7, and so on.
You know, I noticed something. With the NES, you generally have to program various tasks (text rendering, scrolling, etc) from scratch each time you need to use it. Modern platforms, at least modern game development software (flash, unity, et all), might already have those tasks already defined, and you don't need to build an engine completely from scratch. Would that be the case? On the flip side, what about developing the core NES engine (for example, that has seamless 8 way scrolling like Gauntlet, or dreaded slope collision), and then using that same engine with each new game? You wouldn't need to program all those features every time you make a game, though the games that could be produced would be limited.
Alternatively, I had an idea for an NES game making program that is -very basic- and can only produce -very basic- games with a proprietary engine. Something similar to Game Maker, where you can use an interface to plot your graphics down, where the guy should be, and buttons that program how fast they should move. Of course, given the limited nature of the NES, this seems more like a waste of time when the game won't be optimized, but the point still stands.
OneCrudeDude wrote:
that has seamless 8 way scrolling like Gauntlet
Gauntlet's way of doing 8 way scrolling doesn't take more than 5 minutes to implement: it "cheats" by using 4-screen mirroring (extra memory for nametables on cart) and the levels never span more than 4 nametables.
But you are correct, there are many portions in a NES game that can be reused from game to game: map scrolling, compression, audio, sprite rendering, etc etc.
OneCrudeDude wrote:
With the NES, you generally have to program various tasks (text rendering, scrolling, etc) from scratch each time you need to use it. Modern platforms, at least modern game development software (flash, unity, et all), might already have those tasks already defined, and you don't need to build an engine completely from scratch. Would that be the case? On the flip side, what about developing the core NES engine (for example, that has seamless 8 way scrolling like Gauntlet, or dreaded slope collision), and then using that same engine with each new game? You wouldn't need to program all those features every time you make a game, though the games that could be produced would be limited.
Modern platforms have more processing power, so it's possible to make highly customizable engines. In old platforms like the NES, versatility equals slowness. Game engines have to be very specific to each game, because you can't waste CPU time on features you're not using. This severely limits the types of games you can make with the same engine and makes the games less unique.
Quote:
Alternatively, I had an idea for an NES game making program that is -very basic- and can only produce -very basic- games with a proprietary engine. Something similar to Game Maker, where you can use an interface to plot your graphics down, where the guy should be, and buttons that program how fast they should move. Of course, given the limited nature of the NES, this seems more like a waste of time when the game won't be optimized, but the point still stands.
Sounds like too much trouble for such a small reward. Most games made with game making tools suck balls, because they attract talentless people who can create a game in a couple of days. Sure, a few people who know what they're doing can make great games, but that's rare. The smaller amount of customization allowed by an NES engine will only make this worse.
I guess you're right, but my biggest fear of NES development is the lack of an interface, and how everything must seemingly be done directly to the metal. As for unused features, can't you just cut them out from the final game? Or is it much easier said than done?
And regarding 8-way scrolling, is there any other way to do it in an artifact free way, aside from hiding them with sprites or a black bar?
There was a good thread about this topic a few months back. I can't seem to find it in a search, though.
An NES game-maker is entirely possible to do. My question is why anyone would build one.
OneCrudeDude wrote:
On the flip side, what about developing the core NES engine (for example, that has seamless 8 way scrolling like Gauntlet, or dreaded slope collision), and then using that same engine with each new game? You wouldn't need to program all those features every time you make a game, though the games that could be produced would be limited.
It's doable, yeah. Battle Kid/Battle Kid 2. The Sydney Hunter thing looks like it's also the same engine. I'd assume the Mega Man games didn't rewrite the engine every time. Tokumaru touched on versatility being slow. There's also versatility being large. An extra 2KB of ROM for some engine features you're not using is significant. And while it's possible to write the engine such that you can undefine the parts you aren't using like
famitone2 has, this is just more work on the engine writer for not much gain. A time vs payoff wall.
It's also worth noting there's not necessarily a shortage of engines and source code available. Pretty much everyone still writes their own stuff, for reasons covered.
Edit: Also an engine is not a game. I have focused my efforts in this topic on why this is hard for engine reasons, but making a game is hard on its own like rainwarrior said some post ago. Have you made games for any other platform?
Quote:
Alternatively, I had an idea for an NES game making program that is -very basic- and can only produce -very basic- games with a proprietary engine. Something similar to Game Maker, where you can use an interface to plot your graphics down, where the guy should be, and buttons that program how fast they should move. Of course, given the limited nature of the NES, this seems more like a waste of time when the game won't be optimized, but the point still stands.
It's possible to make one that does things you might not consider basic, I'm thinking about this now, and am amazed by how much I think is possible here, but someone would have to actually go and do it. It's not a waste of time because of the limited nature of the NES. A person who would know how to program a compiler could very likely do a stellar job of something like this, in a way that there's barely a performance hit from making a game this way rather than just programming it. But it's another time vs payoff wall. It's a waste of time because (if I were writing it just to aid my own development) I could get the game I wanted help with done before the helper project could put on its pants.
Quote:
I guess you're right, but my biggest fear of NES development is the lack of an interface, and how everything must seemingly be done directly to the metal. As for unused features, can't you just cut them out from the final game? Or is it much easier said than done?
I could teach you 6502 from scratch faster than I could build any of the things you're talking about. I could teach SCORES of people 6502 from scratch.
I could start working on the thing right now, and you will be DONE WITH YOUR NES game
long before I am finished if you started right now. Edit: Just start.
This dude knew basically nothing when he started, and he's made slow and steady progress. There's another member here who got a no scrolling screen changing scheme done in less than a month with NO prior 6502 or NES experience. (Though he was familiar with higher level programming.) What gets in the way of a lot of projects is the person who wants it done thinking about how cool it'd be instead of them just doing it.
I guess the general answer to most questions you could ask, is that it's probably possible, sure. I really like it so I'm mentioning this post again (last time in this topic, I promise.).
I mean, as a programmer, the answer is "if we spent enough time making it work it could likely work", but what "enough time" is and whether it's worth spending that time to make it work is the thing. And for that, I'd have to know whether or not it already would work easily and approximately what would need to change to make it work.
(This answer applies to basically any "What would it take to do X in the game?" question. A good programmer never says No unless time or cost prohibits doing the thing, because otherwise the answer is Yes.)
I guess you're right, but I'd be far more inclined to hack existing games to be a little better. For example, I would like to hack the Chinese Pokemon Yellow bootleg and recreate the first generation of Pokemon games for the NES. I'd hack the game to use MMC5 (since the GBC's attributes were similar to the MMC5's) and replace the graphics, essentially make a colorized version of the Pokemon games. If I was more ambitious, I'd even reprogram the battle system and implement some of the features of the newer games. I have no original creativity, sadly, so learning this would be a waste of effort if I have no ideas. Hacking and homebrewing are two different beasts. Unless, of course, I really, REALLY wanted to make a better port of Joe & Mac than Elite Systems managed.
As a side note, I would always take anything the Skullgirls people have with something a bit larger than a grain of salt, maybe a whole saltshaker full of salt. I can't take a game that has become exponentially more popular by a porn animation seriously, especially when said animator has actually been hired as a clean-up artist (and they boasted about it too). At least it wasn't a certain Nickelodeon pilot.
tokumaru wrote:
Most games made with game making tools suck balls, because they attract talentless people who can create a game in a couple of days.
Most games suck balls period. As
Theodore Sturgeon put it, ninety percent of everything is crap. Are you talking LJN bad, Color Dreams bad, or Active Enterprises bad?
Quote:
Sure, a few people who know what they're doing can make great games, but that's rare.
Not every game needs to be
Battletoads.
Quote:
The smaller amount of customization allowed by an NES engine will only make this worse.
But I still think it'd be valuable to have a prefabricated scrolling and sprite display engine roughly as capable as that in
Super Mario Bros. 2, except without the requirement for extra RAM. Then the programmer would just have to write code for how objects are shaped (like adding custom level objects and modifying them for each column's destruction bit), when objects are spawned, and what happens when they collide. From these primitives, one could create a game like
Mario or
Mega Man or
Castlevania or what have you.
Popularity of a game or its reasons for popularity (edit: which... in this case, ain't what you mentioned) do not necessarily reflect its quality , and the quoted programmer has nothing to do with the designs of the characters or what you mentioned.
I believe Mike Z is a pretty exceptional programmer, because of what he manages to fit into Xbox 360's/PS3's RAM. (If you think it's not hard, you're not thinking fully about the problem.) The image formats that make some of that possible have not been reverse engineered, and not for lack of trying. If you happen to respect hackers, you may have heard of
Dantarion, responsible for figuring out all sorts of neat fighting game formats. And then there's
this post by Dantarion. Even if you hate the game/think he's a bad game designer, I think his views on programming are worth considering. I'm not saying he's John Carmack, but he's been around the block. It's cool if you disagree, but I'd say that in general dismissing a person based on a single project associated with them (possibly for decisions they didn't make) isn't too cool. You can miss out on a lot of good information this way. I've learned a lot from artists who have worked on sketchy things as well, for what it's worth. I'll happily PM you further on this if you'd like. It's very off topic, but I couldn't say nothing here.
I'd also say you'd probably have better luck starting from scratch than hacking that specific Pokemon Yellow. You're talking about replacing the entire game, basically.
Yeah, I noticed that might be an issue (with the game), so I would potentially use my development skills solely to port games over to the NES. I'm not sure if I'd have the ambition to do it (or modifying the graphics from other consoles, such as the hypothetical Joe & Mac re-conversion), but I reckon I could get some peeps to help along. I have a good idea of what the NES' graphics are capable of, so I could probably give my colleagues some guidelines as to what the graphics should be like. But porting games would be possibly illegal, though, which explains why there are so few 'direct ports' of games; Thwaite is adaptation of Missile Command, STREEMERZ is a port of the flash game (with Pondunkian's permission, no less). I'm not a good game designer, and I feel the NES missed out on a few arcade classics.