How much to pay a programmer?

[AlexE]

For such a niche activity as NES game development, I understand that there may not be a standard for how much a programmer(s) should be paid or what method they are to be paid in ($XX per hour, per week, per product, etc.). So, I would ask if someone were to come up to you and present a job opportunity for NES 6502 programming, how much would you like to be paid and in what manner?

How does the scope of the game play into the finances of the project? How many programmers are needed per project depending on the scale of the game? How would one organize the team and keep everyone together? Perhaps there is some kind of online Cloud program that lets everyone work on a single ASM file in real-time similar to Google Docs. Or would the programmers prefer to have separate files to eventually composite into one file for testing?

The more information the better.

[rainwarrior]

For such a niche activity as NES game development, I understand that there may not be a standard for how much a programmer(s) should be paid or what method they are to be paid in ($XX per hour, per week, per product, etc.). So, I would ask if someone were to come up to you and present a job opportunity for NES 6502 programming, how much would you like to be paid and in what manner?

As a ballpark: I think entry level programming jobs in the US would pay at least $1000 a week as a salaried employee. An experienced programmer might earn well over $2000. If you're hiring them as an independent contractor and not an employee (with benefits, an office, support, paying for their equipment etc.) you might expect a 1.5x or 2x multiplier on that rate.

Nothing stopping someone from charging whatever they want, though. Someone who isn't trying to support themselves with the work (e.g. a student whose room and board are otherwise secure) might undervalue their time, and severely undercut a professional rate. Some people might do it just for the learning experience or other interest, but that's a rather personal decision.

How does the scope of the game play into the finances of the project? How many programmers are needed per project depending on the scale of the game? How would one organize the team and keep everyone together?

I don't know what kind of meaningful answer you'd expect to this question. Every game is a unique situation. Assessing and managing the scope and finances of programming work is its own professional job, and it's not an easy one. There's no easy formula for this or generic rules I could give you. It depends on a thousand factors that go into the making of a game.

Perhaps there is some kind of online Cloud program that lets everyone work on a single ASM file in real-time similar to Google Docs. Or would the programmers prefer to have separate files to eventually composite into one file for testing?

No, I don't think anyone would want to be remote editing the same source file in real time, except as a joke or party game. The "standard" solution for this problem is source control (e.g. svn, git, perforce), and you try to keep files separated by task so people can work independently, and not have to waste too much effort merging their changes with each other.

[Kasumi]

Programming is skilled work, so expect to pay more than minimum wage per hour. Even 12 to 15 USD per hour is on the low end. Rainwarrior's covered this.

The scope of the game only factors in in that it'd take longer. A lot of us here could do most of what you see in commercial games. If you're willing to pay for how long it takes, that's all we'd need to know. But making a game like this usually also means making tools. Generic solutions are available for some things (Like Tiled for making maps), but even for many of those a tool still has to be written to make the output more NES friendly.

Working on a single file together in real time is probably a bad idea. There's version control software like git of subversion that allows programmers to collaborate in a slightly safer way. If I'm writing a totally different state than the other programmer (like battle mode vs overworld), we just need to document which RAM we need persistent across frames so we don't step over each other. If we're working on similar things, they just need to talk about what temp RAM is used and what functions do. (And maybe comment why not to change something that may look tempting to change.)

How many programmers etc. depends on the scope of the game too. As far as how we might like to paid, that also depends. I'd charge per task (animation system, background scrolling, etc.) rather than per hour. Others might want something different.

[AlexE]

As a ballpark: I think entry level programming jobs in the US would pay at least $1000 a week as a salaried employee. An experienced programmer might earn well over $2000. If you're hiring them as an independent contractor and not an employee (with benefits, an office, support, paying for their equipment etc.) you might expect a 1.5x or 2x multiplier on that rate.

Nothing stopping someone from charging whatever they want, though. Someone who isn't trying to support themselves with the work (e.g. a student whose room and board are otherwise secure) might undervalue their time, and severely undercut a professional rate. Some people might do it just for the learning experience or other interest, but that's a rather personal decision.

That sounds like something a Kickstarter or Patreon campaign would be helpful for as money is pretty tight on my end for the time being.

I don't know what kind of meaningful answer you'd expect to this question. Every game is a unique situation. Assessing and managing the scope and finances of programming work is its own professional job, and it's not an easy one. There's no easy formula for this or generic rules I could give you. It depends on a thousand factors that go into the making of a game.

Absolutely understandable. As an animator, I am faced with trying to weigh all the variables that comes with the art form to set a rate for freelance (complexity, writing, voice acting, etc.). I honestly wasn't expecting a concrete, set rate, but YOU NEVER KNOW; it doesn't hurt to ask.

No, I don't think anyone would want to be remote editing the same source file in real time, except as a joke or party game. The "standard" solution for this problem is source control (e.g. svn, git, perforce), and you try to keep files separated by task so people can work independently, and not have to waste too much effort merging their changes with each other.

Ah, okay. I'll look into that.

[darryl.revok]

I don't think I'm qualified to give you an answer per say, but I'd be happy to share some thoughts on the matter in hope that they aid the discussion.

First off, I think this kind of thing could potentially be really positive for the scene. Not everyone is going to have both programming skill and art/game design skill. Plus, you've also got to consider marketing, and getting people to buy the product in the end. Not everyone has the willingness to spend a long time programming a game, designing all of the art for it, the music, the money to put up for manufacturing, and the time and talent to effectively sell the product. There are a lot of different aspects that would go into the overall job, and I don't think having more people involved is, in itself, a bad thing.

Now, I only know of one person who's done a contract NES programming job in recent years, I'm new and haven't finished my game, but just in hopes of kickstarting a talk on the subject...

How does the scope of the game play into the finances of the project?

This is both a complex and simple question, I feel. On one hand, obviously, a larger project will have higher costs. More code, more art, more music, those things take time and maybe money.

The part that I feel is a little more complex is how those scale. These are dependent on your design decisions. Are you going to have a different song for every level, or something like four main themes like SMB? If you choose the second option, then adding more scope doesn't increase the cost of development. Are each of your levels going to have unique art, or are they going to recycle tiles from levels you were going to make anyway? You can save development costs there. Will the levels have new enemies and new logic or will they follow the same format as the rest? A skilled developer will most likely create some sort of tools to aid in map creation, so perhaps even you could bear some of the load of level design without programming knowledge.

The gist, I believe, is that the scope is going to affect costs a lot less when adding scope means reusing elements already created and rearranging them.

If you want something that pushes technical boundaries then you'll probably add development costs unless you get lucky and find someone who's already done what you happen to want.

How many programmers are needed per project depending on the scale of the game?

I think this is less dependent on the scale and moreso on how fast you want it done. Unlike a modern console, it's actually feasible for one programmer to make a game on NES.

Also highly dependent on the skill of the programmer, and their familiarity with the workload.

It might be easier to distribute tasks between disciplines, rather than having multiple programmers. As in, hire someone to help with design, someone for music, someone for code, someone for marketing, etc, minus your own strong points, plus the things that you don't have time for.

I'd think there'd be a lot of time involved in coordinating knowledge between programmers. There's a lot that I juggle in my head while I'm working. If you had multiple programmers, they'd probably be best suited to be working on different portions of the program. But, there's still a lot of coordination required, and that adds labor. Necessary labor for a large programming project, but for NES, I'd feel it's questionable at least. If there was need for multiple programmers, it would have to be quite a large game.

[rainwarrior]

Absolutely understandable. As an animator, I am faced with trying to weigh all the variables that comes with the art form to set a rate for freelance (complexity, writing, voice acting, etc.). I honestly wasn't expecting a concrete, set rate, but YOU NEVER KNOW; it doesn't hurt to ask.

If you want a real answer to your question, you should find a prospective partner who understands the work involved and discuss your project with them. Find your lead programmer, and then it's their job to tell you how many programmers you'll need, and what it will cost. Perhaps you've made it your job to come up with the funding, but you can delegate management of programming (including budget and hiring) to someone who knows that field.

I suppose this is just generic business advice, though, and it applies to all areas of work in your project. Nobody's an expert in everything.

[dougeff]

Now, I only know of one person who's done a contract NES programming job

Shiru's made 3 games as contract jobs.

And, I'm currently working on a contract job...and from my very brief experience, a payed project needs to be top down...

That is, someone with management experience and organization skills needs to head the project, find the team members, and set deadlines, and so forth.

The other way (again, in my very little experience) doesn't work...A programmer looking for an artist and a musician, without leadership or direction, will likely end up a failed project that wastes time and makes no money.

So, I guess my advice would be...talk to people who make games like the ones you have in mind. Network.

[AlexE]

Programming is skilled work, so expect to pay more than minimum wage per hour. Even 12 to 15 USD per hour is on the low end. Rainwarrior's covered this.

The scope of the game only factors in in that it'd take longer. A lot of us here could do most of what you see in commercial games. If you're willing to pay for how long it takes, that's all we'd need to know. But making a game like this usually also means making tools. Generic solutions are available for some things (Like Tiled for making maps), but even for many of those a tool still has to be written to make the output more NES friendly.

Working on a single file together in real time is probably a bad idea. There's version control software like git of subversion that allows programmers to collaborate in a slightly safer way. If I'm writing a totally different state than the other programmer (like battle mode vs overworld), we just need to document which RAM we need persistent across frames so we don't step over each other. If we're working on similar things, they just need to talk about what temp RAM is used and what functions do. (And maybe comment why not to change something that may look tempting to change.)

That's what I thought: having a document to separate each step of development into individual programmers based off of memory location.

First off, I think this kind of thing could potentially be really positive for the scene. Not everyone is going to have both programming skill and art/game design skill. Plus, you've also got to consider marketing, and getting people to buy the product in the end. Not everyone has the willingness to spend a long time programming a game, designing all of the art for it, the music, the money to put up for manufacturing, and the time and talent to effectively sell the product. There are a lot of different aspects that would go into the overall job, and I don't think having more people involved is, in itself, a bad thing.

I agree with you there about bringing positive attention to the scene. Much like New 8-Bit Heroes's game Mystic Searches and the documentary that pairs with it, I think a full-scale, professional Nintendo game would help revitalize more interest into retro console development. That can lead to more clean, professional and new tutorials that present information clearly to the viewer like this one I found about Game Boy CPU and assembly.

This is both a complex and simple question, I feel. On one hand, obviously, a larger project will have higher costs. More code, more art, more music, those things take time and maybe money.

The part that I feel is a little more complex is how those scale. These are dependent on your design decisions. Are you going to have a different song for every level, or something like four main themes like SMB? If you choose the second option, then adding more scope doesn't increase the cost of development. Are each of your levels going to have unique art, or are they going to recycle tiles from levels you were going to make anyway? You can save development costs there. Will the levels have new enemies and new logic or will they follow the same format as the rest? A skilled developer will most likely create some sort of tools to aid in map creation, so perhaps even you could bear some of the load of level design without programming knowledge.

The gist, I believe, is that the scope is going to affect costs a lot less when adding scope means reusing elements already created and rearranging them.

If you want something that pushes technical boundaries then you'll probably add development costs unless you get lucky and find someone who's already done what you happen to want.

For the game that I have in mind (a Metal Gear 2: Solid Snake-inspired action-stealth video game), I will be most likely working on game design, story, and music as those are my strong points; I'm still very novice at 6502 assembly and programming in general. I've been learning a lot about how the NES works and its assembly language thanks to meticulously following tutorials. Assuming things work out well, I'd like to use a finished Squeedo synth for the game audio instead of using native 2A03 or other classic expansion chips to a) improve the game's music and sound effects and b) use it as a selling point to invoke nostalgia and awe (a la the same "OMG 16-BIT GREFFIX"-style craze of the 90s). After all, the game is heavily based off of Metal Gear 2 for the MSX computer which used the Konami SCC chip, capable of 5-channel wavetable synthesis making that Metal Gear 2's soundtrack unbelievable given the graphical style that we commonly associate with PSG bleeps and bloops. The Squeedo, according to Membler, is capable of even more than that.

Now if only the NES were stereophonic so I could get that SEGA Genesis hard-panning. That way, the music could be more atmospheric and sound effects could be panned depending on the player's position on-screen. Having stereophonic sound effects could even play into game design where the player has to hide from a hidden enemy based off of whether the hidden enemy is coming from the left or right side of the screen. But that's just wishful thinking since adding true stereophonic sound to a NES via Squeedo (not simply splitting 2A03 to left and right channels) would be a pain to mod if the audio goes exits the console and not the Game Pak through RCA cables. ...That reminds me of some kind of Dolby Pro Logic pseudo-surround sound the SNES had going for it in, like, one game...

As for pushing the technical boundaries of the console, the game I have in mind would absolutely do that. Metal Gear 2's radar kept track of guards moving throughout an entire 9 x 9 playing-field. The MSX, an inferior console (so I've been told), managed to do it in 1990. As to exactly HOW, I can only guess, though I can understand that it must be possible. As to how to format a functional minimap from a pleasing GUI perspective and how to implement it from a programming perspective on a 256 x 224-pixel screen will be a challenge. My thoughts are that it could be placed off to the side like I have below (probably formatted differently in the NES version in a status bar). This may not cause much slow down if any at all because the dots on the radar would be very small and the likelihood of having more than 8 dots on the minimap to cause slowdown would be very low, and the building layout would be either a) done on a scrolling BG layer or b) non-existent like I have in the proof-of-concept demo.

Or it could be in its own un-paused Menu so that the player doesn't rely solely on the minimap to take down enemies. That means that the game continues playing, guards moving and all, on a separate Minimap screen.

However, in the NES Metal Gear games, there is no radar at all since all the guards reset their positions when Snake enters a new screen. This would be easier, but it would make the gameplay more basic and lackluster. A fuller experience is something that I strive for in this game. Something to make Papa Kojima PROUD.

---------------------------------------------------------------------------------------

Metal Gear 2's radar. Snake is the red dot and the guards are white.


The radar from my tech demo (made in Game Maker: Studio). The guards are yellow dots.
---------------------------------------------------------------------------------------

As for recycling assets like enemies and set pieces, that comes naturally to game design. Constantly adding new rules to the game would make a bad game; it is the arrangement of existing enemies in a gradually more challenging way while also slowly adding new elements to keep things fresh that makes a good game.

For example, loop-de-loops in 2D Sonic games are not made challenging. Normally, they are only there to be visually impressive and place nostalgia goggles over the fans' eyes. Skilled players can actually use loop-de-loops as speed boosts by jumping at the apex of the loop onto the decline, though this is never stated in the games' manuals so this is more of an exploit than an intentional game mechanic. As for challenge, loop-de-loops involve making sure you have enough momentum to get over that first incline. Gaining momentum in a Sonic game is as simple as holding down and mashing A to Spin Dash; not challenging. However, if the loop-de-loops had holes in them and spiraled around each other to form a puzzle or to form a branching pathway for Sonic to take, that would be interesting and add more substance to the game besides obligatory nostalgia for the original Genesis games. I'm not saying to REMOVE loop-de-loops, I'm saying to INNOVATE on loop-de-loops.



I think I might be digressing...

As for level art, I think it would be a good balance to have a mixture between recycling previous art assets and mixing it with new ones in order to keep the different locations appear new as well as reserve as much memory as possible. The Retro City Rampage NES video explains how to reuse and cut down on graphical assets pretty well. In the classic Metal Gear games, both NES and MSX versions, the worlds are very large and continuous (meaning they aren't divided into discrete levels like in Mario). Though in the beginning, it is pretty easy to make your way around, it gets pretty hard to tell where you are in the world in relation to your goal. Having landmarks (new art) to help plot out the map for the player would help keep things more manageable and cause less frustration.

I'd think there'd be a lot of time involved in coordinating knowledge between programmers. There's a lot that I juggle in my head while I'm working. If you had multiple programmers, they'd probably be best suited to be working on different portions of the program. But, there's still a lot of coordination required, and that adds labor. Necessary labor for a large programming project, but for NES, I'd feel it's questionable at least. If there was need for multiple programmers, it would have to be quite a large game.

In the case of this game, I think so.

If you want a real answer to your question, you should find a prospective partner who understands the work involved and discuss your project with them. Find your lead programmer, and then it's their job to tell you how many programmers you'll need, and what it will cost. Perhaps you've made it your job to come up with the funding, but you can delegate management of programming (including budget and hiring) to someone who knows that field.

I suppose this is just generic business advice, though, and it applies to all areas of work in your project. Nobody's an expert in everything.

I understand what you're saying here: basically, have people who are the most skilled in their area handle work in that area.

Shiru's made 3 games as contract jobs. And, I'm currently working on a contract job...and from my very brief experience, a payed project needs to be top down... That is, someone with management experience and organization skills needs to head the project, find the team members, and set deadlines, and so forth. The other way (again, in my very little experience) doesn't work...A programmer looking for an artist and a musician, without leadership or direction, will likely end up a failed project that wastes time and makes no money.

The maxim of "get your shit together" carries over from projects of all kinds. I'm an animator who does a lot of work on Newgrounds and YouTube. Myriads of projects fall out of the woodwork and only a handful of them get worked on because of teamwork and planning. Though in animation there is always fun to be had in the workplace (animators make cartoons for goodness sake), it is always grounded in a serious get-down-to-it attitude and I think a creative project like animation and video game-making needs a healthy balance of both seriousness and fun-ness to make a great product; something where money is not the only driving incentive. Everything I have made for the game is entirely preproduction and I don't intend on starting on game dev anytime soon. Ideally, I'd have made several other smaller games before this one as practice in game making both in 6502 and in other languages like GML and C before the production of this Nintendo stealth game.