Time Frame for Full Game Development

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Time Frame for Full Game Development

Post by darryl.revok » Tue Jul 28, 2015 9:10 pm

Hello all!

Okay, I have a multi-part question, and I know there are a lot of variables so I'm going to do my best to make it answerable.

First off, I'm wondering what ends up becoming the bottle-neck on producing a full-scale homebrew game, and why there aren't more full-length new games for the NES. I've seen a few, Battle Kid comes to mind, and I know there are a couple others, but I don't know if there are more than ten games the size of a commercial game that have been released in the last ten years.

So I thought the limiting factor would be the esoteric nature of the assembly coding, but I'm not certain. It seems there are a lot of people here who are pretty well versed with 6502 programming and I would imagine there are plenty here with enough know-how to build an engine for a brand new Mega Man style game, Zelda style game, Metroid style game, or what have you. So I'm thinking beyond the coding that designing graphics, sound, levels, testing, etc, alone would take hundreds of man-hours, and for something that doesn't make enough money for one to making a living making NES games, do you guys think that becomes the limiting factor? Having enough hobby time to create all of the game content for something that would take hours to beat.

Does anyone feel like they could make an estimate as to how long different aspects of the development of an NES game would take? I'm trying to get a better idea of what I'm really looking at to accomplish my project. I fully expect that it will be a long endeavor.

I'm starting from scratch with this, so I guess for starters I'm wondering how long it might take to learn enough about the coding to develop a solid game engine, and to be able to modify gameplay elements along the way to adjust play balance and incorporate new features. I'd say I don't want to do something really basic, I'd like to make something on par with some of the better later titles for the system, although I hope to have access to the internet and knowledge bases from those who have gone before me, which should hopefully reduce the time. My goal isn't to become a master programmer for the system, just to make a great game that I like a lot.

Beyond the learning aspect, how long do you guys think it would take someone to actually make the code for the game engine after becoming relatively familiar with it? I like programming enough and it's fun in short bursts but I guess this is the part that I'm most nervous about because it's been a long time since I've worked with a programming language consistently for years, and I know if I take that much time to do the code then it would be unlikely for me to take the time to do the graphics and music and level designs the way I'd like. Once the code part gets done (asides from tweaks) I'd feel a lot more comfortable spending a lot of time on the design parts. Those are the parts that are mostly just fun for me.

Graphics, I guess I have the best idea about. I'm sure it's different from person to person and I know how fast i can do this so I'm fine with that. It all comes down to how many characters and levels I want to make time to do and how many animations I have time to give them, but the more time I feel like I can get to dedicate to this part, the better, because this is where I can invent new varied content.

The music I'm still fuzzy on how it's written. I've seen programs like Famitracker that seem to be more familiar to normal midi music applications and easy enough to use, but then I've read people talk about programming their sound engines and I'm really hoping that the music doesn't have to actually be programmed in writing. I've read about video game composers using electronic keyboards though write their music so I'm guessing that the music can be written in more of a midi-fashion and then the software needs to be programmed on how to specifically interpret the music file, taking into account trade-offs for the capabilities of the hardware. Does that sound right at all?

Now, I guess the last part I'm wondering about is level design. Has anyone created a GUI sort of application for Windows or Mac wherein one can layout their stages while viewing the actual tiles, or does one have to actually program each tile of the layout and then assemble the code to check it in the game? If one does have to type it out, any thought on how long it takes to do something like this for something like say... Mega Man or Metroid?

Okay, I guess that's most of the big questions I'm wondering about right now. Hope you guys can help clear things up and hope it's not too much, or too noobish. Thanks!

User avatar
dougeff
Posts: 2793
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Time Frame for Full Game Development

Post by dougeff » Tue Jul 28, 2015 10:00 pm

A lot of this will depend on you Darryl. How long it will take will depend on your skill set, and exactly what you want to make, how much free time you have. I'm new here too, so take it with a grain of salt. But, I think the main 'bottleneck' is that it's very time consuming, especially the kind of games you're talking about (Zelda, Metroid, etc). The first game I wrote took me 2 months to make, and I can beat it in 6 minutes. The game I'm currently working on (ninja gaiden style) will take me 9-12 months, and probably will be beatable in a half an hour to an hour. Some puzzle homebrew games I've played probably took a few months to make, and are definitely several hours of gameplay.
Music, you can import MIDI to famitracker, yes, but the midi file needs to be made with a different program. It takes me about an hour for each minute of music. I use my own music engine, because famitracker makes huge files that are ROM hogs, and its very user unfriendly interface.
It's good to see more people interested in NES programming. Good luck. Read the wiki. Go to NintendoAge and read Nerdy Nights on the 'brewery' section.

Oh, and you don't necessarily have to code in 6502 assembly. I'm pretty sure Shiru codes in c/c++ and he made some lib files for it. But it will help if you learn some ASM.
Last edited by dougeff on Tue Jul 28, 2015 10:06 pm, edited 1 time in total.
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
rainwarrior
Posts: 7978
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Time Frame for Full Game Development

Post by rainwarrior » Tue Jul 28, 2015 10:04 pm

Honestly, estimating software development timelines is nearly impossible when I know all the details of the project. Trying to write a guideline for how to estimate software development timelines is... ludicrously impossible I think. Ha ha. How could I tell you how long a game might take to make without knowing a single thing about it, or how much experience you have?

I've been a professional game developer since 2007, and I'm still not very good at estimating timelines. With my current project, my initial plan was to make a small game in about a month. I'm coming up on two years pretty soon. :P

The other thing is, you can always revise your plans to meet a deadline. Professional development plans always include a prioritization where parts of the plans can be easily cut to save time. The profesional question isn't usually "how long will this take?", but instead: "here's how long you have, and how much money, what can you do with that?"

Just to offer some real-world cases for perspective: the "worst game ever", E.T. for Atari 2600 was developed in less than 2 months by a seasoned pro. Even a game as simple as Pac-Man took 18 months or so. A few months ago, Miau put together a small NES game in a couple of days: Banana Nana.

You're hardly going to find much consistency in timelines for game development. Some studios are pretty good at knocking out quick games under a deadline. Movie tie-in games tend to go to people like this. That's about as predictable as it ever gets in game development, but you may realize that the quality of this type of game is traditionally low, and that's not even counting the many movie licensed games that fail in development and never make it to market.

Failed and cancelled projects are also part of the professional timeline; I've heard it estimated that at least half of software projects fail, and that meets my own experience, anecdotally. Whatever timeline you hear for a game, double it to account for the other failed game project you didn't hear about. :P

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Re: Time Frame for Full Game Development

Post by Kasumi » Wed Jul 29, 2015 12:41 am

darryl.revok wrote:Hello all!
First off, I'm wondering what ends up becoming the bottle-neck on producing a full-scale homebrew game, and why there aren't more full-length new games for the NES.
Code is nearly always the bottleneck. I can barely imagine a project that's not a single screen where graphics/music would take longer. It's only a matter of how much longer.

I made a simple single screen demo recently and that took maybe 24 hours total? For both graphics and code. 4 hours animating 3 frame walk animations in 3 directions (Only 3 because left/right mirroring). 6-8 hours on the single detailed background. (Maybe longer.) Whatever's left on code.

What did the code entail? A full uncompressed array of tiles for one screen. A second uncompressed array of collision data. Very, very basic collision detection. Displaying metasprites of a fixed size. Sorting said metasprites by depth. A bit of behind the background magic. (So metasprites could walk behind certain things in the background.) An object management system, so different types of things wouldn't need to be hardcoded. A single IRQ bankswap, since the single screen ended up using more than 256 tiles. A bit of naive pathfinding.

Everything was written in a completely unmaintainable way as fast as possible. I had actually planned to do a lot more with this project, but it was kind of just... a simple gift and it still became life consuming. I wanted to have some sprites to decorate the single screen to get some extra colors. Collision between the metasprites would have been nice. Or any kind of interaction between them...

If I had written all of that stuff so that it would have been maintainable in case I wanted to add more to it, it probably could have taken twice as long.

There are lots of interesting gotchas to NES development. My least favorite is getting graphics in the game. I made my 3 frame walk animations. I felt accomplished, like I was done. But then I still had to cut up the frames into 8x8 sprites. And then note those sprites' tile numbers and type them out.

Or write a tool to do so automatically.

(NES Screen Tool provides a way to arrange metasprites. But you'll still likely need to write a tool to parse that output...)

For a small game, you might actually save time not writing the tool. Either way, it's time you have to spend just getting the graphics into the game. For the project I mentioned I only had to deal with tile numbers, because all the metasprites were 2x4 sprites. I opted to type them out. If I wanted to arrange them more arbitrarily, I'd need to also type up their X/Y offsets...

If every metasprite is the same size in your game, this isn't necessarily a problem, but that's rarely the case...

As far as backgrounds... an uncompressed background takes up 1024 bytes. The NES can only really address 32KB at once. So... you could have 32 screens with absolutely no room for code...

You could write compression for the screens. Which you basically need to (or at least should) for a large game, because that's a stupid amount of space for screens. I think screens in my game average like 51 bytes which is 5% of the uncompressed space. But devising the scheme I'm using (and the tools to output levels in that scheme) took a lot of time. And it's not generic. Uploading my code/tools doesn't make them easy to add to a new game. The constraints on RAM/what's needed per game vary widely. So basically anyone that wants to make a large project has to start from zero. Unless you're making a very similar sequel like the Mega Mans.

There are a lot of other smaller things that are tough about nesdev that are hard to explain if you're not really a programmer. I guess the easiest thing to say is you basically won't find "libraries" or open source ways to do common tasks for basically anything but music. You can find some things that will easily display single screens, but those only work so long as your project is ultra small. The second you need things like scrolling or even just hundreds of screens, you're on your own for everything. Reinventing the wheel...

I'd say if you want to make a large project, you absolutely need to know a higher level language so you can create tools to format your data. It could be C, Python, Lua, whatever. Making tools in 6502 as well is possible, but I imagine it'd be hellish.

tl;dr: A larger part than most people expect of nesdev time is preparing data for the console. You can almost never use your data "as-is" like you could on PC. If I had made my single screen simple demo for PC, it'd have taken a couple hours to code? Load and display a png for the background, a more traditional spritesheet for the animation. Use a generic tool like Tiled to create the collision array.
I'm starting from scratch with this, so I guess for starters I'm wondering how long it might take to learn enough about the coding to develop a solid game engine,
Somewhat tough question. My first game took around four months. I started with no NES/6502 knowledge, but had a fair amount of previous programming experience (In C/Lua). Even after the first game was done, I'd say I didn't really know how to program for NES. It probably took another 4 months on a new project to really "get it".

My recommendation is to do the same. Start a basic throwaway project (mine was a clone game) before starting on the project you really want to make. Trying to clean up the code on my first game to progress it more would be more work than making it again from scratch...

I said earlier you'll probably need to learn something higher level to really make a game, and I don't have estimates for how long that might take. It's been a decade since I learned that stuff... It also doesn't help that a lot of the compression/file parsing you'd be using it for in nesdev was way different than the kind of things I was doing when I first learned it.
I'd like to make something on par with some of the better later titles for the system, although I hope to have access to the internet and knowledge bases from those who have gone before me, which should hopefully reduce the time. My goal isn't to become a master programmer for the system, just to make a great game that I like a lot.
I'd be impressed if someone here could make something on par in scale with Super Mario Bros. in a year. (And I'd even let them use a mapper! Super Mario Bros. is impressive to me in large part because they don't...) If you want to match like say... Kirby's Adventure without a team, how's 5 years sound? Something in between? 2-3. And this is assuming you're already good at 6502. But those are just guesses... Like rainwarrior said, it's hard to judge it. It's hard even if you know exactly what you want. (And you only ever think you know exactly what you want. Once it starts to get made, that constantly changes.)

If you want to make a great game, you will probably end up being an extremely competent programmer. Great games don't come from bad or even average programmers.
Once the code part gets done (asides from tweaks) I'd feel a lot more comfortable spending a lot of time on the design parts. Those are the parts that are mostly just fun for me.
The code part will never be done. Yes, not even aside from tweaks. 6 years into my main project, I'm about to rewrite how levels are stored. Yes, the most fundamental thing that's been done the longest. You basically never see everything when you design code. If it were that easy, bugs wouldn't exist.

I, like you, also look forward to the time when I'm only doing "design parts", though. :D A lot of projects would get there before 6 years, but mine does a lot of hard stuff.

The ride never ends... If the design part is what's fun for you, I'd reconsider NES dev. You will be spending the lion's share of your time on code. Especially if you're learning as you go. At least 60%, and probably more like 80%. The four month game I mentioned? I spent less than a week making all the graphics for it. Then rest of the time was just coding it. Really!
The music I'm still fuzzy on how it's written. I've seen programs like Famitracker that seem to be more familiar to normal midi music applications and easy enough to use, but then I've read people talk about programming their sound engines and I'm really hoping that the music doesn't have to actually be programmed in writing.
You either write a music engine, or you use one of the available ones. Music is kind of nice... it's almost the only thing there's lots of engines for. There's Famitone2, there's Gradual Games' Music Engine, there's MUSE, there's Dragnsf (which you have to ask Drag for), and there's even others I don't remember at the moment...

And how it typically works is that each music engine supports some subset of what the NES music hardware can do. You write your music without using the things the engine doesn't support, and then the tools convert your data automatically. Famitone2, you write your music in Famitracker, export the text data and run it through the tool. If you wanted to write your own music engine, and didn't know a higher level language... yes. You'd have to manually type in notes and effects. Because... the way to avoid that is writing a tool that can parse/convert famitracker text output. (Many official games actually had their music typed in manually. Cool stuff like Famitracker didn't really exist.)
I've read about video game composers using electronic keyboards though write their music so I'm guessing that the music can be written in more of a midi-fashion and then the software needs to be programmed on how to specifically interpret the music file, taking into account trade-offs for the capabilities of the hardware. Does that sound right at all?
Famitracker has midi keyboard support, yes. However, NES music typically doesn't have arbitrary note length, which can make just playing a song and it suddenly sounding right on NES difficult. Just making a standard midi or mp3, and then later trying to cover it in famitracker is a possible workflow. But I feel like it'd create hard to convert music, or music that would end up having a larger filesize than if it were written in straight famitracker.
Now, I guess the last part I'm wondering about is level design. Has anyone created a GUI sort of application for Windows or Mac wherein one can layout their stages while viewing the actual tiles, or does one have to actually program each tile of the layout and then assemble the code to check it in the game? If one does have to type it out, any thought on how long it takes to do something like this for something like say... Mega Man or Metroid?
Everyone created a GUI. EVERYONE! Except that one guy.

But like I said way, way above, you basically can't use anyone else's tools for your game unless your game is VERY simple. A thought of how long it would take for a game of Metroid or Mega Man? Hmm... Imagine you've got four labels. The first number under each label corresponds to a single metatile. You check your actual tiles... type one number. Move to the next label. Type the next. Next label. Next number. Next label. Next number. Cool. Now do that 255 more times. Now do all of that 7 more times, if you have 8 different tile sets. Now type up 240 numbers for every single screen in your game.

The include file my map editor currently outputs is around 2000 "useful" lines. Most of them include a binary file which have an average size of maybe 16 bytes? So... you'd need to type 16 bytes for each of those 2000 lines. And my game does not yet have even 1/2 of what Megaman and Metroid have. YOU DO NOT WANT TO BE THAT ONE GUY! You can use a generic tool like Tiled or Tile Studio to draw your maps. But as I've said a lot, you still need to write tools to parse and convert the output of these programs into something the NES can work with.

Here's a video of Miau's editor.

And here's a picture of the level editor part of mine. It also lets me set up palettes, arrange tilesets for the objects, setup background animation, and place objects in the level. It even compresses my text, but that's not part of the GUI.

(Standard disclaimer: My game has actual graphics, but this image focuses on the map editor.) And I get to rewrite this because of the thing I mentioned earlier, yay... :roll: :wink:

User avatar
rainwarrior
Posts: 7978
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Time Frame for Full Game Development

Post by rainwarrior » Wed Jul 29, 2015 12:52 am

Oh yeah, WRT tools, for small NES projects I usually just grab something that already exists like Shiru's NES Screen Tool.

For my large game project, I wrote my own tool: My tools are the Tools of Lizard

Making development tools is part of any game project. The simple ones might have just a python script or two, but any game has unique needs that deserve custom tools.

Tom
Posts: 67
Joined: Wed Apr 06, 2005 5:36 am
Location: Massachusetts

Re: Time Frame for Full Game Development

Post by Tom » Thu Jul 30, 2015 9:39 am

darryl.revok wrote:I'm wondering what ends up becoming the bottle-neck on producing a full-scale homebrew game
Interest. Starting a project is fun and exciting. Finishing one becomes a chore. Similarly, the parts of the project you don't enjoy are what's going to take the longest. I enjoy coding, so that's never the bottleneck for me, but the graphics take me forever.

For instance, I spent about 2 months on the beta version of GemVenture, but over a year beyond that finishing it up the cartridge release.
-Tom

User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Time Frame for Full Game Development

Post by darryl.revok » Thu Jul 30, 2015 10:52 pm

Thank you everyone for your detailed replies. I've thought a lot about your answers, and I still would like to proceed with my NES development project.
dougeff wrote:Music, you can import MIDI to famitracker, yes, but the midi file needs to be made with a different program. It takes me about an hour for each minute of music. I use my own music engine, because famitracker makes huge files that are ROM hogs, and its very user unfriendly interface.
Okay, this makes some sense, but I'm still confused about the music. Okay, so you can import MIDI to Famitracker, and from what I've seen, Famitracker itself is similar to a MIDI composer software, but you say that the files are ROM hogs. So, does that mean that the alternative is to key in the music in code, by tone and note length?
rainwarrior wrote:I've been a professional game developer since 2007, and I'm still not very good at estimating timelines. With my current project, my initial plan was to make a small game in about a month. I'm coming up on two years pretty soon.
Seems to be pretty common with game development in the professional and homebrew communities alike.

I checked out Banana Nana. Pretty impressive for a few days work, honestly. Better than I expected. I checked out Lizard, as well, and I'm excited to play it. Will there still be cartridge versions available even though the kickstarter campaign is over?

Two years seems pretty reasonable for a full game like Lizard. You said you originally intended a month for a small game, but I'm guessing that the scope of the project changed during that month after seeing what the project is now, right? It doesn't look like a particularly small game.
Kasumi wrote:The code part will never be done. Yes, not even aside from tweaks. 6 years into my main project, I'm about to rewrite how levels are stored. Yes, the most fundamental thing that's been done the longest. You basically never see everything when you design code. If it were that easy, bugs wouldn't exist.
6 years seems pretty excessive, unless the project is huge or the work is spaced out. Any idea how many man-hours that might be? You seem pretty competent in the coding from what you said, and you also estimated maybe 5 years for Kirby's Adventure, so I'd definitely be interested in seeing what a very long commitment to a homebrew project could produce.

I planned that the way I'd try to approach design for my project would be to first create a simple map of a few rooms and populate those rooms with every type of tile and character that I'd need to program behavior for, and work on creating an engine which can handle any conditions that I would be putting into the game. After that, it would just be a matter of creating map data. Does that not sound reasonable?
Kasumi wrote:And how it typically works is that each music engine supports some subset of what the NES music hardware can do. You write your music without using the things the engine doesn't support, and then the tools convert your data automatically. Famitone2, you write your music in Famitracker, export the text data and run it through the tool. If you wanted to write your own music engine, and didn't know a higher level language... yes. You'd have to manually type in notes and effects. Because... the way to avoid that is writing a tool that can parse/convert famitracker text output. (Many official games actually had their music typed in manually. Cool stuff like Famitracker didn't really exist.)
Okay, so this makes a little more sense. So, with Famitracker output being a ROM hog, is this why you create a tool to parse the output? Is there any reason that one of the audio software packages couldn't just have a more efficient algorithm? I'm thinking, if I understand correctly, that Famitracker was made for people who just wanted to make music first, so it would dedicate the full resources of the NES to that task, and that people who want to make games create a more limited format to leave room for their game processing and non-music sound effects. Is that on the right train of thought? Do you typically need to use something like C++ to create a stand-alone application for this, or does the software support scripting?
rainwarrior wrote:Oh yeah, WRT tools, for small NES projects I usually just grab something that already exists like Shiru's NES Screen Tool.
Has anyone tried Retro Graphics Toolkit? I don't know much about it, but I came across it one day and haven't seen much discussion of it. I know the author included scripting options and I believe incorporated a level design feature.
Tom wrote:Interest. Starting a project is fun and exciting. Finishing one becomes a chore. Similarly, the parts of the project you don't enjoy are what's going to take the longest. I enjoy coding, so that's never the bottleneck for me, but the graphics take me forever.
Does anybody ever do any collaborative projects? It seems like that would help increase the turnover rate of completed games and keep the excitement up.

User avatar
za909
Posts: 219
Joined: Fri Jan 24, 2014 9:05 am
Location: Hungary

Re: Time Frame for Full Game Development

Post by za909 » Fri Jul 31, 2015 3:52 am

And this is exactly why I had to realise that whatever I was planning could not be taken seriously at all. I jumped into 6502 with almost no programming experience beforehand, and although I could get some things done it still doesn't change the fact that I'm not fast enough and I'm not wired for this as much as most of the other people are here.

My original intent was to just add DPCM functionality to Mega Man 3, but then I realised that it wasn't that hard... so I started a project from scratch, but since I learned how to make a good-enough sound engine for myself I quickly scrapped the idea of using just NROM because I knew I could do better music than the basic hardware features would allow me. And also I thought including cutscenes would be impossible with just the 8k CHR-ROM. So then I moved to UNROM, did all the things to make use of CHR-RAM tile animations because my single-screen overhead view game didn't need any serious draw buffer updates, so my VBlank time could go to updating tiles.
Then I thought... what if I use so much space for graphics and not leave myself enough for progamming...who knows how much I'll need. And then I switched to UOROM... (Same thing as UNROM, just with 16x16kB banks instead of 8)
And it quickly got out of control, mostly because I couldn't keep focusing on one thing. I was doubting my abilities to program everything necessary for the core of the game, but I couldn't move on because I needed the graphics, which I honestly suck at.
There was no way of getting help because I could not promise money because I had no idea if I could finish the project eventually, but couldn't move forward to find out either. And now that I have one month before going to university I decided to give up entirely. Programming has never been my profession, only a fun hobby. But still at least I could make what little I got working. I'd love to collaborate eventually but frankly I'm quite useless here (I can throw together a sound engine any day confidently but that's about it). There are way better programmers, musicians and pixel artists I could ever hope to be.

But to actually say something on topic... all this took 4 months overall (but has a lot of unused routines in it which would've been used during gameplay)
Never mind the CPU usage gray bar, I guess I didn't turn the jsr into a comment in the last build, oh well.
Attachments
ROM.nes
(256.02 KiB) Downloaded 115 times

tepples
Posts: 22223
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Time Frame for Full Game Development

Post by tepples » Fri Jul 31, 2015 8:08 am

darryl.revok wrote:Okay, so you can import MIDI to Famitracker, and from what I've seen, Famitracker itself is similar to a MIDI composer software, but you say that the files are ROM hogs. So, does that mean that the alternative is to key in the music in code, by tone and note length?
Key it into FamiTracker. I've seen one FTM file that was obviously imported from something, not sure whether MIDI or something else, that had one row per NES frame. That's 60 rows per second. I had to remake it using proper row sequencing.

In general, you can export an FTM as text and then import the result into something that converts from FamiTracker's text export format to whatever format a particular music engine takes. One possible problem with this is that a particular music engine's data format might support features that are more or less expressive than what FamiTracker provides. My own engine, used in Thwaite, RHDE, and a few projects by NovaSquirrel, lacks support for pitch slides but provides these features that FamiTracker lacks but which I found important to my own compositions:
  • Transpose a single pattern and use it multiple times at different keys or different octaves, with different instruments, or on different channels.
  • Ability to loop a pattern shorter than the pattern being played on another channel, or start a loop at a time other than the pattern boundary.
  • Couple the triangle and noise channels for more sophisticated drum lines without needing DPCM. Technically, this is implemented as a drum being made of two sound effects, one of which interrupts the triangle channel.
  • Space-efficient storage of sustain phase as a volume ramp.
  • A fifth virtual channel to inject note attacks on top of another channel that uses only the sustain phase, allowing staccato ostinato that plays on top of another pattern of sustained notes.
darryl.revok wrote:Do you typically need to use something like C++ to create a stand-alone application for this, or does the software support scripting?
Custom data conversion tools in my game's build process are command-line tools written in Python.
darryl.revok wrote:Does anybody ever do any collaborative projects? It seems like that would help increase the turnover rate of completed games and keep the excitement up.
Right now I'm on a project where someone else is doing the graphics and I'm being paid to "proofread" the graphics (for things that break NES limits) and write the code.

User avatar
dougeff
Posts: 2793
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Time Frame for Full Game Development

Post by dougeff » Fri Jul 31, 2015 10:10 am

I actually thought about rewriting Famitracker's ASM source code (firstly in a asm6 format), but also removing all the features I don't use, to keep the code small. In the end I opted for writing my own sound engine because of sound fx. Let's say you write a song that uses all the regular channels...but the game wants to use one of the channels for a sound effect. Its much easier to write an engine with this in mind than to convert someone else's music engine to handle multiple queues to the same sound channel.
Honestly, Darryl, if you can code a game anywhere as good as Metroid or Zelda, I'll write the music and engine for you. That's 'if' because the last time I did that, I spent 2 weeks writing music for a game, and the other guy disappeared without finishing it...which brings up another issue with collaboration. While great in concept, not so great in practice.
nesdoug.com -- blog/tutorial on programming for the NES

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Re: Time Frame for Full Game Development

Post by Celius » Fri Jul 31, 2015 11:30 am

This is an interesting topic. The game I'm creating is a side scrolling platformer, where you shoot enemies, pick up power-ups, get points, etc. My first attempt at this project was a total disaster. I came up with some goofy map format that didn't allow you to scroll 2-ways, I was manually moving hardware sprites as the screen scrolled... It was a total waste of time.

I ended up scrapping all of that work, and a few years later, I decided to start re-writing the engine with all that I had learned about programming over those years. It sounded like a piece of cake. I came up with all sorts of simple formats that I thought would be pretty easy to implement. I developed an outline of everything that needed to be done, and started going down the list. Then things started coming up that I never thought of. For instance, sure I have code that can draw an object using sprites, but what about animation? For instance, an enemy is running toward you, and needs to show an animation of running. How do I handle that? For some reason, during the planning phase, I had overlooked that. I had to go back and tweak a lot of things to handle animation.

Once you have everything working, it's time to start building levels, writing AI for enemies, making level music, etc. This sounds easy/fun. You will likely find that you have to go back and make adjustments to your engine to make the game enjoyable. For instance, with the physics involved in my character jumping, it turned out that it was obnoxiously hard to make certain jumps, and it was difficult to fine tune it so that it was easier, but just hard enough to still require some skill. Then AI is about the most irritating thing to come up with. Unfortunately, you can't just tell enemies to "do stuff", you have to figure out the logic behind every single decision an enemy makes. You don't want enemies to seem too smart and act with lightning fast precision, but you do want to present some challenge to the player. Not only that, you have to worry about enemies walking off screen and deactivating themselves, if your game gradually activates enemies as you progress through the level, which is likely as you have limited resources to work with. It's a lot to juggle.

So I would say, the biggest bottle neck is overlooking things in the planning process, and having to make adjustments along the way. You think the game is going to take a few months to complete, but you find yourself working on it five years after you start it.

And a final thought about people not finishing games. Most of us probably quit working on them because we have other priorities in life, or just lose interest.

User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Time Frame for Full Game Development

Post by darryl.revok » Fri Jul 31, 2015 4:48 pm

za909 wrote:I jumped into 6502 with almost no programming experience beforehand, and although I could get some things done it still doesn't change the fact that I'm not fast enough and I'm not wired for this as much as most of the other people are here.
It seems to me that the plus side for 6502 assembly is the fact that the instruction set is very small. That makes it very easy for someone to learn all of the commands at their disposal, so at least that doesn't become the hurdle. Someone with more experience could correct me if I'm wrong, but it seems like due to the simplicity of the language, the actual challenge will from solving logic problems, with a somewhat limited mathematical toolset. That and the willingness to drive yourself crazy sitting in front of a computer screen racking your brain for an answer. I expected this much.
za909 wrote:And it quickly got out of control, mostly because I couldn't keep focusing on one thing. I was doubting my abilities to program everything necessary for the core of the game, but I couldn't move on because I needed the graphics, which I honestly suck at.
There was no way of getting help because I could not promise money because I had no idea if I could finish the project eventually, but couldn't move forward to find out either.
You know, I think your honesty about this situation is probably pretty applicable for most people who begin a project like this. Anyone who's continued a long game project to the end is definitely commendable and I would imagine outside of the norm.

First off, I want to say that I think if someone is doing this for the money, I don't think this is the way to go, at all. I can't imagine that an NES game will ever be actually profitable in consideration for development time, unless there was a huge magical revival of the NES. I mean, it's more popular now that it's been since the release of the Super NES, so it's not impossible. The point is, I think you could make carts profitably, if you already had the software, sure. But even if someone was to make a $10,000 net profit from selling a lot of cartridges minus manufacture costs, spread that $10,000 over 2-5 years work and one would have done much better working for minimum wage. This is probably obvious but I hope anyone in my position, as just now taking the very first steps into NES development, has considered this.

Now, does that mean that there's no reward? Of course not. If someone made a great game, I'm sure they could get recognition for their efforts even if those don't correlate to sales. One of only a couple NES cartridge releases in a year stands out a lot more than for a modern console, and frankly, an actual NES game on real hardware provides something that's different than a PC. Not decisively better or worse, just different. Some people like that, myself included.

You said you couldn't manage to focus on one aspect of the development and I think that's something we all need to look out for. As someone else said in this thread, starting a project is fun and exciting. My question is, why did you decide to get into doing this? I would imagine that we all share an appreciation for the NES and some creative inclination, but the combination of an inclination for coding, graphic design, music composition, sound programming, story writing, gameplay and level direction, as well as willingness to spend years on a project, is a rare thing indeed. As being new here, I hope I'm not speaking out of turn, but I'm surprised to see that most everyone is involved with solo projects. I mean, the community is great for people sharing knowledge to progress their solo projects, but I do still think engines and techniques could be built upon and improved rather than scrapped and started over every time. The way I see it, people have the same to gain from a solo project as a collaborative project, and that's recognition. Nobody's going to get rich, and nobody's going to shine in an area of their game development at which they are not skilled. A credit for a part in a great game would be better to me than full credit for a mediocre or non-existent game.

Definitely though, congrats to those who have completed or are nearly complete on a full game project by themselves. That requires a lot of talents and extreme work ethic.
za909 wrote:But to actually say something on topic... all this took 4 months overall (but has a lot of unused routines in it which would've been used during gameplay)
Sweet! I'm excited to check it out, and I'll let you know when I get to. I've been without an emulator since I started collecting again. I'll play it tonight if I can get an emulator for my Mac and give you my feedback. Still gotta get the PC setup for my development environment.
tepples wrote:In general, you can export an FTM as text and then import the result into something that converts from FamiTracker's text export format to whatever format a particular music engine takes. One possible problem with this is that a particular music engine's data format might support features that are more or less expressive than what FamiTracker provides.
Okay, I think I more or less understand now. Thank you.
tepples wrote:Right now I'm on a project where someone else is doing the graphics and I'm being paid to "proofread" the graphics (for things that break NES limits) and write the code.
Right on. Is this the River City Ransom inspired one I saw posted a while back? How's progress coming?
dougeff wrote:Honestly, Darryl, if you can code a game anywhere as good as Metroid or Zelda, I'll write the music and engine for you. That's 'if' because the last time I did that, I spent 2 weeks writing music for a game, and the other guy disappeared without finishing it...which brings up another issue with collaboration. While great in concept, not so great in practice.
I'll keep this in mind, should I ever get to that point. I'm sure I could at least make something graphically better than Metroid or Zelda, because as someone else said on this thread once, Nintendo didn't really have that great of art direction until Doki Doki Panic, but the rest of the process of making the game is going to be a hurdle. Is sound an aspect that's easy to add to a project after the rest is done?
Celius wrote:So I would say, the biggest bottle neck is overlooking things in the planning process, and having to make adjustments along the way. You think the game is going to take a few months to complete, but you find yourself working on it five years after you start it.
I see. I imagine this is especially true for those with no programming experience. Sometimes it's hard to know exactly which tasks are going to be difficult to solve. Even these character animations I've been working on have been more time consuming than I would have expected even after the first day spent on them.

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Re: Time Frame for Full Game Development

Post by Kasumi » Fri Jul 31, 2015 6:19 pm

darryl.revok wrote:6 years seems pretty excessive, unless the project is huge or the work is spaced out. Any idea how many man-hours that might be? You seem pretty competent in the coding from what you said, and you also estimated maybe 5 years for Kirby's Adventure, so I'd definitely be interested in seeing what a very long commitment to a homebrew project could produce.
The project IS huge. I honestly don't even want to think about how many man-hours it might be. And you'd probably be disappointed by its progress, honestly. But maybe I'll PM you. Obviously share nothing if I do.
I planned that the way I'd try to approach design for my project would be to first create a simple map of a few rooms and populate those rooms with every type of tile and character that I'd need to program behavior for, and work on creating an engine which can handle any conditions that I would be putting into the game. After that, it would just be a matter of creating map data. Does that not sound reasonable?
Some of those steps are like saying "build a spaceship." They'll need to be broken down much, much further, especially if you scroll.

And that process can also be deceptive. If you only create one map, you may not realize your map data is WAY too huge when it comes to "just a matter of creating map data." You want 72 levels and can fit... 8. Or... your RPGs full text ends up not fitting. Or... you want objects on the same screen you didn't plan for in CHR. You'll probably never get to the step of "just making graphics", or "just making maps" unless your game is VERY, VERY simple. You said you wanted to be on par with later titles for the system, though.
It seems to me that the plus side for 6502 assembly is the fact that the instruction set is very small.
Until you realize a thing that takes 100 lines of assembly takes like 8 in C. It's a gift and curse. I think 6502 is very easy to learn, yes. But... using it for anything is time consuming. (Not necessarily hard. Just time consuming.)
First off, I want to say that I think if someone is doing this for the money, I don't think this is the way to go, at all.
Oh, the paragraphs I could write about this. In 20 years when my game comes out, hopefully everyone (here in particular) understands the choice I made.
My question is, why did you decide to get into doing this?
I wanted to make a Game Boy/Color game at first, but couldn't figure it out. :( The NES documentation at the time was easier to follow, so I did that. (Now, I totally could make something for Game Boy. I could make something for any documented console...) People who know about this project assume I absolutely LOVE NES, but it was Game Boy I loved. :lol:

I could imagine myself making a game alone that competes with Super Mario Bros. 3. I couldn't imagine making a game alone that competes with Super Mario Galaxy.

I never thought it'd take this long either, or I probably wouldn't have started. It's like rainwarrior says... hard to predict development time.

Regardless, I'm super happy to have learned an assembly language. I'm entirely self taught as far as programming, and there were some programming concepts I simply didn't understand when I was using C. I used pointers. I didn't deeply understand pointers. I learned why you can't divide by zero when I wrote my own subroutine for division. (It's one thing for people to tell you. It's another to write the thing and see, "Oh. That's what would happen." Also, you can just write a special case to not crash when you do it yourself. :lol: )
I mean, the community is great for people sharing knowledge to progress their solo projects, but I do still think engines and techniques could be built upon and improved rather than scrapped and started over every time.
Techniques are shared. Engines are hard to, like I said earlier. Even with all the free music engines I linked, a lot of people still decide to just write their own because they have specific needs. Some of them might be too slow for my game, for example.

But collaborations absolutely happen. Just generally not on code and I've decided not to write about why.

Super Bat Puncher's Miau has Dave Harris making the music, Battle Kid's Sivak had help with graphics by multiple people, and uses DragNSF to play its music. Some of Shiru's stuff is collaborative too, even though he's more than capable of doing it all alone. Most of the homebrew people really talk about are collaborations.

Interesting timing on this given all the things I've said recently. :lol:
Is sound an aspect that's easy to add to a project after the rest is done?
I'd say it's significantly easier than most other aspects to a game to add/update/replace. But... it always depends on what you're actually doing in your code. Make sure you reserve enough RAM for a music engine (especially for the zero page). That's the main concern.

User avatar
dougeff
Posts: 2793
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Time Frame for Full Game Development

Post by dougeff » Fri Jul 31, 2015 6:48 pm

Until you realize a thing that takes 100 lines of assembly takes like 8 in C.
Try to do some higher level math with ASM, I mean other than having a table of pre-rendered answers. Well, don't, it will drive you crazy. Or, try to do floating point math entirely in ASM.
nesdoug.com -- blog/tutorial on programming for the NES

tepples
Posts: 22223
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Time Frame for Full Game Development

Post by tepples » Fri Jul 31, 2015 7:23 pm

dougeff wrote:
tepples wrote:Right now I'm on a project where someone else is doing the graphics and I'm being paid to "proofread" the graphics (for things that break NES limits) and write the code.
Right on. Is this the River City Ransom inspired one I saw posted a while back?
Yes.
How's progress coming?
One level is essentially done. This means I can essentially just plug more levels in as the art department gets them to me.
dougeff wrote:Try to do some higher level math with ASM, I mean other than having a table of pre-rendered answers. Well, don't, it will drive you crazy. Or, try to do floating point math entirely in ASM.
I actually wrote a decimal floating-point library back when I was considering writing an idle game (Cookie Clicker style) for the NES. I wrote my own multiply, divide, and arctan for Thwaite, and they ended up reused in RHDE and Sliding Blaster.

Post Reply