Originally posted by: davidpgil

Update -- its been over a year. I took a massive tour trying to get into NES game dev that lead me to many false starts and I am still not anywhere close to "making the game".

Tangents I took:
1) Learn about Commodore 64 because it uses the same 6502 chip -- was going to learn to code 6502 the old school way on a actual Commodore 64. Its a money pit.
2) Get involved with NESMaker -- brief stint. I hated it. Its game dev for people who are terrified to program. I want to learn to code ASM.
3) Get Making NES Games by Mr. Hugg -- development happens on his own web based IDE in mostly C. I hated that approach. I want to use a desktop editior and code in ASM.
4) Nerdy Nights -- Initially promising! However, the tutorials start to miss too many project files, especially in the sound section. Which I decided I would start in the sound section for my project. I found alternative project files but they use CA65 instead of NESASM which is what Nerdy Nights uses.
5) Michael Chiaramonte development videos -- These are actually quite good but each one is so long and densly packed with info and not done in a tutorial format.
6) I also MAY do this course for the 2600 which also has a 6502 chip: https://www.udemy.com/course/programming-games-for-the-atari...  ... My reasoning is to just gain experience with coding in ASM. Not sure yet.

As of today I think I just need to brute force problem solve my way through the Nerdy Nights tutorials using CA65 project files but still follow the logic in the lessons. I also probably need lost of help from NESDev and probably Nintendo Age.

Keep in mind im doing this project in my spare time when I have energy to work on it. Things have gone painfully slow.

Originally posted by: rlh
 
I started "coding" at the age of 16 in 1997, which was the year my family got our first computer. I had one goal, and that was to "learn how to make games".  I've learned a lot since then and I often got derailed on tangent projects because I soon discovered that for me, I was more interested in learning how to make cool things, so most of my projects simply ended up being demos.


That said, for over the past 20 years, I've found the best way to learn something is to pick something you'd really like to make with a tool and just make it.  Learn how to get around every hurdle preventing you from accomplishing your goals. If your game is inefficient, then dig deeper in compiler/assembler or CPU architecture.  Sure, there are a lot of books and materials you can read through but if you have an end-goal to makes something, then determine specifically what you want that to be and just go make it.  Yes, you will make mistakes.  This is part of the coding process.  We all do this.  I wish I could say that even today, 20 years later, I had once in my career written a "perfect" application.  This doesn't happen because everything is to big to be a simple tool that involves 10 lines of code.  Any sizable project will have it's shares of successes but also minor mistakes or, at least, techiniques and approaches that could've been better.  But, that's how you learn and get better!

I suggest starting with something small.  I don't know, make a Tic-Tac-Toe game with a naive AI.  That should be "simple" enough.  If you also want to get into sound editing, add some beeps and boops when a player plays, or maybe cycles through places available on the board or, if you're really ambitious, make a simple tune that plays on the menu screen.  This isn't going to be a blockbuster but should get you familiar with game state, scene transitions, audio and handling input.  Build off of that.

>> My game idea is to make an animated intro sequenced accompanied by music. Pretty simple. I have already accomplished this using Godot Game Engine and want to make a "real" intro for the NES. 

It sounds, to me personally, you might have thought about this a bit too much.  That's cool, sometimes the journey is the most fun part.  But, if you want to make a game, start small.  Make a really basic game, and learn from that experience.  Then, maybe, start working on making something a bit more "awesome".

>> I think I just need example code that does this intro accompanied by a song. Do you know where I could look? I don't think I have overthought this. If anything I just need better example code.

Also, regarding hand-coding everything and wanting to leanr ASM.  I want to both 100% agree... and disagree with this approach.  Let me explain.  First, coding a game at the lowest level possible is an invaluable experience. I code today in C#, but I've had my share of experiences as a professional coding in C++, C and even a little ASM.  As much as I'm happy today to abide in C# for my professional career, and I'd never choose those tools for the nature of the work I do today, I would never trade my time using those tools and from time to time, I do want to come back them.  The reason is because the closer you get to working directly with the hardware, the more familiar you will be with the hardware when you use more advanced, high-level tools.  Put differently, it's because I've developed in those lower-level languages that I understand what's going on under the hood in the .Net compiler and IL interpreter.  I know how computers work, I know trade offs of various techniques and I also know when it's important to break "conventional wisdom" because that wisdom is sometimes built on sacrificing performance over philosophy.

>> I already know how to code in javascript, python and some C/C++. I want to learn ASM because I want to deepen my understanding of how code really works while geeking out.  

I'll stop rambling but, I simply recommend that you start with a very barebones game.  You don't even have to share it.  Simply make a game or application that touches all aspects of the NES.  Once you get your developer "sea legs", then scale up to a tougher project that you might actually be more hyped about making.  Look for answers specifically as problems arise, rather than attempting to become a well-knowledged developer.  Just start.  Once you're familiar with the hardware and the ASM, do be affraid to scale-up to more robust, high-level tools. In fact, it was my understanding that NES maker didn't compile games but kind of made games that built in ASM and then might have compiled the games.  The idea being, you could interrupt the compilation process and manually modify the outputted ASM.  If that's the case, so long as you can make your game generally within the parameters of types of games it's designed to make, then use that tool, and then tweak the ASM to your hearts content.  I've not used that tool, but from what I gather, it looks like a great way to quickly roll out title based games, or scrolling levels and then you can tweak the specific details.  I could be wrong.  I have no idea how well they made that application, but so long as it generates well documented/named ASM code for pre-compilation, it might be an invaluable tool for single homebrew devs to make great game start-to-finish.

>> NESMaker maps to the ASM that the NES reads in a way that could be useless to the user as I understand it. NESMaker is the polar opposite of what I want to gain from making a NES game. I actually want to learn how to really make stuff work.