NES games surely can be both, but is the "correct" thing to call them Indie over homebrew? Is one game being better than another make it need to be called "Indie" even though they probably used the same tools to make it anyway?
I remember that the TI-scene never adopted any name, besides simply calling them "Games".
I simply don't care. Sometimes I think we spend precious time discussing meaningless things instead of using that time for actual development.
To me, "homebrew" means using a platform in ways that the maintainer of the platform did not intend. For example, this may mean "homebrew" games circumvent a lockout and "indie" games don't. Hence NES "homebrew" games but Xbox Live "Indie" Games, which use the same business model that Apple copied for the iOS developer program. And if I were to use this model for Apple iOS, App Store games would be "indie" and jailbreak games "homebrew".
As for the TI-83 and TI-86, Texas Instruments intended for user applications written in assembly language to run on those platforms, so there isn't a distinction to be made.
Sometimes we discuss meaningless things because we happen to live in an environment with lawyers whose job is to discuss things that may at first appear meaningless to us.
As for the TI-83 and TI-86, Texas Instruments intended for user applications written in assembly language to run on those platforms, so there isn't a distinction to be made.
Sometimes we discuss meaningless things because we happen to live in an environment with lawyers whose job is to discuss things that may at first appear meaningless to us.
So...are games like Tengen homebrew?
The TI83 is a little different, because the built-in ASM feature was pretty badly done.
Your program needs to be in HEX format, which takes up twice as much memory as binary format. When your program is run, a second unpacked copy is made at a fixed address (the beginning of user memory). If your program does not terminate properly, the memory is permanently leaked until a reset.
Because it made copies of the program, your program size was limited to about 8k in size, 16k for the hex version that sits in RAM doing nothing, and 8k for the packed version.
So because of how bad TI's built-in ASM support was, people made Assembly Shells. They showed an interactive menu that let you run a program, then it relocated the program to the beginning of user memory through simple memory swapping. You didn't need HEX programs, or second copies of your programs in memory anymore, you could save games by writing back to the program code, it was much better than what you had before. But memory was not in a good state during program execution, so programs which relied on external levels needed to have the levels loaded in memory after the game itself. And if the game terminated to the TIOS without quitting successfully, your memory was in shambles, you needed to reset.
Finally, someone came out with a good ASM shell called Venus, which ran only a tiny hex stub. The hex stub found the shell program in memory, jumped to the real code, which deallocated the stub from the beginning of user memory. Then when it loaded the user's program, the entire program was properly relocated, including the size bytes, and program table entries were updated correctly. Finally, you had a consistent RAM layout that would not cause problems if the program terminated unexpectedly, and did not care what order programs existed in in memory, and no memory leaks.
So here we have TI's approach to ASM code (make it in hex, eat extra memory, cause a memory leak if it can't return) transformed into something far more useful. But only enabled by TI allowing user code to execute in the first place.
The TI82 is another different story, someone found a bug in it that let you overwrite a jump table address when you assign a number to a malformed Matrix variable. So you overwrite the number in the corrupt matrix, and it jumps to user code the next time you hit enter, often before then since you're also holding down enter at the time.
So if the TI83 didn't have built in ASM, I'm sure someone would have done something similar to make it happen.
Your program needs to be in HEX format, which takes up twice as much memory as binary format. When your program is run, a second unpacked copy is made at a fixed address (the beginning of user memory). If your program does not terminate properly, the memory is permanently leaked until a reset.
Because it made copies of the program, your program size was limited to about 8k in size, 16k for the hex version that sits in RAM doing nothing, and 8k for the packed version.
So because of how bad TI's built-in ASM support was, people made Assembly Shells. They showed an interactive menu that let you run a program, then it relocated the program to the beginning of user memory through simple memory swapping. You didn't need HEX programs, or second copies of your programs in memory anymore, you could save games by writing back to the program code, it was much better than what you had before. But memory was not in a good state during program execution, so programs which relied on external levels needed to have the levels loaded in memory after the game itself. And if the game terminated to the TIOS without quitting successfully, your memory was in shambles, you needed to reset.
Finally, someone came out with a good ASM shell called Venus, which ran only a tiny hex stub. The hex stub found the shell program in memory, jumped to the real code, which deallocated the stub from the beginning of user memory. Then when it loaded the user's program, the entire program was properly relocated, including the size bytes, and program table entries were updated correctly. Finally, you had a consistent RAM layout that would not cause problems if the program terminated unexpectedly, and did not care what order programs existed in in memory, and no memory leaks.
So here we have TI's approach to ASM code (make it in hex, eat extra memory, cause a memory leak if it can't return) transformed into something far more useful. But only enabled by TI allowing user code to execute in the first place.
The TI82 is another different story, someone found a bug in it that let you overwrite a jump table address when you assign a number to a malformed Matrix variable. So you overwrite the number in the corrupt matrix, and it jumps to user code the next time you hit enter, often before then since you're also holding down enter at the time.
So if the TI83 didn't have built in ASM, I'm sure someone would have done something similar to make it happen.
Dwedit: Interesting story about TI-83. I was only in the scene during the AShell days though.
Good point. Games that would qualify as "homebrew" under the previous rule (using an exploit to execute) but are published by an established business are called "unlicensed". So perhaps the actual chart is like this:
Platforms with no lockout mechanism, such as Windows, Mac OS X, and Android, have no "Not approved" column.
Discussing definitions first is like the ounce of prevention that's worth a pound of cure or the stitch in time that saves nine. It keeps debates from becoming unproductive because they have collapsed into an argument over a definition.
3gengames wrote:
So...are games like Tengen homebrew?
Good point. Games that would qualify as "homebrew" under the previous rule (using an exploit to execute) but are published by an established business are called "unlicensed". So perhaps the actual chart is like this:
Code:
Business `. Approved | Approved | Not approved
scale `. by mfr? | |
----------------------+------------+--------------
Has own office | Mainstream | Unlicensed
----------------------+------------+--------------
Home-based | Indie | Homebrew
scale `. by mfr? | |
----------------------+------------+--------------
Has own office | Mainstream | Unlicensed
----------------------+------------+--------------
Home-based | Indie | Homebrew
Platforms with no lockout mechanism, such as Windows, Mac OS X, and Android, have no "Not approved" column.
Discussing definitions first is like the ounce of prevention that's worth a pound of cure or the stitch in time that saves nine. It keeps debates from becoming unproductive because they have collapsed into an argument over a definition.
I figured an Indie game is more like one without any support (or restrictions) from a publishing company or outside investors. That could cover a lot of cases, one could have an office and do that.
Which pushes the definition burden to "publishing company".
Sorry for the necro-lite... I know this topic hasn't been touched in about a month, but I wanted to give a little perspective on my perceived difference between the "Indie" and "Homebrew" scenes. Feel free to take with a grain of salt, as I tend to have a rather bizarre logic controller inside. 
To put it simply, the homebrew scene is a primarily hacker-centric community. I'm not talking about black-hat hacking, but the kind of tinkering that is exhibited in the industrious and creative personalities. They do it for the thrill of creating something that is their own. That isn't to say that they don't "borrow" elements (anything from using other people's tiles, to almost entire products with mere tweaks), but they do like to have it their way. Their own spin to an old idea.
As for indies/independents, they tend to be more on the business-side, as has been previously suggested. Indies want to take their hobby a step further, and do it for a living, and/or fame and notoriety. They tend to "borrow" less, and want as much creative freedom/control over their product as possible. They also tend to target more mainstream markets, as there is usually a fiscal motive behind things (not to say indie devs are all about money; just that it is usually a consideration -- more so than for homebrewers).
I've been primarily an indie developer for the past decade+, but my focus has tended to go more toward what I perceive as the homebrew line. Making an NES game has been a dream of mine since I first got an NES. Things like the Atari et al didn't inspire me in that way. So, I decided to stop trying to "change the world" as an indie developer, and focus on what I want as a homebrewer.
Of course, there are various interweaving characteristics between indies and homebrewers, so the differences are relatively fuzzy... but the descriptions I gave are what I've observed from hanging around the gaming scene for about the past 30 years.
To put it simply, the homebrew scene is a primarily hacker-centric community. I'm not talking about black-hat hacking, but the kind of tinkering that is exhibited in the industrious and creative personalities. They do it for the thrill of creating something that is their own. That isn't to say that they don't "borrow" elements (anything from using other people's tiles, to almost entire products with mere tweaks), but they do like to have it their way. Their own spin to an old idea.
As for indies/independents, they tend to be more on the business-side, as has been previously suggested. Indies want to take their hobby a step further, and do it for a living, and/or fame and notoriety. They tend to "borrow" less, and want as much creative freedom/control over their product as possible. They also tend to target more mainstream markets, as there is usually a fiscal motive behind things (not to say indie devs are all about money; just that it is usually a consideration -- more so than for homebrewers).
I've been primarily an indie developer for the past decade+, but my focus has tended to go more toward what I perceive as the homebrew line. Making an NES game has been a dream of mine since I first got an NES. Things like the Atari et al didn't inspire me in that way. So, I decided to stop trying to "change the world" as an indie developer, and focus on what I want as a homebrewer.
Of course, there are various interweaving characteristics between indies and homebrewers, so the differences are relatively fuzzy... but the descriptions I gave are what I've observed from hanging around the gaming scene for about the past 30 years.
Wow, do we really have that many non-posting lurkers here? Welcome!
Dwedit wrote:
Wow, do we really have that many non-posting lurkers here? Welcome!
Hi! Thank you for the welcome.
I'm not what one would call a "lurker" -- I only just began down the path of NES homebrew. I just started browsing this particular forum today, and saw this thread. It interested me, and I thought I had something to contribute. Bada bing, bada boom.
I do look forward to continuing to contribute. It seems there are plenty of sharp, knowledgeable people around here. I'm still basically getting my NES development environment set up (the "Yet another reason not to use NESASM" thread has really piqued my interest in finding some alternative development tools), so expect (possibly dumb) questions from me in time.
