I'm curious to see if anything can come out of this that would up our development potential. I think everybody's brought up some good points so far.
dougeff wrote:
Maybe there should be more collaboration... or more posted source code, so not everyone has to rebuild a scrolling platformer from scratch every time.
I've been considering posting some of the code I've been working on, most notably my SMB3 style scrolling code. The main reason that I haven't is because I feel like there's still a little bit of room for improvement, so I wouldn't want to put up a preliminary version and then have to modify it, especially if someone started using it in a project already.
Some quick thoughts on the idea of sharing code:
Since the program is written essentially in machine instructions, an NES ROM will always have uncommented and unlabeled source code. It's impossible to eventually put your game out without also simultaneously releasing the code, albeit in a form that's harder to work with.
There are definitely plenty of exceptions for when someone creates a unique aspect of their game in code, but for most basic functions, I don't feel like there's much reason to keep something to oneself for the sake of making one's game better. Like, for example, scrolling, collision detection, things that have been done time and time again, someone else may feel differently, but I don't mind personally if someone was to use them to make something entertaining. Now if somebody ripped of my graphics, my gameplay concepts, my story, etc, naturally I'd be pissed, and hopefully, since we all share our ideas to some extent, that would A) help to prove copyright should the need ever arise, and B) hopefully deter people from doing something dirty in the first place since everything is so much out in the open already.
tokamaru wrote:
Editing an NES engine is not trivial work, you have to understand how it works in order to not break it in the process.
I think this is a really big point concerning this topic. Someone who doesn't have a pretty decent understanding of 6502 wouldn't be able to implement parts of an engine or modify the code to their use. I don't like to use any code that I don't understand. If I read a suggestion on how to do something better, I've at times waited a week or two to implement it until I can get a chance to break it down and understand it. Often, it needs to be a little bit different to fit my program. Ultimately, I feel a person can usually learn more by having assistance making the final tweaks to get their routine to work, rather than having it built from scratch by someone else.
The way I can think that putting complex code up would be most helpful to beginners, is if that code came with a tutorial. I remember reading that Memblers was considering making a tutorial on two-axis scrolling. In my opinion, this would be the most helpful approach. Then a reader could walk away knowing how to do something instead of just having some code.
tokamaru wrote:
Also, creating an engine can be seen as test
I tend to somewhat agree, but I also agree with most of the points people have made from different perspectives. I don't feel that it's a test that needs to be taken completely alone. There are lots of people here who will help if you hit a wall or have some issues with your code, but I doubt many who would write the program for you from scratch.
I see it kind of like completing a college degree. One of the most valuable things a potential employer sees in this is the simple fact that a person was able to commit themselves to a single overarching goal for at least 4 years, take direction, and follow through. With the game engine, it's nowhere near 4 years for the basic framework alone, the person has to be able to work under their own direction and stay motivated without being told to, and of course, also follow through.
dougeff wrote:
But, not everyone is good at everything. Maybe this guy is good at drawing sprites, but lousy at programming. And, maybe that guy is a good programmer, but doesn't know anything about music. So. Maybe it should go like this...one programmer gets a game to a functioning point, enlists some help to draw graphics, write music, and/or do level design.
Well, I'm wondering if those who need something like this might do well to reach out to the pixel art and chiptune communities. While there are boards for graphics and music here, I mostly see this as the programmers forum, and the discussions usually relate more closely to getting the graphics and sound to work in an actual game format. That, to me, makes the developers the ones who put the "rubber to the road" when it comes to making an actual game. Would the homebrew NES community benefit from more close interaction between the groups of people who specialize in different areas? Perhaps, but I don't feel like I've been around long enough to really say.
dougeff wrote:
Another problem... is there anyone here who ISN'T in the middle of his own giant project? And therefore too busy to collaborate on another project.
For me, first question, I am involved in my own giant project, and second question, I could be interested in collaborating on another project. I've got a ton of graphical content to create for my game. That alone is going to take a long time. If I'm going to work on animations full-force, I'm going to do it on my game. However, if someone was to have the graphical content for a SHMUP, I'd do the programming for that as a side project. I feel pretty confident that I could use parts of the code I've already made and already know inside and out, and add new parts of the code as necessary when I get the content. I don't know if anybody is interested in working on a project in that manner, or even if anybody else wants to make that type of game, but it's at least theoretically possible that someone could do both.
tepples wrote:
In addition, some #nesdev people have expressed contempt for it, claiming that much of the value of the SMB1 engine is its familiarity to players, and there is therefore no demand for an original game engine that lacks this familiarity factor.
I don't feel like this is entirely true. Plenty of games used a format similar to SMB1 of scrolling from left to right, and overcoming obstacles in one way or another. If you're talking about making a game where you hit question mark blocks, break bricks, and step on goombas, then, yeah, maybe, sure. But, if the idea is to make a free software platformer engine, the more basic may even be better. That way, a beginner could take the engine in a direction that's more action, more puzzle, more platformer, etc, without having to pick apart the code and remove the parts that aren't useful for them. To my understanding, SMB1 crammed everything into an NROM cart and used some pretty clever programming, considering the lack of any precedent, to do so. Therefore, the code for SMB1 is probably pretty hard to modify into an original game.
From my little bit of experience, I get the impression someone would already have to be pretty good with 6502 to look at something like SMB1 and gain knowledge from it. If there was, just as an example, a tutorial where instead of learning to build pong, someone learned to build a simple functioning platformer with scrolling, collision detection, player control, and simple physics, that might help bring more, and better equipped people into the foray.
From what I've read, it seems like people wanted to see you do something unique because everyone knows you are extremely skilled, and I understand your perspective on that art from the post you linked. I, for one, am excited to see the project on which you are currently working. Seems like you found a project with the parts you needed and a chance to let your skill shine in a full-length original game. I get the impression that a good collaboration is what you've been looking for to best put your talent to use.
I wouldn't see that as a reason not to do a free software tutorial sort of engine, if that is something you wanted to do.
rainwarrior wrote:
Probably the majority of burnouts don't even get that far, but making the starting part of the project easy for people that can't hack it doesn't necessarily help with the long term work.
If people are afraid to start because they're intimidated by the idea of assembly programming, I can relate to that. I'll be honest, before I started reading here, I thought programming in assembly was going to be the most difficult and cumbersome interaction with a computer that a person could have. (without punch cards) I don't think that's true now. I think it's a very fun challenge.
But, whether the initial learning curve is steeper or not, people that aren't going to hack it will drop out eventually at some point. I don't think there's much of a shortage of half finished demos. It's the completed full-length quality games, particularly on cartridge, that I bet people want to see more of.
One thing that hasn't been brought up thus far is money. I know that's not why any of us are here now, which is a good thing, IMO. However, if it was possible to get a decent return on a project, even those who are doing it for passion would be more motivated. It's possible to make money on an actual production run, but reducing development time would be the only feasible way to make the sales merit the work financially. The only other option I could see would be to increase sales to a point that a two to four year production cycle is profitable, and that's highly improbable.