Kasumi wrote:
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.
darryl.revok wrote:
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.
Quote:
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.
darryl.revok wrote:
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.
rainwarrior wrote:
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.
dougeff wrote:
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.