Hmm, that's odd about the AVS not working. Not sure why, but it could be that my Verilog code is problematic - first mapper I tried writing after all, so can't guarantee it doesn't do something funny.

I don't have an AVS to test on though, so the only way would be for someone with an AVS to try what works. Or if someone sees a glaringly obvious problem in the Verilog and recommends an alternative implementation. Source is includes for anyone who wants to check it out.

Hmm, that's odd about the AVS not working. Not sure why, but it could be that my Verilog code is problematic - first mapper I tried writing after all, so can't guarantee it doesn't do something funny.

I don't have an AVS to test on though, so the only way would be for someone with an AVS to try what works. Or if someone sees a glaringly obvious problem in the Verilog and recommends an alternative implementation. Source is includes for anyone who wants to check it out.

I could try using different Mapper 30 roms, but I don't know any off the top of my head apart from Mystic Origins.

Hmm, I seem to recall that the Everdrive had problems with the HiDef NES and Krikzz had to do a major refactoring of the mappers to make it work.

And looking at the files in the development folder it looks like the available mapper examples files (which I based the mapper30 implementation on) pre-dates the hidef NES, so would have the same problems. But the mmc5 example OTOH is from August 2017, so might have the fixed.

I'll be back home from vacation this week and will see how the mapper30 code runs on the HiDef NES.

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.

_________________I come from the net. Through systems, peoples and cities to this place.

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.

In the end such measures serve more to arbitrarily filter out games made in easy to use application development suites. I've had to hide which compiler I use several times in order to get fair treatment.

In the end such measures serve more to arbitrarily filter out games made in easy to use application development suites. I've had to hide which compiler I use several times in order to get fair treatment.

Agreed. Not only that, but there's precious little space on the cartridge to begin with, so making a splash screen and a menu that you can't get rid of in NESmaker seems more like a punishment for not knowing how (or not wanting to bother) to program an NES game from scratch. Splash screens and secret menus make more sense for things like Unity or Gamemaker where space isn't a big issue and people can use the program for free.

IMO there is no real need to signal if a game was made with NESmaker or not. If you're playing such a game, and can't tell if it was made with a specific tool then isn't that a good thing? In comparison, if it's obvious the game was made with a specific tool then why do you need a splash screen to tell you that? It really doesn't take much research to determine if a game on any platform is a worthwhile purchase provided you recognize any pre-order is a gamble.

Telling a certain group of people making NES games they need to wear a Star of David sounds pretty elitist to me... I hope most would agree it's not our place to try and regulate things of this nature.

Now if the NESmaker creators wanted to put their own branding in a splash screen as a form of advertisement for their tool or whatever that would be a different story obviously completely up to them. They could also choose the options available to enabling/disabling it.

_________________If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Honestly, I think lots of people would even enjoy having a splash screen for this?

I agree that it will be trivial to defeat as an overt watermark, but I also think it's bizarre that people think the point of the splash screen is to make this stuff wear a badge of shame. Like if you're a person that thinks this is the purpose of the splash screen, I don't understand why you'd even be a customer/client of NES Maker in the first place.

A splash screen is branding, advertisement for the NES Maker, but just as much as that it can easily be a statement of pride in and support of it. If you like what this platform has made possible for you, I could definitely see wanting to acknowledge it with a splash. Isn't this a symbiotic relationship, not an antagonistic one?

My comment was primarily in response to the mentions of the splash screen aiding in the prevention of shovelware. But perhaps I misinterpreted what was being said as we discussed how the feasibility of such a screen may warrant it being there or not.

_________________If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

I don't think it was a misinterpretation, really, but people are saying a lot of different things about it at once. Looking back in the thread, the specific suggestion seems to have started as "engines like Unity and Gamemaker do this..." but everyone's got a slightly different angle on it. Maybe nobody was saying that specifically...

I just think it's absurd if you try to think about Unity forcing a splash screen on their users if they thought it was supposed to mark low quality games. That would be insane. Conversely it seems equally absurd to me to request that NES Maker have a splash screen for that purpose.

Unity puts splash screens on their games to advertise their product. Also their engine is free to try, and you can buy a license to be able to replace that splash screen. (Costs a lot more than $30, BTW.) I think the advertisement is a good reason for NES Maker to have one by default. Someone who feels that they are a brand worth supporting may want to leave it in. This can also cultivate a sense of community around it. I think a splash screen is a good idea, here.

On the other hand, if you believe NES Maker will only produce crap games that need to be marked and identified, you're clearly not interested in buying or using it, and catering to you isn't going to help their project or community, as far as I can tell. At least, that's how I'd view such a request if it were me.

(So maybe the splash screen issue itself is a red herring, but this thought applies to any similar request.)

Ability to customize the splash screen with the NESmaker credit on the bottom half and other appropriate notices on the top might encourage the developer to be lazy and leave it there in order to give notice of copyright in the game and in, say, the webcomic it's based on.

Who is online

Users browsing this forum: Google Adsense [Bot] and 15 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum