The NESMaker Distinction

[FrankenGraphics | 104]

As a homebrew game designer and developer, i think it is interesting to know what tools people use and for what. A detailed list in each titles' own thread can prove valuable for comparing notes. For example, project blue used the following tools (skip if not interested)

-NESICIDE - Project organizing and general IDE features. Donny swears by it; i've yet to give it a good chance. 
-CA65 - the assembler nesicide is a layer to. I also used it in of itself as a binary file splitter/merger/concatenator/maker for my graphics as a replacement for the command line tools linux users take for granted but us windows users lack. For example useful for me for moving text and hud tilesets from one 4k graphics table to another. 
-NP++ and Sublime Text - i edited assembly data tables for my graphics with these. I use both to separate what i'm working with at the moment. 
-Blarggs' NTSC artifact generator for checking what the graphics might look like on that (i live in a PAL region)
-NESST - my single most important tool. i drew the backgrounds and sprites and animated my metasprites in it, made level prototypes, explored and analysed tile reuse efficiency with it. 
-Donny's custom level editing tool for PB. We couldn't have done the actual levels without it. 
-Photoshop. Some things just can't be done with NESST, like sprite overlays over backgrounds and animation timing previews. It is somewhat clunky though. 
-NESmaker. In some cases, it proved a quicker way to preview if my animation timings and metasprite compositions checked out right by making a little "faux game" with an animated object on screen. This saved me some time from not having to use photoshop to that end. 
-I-CHR by Kasumi. I used it for importing my sprite overlay work in photoshop into a tile format the NES actually can use. If you provide a palette reference so I-CHR knows how to index colors, it's great for this purpose. 
-RetroUSB PowerPak for testing on a PAL system. No emulator gets this right, and that's a fact i'd like to stress.
-INL:s rom burning soft- and hardware to make an actual test and see if broke studios' PCB was compatible with our game and said tools. 
-mesen, nintaco, nintendulator and fceux. 

I think the key here is there's different ways to use nesmaker. In this case it was used as a tool among other tools, but not generating any assets that went into the game other than knowledge how to proceed using NESST. It might also be used as a tool to produce assets that might acutually go in a game written from the ground up. It may be used and modded so extensively the resulting game loses most or even all traits of the original engine. It might be used with a significant amount of modification but still be recognizable as a "nesmaker game" by someone with a bit of technical insight. Or it might make a game without a single line of code modified, which was original sale pitch. It seems to me, there's both a lot of nuance, and a wide array of possibilities here. 

Categories aren't very good at nuance. But they're good at structure. I find them helpful. Because since NESmaker (toolset, interfance and above all engine) does a lot of hard design choices for the user (which can be seen as both a pro and a con, depending on both user and context) is the most form-giving tool to date. Yes, you can do pretty much anything with NESmaker given you have enough motivation, time, and skill, though at some point, the GUI and/or the original codebase will inevitably be too tight a shell because no GUI can ever cater for every need. like i think might be the case with mugis' game? 

One point in the previous thread i got stuck on a bit..

I don't think i agree with comparing the NN tutorials to NESmaker and say it's equally a form-giving platform. For me there's three five basic categorizations. 

1) stray example codes and tutorials. NN would fall into this category. As would joypad reading and warmup initialization examples on the nesdev wiki. You learn the basic ropes, but none of this is significantly formative for the game you are designing. It would take an expert time to disassemble or debug to figure out what method was used. Learning from or even copypasting that example code is a bit like knowing how a pawn moves on a chess board - it influences the game in the slightest possible way, because the examples are atomic. It's up to you to connect them and the combinations are infinite. We might not even have decided to use a chess board for our game yet!

2) Actual libraries. Like NESlib, or nesdougs' (derived?) mmc3 library. These provide you an easier, more human programmers' interface with the hardware in exchange for some restrictions, and those restrictions start to shape the game design in subtle ways if you know where to look. For example, if you're using NESlib, say goodbye to using colours #$2d and #$3d in conjunction with the fadein and fadeout routine, because these routines will en/decode these colours wrong. Now we might have decided we'll use an 8 by 8 square grid for our chess game, and maybe with two zone colours even. We haven't decided on the rules yet though.

3) Drivers. These are complex, monolithic blocks of code that function in a specific way towards a specific goal. In nes development, we benefit greatly from music drivers. It is fairly easy to figure out what game uses what engine by means of it features, even if composers can do their best to hide restrictions with creative tricks. There are still very distinctive things like exactly what it sounds like when an SFX cuts the music, how much the engine affects the general performance of the game, and so on. At this level, we're starting to see some classification of basic opening moves in a chess game, but they do not define all of the game alone either. I'm going to stop this chess analogy because it sucks, haha. But you get my point.

4) Whole engines. family BASIC, Bob rosts old nintendo BASIC engine, Mojon twins' engine (sorry, don't remember the name) and the different NESmaker modules would fall in this category. Now we're really narrowing down the design to a pragmatic but of course also limiting set of features. Through all these layers of platform building through steps 1-4, we've made a lot of hard design desicions along the way. 

5) Engine specific IDE. There's only one of its kind to this date here, which is NESmaker. Neciside might be an IDE, but it virtually assumes nothing about the game meaning you need to figure everything out yourself, but on the other hand, no doors are closed. It's a tradeoff, and i want to stress i don't think you could say one is better than the other. It depends 100% on your use case. I might not agree with every decision about the NESmaker interface *personally*, like how it autogenerates some code (locks you out of editing some stuff), and how assets are managed, but it might just be right for somebody else with a different idea or a different goal. The point here is, the interface is another formative layer for the game design. My NESmaker project "Garbage Hunter" can attest to that. 

So why do i list these layers of distinctions? What gives? 

I think it's not just about the same relative ease somebody can hit "assemble" on the final NN tutorial and hit "assemble" in NESmaker, because what comes out of NN is barely a game even by early 80s standards. You still have all the technical design work in front of you. With NM, you have most of the tech stuff done with at your first hello world, and with it a lot of design decisions about your game. This is super helpful to newcomers, and i think that's the promise of NESmaker. But it also means NESmaker games start out very distinctive and with a low "make" threshold, meaning a lot of games start out seeing publicity and sharing that same distinctiveness. I remember when i saw "dungeons and doomknights" trailer, i thought "oh that must be one of the first nesmaker games to 'go public'". I don't know where that game is now except i saw a pretty cool looking dragon fight screenshot lately, but anyway. Most nesmaker games have a distinctive graphic style as well, which has a lot of variation within its own biosphere, but which you often can trace to the underlying metatile and path structure of the CHR RAM. I can't say i would know heads or tails if i looked at Nebs n Debs or Twin Dragons if they started out as NN tutorials or something else, though. And i'm not sure if i would be able to tell mugis' Dimension Shift had a NESmaker origin from a trailer either (sorry i haven't had the time to actually play it yet), because there is so much work done to make it distinct on its own terms.

So yes, i think it's interesting to know what engine or tools a game was made with and see if i can trace its "DNA", because these things matter to me as a nerd. And NESmaker is probably the most significant change in the creative output and demographic of scene since shiru's NESlib (or zooming secretary that proved C was viable for some game designs). 

So there it is. I think it's useful, because it's simply put significant and, generally speaking, distinctive. Not because NESmaker games are somehow inherently "worse" from other NES games or anything. Does any of this make sense?

I guess it depends on the intention of the use of the label more than anything, too. 

Edited lots of times to make myself less incoherent. 

Edited November 15, 2019 by FrankenGraphics

[Mugi | 83]

i believe the point Joe was trying to make with his comparison of NN and NESmaker was that like he said himself, you CAN load an empty module into nesmaker.

which then does not assumen a single anything about your game. Yet the example code is still there.

to your empty module, you CAN load a routine to read a controller.

Yes, it comes with modules that lock you in ways, and do A LOT of the dirty work for you (a full, albeit simple, in some ways game engine.) but you can also get nesmaker, and start from literally nothing but code examples that are bundled with it.

 

as far as my case goes... dont tell this to Joe but I had to go and take a Hex editor to nesmaker already to make it do some things it doesnt normally do, because that's how much different the codebase is now, it quite literally does not even load into nesmaker without throwing hissy fits about a lot of things, including the fact that we compress our CHR's and we set them up completely differently than nesmaker's default chr allocation is set-up.

I also have the added excitement of having the UI crash on me if i click on certain elements on it, such as the object handling

as such, im still learning the ropes here, and nesmaker is a fairly secure enviroment for taking one's first steps, so im not willing to completely ditch it just yet.

[FrankenGraphics | 104]

I don't mean to be contrarian, but for the intents of my previous post; assuming nothing is what nesicide does. While both are IDE:s, their respective design philosphies rest on different use cases. 

In my experience, a small but still very significant amount of Game design is actually built into the GUI itself of NESmaker (not even counting its auto code generation at build time) and that's one big thing that sets it aside from nesicide, with both pros and cons that will depend on your goals. Then there's still the codebase... Even an empty module is a lot of assumed game design concepts and technical priorities. You still have the big common denominator of all modules in that empty module. And if you clean *it all* out and really start writing from scratch, i think it would really pay to make a thorough comparison which of these two IDE:s would be best for your (not meaning literally your DS, just any hypothetical) game project in the long run. Which is of course hard do do without experimentation because there is hardly any reviews of either, at least not without a lot of bias. But basically, you wouldn't need to hex edit nesicide to make it comply. The price you pay for that freedom is that assets creation like levels and screens are wholly external. 

On the other hand, if you mean to write a new module for others to use with nesmaker (like dale_coopers' 2 player module), i think it makes perfect sense because it provides more and more variety to the non-coding or light-coding end users. 

Edited to relate more to mugis reply with the hex editing stuff.

Edited November 15, 2019 by FrankenGraphics

[gauauu | 81]

Just wanted to chime in and say I completely agree with your categorization, Frankengraphics (hmm... It won't let me tag you from the mobile editor).

 

[Deadeye | 1,595]

Thank you @FrankenGraphics, your thoughts are very well put together.

[Mugi | 83]

25 minutes ago, FrankenGraphics said:

I don't mean to be contrarian, but for the intents of my previous post; assuming nothing is what nesicide does. While both are IDE:s, their respective design philosphies rest on different use cases. 

In my experience, a small but still very significant amount of Game design is actually built into the GUI itself of NESmaker (not even counting its auto code generation at build time) and that's one big thing that sets it aside from nesicide, with both pros and cons that will depend on your goals. Then there's still the codebase... Even an empty module is a lot of assumed game design concepts and technical priorities. You still have the big common denominator of all modules in that empty module. And if you clean *it all* out and really start writing from scratch, i think it would really pay to make a thorough comparison which of these two IDE:s would be best for your (not meaning literally your DS, just any hypothetical) game project in the long run. Which is of course hard do do without experimentation because there is hardly any reviews of either, at least not without a lot of bias. But basically, you wouldn't need to hex edit nesicide to make it comply. The price you pay for that freedom is that assets creation like levels and screens are wholly external. 

On the other hand, if you mean to write a new module for others to use with nesmaker (like dale_coopers' 2 player module), i think it makes perfect sense because it provides more and more variety to the non-coding or light-coding end users. 

Edited to relate more to mugis reply with the hex editing stuff.

again, the whole part of nesmaker that is baked into the tools design (such as the way it sorts chr files and simply will not let you change that.)

well, dimension shift changed that. What is the direct result of this action is that you will have to do like you would do in any other enviroment, you design your screens outside of the IDE.

now, Dimensionshift is able to still use nesmaker's screenpainter because we removed it's restriction to display full 128x128 pixel chr files.

the normal nesmaker screen painter splits the chr into 4 parts;

6 rows of "Main Tiles"

2 rows of "screen tiles"

4 rows of "path tiles"

4 rows of "hud tiles"

 

a normal level tileset consists of one main tiles, and one screen tiles. For the sake of simplicity, lets ignore the path functionality for now.

the path and the hud tiles are essentially locket assets, and you can define a tileset, and in addition to that, without doing full chr reloading, you can define one screentiles per screen

or per scrolling area if you use the scrolling.

 

nesmakers UI is locked into not allowing you to mess with this categorization. So what we did, is changed the tool so that it now thinks a "Main tiles" is 128x128 pixels in size

and the assembly itself has been completely written from scratch to deal with chr ram etc.

resulting in the fact that i can now load full chr's into the screenpainter and use them as i wish.

 

the moral of the story here is that while i simply brutedorced nesmaker to do what i want it to do, the point is that it can simply be outsoruced from the tool.

using nesmaker as an IDE to make a game, doesnt mean you have to use nesmaker to draw screens. I do a lot of the screens of DS with shiru's screen tool.

it all boils down to how one wishes to use the tools provided, and the limitations that come with them.

[FrankenGraphics | 104]

Quote

"the point is that it can simply be outsoruced from the tool."

I would't frame that as "simply". Like you said, you hex edited closed software to make it do what you want.  

Yes, you can use external tools (all my graphics and special screens for garbage hunter were made in nesst) but it's also several steps slower at each import compared to just using a text editor and asm6 up straight, or nesicide. It's a perfectly acceptable tradeoff if you know a module will align fairly well with your overall design goal and thereby cut production time rather than add to it. 

At some point though, if you set out to make something very different from what is offered, a  user in the crossroads of what route to choose might at least consider begin with a more open/free/modular tools because otherwise you might spend time debugging someone elses' code (which is generally way harder than debugging your own), hacking tools, negotiate interface obstructions, find workarounds, spending time clicking through dialogues and other things you won't even have to worry about outside NM but sort of must be there, more or less, for the benefit of entry level users.

Your work with NESmaker is exceptional, and yes, it does really prove you can make very unexpected things while keeping your base in NM.
But, i really think that for the average nesmaker user with more ambitions than experience, the future potential of NESmaker is getting more modules (or even whole new engines and accompanying plugins) out for use with it. 


 

Edited November 15, 2019 by FrankenGraphics

[Mugi | 83]

by "simply outsourced" i meant, Use shiru's screen tool instead of nesmaker. i didn't outsource it, i bruteforced it to bend to my will. xD

and yeah, using external tools like screentool is slower because you have to do the whole juggle with the data as opposed to how drawing in nesmaker literally edits the NT's in realtime and that's that. but as such it's not any slower than making a game without nesmaker to begin with.

 

as far as the future of nesmaker goes, we will have to come back to that once the fabled 5.0 version is out.

[shauntendo64 | 2]

I have absolutely no experience in NES development, but am a huge fan of homebrew games and enjoy collecting them.  My hesitation of games made exclusively with NESmaker is that we get a flood of cookie cutter games that are all very similar in mechanics and style.  This would really take a lot of the fun out of it as I appreciate the wide variety of mechanics and games people come up with in the homebrew community. 

I understand that almost all homebrew developers are using some sort of tools to help in coding and creation of their game.  I don't really understand why using NESmaker is considered "worse" than using any other tool that is out there. 

If a game was made exclusively with NESmaker with minimal to no modification to the coding, I'd want to know that before buying it.  If a game was made using NESmaker as one tool (among other tools and coding), then I don't really care, and don't think that should be looked down upon in my opinion.

[MachineCode | 159]

I liken it to the difference between using a program like Ableton Live to make original compositions vs slapping together the stock loops that come with the software and calling it your own. Like any tool, it really depends on how you use it.

[Link | 2,708]

notepad, notepad2, notepad++, LaTeK, MS Word, DreamWeaver... all and many more can be used to make a website, to say nothing of languages and css... The end result matters. Yes, a msword.exe website is probably gonna suck. But if it somehow doesn’t, would you denigrate it just because “MSWord, lol”?  

Or on the other hand is writing purely in Assembly like Paint, and NESmaker is like Photoshop (or Premiere)? And Paint takes more effort so its pictures are guaranteed to be better? Advanced tools let people do more and collective human knowledge benefits all of us. I know carpenters who make custom furniture, they can use power tools  or buy dimensional material without losing personality in their projects. I don’t think anybody is purely using axes and planes and sandpaper right now. Some will mill a log or trunk down customwise and that’s super cool, but doesn’t mean other approaches aren’t. If your shit is more impressive on its own merits, then it will be, regardless. So do good, instead of talking bad. I have nothing but respect for solegoose, sivak, and other homebrewers and people early to the scene. But like music, the scene is going to advance. Critique has to happen on merits of the product. 

[erac | 78]

I think it's important to note what engine a game uses, if any. The Unity and Gamemaker reputations are 100% deserved, and it goes the other way too: if something uses the Q3 engine, I want to know that too. So that's where I draw the line: if you use nesmaker as an ide, who cares. If most of the code is nesmaker's, that is a big deal.

I wouldn't classify Mugi's project as a nesmaker project, since it mostly doesn't use the nesmaker engine anymore. Knowing the history is good, and I don't want them to start hiding it started in nesmaker, but they're open about that already.

[fcgamer | 4,719]

I generally judge items by the end product, and I've made the argument before comparing it to music:

Snobbery over whether the artist write his or her own song, or whether the singer plays an instrument. I play instruments and I've written sings before, so of course I feel it's special or have a "preference" if the person writes his or her own material, if the person can play the instrument. At the end of the day though, it isn't the end all of be all of good music. Replace this scenario with using nes maker versus another tool versus completely "from scratch".

If we do decide to go the labelling route (I honestly hope that we don't, imo people will conjure up some preconceived notions about the work, out if the gate, unfairly if it is labelled) then I feel we also should make it a requirement to label *every* game with the tools used.

 

[fcgamer | 4,719]

There is also going to be a point where it would be like splitting hairs to classify certain games, depending on how they were made. What would we do for labelling them, where it becomes like splitting hairs? 

I see the above situation all the time with my primary collecting focus, what is a "bootleg" , an "unlicensed " game, a "pirate", a "counterfeit", a "hack", a "repro",  etc. I see quite a large distinction between all of those above, and hate when the terms are used "improperly". For most folks though, there won't be nearly the distinction I see, and it's just something I learnt to deal with. In fact, it's just added another level of research, to determine sometimes what something is, but I honestly don't see anything wrong with that, as it just adds another level to it all.

As a few others have said, the situation feels more to me like some of the old guard feeling threatened or worried since more folks can now enter into their domain. 

And regarding quality, I've seen dozens of homebrew games over the years that didn't look particularly good, and then some that might be good, but just looked on par with modern games being made by Nice Code of China. 

To sum it up:

No labels please, but if we use labels, make it a requirement for all tools, for all games. 

[MachineCode | 159]

4 hours ago, Link said:

Yes, a msword.exe website is probably gonna suck. But if it somehow doesn’t, would you denigrate it just because “MSWord, lol”?

No, in fact I’d be impressed that they were able to get working HTML files out of a word processor that doesn’t deal in raw text data but rather a weird xml type structure underneath.

[gauauu | 81]

3 hours ago, fcgamer said:

No labels please, but if we use labels, make it a requirement for all tools, for all games. 

Once again, there's a huge difference between a tool and an engine. Making it a requirement to label all engines makes some sense to me. Tools does not.

The distinction isn't msWord vs notepad. A better analogy is customized SquareSpace template vs homemade website. I'm fine with whatever we decide about labels, but let's please get our analogies right.

 

Edited November 15, 2019 by gauauu

[arch_8ngel | 1,597]

9 minutes ago, gauauu said:

Making it a requirement to label all engines makes some sense to me.

 

Why?

Just let a game stand on its own merits without any potential prejudice associated with forcing a label on it.

 

[FrankenGraphics | 104]

5 hours ago, Link said:

notepad, notepad2, notepad++, LaTeK, MS Word, DreamWeaver... all and many more can be used to make a website, to say nothing of languages and css... The end result matters. Yes, a msword.exe website is probably gonna suck. But if it somehow doesn’t, would you denigrate it just because “MSWord, lol”?  

Hm... I don't think web deving works too well as a comparison, and here is why i think that:
-Yes, there is sometimes some snobbery (don't listen to them) going on in webdev circles about using divi or wix or wordpress templates vs build yourself a template for your site. 
-But even professional webdevs use these services regularly. Why? Because it is a very pragmatic outlook to be web deving. Even when there is an aesthetic dimension to it, the aesthetics are utilitarian in nature. Even an art-heavy service like wetransfer functions to promote the company as forward-thinking and provide the user with easy to digest newsbits while the file is uploading.  Rarely, the webpage is the goal in of itself. It's just a tool to get income flowing, information in/out and customers happy. It can be, but rarely is, a cultural or entertainment product in of itself. It's "just" a vessel for actual content.

-It also differs from game development in that what webdevs mostly do is layout work, with little to no actual programming. with html and css, you don't define the behaviour of the browser or the backend. It has more in common with typesetting and magazine layout. In other words, the creative possibilites are narrowed down to its primary functions: view/read content, submit user created content, and link together. And in this decade, generate vast amounts of personal user data for marketing purposes.

Making a game, maybe even in general, and perhaps especially for a platform that was never intended to be programmed by its users in the first place - in fact, nintendo went to great lengths to discourage this by obscuring technical information, making the hardware design unnecessarily cryptic, and so on - entirely exists in the field of aesthetic expression, as long as we're looking at bedroom coders, homebrewers, chiptune composers, story writers and starving pixel artist bohemians ( ).

tl;dr: a homebrew game is primarily an aethetic expression in which the creator(s) rarely expect to get compensated for their time. Most homebrews are being done at economic loss. Web pages are most often utilitarian in nature and are most often commissioned by for-profit or elsewise funded entities. 

 

Quote

Or on the other hand is writing purely in Assembly like Paint, and NESmaker is like Photoshop (or Premiere)? And Paint takes more effort so its pictures are guaranteed to be better?

There pretty much isn't an analogy for Photoshop within nesdev. We're talking about a giant studio tool that has been commercially developed by whole teams of payroll staff over decades and has a near market monopoly on digital photography development and raster graphics. It can do just about everything between heaven and earth when it comes to raster graphics, absolute or indexed and sometimes vector graphics, even including animation, but it can be a bit clunky with its overhead. 

The closest likeness to photoshop in programming would maybe be VSCode, which share all those traits and is similar for a nesdev homebrewer in that all the functionality to do whatever is there, but you probably won't need most of it. Still, you can manage your assisting python scripts along with your NES assembly code in the same convenient environment if you want to.

It's also similar in that you're unlikely to use VSCode unless you also write enterprise level program blocks, and you're unlikely to use photoshop unless you're also working with graphics or photography at some level elsewhere. If you don't, there are more and better specialized tools with lower entry thresholds, such as asesprite, yy-chr, nesst, and so on. 


edit: gauauu just summarized what i meant to say in a single line, lol.


 

Edited November 15, 2019 by FrankenGraphics

[fcgamer | 4,719]

17 minutes ago, FrankenGraphics said:

Making a game, maybe even in general, and perhaps especially for a platform that was never intended to be programmed by its users in the first place - in fact, nintendo went to great lengths to discourage this by obscuring technical information, making the hardware design unnecessarily cryptic, and so on - entirely exists in the field of aesthetic expression, as long as we're looking at bedroom coders, homebrewers, chiptune composers, story writers and starving pixel artist bohemians ( ).

This for me suggests even more why we *shouldn't* be labelling items. If it's being done for aesthetic reasons, passion, hobby, etc, why the need to get snobby and judge things prematurely? If we want to go this route, I'd gladly go back and write reviews for the from scratch homebrews, listing which are good and which imo "suck", yet over in NA it was frowned upon since I'd be crapping on passion projects from community members.

Fun fact: solegoose stated at one point over on NA that he'd appreciate and support all homebrew projects, and even said some of the earlier stuff he did was not the best, iirc. If anyone wants to search on the go collect mess and fine an exact quote, go for it. While I don't think he's a bad guy, his whole hatred against nes maker and then the above just suggest to me that he feels threatened by others entering into the homebrew domain.

Edit: I'm paraphrasing what the aforementioned member had said, and my understanding and recollection of it. If someone looks up the post and I'm remembering way off base or out of context, I'll gladly edit my post and apologize to said member publically, as I'm not out trying to start a fight or argument here, rather just trying to add to the discussion.

Edited November 15, 2019 by fcgamer

[arch_8ngel | 1,597]

13 minutes ago, FrankenGraphics said:

tl;dr: a homebrew game is primarily an aethetic expression in which the creator(s) rarely expect to get compensated for their time. Most homebrews are being done at economic loss. Web pages are most often utilitarian in nature and are most often commissioned by for-profit or elsewise funded entities. 
 

I don't think that has any bearing on whether it is somehow beneficial to force a label onto a game, or whether those labels risk prejudicing potential audiences.

 

Let a game stand on its own, in the public forum.

If the game's creator wants to add a label, that should be solely up to them, and no one else.

Discussions about the engine and toolchain can take place with, or without, the consent and participation of the game's creator, but IMO that is entirely separate from compelling a label that "flags" the game when it appears on a list of upcoming games.

[zi | 144]

the problem is, when presenting "nesmaker" as a label, it looks like a warning- it makes "nesmaker" a pejorative term. Is a Nesmaker game the same quality as a 'from the ground up' assembly game? i've heard folks snipe-in and say the nesmaker is glitchy. meaning: there are glitches embedded in the the tool itself that effect the game, which can't be fixed in a way that a ground-up assembly game can be tested and fixed. so...

IF you can show a video, screenshot, whatever, of a nesmaker game that is unfixable glitchy because of the nesmaker system itself, THEN slap the "nesmaker" warning on it. 

IF you can't provide such evidence and no one should can tell the difference, THEN this is divisive elitist home-brew gatekeeping that makes the community look bad. The differentiation between tools is an argument that disrupts the focus of effort: making a video game. The only reason to put the NesMaker sticker on it is to advertise Joe's path towards home brewing- anything else feels like a warning or judgement of quality, whether intended or not.

[MachineCode | 159]

1 hour ago, FrankenGraphics said:

-It also differs from game development in that what webdevs mostly do is layout work, with little to no actual programming

I think you might be confusing web developers with web designers, or at the very least not making the distinction between front end and back end web developers.

Also, the reason developers tend to look down upon Wix and Wordpress or any WYSIWIG created sites is because we've all had the misfortune of having to maintain or add to the absolute shit code these things put out due to trying to be one size fits all. No human developer in their right mind would wrap a simple line of text in 5 layers of span tags with 3 different classes, but my coworkers and I sure had a good laugh, and then cry, upon being handed multiple WP sites that did just that and worse.

I would say this matters way more in something like web development where there is a large professional industry built around it and having to undo the damage done by people who while well intentioned, really didn't belong doing this kind of work, wastes a lot of time and money and potentially causes many headaches down the road.

For something like homebrew NES games where it is literally just people trying to realize their passion and creativity as a hobby, unless it's just curiosity due to a love of the process of NES development or trying to get props on your skills as a developer from other developers, I don't see why anyone should care as long as the game is good and runs well. That's why I'm in the label it all regardless of the tools used camp. I just like the process and want as much info as I can get behind what makes a game possible. Good, bad, or otherwise.

[MachineCode | 159]

@Mugi I wouldn't worry too much about this stuff. Dimension Shift looks like an objectively awesome game so whatever tools you used and however you used them doesn't add to or take away from the job well done. If people wanna get bent out of shape about that and skip over it because you dared use NESMaker as part of the process, that's their loss. 

[FrankenGraphics | 104]

I've done things from the ground up, (most of which isn't fit to see release). I've collaborated with others who have written their codebase from the ground up. And i have made a nesmaker game called Garbage Hunter.

It doesn't concern me one bit if people label garbage hunter as a nesmaker made game, because it is. For all the modifications i did to the source;  both undercarriage and chassi, it's still identifiable as a nesmaker engine game through and through. I'm also not comfortable with releasing it to the public because it could use another half year of polish to work more as an adventure and less as a 2-minute arcade experience, but that's on me, not the engine. 

I'm not denying the nesmaker label has been used, is used and will be used to disqualify the work of people, just like a game maker game or appstore app might suffer the same fate, but that's on each individuals' prerogative to put value into that classification. the classification itself is not carrying that value - the scene is - and it will vary from individual to individual. 

I'm also not fully convinced of either side, but i am convinced of this: 

It is useful information to know that Dikki painguin in: TKO forthe third reich was made with/based on bob rosts' nbasic, seen as an engine. Not only is it nerdly pleasurable to compare this to other nbasic made games and try to spot similarities and differences, but it also helped me orient myself way back when and try nbasic out for myself because i felt inspired by it. If i hadn't found that info and made a first hello world and get the gratification of seeing it "come alive", i might never have maintained interest in the scene enough to start lurking the nesdev forums, and i might never have started being creative for the platform in the first place. I'm only here in the scene because someone classified it and pointed me in the right direction.

Nesmaker today is what nbasic was in the early 00s, although more well-featured and with a larger install base. It has forever changed the installbase of asm6, which affects your concerns for when writing new tutorials, for one thing. It is safe to assume asm6 has superceded nesasm as an entry level assembler and it makes more sense to write your tutorials for the latter today. 

It also makes my life more convenient as a homebrewer. I've maybe answered the question in PM:s and on forums if Project Blue is a nesmaker more times than i care to count. Same goes with people asking if it is a megaman hack. I get it, they're just curious and can't possibly have all the specialized knowledge at hand to make a call for themselves. At first, i tried to be nuanced and detailed about this (much like in my post where i described how nesmaker can be used as an assets tool), but that generally just leads to people not reading what is actually said. So now i simply tend to reply "no", however dissatisfactory that answer is. 

 

Edited November 15, 2019 by FrankenGraphics

[FrankenGraphics | 104]

7 minutes ago, MachineCode said:

I think you might be confusing web developers with web designers, or at the very least not making the distinction between front end and back end web developers.

You're absolutely right. Apologies on my part!