JoeGtake2 wrote:Hey everyone - so...this is Joe, proprietor of this wacky concept. Even though I have met so many of you and done everything in my power to be a force for awareness for what everyone here is doing over the past three years and hoped I'd fostered good will, I dreaded coming here and finding this community's backlash to this project, and have been sort of putting off coming to see what was said in this thread. I honestly feared the worst. I was pleasantly surprised to see at least a good handful of you have voiced some level of support, or at least helped correct misinformation. I wanted to come on personally and answer some questions.
That's a natural fear to have, as tools often touted for good, always get used for nefarious uses. See Unity, See asset-flip/fake-games made with Unity on Steam.
JoeGtake2 wrote:
All the while, we continued to get requests for the tool from people who had seen it at conventions. When I say requests, I'm saying hundreds of people. We got together with Paul Malloy from Infinite NES Lives and built a system for one-click deployment to a cartridge. At that point, we debated whether or not to make this tool available to the people that wanted it. There was a lot in the tool that was hacked together for our purposes, and we realized it would need a lot of work on UI design, and needed lots of tweaking to actually be as intuitive to a new user as it had become to us. We wanted to build more comprehensive graphics editors, a music composition tool, more options for arranging memory to fit genre needs (allocating more text allotment for RPGs, scrolling capability for platformers, etc). Thus...the Kickstarter, to allow us to hire our tool developer, who is a freelance programmer for a living (it's how he feeds his kids and keeps his lights on) full time for as long as possible. We decided that if people wanted it, we'd build it and make it as cool as we possibly can. If they didn't, no harm no foul.
There will always be interest in tools, even if people don't really have the skill to use it. Such tools don't exist very long, or operating systems (*cough*cough*windows*) change too much over time rendering the tools inoperable, and any knowledge of how to use them becomes lost.
JoeGtake2 wrote:
Which brings us to now.
As to some of the concerns I've seen on this thread...
One of the things I've noted is the concern over the shovelware that will be created as a result of this tool.
That's a valid concern, veeery.
JoeGtake2 wrote:
I do understand this concern. Honestly, I do. However, I want to offer an anecdote from my decade of teaching game development (I taught game development in Baltimore City Public Schools for many years, and helped shape and pilot the curriculum for the city's CTE program). While teaching, I had a mixed bag of students as far as interest and competency goes, some of whom were still struggling with basic algebra and had never seen a line of code. I used to start them off in GameMaker. We would launch straight into the GML (which, if you're unfamiliar, is a pretty simple high level proprietary scripting language), and most of them would straight up shut down. It was *too hard*, not because it was beyond the, but because it was foreign and because they couldn't get beyond their own sense of it being too hard. So then, I began teaching the simple drag and drop functions, which they'd immediately latch on to and would gain profound confidence, which also spawn their ambition. They'd start asking "Well...how could I do this cool thing I want my game to do?" I'd tell them that the only way to do it was by using code. At that point, we'd go back to coding, and I swear, even the least capable student in the class would say, "Man, why didn't we just START with code? It's so much easier!". And I'm talking about the exact SAME kids who originally considered coding too hard.
That's my issue with a lot of "Framework" packages of libraries that exist for existing tools. People don't actually know how to code anything because they don't have any concept of how the underlying code works. The nice thing about "javascript" that we see in web browers, is that current games (that don't use webasm) in the browser can just be inspected and you can get an idea of how the game actually works. RPG Maker MV, and Visual Novel Maker are current HTML5 game engines that students can use and inspect code to see how code works, but the underlying libraries may still feel like a blackbox since too much stuff is on top to see how it works.
JoeGtake2 wrote:
But let's go worst case scenario. Lots of people get NESmaker, they never push it beyond making clone games with the default engines. Well, that's effectively what the ROM hacking community has been doing for decades now, except in this case, at least it's legal and more malleable on the user side. Rom hacking has absolutely kept interest and investment in the system alive, and has actually produced some great 8-bit experiences, tools, and fundamental understanding of what the system can do. Even if 1% of the Kickstarter backers make really cool games that are worth playing, that's 14 new NES games that may not have existed otherwise. And yes, despite Unity and Unreal and GameMaker being simple tools for creating games, leading to plenty of shovelware, they've also helped developers create amazing games for their respective platforms too. Hopefully, the same will be true for this. That's our goal.
About the extent of "preventing shovelware" I'd suggest three things:
1) Boot screen (showing both the tool name, and any modules loaded into it, be it icons or just some kind of barcode)
The reason boot screens exist is to identify the software used, and to credit the tool maker if no money changed hands, this is reasonable unless some extra space needs to be squeezed out.
2) Credit screen (again, showing the tool name, modules, and credits for the tools used)
Likewise with the boot screen, but this should also be triggered with a button sequence on the menu if it's not available.
3) Compile date and time, checksums.
This should be prominently displayed somewhere (menu, settings, options), especially when used with real hardware (eg FC/NES, NT Mini, AVS) so that any bugs found can be checked against the version of code used.
And IMO, the reason so much shovelware ends up being created with GM/Unity is because there is an asset-flipping steam-scamming industry around it. NES or SNES tools are not really any more likely to have for-profit shovelware, but because the amount of working compatible hardware out there is not going to be growing, so it's very likely these games will be distributed as rom files, which means they will mostly not be profit-driven.