A True Coding-Free Solution!

So NESMaker isn't my first "Programming Free" game-making software, and I'm sure it's the same for many of you here. I tried Game Maker, Game Salad, Unity, Java, etc. The best and most intuitive program I ever found was a program used to make Android Apps called "Code Blocks". It was a graphical coding interface that used different puzzle-shaped blocks to assemble code. At any time you were a tab-click away from seeing real code you "wrote" by dragging and dropping command-based Lego's. It was made by a college professor to teach about coding, and abandoned for dead on the internet. I see NESMaker and I absolutely love it but I hear the detractors call it a glorified port maker and... in some ways, they're kind of not wrong. With the addition of this system, it would truly be modifiable enough to exceed this insult. So without further ado, I
give you BitBlox! A core component and a true step towards making NESMaker coding free!

Here we see the way Scripts usually look in NESMaker, with one small difference; a tab that allows you to switch from normal view...
uc


to BitBlox view! Here I break down the way creating (what I think is a close approximation of) the same Script.
uc


Here I breakdown beginning a Script in BitBlox
uc


And here I go over all the ideas for Blox I came up with so far, complete with scenarios for usage and how new Blox can be developed.
uc


If this isn't possible, I completely understand, but this idea warrants at the very least a look and a good ponder. I sincerely hope my fellow forumers here can help me get some volume on this post so that maybe it'll be considered. Thank you for taking the time to look, and sorry for the massive pictures :?
 

Mugi

Member
truth to be told, i much prefer it without the blocks.

i've never touched 6502 assembly in my life before i got nesmaker (roughly 2 weeks ago) and the way nesmaker makes you look into it if you wish to do something "out of the box" is an extremely efficient way to make people learn how to
actually write the code instead of just playing with the legos.

it's an interesting idea all the same though.
 

dale_coop

Moderator
Staff member
Agree with Mugi (as usual), NESMaker already would give all basic scripts, and demo assets/tiles/... but most important, you can modify all the scripts, make your owns. With bloc you will be too much limited (and/or the "normal" casual users will be more lost in this blox system).
 
Mugi said:
i've never touched 6502 assembly in my life before i got nesmaker (roughly 2 weeks ago) and the way nesmaker makes you look into it if you wish to do something "out of the box" is an extremely efficient way to make people learn how to
actually write the code instead of just playing with the legos.

You're right, the way things are IS a good way to learn how to write code, and my point is that from its earliest promises, NESMaker was supposed to be about being able to do this with no coding required. This isn't for users like you who can already identify that an NES requires 6502 Assembly. And because there's still the tab that allows you to switch back to code, "playing with the Legos" can actually show you how writing up the code would look if you DID write it by hand. It's literally drag and drop macros and commonly used language. If you see this and immediately think "well coding it up would be easier" then you can stay in the less restrictive Script mode and type away, because this mode is for those of us that just can't wrap our heads around coding language. And it's hard to explain to someone who "gets it" what it's like to just not get coding. It's like a foreign language that others try to teach you by speaking to you in the foreign language.
 

MistSonata

Moderator
What you're talking about is making a high level programming language to handle the underlying assembly code, which isn't impossible (see cc65 as an example) but it is more inefficient, and on a platform where space and processing power are not in ample supply, efficiency is very important. And that's just talking about writing NES code in C, this idea (while very cool in theory) doesn't really take into account how assembly works. How would you do bitwise operations in this system without making it too complicated for the average user? How does it manage the registers? How does it know when to discard a value in a register and when to store it into a temporary variable to use for something important later?

This is why I don't like the "no coding required" tagline, because while it's technically true, it only applies to things that NESmaker is already pre-programmed to do. It gives people the impression that they can do all sorts of custom things that NESmaker wasn't designed for without even touching the code, when that's definitely not the case.
 
FerretHallGaming said:
Mugi said:
i've never touched 6502 assembly in my life before i got nesmaker (roughly 2 weeks ago) and the way nesmaker makes you look into it if you wish to do something "out of the box" is an extremely efficient way to make people learn how to
actually write the code instead of just playing with the legos.

You're right, the way things are IS a good way to learn how to write code, and my point is that from its earliest promises, NESMaker was supposed to be about being able to do this with no coding required. This isn't for users like you who can already identify that an NES requires 6502 Assembly. And because there's still the tab that allows you to switch back to code, "playing with the Legos" can actually show you how writing up the code would look if you DID write it by hand. It's literally drag and drop macros and commonly used language. If you see this and immediately think "well coding it up would be easier" then you can stay in the less restrictive Script mode and type away, because this mode is for those of us that just can't wrap our heads around coding language. And it's hard to explain to someone who "gets it" what it's like to just not get coding. It's like a foreign language that others try to teach you by speaking to you in the foreign language.

I agree, if you had the option to switch between modes, those of you who rather just plain coding will be entirely unhindered. At the very least this would be a great way to use Nesmaker to learn asm, I know you may be thinking "isn't it already?!?!" But some people have different ways of learning stuff, and it can be be difficult any other way. Also, at the very least if and when Nesmaker has a built in code editor, it could color code things like macros, commands, and variables. (Not very effective for me. :lol:)
 
MistSonata said:
What you're talking about is making a high level programming language to handle the underlying assembly code, which isn't impossible (see cc65 as an example) but it is more inefficient, and on a platform where space and processing power are not in ample supply, efficiency is very important. And that's just talking about writing NES code in C, this idea (while very cool in theory) doesn't really take into account how assembly works. How would you do bitwise operations in this system without making it too complicated for the average user? How does it manage the registers? How does it know when to discard a value in a register and when to store it into a temporary variable to use for something important later?

This is why I don't like the "no coding required" tagline, because while it's technically true, it only applies to things that NESmaker is already pre-programmed to do. It gives people the impression that they can do all sorts of custom things that NESmaker wasn't designed for without even touching the code, when that's definitely not the case.

Thank you very much. I wanted a better answer than "learning how to code's better" and you definitely provided it. The bloat something like this may produce may be fatal on a system with such limitations. As for your questions about how it would do these specific things, I don't see those as impossible in this architecture. Scripts for how screens are handled can contain the specifics for how these are done even though the Block itself appears simple, and Blocks can be specific per module so as to fit into an already-working game system.
 
Redherring32 said:
FerretHallGaming said:
Mugi said:
i've never touched 6502 assembly in my life before i got nesmaker (roughly 2 weeks ago) and the way nesmaker makes you look into it if you wish to do something "out of the box" is an extremely efficient way to make people learn how to
actually write the code instead of just playing with the legos.

You're right, the way things are IS a good way to learn how to write code, and my point is that from its earliest promises, NESMaker was supposed to be about being able to do this with no coding required. This isn't for users like you who can already identify that an NES requires 6502 Assembly. And because there's still the tab that allows you to switch back to code, "playing with the Legos" can actually show you how writing up the code would look if you DID write it by hand. It's literally drag and drop macros and commonly used language. If you see this and immediately think "well coding it up would be easier" then you can stay in the less restrictive Script mode and type away, because this mode is for those of us that just can't wrap our heads around coding language. And it's hard to explain to someone who "gets it" what it's like to just not get coding. It's like a foreign language that others try to teach you by speaking to you in the foreign language.

I agree, if you had the option to switch between modes, those of you who rather just plain coding will be entirely unhindered. At the very least this would be a great way to use Nesmaker to learn asm, I know you may be thinking "isn't it already?!?!" But some people have different ways of learning stuff, and it can be be difficult any other way. Also, at the very least if and when Nesmaker has a built in code editor, it could color code things like macros, commands, and variables. (Not very effective for me. :lol:)

I can't even read the Macros because they're all crammed into a narrow box to the right of the screen -. - I know it may not be for everyone, but visual aides help visual learners. Taking something complicated and presenting it as something recognizable will always help someone along the way.
 

Kasumi

New member
MistSonata said:
How does it manage the registers? How does it know when to discard a value in a register and when to store it into a temporary variable to use for something important later?
C compilers deal with this issue constantly, and they're (typically) very, very good at it. cc65 is not the best, but that's more because enough time hasn't been put into it to make it better than because it's not possible to do. That said, 6502 is not a very good target for (specifically c) compilers because it's traditionally designed around having more free use of the stack. Nothing would stop one from creating a thing with very similar (but more limited) syntax as for as readability.

Compilers can think to use the available values in extremely clever ways that even decently experienced programmers may not think up. If you click that, read, don't skim. The compiler isn't the cause of the bug.

To make bitwise operations easy think about what usual things are actually accomplished by using bitwise operations rather than the concept itself. If it's looking at a specific value that just doesn't have a range of 8 bits, you just give the user control of the range of the value for each variable and you're done. Getting how many bits a given range requires isn't hard for a computer, fitting those arbitrary bits into bytes isn't hard for a computer, and knowing which value to AND with to retrieve them isn't hard, since the computer had to assign which bits the value occupies within the byte itself earlier.

The smallform optimizations programmers make aren't really that magic. There are actually a lot of 6502 programming things that computers would probably be better or at least faster at finding optimizations for. The carry was not changed in the last 100 lines? Neat, we can use bcs/bcc instead of jmp and save a byte. Even in my own games, I tend to have the human readable AND #BUTTONA, bne instead of bmi. (My games store buttons in a different bit order than NES Maker if I recall correctly.) A higher level thing would know BUTTONA was an alias for %10000000 and use BMI. You'd get the human readability AND the byte efficiency.

Something that's worth taking a look at is this: https://godbolt.org/

This shows what the assembly will look like for given C input live. Someone could make something like that for 6502. As you add blocks, it can show what those blocks would look like in 6502 assembly. I've been thinking about this sort of thing a lot. NES Maker doesn't really pass my "easy-to-use" test. And it's for program design reasons, not NES limitation reasons.

Way shorter: Things are bad on NES because there's no real incentive to make things easier for it (compared to other things), rather than because it's not possible. But NES Maker has proven a market for it, so consequently a few developers (myself included) are working on things to make working on it easier. I've given a lot of things a lot of thought, but so far the only thing I've really spent the time improving is asset management. Which has been a long road, but I'll make my time back.

I won't make my time back improving the code side, so if I'm going to spend the time to improving that, I need people to financially support it or it's not worth doing. I'll probably test the waters a bit after the asset management thing finally comes out.
 

MistSonata

Moderator
FerretHallGaming said:
MistSonata said:
What you're talking about is making a high level programming language to handle the underlying assembly code, which isn't impossible (see cc65 as an example) but it is more inefficient, and on a platform where space and processing power are not in ample supply, efficiency is very important. And that's just talking about writing NES code in C, this idea (while very cool in theory) doesn't really take into account how assembly works. How would you do bitwise operations in this system without making it too complicated for the average user? How does it manage the registers? How does it know when to discard a value in a register and when to store it into a temporary variable to use for something important later?

This is why I don't like the "no coding required" tagline, because while it's technically true, it only applies to things that NESmaker is already pre-programmed to do. It gives people the impression that they can do all sorts of custom things that NESmaker wasn't designed for without even touching the code, when that's definitely not the case.

Thank you very much. I wanted a better answer than "learning how to code's better" and you definitely provided it. The bloat something like this may produce may be fatal on a system with such limitations. As for your questions about how it would do these specific things, I don't see those as impossible in this architecture. Scripts for how screens are handled can contain the specifics for how these are done even though the Block itself appears simple, and Blocks can be specific per module so as to fit into an already-working game system.

Well, regardless I don't think Joe would be too interested in something like this, as nice as it would be to have. Feel free to bring up your idea on the FB group if you really want (Joe doesn't frequent the forum much anymore) but I'm sure Joe could list a million more reasons than I could as to why this wouldn't be practical.
 

RadJunk

Administrator
Staff member
As someone who literally looks at code all day (I work at a software company) this would drive me a little nuts. I mean I see a use case for something like this in a teach environment as far as logic goes but not much more than that.

Cool concept though.
 
RadJunk said:
As someone who literally looks at code all day (I work at a software company) this would drive me a little nuts. I mean I see a use case for something like this in a teach environment as far as logic goes but not much more than that.

Cool concept though.

We also have to take into account that Nesmaker is inevitably going to have more and more young users using it to learn 6502 programming, and to achieve absolute usability, allowances have to be made for that. While it doesn't necessarily have to be in this manner, we can't deny that something needs to be implemented.
 
Kasumi said:
C compilers deal with this issue constantly, and they're (typically) very, very good at it. cc65 is not the best, but that's more because enough time hasn't been put into it to make it better than because it's not possible to do. That said, 6502 is not a very good target for (specifically c) compilers because it's traditionally designed around having more free use of the stack. Nothing would stop one from creating a thing with very similar (but more limited) syntax as for as readability.

Compilers can think to use the available values in extremely clever ways that even decently experienced programmers may not think up. If you click that, read, don't skim. The compiler isn't the cause of the bug.

To make bitwise operations easy think about what usual things are actually accomplished by using bitwise operations rather than the concept itself. If it's looking at a specific value that just doesn't have a range of 8 bits, you just give the user control of the range of the value for each variable and you're done. Getting how many bits a given range requires isn't hard for a computer, fitting those arbitrary bits into bytes isn't hard for a computer, and knowing which value to AND with to retrieve them isn't hard, since the computer had to assign which bits the value occupies within the byte itself earlier.

The smallform optimizations programmers make aren't really that magic. There are actually a lot of 6502 programming things that computers would probably be better or at least faster at finding optimizations for. The carry was not changed in the last 100 lines? Neat, we can use bcs/bcc instead of jmp and save a byte. Even in my own games, I tend to have the human readable AND #BUTTONA, bne instead of bmi. (My games store buttons in a different bit order than NES Maker if I recall correctly.) A higher level thing would know BUTTONA was an alias for %10000000 and use BMI. You'd get the human readability AND the byte efficiency.

Something that's worth taking a look at is this: https://godbolt.org/

This shows what the assembly will look like for given C input live. Someone could make something like that for 6502. As you add blocks, it can show what those blocks would look like in 6502 assembly. I've been thinking about this sort of thing a lot. NES Maker doesn't really pass my "easy-to-use" test. And it's for program design reasons, not NES limitation reasons.

Way shorter: Things are bad on NES because there's no real incentive to make things easier for it (compared to other things), rather than because it's not possible. But NES Maker has proven a market for it, so consequently a few developers (myself included) are working on things to make working on it easier. I've given a lot of things a lot of thought, but so far the only thing I've really spent the time improving is asset management. Which has been a long road, but I'll make my time back.

I won't make my time back improving the code side, so if I'm going to spend the time to improving that, I need people to financially support it or it's not worth doing. I'll probably test the waters a bit after the asset management thing finally comes out.

And thank you for understanding a bit better what I meant. If you were to start such a project on NES, I'd definitely help fund and try to garner attention for it.
 

MistSonata

Moderator
Kasumi said:
Way shorter: Things are bad on NES because there's no real incentive to make things easier for it (compared to other things), rather than because it's not possible. But NES Maker has proven a market for it, so consequently a few developers (myself included) are working on things to make working on it easier. I've given a lot of things a lot of thought, but so far the only thing I've really spent the time improving is asset management. Which has been a long road, but I'll make my time back.

I won't make my time back improving the code side, so if I'm going to spend the time to improving that, I need people to financially support it or it's not worth doing. I'll probably test the waters a bit after the asset management thing finally comes out.

If you decide to do it, that'd be awesome. I hope you let us all know when you do.
 

RadJunk

Administrator
Staff member
Redherring32 said:
RadJunk said:
As someone who literally looks at code all day (I work at a software company) this would drive me a little nuts. I mean I see a use case for something like this in a teach environment as far as logic goes but not much more than that.

Cool concept though.

We also have to take into account that Nesmaker is inevitably going to have more and more young users using it to learn 6502 programming, and to achieve absolute usability, allowances have to be made for that. While it doesn't necessarily have to be in this manner, we can't deny that something needs to be implemented.

I disagree actually. While I think it is important to TEACH people how to do this, it is not always necessary to reduce it down to literal blocks to do so.
 

Digital_Dragon

New member
I've actually used something like this in an IT class before. Good way to teach general coding logic, though wether people want to learn to code using NESmaker I don't know. Maybe it would help someone make that one unique feature in their game, so I say good luck. But I don't see it being a widely used thing.

It's a bit of a middle ground between 'No Coding' and full use of ASM. I think something people could really use is a way to change constants and things in the engine like enemy speed and behaviour, through the UI a bit more easily. Though I'm sure with updates and plug ins this stuff will come.
 
RadJunk said:
Redherring32 said:
RadJunk said:
As someone who literally looks at code all day (I work at a software company) this would drive me a little nuts. I mean I see a use case for something like this in a teach environment as far as logic goes but not much more than that.

Cool concept though.

We also have to take into account that Nesmaker is inevitably going to have more and more young users using it to learn 6502 programming, and to achieve absolute usability, allowances have to be made for that. While it doesn't necessarily have to be in this manner, we can't deny that something needs to be implemented.

I disagree actually. While I think it is important to TEACH people how to do this, it is not always necessary to reduce it down to literal blocks to do so.

Which is why I added the "it doesn't necessarily need to be in this manner" part. I wasn't exclusively saying that we need to use code blocks, I was just saying we need to figure something out. Sorry for the confusion.
 

Kasumi

New member
Here is my "gold standard" for an easy to use game making program:
mMIJBnw.gif

It is The Games Factory. It was actually the same price as NES Maker when I got it.
It's what I'd personally like to see NES Maker (or something like it) move towards. It looks a bit different than the blocks, but basically New Condition will add an if statement. Types of things are visually grouped. Then, any actions you add to the condition's row under any objects will run when the condition is true. "Box collides with circle: Destroy Circle. Add 100 to score." NES Maker's action state management is sort of like this workflow as far as "coding". But one can't do other things in a similar way.

Most game making programs have ended up more complicated than The Games Factory as far as "make a game in 30 seconds", because I think they forget some of why people get into them. The Games Factory isn't perfect, it's not as powerful as modern day Game Maker/Unity/Godot/Construct/Clickteam Fusion (its spiritual successor). It lacks the concept of loops! (Though possible with an extension.) But you could make a character move around in a world in like five minutes, after like five minutes of tutorials. It's my belief that the quicker the user can get something on screen, the less likely they are to quit when things get a bit harder since they'll feel like they're making progress. NES Maker setup is pretty "front heavy", so a user might quit before they see anything move in the game itself.

Edit: I checked and The Games Factory does have a repeat condition. I'm not sure if that can be used for things like for loops... back in the day I remember people recommending an extension for it, but I'm not sure why now.

The Games Factory does not provide ANY scripting support at all, out of the box. (Or if it does, I never found/used it as a kid.) The only way to edit its code is that "event editor", unless you make a plugin or something. Having access to the code is a plus for NES Maker, but only to some kinds of users. If NES Maker came out in the time in my life when The Games Factory did, I wouldn't have gotten very far.

I'm not 100% sure where I'm going with this post. :lol: I actually miss workflows like this in general. Even for non NES gamedev, it's hard for me to recommend ways to start because lots of other stuff also has front heavy setup. I genuinely believe developers have just... forgotten that things could be easier because they've "grown up" as the complexity did and so the current methods are still easy to them. There are enough programs that try to toe the line between easy to use and super powerful. I think it'd be cool if something just went full easy to use. As in, if you want the power you have to switch programs entirely. Pico-8 actually uses some of that "Need more? Switch programs" mindset, but it's typing code vs a block/event style. I definitely, really see the value in using the visual ways to compose code in the beginning.

If you start with "regular" typing programming, you're actually learning two things at once. Syntax AND the logic. With a visual thing, you're learning only the logic. While now like others have mentioned, I find visual stuff slow to work in, back then syntax errors were absolutely a wall in getting what I wanted done when I understood the logic.
 
Kasumi said:
I genuinely believe developers have just... forgotten that things could be easier because they've "grown up" as the complexity did and so the current methods are still easy to them. There are enough programs that try to toe the line between easy to use and super powerful. I think it'd be cool if something just went full easy to use. As in, if you want the power you have to switch programs entirely.

This. It's hard for me to imagine that at this point in time we don't have a program that's genuinely idiot proof even if it can only make extremely simple games. Even if the programs it makes are under-optimized, full of bloat, and inefficient, with the processors and memory we have access to today, why not make a program that makes an NES-style game that's port-able to a console? Even if it takes 4GB to make Final Fantasy 1 in it? It'll still allow a different subset of people without the time and knowledge to create a complete project and then get the proof of concept they need to move forward.
 
Top Bottom