TheNew8bitHeroes

Sumez - you're 100% correct. In game development, you'll always be working on existing libraries and various layers of abstraction. Your Unity example is perfect - in Unity, you're not making a 3d rendering engine, but you could be making your game logic. In NESmaker, you're not making an animation driver, but you could be making your game logic. That's a perfect parallel. The difference here, though, is that there aren't developers insisting that people who use Unity embed a watermark in their game or slap a big logo on their artwork to denote it was, in fact, a Unity project, and "different" from other forms of game development. But that's what is being argued here. It's a strange cognitive dissonance for anyone to recognize the former but still insists on the latter. Kevin Edwards just posted some really fun stuff on Twitter about working on Silver Surfer and a handful of other NES games, and talked about how just a year or two later, major changes to technology revolutionized and simplified the work flow. But developers with access to the newer tools which made the development process easier and more streamlined weren't regarded as "demoralizing" those that did it the longhand way, charged with labeling their games as using the benefits of new technology. In fact, now in retrospect, you likely couldn't tell me what commercial NES games used what tools in their development. And that's kind of the point. If a game is some reskin of a tutorial, it can just be "well, that's a crappy, cookie cutter game", regardless of tools used to produce it, whether it be a NESmaker game or a reskin of the Nerdy Nights tutorials, or a game slammed together with cargo cult style programming from various places on NESdev. If a game is a quality, unique, original, evocative game, it can just be "well, that's a cool game", regardless of the tools used to produce it, whether it be someone who uses NESmaker as a base, or a combination of Shiru's tools, Git for source control, famitone's audio engine, and code ripped from online tutorials, or literally coded it byte by byte in notepad. Let the quality of output work speak for itself. If a "from scratch" (which, of course, is a relative statement, as you've stated) developer makes a bad game while someone who uses a host of tools makes a good game, recognize the games in terms of the quality of the output, not the production method. That's how every other creative medium works. Putting some arbitrary line in this niche community serves no purpose but to invoke a petty division where there shouldn't be one. If it was made "at home", it was a homebrew. The definition of homebrew is "made at home, rather than in a store or factory." Homebrew video games is defined as "ideo games or other software produced by consumers to target proprietary hardware platforms (usually with hardware restrictions) that are not typically user-programmable or that use proprietary storage methods." Neither definition includes any distinction that warrants some separate classification for using tools to achieve the game's creation.

**Disclaimer: What you see in this post was not programmed by hand. It was created using tools provided by Apple, specifically OS 10.12.6, a code library developed by Google for Google Chrome, and the discussion template provided by this chat board service utilized for this website. I believe that it is imperative that everyone not coding their responses from scratch place a disclaimer at the top of all messages henceforth, so as not to trivialize the work of the programmers who built the foundation for you to be able to reply here. MachineCode - my comments were more for the thought experiment for the whole conversation in response to your reply, not necessarily aimed directly at you. Thanks for the good discussion! Sumez - why is it "undeniable"? Let's take two hypotheticals - a traditional NES homebrewer like those I've known for the past few years, and someone like Mugi, making Dimension Shift with NESmaker. The traditional homebrewer: Would learn the basics in forums and tutorials, doing a lot of cutting, pasting, and tweaking code, seeking advice from other developers on how to manipulate the ASM to make it do what they want. Things like input handling, the header, standard NMIs, drawing routines...they'd be pretty stock. They would use Shiru's NES Screen tool for graphics and level design, they would use FamiTracker for music, and probably FamiTone for music playback rather than writing their own music engine. They would use someone else's assembler to compile. They would use debugging tools in MESEN. Someone like Mugi: Had a starting point template. Started gutting the code to create a module that does what he wanted to do, seeking advice from other developers on how to manipulate the ASM to make it do what he wants. Things like input handling, the header, standard NMI, drawing routines...they're left pretty much in tact. He uses our tile editor for graphics and our screen builder for level design. They use FamiTracker for music, and GG Sound engine for music playback rather than writing his own music engine. He uses ASM6 as an assembler, which is bundled with NESmaker with permission. They use debugging tools in MESEN. Does your distinction lie in the fact that the tools are all collected together in one tool chain? Or is it that there was a starting base to work from, rather than tutorial code? You're making MASSIVE presumptions about people using the tool when you say: Let the work speak for itself. The tools are incidental. No one looked at Ori and the Blind Forest and said, "Yeah, well, they need a Unity watermark on the intro, because those of us who created our own game engines from scratch are demoralized when someone asks if our game was made with Unity". Because that would be dumb. If it takes the traditional homebrewer 2 years to develop their engine, create their assets, and build their game, and it takes the NESmaker developer 2 years to write their custom module, create their assets, and build their game...and they've both personally written the same number of lines of code, and both ultimately have the same understanding of how the hardware works...then what exactly is the distinction? You'd have to be making the case that's not possible. That comes from a place of ignorance...as Mugi or Dale Coop or some of the other developers who came to a better understanding of the NES inner workings FAR faster than most traditional homebrewers I knew... Would you say the same thing about a music engine, or are YOU trivializing all the hard work that went into FamiTracker and FamiTone? Would you say that chiptune artists that want to make music using FamiTracker need to be separated out from chiptune artists that completely build their own tracking utilities and playback engines? Building a good music playback engine is a nightmare for the NES, so I certainly hope you're not trivializing the work of all the people that spent years learning the mechanics and created playback engines by hand, as you put it. But that's different? Because reasons? Again - no one is trying to portray that their intro burner project that utilizes a reskin of the templates is in the same class as Jim Power, the same way no one is trying to portray that their first burner Unity tutorial game is in the same class as some tip shelf indie game. But you know what? Ori is an example of a top shelf indie game that used Unity. Dimension Shift is a top shelf NES game that used NESmaker. The tool is only of interest to those who are more interested in the process than the product. And to be so is fine, but...that's sort of like asking a musician, "I like your music, but did you hand make your guitar? No? Well then you need to say that as a disclaimer on your album cover."

MachineCode - I understand what you're saying. I worked in the music industry since the late 90s. But no human being alive insisted that tapes, records, or CDs come with a disclaimer that the music on them was produced using Pro Tools. That's not a thing that ever happened. You're right that some people thought (and still think) that the existence of DAWs has led to an uptick of attention for mediocre talent, as you described. But it also launched careers of many extremely talented musicians, launched entirely new genres of music, and changed the art of music producing altogether. And analog recording still exists, and those that do it are usually very proud of the fact they record to 2" tape and their music never touched the digital domain, but they don't at the same time insist that anyone who used a DAW imprint that fact on the album artwork. Which is the parallel what is being suggested in this case. It's like saying that the Billboard Charts had to list whether an album was recorded to tape or to digital. Is that really the avenue we want to take new NES games?... Alright. They were the most welcoming to me when I joined this scene as well. I'm not sure how that plays in to the conversation though. Is this mandating of a distinction something that is welcoming those new to NES development, or confrontational and exclusionary to those new to NES development? To me, it's the latter. It's people saying, "Well, you don't do it the way I did it, and I need to make sure people KNOW you don't do it the way I did it. My way belongs to a group that your way doesn't." You say it's not elitism. The definition of elitism is: "Elitism is the feeling or notion that oneself or their group- along with the accompanying ideals and standards- are better than another person's or group's" The Jim Power Kickstarter includes the words "Jim Power NES was NOT made by any sort of game maker program; so the quality of the product is far superior." in its description. That literally could be a dictionary example of elitism.

Since this has come up again, and I've received multiple requests to chime in, and it seems there is still a pretty broad misunderstanding of what "NESmaker" is, does, and how it's being used (as opposed to "non-NESmaker" developed NES games), I thought I'd try and write a definitive write up on this thread to help clarify a few things. It will be thorough and hopefully as objective as I can make it. I've been an independent game developer since the early 2000s and a game development instructor since 2006. I've been actively involved in NES development since around the end of 2013. I chronicled the homebrew scene as part of The New 8-bit Heroes documentary. Besides building our game engine "from scratch" using notepad and an assembler, we got to see (and document) the workspaces/workflows of Joey Parsell (Memblers), Damian Yerrick (Tepples), John White, EDB Holland (Sole Goose), Derek Andrews (Gradual Games), Eli Galindo (Piko Interactive), Jordan Ordorica (Sivak / Battlekid), Frank Westphal (Armed for Battle), Rob Bryant (Sly Dog Studios), Brad Smith (Lizard), Rachel Weil (a bunch of awesome stuff), Brian Parker (RetroUSB), the entire Collectorvision team, James Deighan (now with MegaCat), Kevin Hanley (KHAN Games), Kevin Horton (Kevtris), and probably a handful more that are slipping my mind. I list that group specifically because they are formative in NES homebrew development, and I met almost all of them personally. I got at least a glimpse into their development process, their tool chains, got the stories of how they got into it all and how they built their games. The argument of "tool use" requiring a particular designation: Just about every person on that list used some tool chain to aide in their process. Whether they created their own custom tools to handle things particular to their game, utilized free tools listed on the NESdev boards, or used non-NESdev related tools in ways that could generate or organize necessary data. Many developers (on the NESdev and Nintendo Age forums) started with burner projects, walking through entry level tutorials and building simple games through cargo cult programming (effectively, copying snippets of code and pasting it in their game, tweaking until it worked). Lots of developers farmed out difficult portions of their projects to other developers. Almost everyone that we met used a tracker like famitracker to create music combined with someone else's ASM sound engine (famitone, gg sound engine, and pently being popular examples). Most people used Shiru's suite of tools, like his screen and map tools. There is an epic catalogue of tools on the NESdev wiki to do any number of things. These include full IDEs like NESICIDE and WUSDN that were around long before NESmaker. In addition to NES specific tools, developers use things like photoshop and pixly, they use modern source control for asset organization, they use Notepad++, FCEUX or MESEN emulators for their debugging and PPU viewers, CC65 to write in a higher level language and compile down for the NES,...ultimately too many things to list here. For clarity, those advocating for a distinction between "NESmaker games" and "from scratch" games are not talking about "from scratch" at all. They are of the opinion that all of the things listed above can be used without any special designation, while NESmaker itself crosses some arbitrary border into "uses tools" that needs to be qualified. To me, this demonstrates the absurdity of the argument. I'm sure there are the most rare exceptions, but every single developer who has ever developed a legitimate NES game, from homebrewers to major studios in the 80s, used tools and external resources to a large degree to create their games. So we need to either disregard the "uses tools" distinction altogether, or otherwise be fully transparent of all tools used to create a game. I'm down with either, but the whole thing just seems sort of ludicrous to me. In the professional game world, there isn't some giant clamoring of insistence demanding Ori and the Blind Forest clarifies it was made with Unity so that it can be properly catagorized. There is no assertion that Undertale must be thought of separately from other indie games because it's a GameMaker game. No one is petulantly demanding that Skyrim or Fallout be put in a special genre because they use the Creation Engine. That's just not the way it works, at any level, from small indie titles to major multi-platform AAA releases. Generally, these games have no problem with listing and crediting the tools with which they were made, but use of those tools doesn't somehow necessitate some hierarchy of classification. Being both in the game world outside of NES development and being a part of NES development, there's nothing different in this case except by those who want to invent a difference. But if the charge is that games need to list the tools with which they were made? Great. Then make it a universal point, and have every game list all things not created by them that were utilized in the game's creation so that the player can determine whether or not the level of usage of development tools keeps it within their own orbit of personal interest. Strange gray area cases: Lets pretend that you disagree with the above paragraph. That you believe usage of NESmaker specifically to create a NES game absolutely must be qualified as some different beast than "proper homebrewing". Alright. But let's start with our own studio's in house games. Does a game that we, the tool creator, who have programmed every line of code from scratch, as well as built the tools to better organize our graphics and assets, fall into the same category of requring the distinction? Are they no longer "from scratch?" If so, wouldn't that imply that anyone who builds their own tools needs to list their own "maker tools" and be qualified as not "from scratch"? Because...that would be just about every NES homebrew that exists and likely ever will. Let's say you agree that that's a special case...THAT is a true homebrew and needs no distinction. Cool. What if one of our team members who is not a programmer develops a game in house? That is still our studio's tools, all the programming done in house and from scratch, but by an individual who was not personally responsible for the coding. Does that game require the distinction? Would that mean that an artist at MegaCat that uses their in house tools can't make a game without it requiring a special designation of not "from scratch"? Or, what if we work with an external studio...say we work with Retrotainment and use NESmaker to generate nametable data for screens for a game that uses the physics engine they created for Haunted Halloween. Does that require the distinction? What if Piko Interactive really likes our asset management and organizational structure...they write all of their own code "from scratch", but use NESmaker for graphics and assets because of the ease of organization. Does that require the distinction? Since NESmaker has the ability to expand its use by creating custom plug ins, what if someone didn't use any existing NESmaker methods, builds their own plug ins in C, but utilizes NESmaker because it's what they learned on and they like using it? Even though they have programmed the engine from the ground up and even created their own tool chain, does that require distinction? It's cases such as these which further make the idea of a distinction rather absurd. As people find more and more creative ways to work NESmaker into their development tool chain, what level of usage denotes that this is a "from scratch homebrew" versus "needs to be labeled made with tools" homebrew? Or does the fact that NESmaker was, in any way, part of the development require a distinction? And if so, why? And why only this particular tool? See how senseless that gets? The idea that NESmaker games are template games: No game created with NESmaker that has attempted any sort of legitimate release was a reskin of a template project. There are far more burner project roms that were reskins of the Nerdy Nights tutorials floating around the internet than there are direct reskins of NESmaker tutorials. The feared apocalyptic storm of NES shovelware that was warned of simply never happened, and in fact ALL NES game Kickstarters seem to have benefited from more people getting into the passion of developing in the last two years. For developers that have pursued full releases, an extraordinary amount of work went into the game, including at the code level. Experiencing an awful lot of homebrews, I can tell you that most NESmaker games that are of quality to be released contain MORE custom code than many of the existing "from scratch" homebrews that were created pre-NESmaker. I'd be happy to offer examples for anyone interested. What NESmaker templates allow developers to do is quick wireframes and rapid prototyping, but the default modules that come with NESmaker are hyper-generic with plenty of inefficiencies and bugs. They are starting points to give users the confidence to begin exploring the ASM with real time feedback, and begin truly building their own games. Can a person make a game in NESmaker with zero programming experience? To the same level a person can make a game in Unity or GameMaker with zero programming experience. But there is an obvious difference between a beginner's tutorial re-skin and Ori and the Blind Forest, despite them both using Unity. They might both start with the same base for object management and screen refreshing and sound handling, but no one would mistake a novice user's tutorial project for a polished, professional game, even though they use the same starting point and IDE. For reference, the concept behind NESmaker comes from spending 6 years teaching game development. I learned definitively that for most students, giving a visual wysiwyg front end was the best way to teach programming, because there was an easy visual cue with which to marry the understanding of the code and logic. Unity was a better way to teach C# than trying to write an application in C#. GameMaker was a better way to teach coding logic through their proprietary GML than having them try to start off by just writing straight code. This was true almost 100% of the time for hundreds of students over 6 years. Having gone through the process of learning ASM myself, and watching dozens of others, both more and less experienced than me, going through the same, I am positive I would've learned ASM, and the ins and outs of NES development, much quicker with a tool like NESmaker. Not because it "did it for me", but because it was easier to track down what I was doing and how it was affecting the game. I would've become a better ASM programmer faster. And what you'll see from the majority of NESmaker users is a similar statement - that they never would have learned ASM the old fashioned way, but now they feel they've really grown in proficiency in a short amount of time. So while yes, it is possible to crank out a burner project in a day with NESmaker without doing any programming, it's also possible to crank out a burner project in a day with the Nerdy Nights tutorials or some of the other resources on the NESdev forums with some simple copy and pasting. I'm not sure exactly what the difference is there. Also, many people don't seem to understand that it's entirely possible to use zero of NESmaker's module code bases, and literally write everything "from scratch" inside of the tool, even creating plug ins to use NESmaker in a way that we never designed it to be used. And there are several users doing exactly that. Most use a template module as a starting point to wireframe, and then completely rip out the guts and program better, more efficient, and more game specific routines meant for their game. The idea that NESmaker games are inferior: This is just ignorant. A game is good or a game is not. Just like a novel is good or a novel is not. No one sits around and laments about the merits of a novel based on whether it used Microsoft Word with spell check and a handy online thesaurus, or a Hermes 3000 typewriter, or an in pen on hand-made paper made from trees cut by the authors own hands. Just like a good song is a good song. No one sits around and laments about the merits of a song based on whether it relied solely on live performance with proper mic placements or recorded it multitrack and mixed it using ProTools. There may be purists who are more interested in the craft than the final product, and that's completely understandable. For instance, I love analog recording and am a bit of a tone junky, and I love hearing about clever uses of vintage analog gear in sessions. I'm also a filmmaker, and I love seeing movies shot on actual filmstock and cut with razors in a vintage editing suite rather than filmed digitally and edited in Adobe Premiere. However, that doesn't mean that I think songs that were recorded to ProTools and that used digital plug in effects rather than analog outboard gear need to have a special identifier and be placed in a separate classification of songs. I don't think movies that were filmed on DSLRs and edited with Premiere need to put in a separate bin based on the tools used to film and edit them. And it certainly does not make these output media automatically inferior. Contesting that it does is just...kinda dumb. As always, I love the conversation and the discussion. The goal here, as it has been since I got involved in this almost a decade ago, is to see people make more NES games and keep the system alive for future generations. Anything that is in service of that goal, I am in full support of. Anything that imposes a petty or pretentious layer of elitism which might be detrimental to that goal, I am adamantly against. I'm not sure how that's not the position of everyone who is part of this passion, but...I've just come to accept that there are people who do this that just don't want anyone new in their clubhouse. I hope that changes. I'll keep supporting everyone who is doing something related to NES development, and thanks to everyone who does the same!

@Scrobins - oh, I felt no disrespect. Not from you, and not from @SoleGoose either. And I appreciate the enthusiasm! I only meant to point out I don't think it's as cut and dry as listing xyz games as NESmaker versus 123 games as non-NESmaker, because NESmaker is a tool like any other tool. Users will use it for a variety of reasons, at a variety of depth. For some, they'll learn ASM the same way Nerdy Nights once taught beginners. For others, they'll use it as an asset organizer, the way that Mugi describes. Others will like using the pixel editor better than alternatives for cranking on CHR files. Others will not use a single line of code that has been written and write entire engine's from scratch. And then there are the games that we, or members of our team, will actively be part of producing in some way. For all these reasons and more, the categorization of these games as "something other" necessitating some sort of designation is as arbitrary as considering games that use Unreal or Unity "something other" necessitating some sort of designation. There will be Unity games that are beginner games utilizing some pre-constructed template, and then there will be Hearthstones or Pixar's Coco VR game or the new Oddworld game or the Switch port of Doom. But you don't see Blizzard or EA insisting that Pixar paste a big Unity logo on their Coco VR game. Anyhow - thanks for the chat and the work you're doing to spread the word about new NES games! If there are any other questions on this matter, feel free to tag me!

@Scrobins - perhaps slightly more related to the list and how it is being qualified in that way, it might be more complex than a diametric designation (submitted for your consideration, not as an argument). Just a few for-instances - Mystic Origins / Searches. That's our in house project. That is the project that ended up spawning our in house development tools, which would then go on to become "NESmaker". But to us, those are just...our development tools, no different than any other homebrew who creates things to do things (which they all do). So...is that a game that would be designated "A NESmaker production", considering every single line of code in it was written "from scratch" and the tools are our own? To add to complexity - what if our team's artist develops his Stellarator game further, or finishes out the next iteration of Troll Burner. That, again, is an in house project, using our in house tools. Does it need to be qualified simply on the basis that we have made these tools available for others to use? And then there's the question of how much use of a tool denotes that it is a NESmaker production? If a user, say, uses solely our screen editor to mine screen data tables, but writes all his own collision routines and basic physics engine, is that a NESmaker production? What if a user just uses our pixel editor to generate CHR files? What if they start with a blank module and write all of their own code from scratch, using no existing module? Personally, I don't care either way how these games get classified on lists or whatever. But for anyone that wants to have some declaration of discrepancy, I think established, proper metrics are important. For instance, I would absolutely NOT call Project Blue a NESmaker game, even though they did use it to aide in creating animations. I don't know if it makes any sense to call our own in house games "NESmaker games", as for us, it's the "Mystic Searches Screen Tool and Game Engine" (files are even still called MST files)...and no, I don't think our process in creating our game differs from any other developer who has created a homebrew, since we literally programmed everything from scratch (save the sound engine, which Derek Andrews graciously allowed us access to), so I'm not sure it warrants any distinction. The same goes for Gamer Quest...we're developing that in house for them. We wrote every line of code for it. I'm not sure how that differs from any other homebrew. So it's something to consider when building classifications. If "A NESmaker Production" warrants its own particular label, what level of use qualifies for requiring such classification? And, again, if classification is warranted, what other tools, engines, or development crutches warrant their own similar classification? I'm glad to be part of the discussion. These are things you may not have considered, so I figured I'd open them up as talking points. If that metric will be an integral part of your list, I think it's worth defining. Also, on that note - don't forget to add Mystic Searches (coming soon) and Mystic Origins (a new run available soon)!

Did not mean to hijack - I was alerted to the context of the conversation and that my name was thrown around, so I thought I'd chime in. For what it's worth - awesome to see people making a compendium of homebrews! We are also working on something to help with that, too! You guys are awesome, and thanks for keeping love for this system alive.

I have no problem jumping into this again. SoleGoose - you've made your position known. My contention is that you must hold yourself to the same standard. Every external tool that you have used that eased your development process, you need to qualify. You might have to acknowledge that your game is a Shiru's Screen Tool / FamiTracker / Nerdy Nights game, for instance (not sure what actual tools you used, but...I'd imagine those and others were employed). Make sure that you designate your games as such to meet your own standard of transparency...don't think of it as a qualitative distinction, just be forthright about it and let everyone else judge for themselves, as you are suggesting. If that's the sandbox you want to play in, then don't be hypocritical about it. You still haven't qualified what denotes NESmaker use. Project Blue, for instance, built an engine, but utilized NESmaker to try out animations, because it was a lot quicker to streamline the process using our object tool. By your metric, do they have to qualify their game as NESmaker game, since it was used as a tool in their pipeline? If so, you probably relied on tools like Shiru's screen tool to the exact same degree...so do you consider your games a Shiru's Screen Tool game? Unless you're willing to list in conjunction with your creations every tool that you used that simplified your process, I don't think your request can be viewed as anything but hypocritical. it's really that simple.