The NES is a great system and developing games for it is an awesome thing to do. There's just one problem. A lot of it has to do with knowing 6502 assembly. There have been other ways of doing it, like with NBASIC or C(thou programming NES games with C seems to require special run-time libraries, that, as far as I know, aren't posted online), but it still involves writing huge complicated paragraphs of code. This is probably what scares most people away and why so many NES projects are left unfinished.
So, I have an idea, which I can't execute myself, due to a lack of time and enough advanced programming knowledge, so the only thing I can do is tell it. How about someone creates software, that will make it easier to make NES games. Sure, there's NESICIDE, but it still uses assembly. I'm talking about a more user friendly, easy to use program, close to the level of Game Maker. It's ambitious, I know, but think about how many people will be attracted to NES Game Development. To have all those creative types, that are not very good at programing, but with a little learning and hard work, be able to make their own games and add more to the homebrew scene.
You could say, I'm just whining, because assembly is too tedious to learn and use; that sitting down, busting out lines of code is hardcore and better, since you have more control over what's going on. Still, I think, the NES Game Maker idea is a good one and somebody with enough programming knowledge should give it a try. Perhaps nothing will come out of it, but maybe, it could be successful and could add new people to the community and, of course, more NES games.
I'll probably get bashed with the rest of the community's wooden club right in the head for posting this, but one of my dreams was to be able to make some neat NES games, but the assembly... Oh, God, the assembly... I'm pretty sure there are many more in my position. So, if it could be easier and more intuitive with PC and Mac games, why shouldn't be with NES games, as well?
Think about it.
an NES game maker is not that possible (unless you create one like Dezaemon which abides to the limits), but making a BASIC or C program for it is!
Rob's NBasic is a horrible option, so to get what you need for basic programming, you might as well learn how Batari Basic's code works and make a variant/fork of it to support NES's hardware, or use Famicom Basic.
Or, until then, Stick with C or assembly. They are the only best choices so far, Although more options are in development, such as Ruby, Python and Atalan/Scratch, There's even a C# (C Sharp) compiler in it's WIP stages, I think.
EDIT: I've been in your shoes, AlienX. Everyone knows how it feels being a total newbie, I've been there and back!
Chances are if you view Assembly as an impossible mountain to climb, you can't program anyway. But that doesn't mean you can't do anything. Programming is one part of making a game, but other important parts are the design of pretty much everything else and the art. Both graphics and sound/music.
If you seriously had an idea for a NES game but can't program, you could develop that idea and find a programmer that can help put it together. But I think alot of people don't realize they only have a small part of an idea and don't realize just how much more they need to figure out.
If you can program in BASIC, C, or something similar you can learn 6502 assembly. It's not that hard. It may take time to write things really efficiently but you may not need it to be very efficient alot of the time.
The NES doesn't have the resources to run any flexible sort of "Game Maker" like a modern PC does. I also don't think that assembly program is the "one problem". Infact I think assembly programming is far from the most challenging parts of making a game on the NES. You have to deal with plenty of other limitations, like the number of sprites, colors, tiles/patterns, bankswitching, limited memory, limited vblank time, etc.
MottZilla wrote:
You have to deal with plenty of other limitations, like the number of sprites, colors, tiles/patterns, bankswitching, limited memory, limited vblank time, etc.
That's the point I was thinking about when I read the first post. There have been many posts like this and many attempts and ideas for making the assembly language easier or bypass it altogether (some successfull) but you still have to learn about how the NES hardware works on a fairly low level to do anything worthwhile with it. You could make some kind of game maker engine, but it would likely be limited to games that were variations of the same game.
You might be interested in this awesome upcoming tool:
http://nesrommaker.wikispaces.com/Seriously though, there's only so much you can dumb down the development process of a retro game before the resulting code is so inefficient that it won't be possible to manage much action with enough speed.
Also, for something like this to be as simple as people who can't program would like, this tool would have to provide different game engines for all the different kinds of games (RPG, platformer, fighting, etc.), and that would be a huge undertaking for whoever is making such a tool, and the result probably wouldn't be as customizableā as users would like. There isn't even any guarantee that the games people make will serve as retribution for all this work, because when tools make the process too easy a lot of lazy people start to think they can also make games, but without real dedication all they can come up with is crap.
I believe that dedication is essential for creating something interesting, be it a game, a book, a drawing, whatever. So if you're already dedicated enough to come up with an awesome idea, you can probably go the extra mile and learn how to implement that idea yourself. If you really can't, you can always look for people who share the same vision as you and have the skills you don't. Either way you have to apply yourself, good things don't come easy.
Even batari Basic, which greatly simplified the process of making Atari 2600 games and significantly increased the amount of homebrew games, doesn't help with the actual game logic at all. It just abstracts the video hardware into something that doesn't require the programmer to "race the beam". It allows programmers to focus on their game engines, which still must be carefully planned on a game-per-game basis.
MottZilla wrote:
Infact I think assembly programming is far from the most challenging parts of making a game on the NES. You have to deal with plenty of other limitations, like the number of sprites, colors, tiles/patterns, bankswitching, limited memory, limited vblank time, etc.
I completely agree. The programming language is just a way for us to communicate with the system, and no matter the language you use, you still have to figure out WHAT to tell the system, and that's the tough part.
Even more complex the the specific hardware aspects you mentioned (sprites, colors, etc.) are the game programming concepts you need to master, like scrolling maps, collision detection, physics, object management... that's is the real challenge.
You could do something like this by basically starting with a template game that you "fill in the blanks". e.g. Someone could write a platform game engine and editor, and there is no game code to change and you just replace music and sound and level data. You aren't going to be able to customize character AI significantly without learning to program, but you can make an engine that is very data-driven and potentially give someone a nice tool for it that packages/assembles your data into the ROM and helps you manage the limitations.
The romhacking community already does this with existing games. You can find plenty of tools that are designed to replace data in existing games, especially Mario Bros games. Maybe you should try this approach? The only thing here is that existing games aren't designed with this kind of easy drop-in replacement in mind, so often the details get a bit hairy.
Honestly though, NES homebrew is a niche thing. There are a zillion easy game making tools for modern platforms. In general, people don't come to NES for easy. The reason there are so many tools for PC is that so many people have them and use them. Only a small subset cares about NES, not enough that someone out there already wants to build you a turnkey game-maker.
Anyhow, asking for it isn't going to make it happen. If you really want it: build it, and share it. You might not know how to program right now, but you can learn. If you did learn, would you care about making it easy for others, or would you just go on to build your own thing?
If you just want to make games without having to learn assembly (which honestly isn't the nightmare everyone seems to think it is), just get Love2D, or Klik N Play/Multimedia Fusion or something along those lines. It doesn't need to run on the NES.
Developing for the NES isn't even all that great, either. The only reason to do it is for the "wow factor" of simply doing something on a system nobody would expect, but even after 10+ years time, we barely have anything more than simple demos and puzzles, despite numerous people chiming in with their next big revolutionary homebrew project that they won't deliver (I'm guilty of this too).
Even if you did pull off something impressive, what would it get you? A small community of NES fanatics who are blown away, and maybe a kotaku article and that's about it. Have you heard of Battle Kid? Probably not, but I'm sure you're heard of Knytt Stories, or that goddamned Flappy Bird game. If you really want to make something impressive, it's probably better to do it on the PC, where the kinds of tools you're looking for do exist, as well as a much bigger community to give you support, not to mention a much more accessible platform for people to play your game.
I'm sorry to say, but we're really just a bunch of tired old dorks who won't let go of a 20 year old game console. If you're looking to strike gold, you probably won't find it here.
AlienX wrote:
Sure, there's NESICIDE, but it still uses assembly.
...or C...or qbradq's uc65 extensions.
Drag wrote:
If you really want to make something impressive, it's probably better to do it on the PC, where the kinds of tools you're looking for do exist, as well as a much bigger community to give you support, not to mention a much more accessible platform for people to play your game.
I can see three reasons why one might target a retro platform:
- Some game concepts aren't so great on a tiny 17" monitor, especially those that expect two to four gamepads. Are more PCs than NES or Super NES consoles hooked up to televisions? Slashdot users appear to think there aren't many gaming PCs in living rooms. Modern consoles are in living rooms, but they also have fairly restrictive developer qualifications.
- The cost of making assets (everything in a project that isn't code) for an NES game is within reach of a 1- or 2-man team, unlike on PC or modern consoles where players by and large won't pay for a game unless it's at minimum 3D with high-definition meshes and textures.
- How tight is the audio latency on a PC? I know it's horrid on Android. Modern consoles have low enough latency audio to support rhythm games, but they also have fairly restrictive developer qualifications.
For simple games with no bank-switching, I think it looks pretty feasible.
Thanks for your replies. They really made me think about this.
rainwarrior wrote:
Honestly though, NES homebrew is a niche thing. There are a zillion easy game making tools for modern platforms. In general, people don't come to NES for easy. The reason there are so many tools for PC is that so many people have them and use them.
That's true, but accessibility is one thing, that would affect how many people play the game. For example, if I make a game in Game Maker, it's gonna be only on Windows. In order to appeal to Mac and Android users as well, I must get GameSalad Creator and start making the game all over again. If it's for the NES, more people will be able to play it, since there are emulators for almost every modern system: Windows, Mac, Linux, Android, iOS, Modded Playstations and Xboxes... In fact, someone could make a reproduction cart and play it on a real NES. While NES homebrew projects are niche, with enough advertising on different sites, it could be somewhat popular. "Battle Kid" certainly did. Yeah, I know, it's not that popular outside hardcore NES fans, but it still got some attention, as far as I know.
MottZilla wrote:
You have to deal with plenty of other limitations, like the number of sprites, colors, tiles/patterns, bankswitching, limited memory, limited vblank time, etc.
I don't really mind the hardware limitations so much. I think they give the system character. Sure, they can be annoying sometimes, but you can't make something incredibly advanced on the NES.
I have been making a game, that's for Windows, but in the style of NES games. And I mean, really in the style of NES games, following every noticeable limitation that the system has, mostly in the graphic department. From the limited color palette, only 3 visible colors per sprite, every 16x16 block of background using only one palette; being able to show only 8 sprites in the same row; the fact, that you can't have much going on on the screen, without slowing the system down, due to the short vblank period not allowing you to move all the different 8x8 sprites, that you have; to the smaller, more unnoticeable things, like the fact that sprites, that have been off-screen don't gradually move pixel-by-pixel in screen; rather, they just pop up, near one of the sides. Following all these limitations can be annoying, but it's required for the game to really feel like it's on the NES. Then I thought: "Why don't I just make it for NES?" I have been following the "Nerdy Nights" tutorials, but due to constant struggling with the tedious-to-use 6502 assembly, I kinda gave up on it.
Now I wonder, would it be better to sit down and continue this struggle, and make a game that's, possibly, more accessible to everybody or should I continue making it for PC, which will be easier, but by the end, not that accessible?
I'd say make it for the PC using Pygame, trying to respect the NES limits as best you can. A Pygame game can be played on any platform that supports Python and SDL 1.2, which includes Windows, OS X, GNU/Linux, and Android. I've done this a bit myself:
Wrecking Ball Boy,
FHBG remake
AlienX wrote:
or C(thou programming NES games with C seems to require special run-time libraries, that, as far as I know, aren't posted online), but it still involves writing huge complicated paragraphs of code.
I strongly recommend looking at the Mojon Twins'
two C
projects.
Anyway, the problem with a "generic" game creator for the NES is that the NES only really has enough processing power and RAM to make any one kind of engine at a time: a generic engine that could be a platformer OR an RPG OR a shmup OR a puzzle game would have to throw a lot of versatility away in order to fit. (Alternatively, we could call that "generic engine" the NES hardware, and the software is the set of definitions that pick one of them)
So, ultimately, someone's going to have to write a suite of different generic runtimes for each supported game type in some lower-level language in the first place, and then have an interface to plug the data in. At that point, you might be better off using one of the myriad ROM
level editors.
lidnariq wrote:
So, ultimately, someone's going to have to write a suite of different generic runtimes for each supported game type in some lower-level language in the first place, and then have an interface to plug the data in. At that point, you might be better off using one of the myriad ROM
level editors.
But there's one big difference.
- Level editor for an original homebrew game: You may distribute the end result to the public. In fact, you're encouraged to do so as it may help you land a job at a company making games for modern platforms.
- Level editor for a commercial game: You MUST NOT distribute the end result to the public. Copyright forbids it.
Here's one way I might consider working around it:
- Prototype a game in each genre as a total conversion of a commercial game that uses absolutely none of its graphics. Or prototype it on PC. Just make it fun.
- Someone else makes brand new engines to play the same games, with an architecture that allows a thorough level editor.
- The level editors for the new engines are the "game makers".
What has held back scrolling homebrew is that the skills for step 1 and 3 and the skills for step 2 don't always intersect.
Here are some minor nitpicks, which might affect how your NES-like game will work:
AlienX wrote:
due to the short vblank period not allowing you to move all the different 8x8 sprites
You can surely move all 64 8x8 (or 8x16) sprites every frame. A sprite DMA, which copies 256 bytes (4 bytes per sprite time 64 sprites) to the OAM uses only about 513 cycles out of the 2273 or so cycles of VBlank. The problem with moving many sprites in a single frame actually lies in calculating these 256 bytes of positions, palettes and tile indices, which is done before VBlank. Depending on how optimized your engine, object A.I. and meta-sprite system are, these calculations may or may not finish in time for the vertical blank.
Quote:
like the fact that sprites, that have been off-screen don't gradually move pixel-by-pixel in screen; rather, they just pop up, near one of the sides.
Sprite popping only happens at the top and at the left of the screen, because sprite coordinates can't be negative. They can however scroll smoothly at the bottom and right sides of the screen without problems. If they don't, it's the games fault, not the NES'.
The pop in on the left can be masked by hiding sprites on the left side and the vertical from the top may be hidden on certain TVs. There certainly isn't a good reason to try to mimic this behavior in a PC game. The idea of having the same background, sprite, and palette system is interesting though, but I think no one would complain if you cheated a bit. Afterall, Mega Man 9 and 10 were well liked despite that they go beyond what the NES could do atleast at certain points.
And the fact that even if you do stay within what the NES can do, people may still think you're cheating if you're just smart about how to use the limitations.
Like Tepples and his variable width font and Cookie Clicker title screen.You may as well just cheat. I understand if you like the aesthetic of the limited colors and whatnot, but there's really no harm in doing a little more because unlike the actual console you can.
Retro Game Challenge (And its sequel) is a cool game that captures the aesthetic while being really loose on the "rules".
Kasumi wrote:
And the fact that even if you do stay within what the NES can do, people may still think you're cheating if you're just smart about how to use the limitations.
Yeah, I guess some people will notice, if I do anything like that. Personally I think I will be using very few of these ways to go around the system's limitations. I'll mostly use stuff like putting a sprite with a different palette over another, to simulate the base sprite having more colors (This was used in some Capcom games, like "Mega Man" and "Street Fighter 2010"); Shifting graphics in certain tiles, so that when they're used, they can simulate another background layer with a different scrolling speed (As used in "Battletoads" and "3-eyed boy". "Sword Master" used it as well, but there the tiles already had copies with the shifted graphics, which took a lot of ROM space, as opposed to the trick that shifts them in the RAM, in the other two games). So, if anyone starts complaining, that I'm cheating, I can just point out those examples.
Kasumi wrote:
You may as well just cheat. I understand if you like the aesthetic of the limited colors and whatnot, but there's really no harm in doing a little more because unlike the actual console you can.
I suppose you're right, but I wouldn't feel as satisfied, if I made games, that are supposed to simulate the NES, but are looser in terms of limitations. I have seen examples of people making games, claiming they're simulating NES games, but don't even keep the palette right. That always bugs me for some reason. Not that I hate those games. "Soundless Mountain II" is a good example of an "NES" game not following the limitations, but still being a good demake of "Silent Hill 2". Still, if I'm gonna make games, that simulate the NES, I want them to really feel like NES games. I guess, I'm just being a perfectionist right now, but still
Anyway, you now know, that I've decided to not make my NES projects not actually on the NES, but still following the limitations. I've found out, that Game Maker Studio can not only export it's games to Android and HTML5, but MacOS, iOS and a bunch of others. So, the accessibility will not be a problem, as I'm getting the software. I will keep you guys notified for the NES-style games, I've made, since you helped me choose this decision and find out more about what the newest programs have to offer. Anyone who wants, can judge if the games really feel like actual ROMs, but in .exe, .dmg, .app or .apk form.
In the words of Robocop: "Thank you for your cooperation!"
My favorite fake-NES quirk is the fictional 320x240 square pixel mode.
Quote:
Personally I think I will be using very few of these ways to go around the system's limitations.
They're not ways around them, is the thing. They're totally valid, and people who think otherwise are uninformed.
This is valid and
so is this. (It plays Rick Astley's Never Gonna Give You Up, but it's an actual rom that actually works.)
You'll purposely not use many "ways to go around the system's limitations"? You'll end up with a game worse than it could be on the actual NES. I don't get it. You want to fake slowdown? WHY?! I'm making a game on NES right now that I plan to rewrite in C, and there is NO WAY I'm having the Steam/3DS/Whatever version DROP FRAMES even though the NES one will on occasion! Whatever you do, don't frustrate your player for authenticity's sake. Also, how do you even decide when it needs to slow down? You haven't worked with the console before, you don't know how much (or how little) you could get away with.
Quote:
I suppose you're right, but I wouldn't feel as satisfied, if I made games, that are supposed to simulate the NES, but are looser in terms of limitations.
If you haven't made NES games before simulating them, you'll undoubtedly break rules without even knowing.
Maybe I'm bitter, but my problem with games that try to stick really close to the actual limitations is that they still end up skipping like 98% of what makes development on NES hard. Moving stuff around because you ran out of space in one bank, hard crashes from your NMI taking too long before its final write to $2007. Bank switch hell in general.
The graphical stuff is the easy part. The reason my game has taken so long is because of all the optimization stuff it needs. You probably wouldn't think twice about something as simple as multiplying a number, but that can be really taxing on the NES.
Or like... you could make a bunch of sweet tunes in famitracker that would not only not all fit in a standard mapper's space, but also be too taxing to play with gameplay going on. Or your levels wouldn't fit.
And you'd be satisfied until you're told of something you're doing that's wrong? Would you then "fix" it, even if it made the game worse? Really, it shouldn't make a difference.
Woah, woah! Relax... OK, I understand there's much more rules to the whole thing. I'm sorry I didn't mention it before, but the limitations, I'm gonna stick to, are mostly the graphical ones. Bank switching can be a difficult thing, which is why, I suppose, the homebrew scene doesn't offer a lot of stuff that uses different mappers. Also, I'm not gonna have the slowdowns. I won't put too much on the screen, either. As much as I like authenticity, some of the limitations are extremely tedious, so, I'm sticking to the ones, that one would understand just by looking at a game. I'll still make sure, it's all as authentic as possible, but not to the point it gets annoying. About the Famitracker tunes: I'll make sure not to include much and have each song be no longer than 30-60 seconds. Sorry, I didn't mention this stuff before. Now that I read my previous posts, it really looks like I want to follow absolutely every freaking limitation that the system has. Really, I'll focus on mostly following the graphics rules (Which is still quite some perfectionism, considering I even want to add that popping up effect). Another thing is, I'll never let limitations get in the way of gameplay. It won't feel unauthentic either, because I'll not try anything, that hasn't been done or couldn't be done on NES. So, sorry, I didn't mention some stuff and don't get pissed off, OK?
By the way, the NES-style games are gonna be posted in a thread called "If I made games during the Nintendo age". The thread is going to be in "General Stuff" since the games aren't NES ROMs. Among the projects are gonna be some original ideas, but also movie adaptations and demakes. The adaptations are gonna be of both movies that never had NES games (like "Alien" and "Aliens") and ones that already have games, which turned out to be horrible (like "Back to the future" and "The Terminator"). I'm gonna make some demakes too, because... I love demakes. Come on, who wouldn't want to see how a faithful port of "Mortal Kombat" would look like?
AlienX wrote:
<ambition>
I wish you well but ... Christ allmighty ... it sounds like you'll be busy until 2040. I hope to still be alive then, but I'm already almost 40 years long.
AlienX wrote:
The adaptations are gonna be of both movies that never had NES games (like "Alien" and "Aliens") and ones that already have games, which turned out to be horrible (like "Back to the future" and "The Terminator"). I'm gonna make some demakes too, because... I love demakes. Come on, who wouldn't want to see how a faithful port of "Mortal Kombat" would look like?
Now that's pretty interesting. I love demakes too, adapting advanced graphics and logic to less capable systems in a way that doesn't feel crippled is fun as hell. And it would be awesome to see a proper Back to the Future game, that actually gives you the power to travel through time and alter the future. And flying the DeLorean. And hoverboards. Yeah, I really like BTTF.
Aliens was actually done on the NES/Famicom. It was just never released.
http://dreamandfriends.com/2011/01/06/a ... nreleased/
Yes, it's a port of the MSX version, which wasn't a very good game. And from what I see, the Famicom one may be even worse... except for the graphics, they're actually better than the MSX game. I'm not saying, that I can make a great game, but it'll be significantly better than this one. At least I won't have enemies, that jump out right next to you or short jumping. Also, the story could be adapted better. Sure, you're Ripley, going around shooting aliens, but that's about it. There are so many different things you can add. The battle near the reactor, the APC rescue, the attack near the medic bay, Ripley going into the Hive to save Newt, Ripley in the Power loader versus the Alien Queen(that could be a great final boss battle). Even if this game was released, it was going to be a failiure. It probably wouldn't be more fun than "Alien 3" by LJN... ugh, don't get me started on that one... There still wouldn't be a good "Alien" games on NES(unless like the Angry Video Game Nerd, you like to say "Yes, there are. They're called 'Contra' and 'Metroid'"). There should've been a decend one. The Xenomorphs deserve it.
You're not going to convince the current generation of NES programmers to write anything like batari BASIC. Hobbyists use their time as a creative outlet. It requires a huge shift in thinking and an enormous amount of personal sweat + tears to develop a third generation language accessible to the novice.
The ideal solution is to learn C and NESICIDE. After that you could write a meta compiler that takes your own scripting language and translates that into C. If you still had enthusiasm after that you could make your own visual RAD tool similar to Game Maker on top of your scripting language.
UPDATE: Just to be clear NESICIDE *IS* the real-life-right-now-best-as-it-gets answer to your topic.
Thanks for the advice, but you're kinda late.
See the entire thread.
AlienX wrote:
Thanks for the advice, but you're kinda late.
See the entire thread.
Yeah. I saw that you went Game Maker. This is the best way to work with what you know now and ease into console development.
My hope is that you try again someday. There is a BASIC compiler for the Genesis. You could make NES style games pretty easily that way - and on a real console too!
http://devster.monkeeh.com/sega/basiegaxorz/
I've always said that there should be a metasprite editor (mostly for the SNES, but NES could use one as well) but I usually get responses like "everything should be tailored specifically for your game" even though you can have much more impressive animation in a much shorter time. I'm not a C++ expert, so don't expect me to make my own.
If you don't like C++, you could learn Python and make your metasprite editor in PyGTK.
There's a metasprite editor for NES in NES Screen Tool. It's not the greatest metasprite editor around, but it does the job.
I added a simple metasprite editor to MapEd Pro. If anyone is interested, I could post an update.
Animation formats:
Code:
1: [FRAME, TIME][...][CTRL_CODE]
2: [COUNT][FRAME, TIME][...]
3: [START][LENGTH][TIME]
Frame formats:
Code:
1: [COUNT][Y, T, A, X][...]
2: [COUNT][A][Y, T, X][...]
Coordinates can be signed or unsigned. It doesn't cover all cases, but most of the commercial games I've seen used something similar.
I've been testing other things that were added to the program, so I haven't posted a new version in a while.
I just came up with another solution. For my future SNES games, I'll implement variable slot height into my self-defragmenting variable sized slot dynamic animation engine. So far, only variable width have been implemented. This means I can have a 32x40 sprite stored in ROM without compressing it to fit within 64x16, without wasting too much extra room.