Published first game - what next?
Moderator: Moderators
Published first game - what next?
Hi folks.
I have published my first game after 10 months of development and got some good feedback from about 60 players. viewtopic.php?f=22&t=20563&start=15#p264956
I've learnt quite a bit about 6502 assembly, tooling and cooperation with pixel artists and music artists. I have also learnt the value of early feedback and that I need to polish main game mechanics really well, for users to enjoy it.
I have reached a state, when I can basically say that I "think" I know what I don't know
I lack the knowledge about mappers, as I only used zero in my first title. My game only supported y axis 2 screen basic scrolling, advanced scrolling is unknown to me. Never had to use more advanced techniques, like sprite zero collision.
My question to you is, should I jump stright into bigger project or pace myself and first get some more xp under my belt? I'm thinking about commercial, kick starter backed game. I have a feeling that large portion of code base could be reused, like NMI handling, password logic, main game loop, partial screen refresh.
I have published my first game after 10 months of development and got some good feedback from about 60 players. viewtopic.php?f=22&t=20563&start=15#p264956
I've learnt quite a bit about 6502 assembly, tooling and cooperation with pixel artists and music artists. I have also learnt the value of early feedback and that I need to polish main game mechanics really well, for users to enjoy it.
I have reached a state, when I can basically say that I "think" I know what I don't know
I lack the knowledge about mappers, as I only used zero in my first title. My game only supported y axis 2 screen basic scrolling, advanced scrolling is unknown to me. Never had to use more advanced techniques, like sprite zero collision.
My question to you is, should I jump stright into bigger project or pace myself and first get some more xp under my belt? I'm thinking about commercial, kick starter backed game. I have a feeling that large portion of code base could be reused, like NMI handling, password logic, main game loop, partial screen refresh.
Re: Published first game - what next?
There is a big gap between Pong and Final Fantasy. Would you back a Pong author's KS for FF?
IOW, I think you'll need more practice before trying a big commercial project.
IOW, I think you'll need more practice before trying a big commercial project.
Re: Published first game - what next?
Yes a big step as Pong is about as simple as an action game can get. And you would probably want a working prototype before going kick starter.
Re: Published first game - what next?
My honest opinion:RJM wrote: ↑Thu Feb 11, 2021 11:04 am My question to you is, should I jump stright into bigger project or pace myself and first get some more xp under my belt? I'm thinking about commercial, kick starter backed game. I have a feeling that large portion of code base could be reused, like NMI handling, password logic, main game loop, partial screen refresh.
I can 100 % tell you that you're not ready for a commercial Kickstarter project.
While your game is nice as a beginner's game, it is as basic as it gets. It pretty much has no game physics at all. It's "Press the d-pad to move the character one pixel in the corresponding direction" plus sprite collision checks.
The idea that a large portion of the code base can be reused for a more complex game is hopelessly optimistic. Imagine a game where you have an actual level structure. Where you have walls that you cannot pass, gaps that you can fall through, jump physics, level scrolling updates that are done live during gameplay. Then imagine you have a lot of characters on the screen, so that your framerate drops down if you don't optimize your code. Then imagine that all of these characters can do different things.
Furthermore, your current game has visual glitches during screen transitions, like frames that consist of nothing but zeroes, visible scrolling misalignments and palette artifacts. Which shows me that you don't have an eye for those kinds of things yet or that you simply don't mind them. But those are not necessary NES issues. Those are things that a professional NES programmer is supposed to fix. ("Super Mario Bros." doesn't have screen transition glitches.)
Since you overlooked them, you're far from being a professional NES programmer and therefore even farther away from taking money for anything.
So, should you jump to a bigger project? Definitely.
You shouldn't tweak your current game for eternity. You might be able to remove some of the glitch issues, but overall, continuing to work on this game won't really give you the experience that you need for more complex games.
I can't understand people who program a simple throwaway game with very basic game logic and then polish and polish and polish it to no end. Save this for the next game, the one that people actually might play for more than five minutes.
So yeah, you should start another game. With a level structure, with scrolling, with more than two opponents at once etc.
But you need to keep in mind two things:
1. Bigger project doesn't mean "Mega Man" yet. And especially not "The Legend of Zelda". Don't even think of programming a game like "Zelda" at this point in time.
2. You are definitely not qualified to start a Kickstarter campaign any time soon. Sorry, but it's the hard truth.
Have a look at the first level of this game, named "Challenger":
https://www.youtube.com/watch?v=Ec_-q4Kyme4
If you can program and completely finish something like that, including having no screen glitches, then you might be qualified to try a full-blown platformer like "Castlevania" next. But only if you bring enough time, patience and discipline.
If you do it right, you can extend the engine for the "Challenger"-like demo game to make the full-blown platformer out of it, without having to start from scrach for this third game.
And if your full-blown platformer is as good as finished, i.e. all levels, all enemies, all items, all physics, the scrolling, the status bar, title screen, ending, screen transitions, character values, all graphics, all music, all text, and you only need some very little tweaking here and there and this platformer is something to behold (like if you created something like "Shatterhand" or "Vice - Project Doom" graphics-wise, with gameplay mechanisms like in "Contra" or "Super Mario Bros. 3") and not some boring snore-fest (like "Mystery Quest" or "Atlantis no Nazo"), then you might start a Kickstarter campaign for this platformer.
If you'd rather program a top-down game instead of a side scroller, have a look at the second level of the game "Challenger" and see whether you can recreate something like that.
But in this case, if you plan to program a full-blown adventure, with 16 x 16 screens for the overworld, another 500 screens for dungeons, 50 enemy types, 10 bosses, a whole bunch of NPCs, cutscene events, in-game dialogs, puzzles, items that can interact with the area etc.: Forget it, unless you want to do this for the next 10 to 15 years.
A top-down game like a better version of "Commando" might be doable as a third game, though. Again, with enough patience and discipline.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Published first game - what next?
Many thanks for your honest opinions calima, Pokun, and especially to DRW for the very detailed answer. This is a great help to me and tbh I was expecting such answers.
Immunatio is my very first NES game, but I've been doing games as a hobby for years. I did some simple 3D platformer with leader boards in the cloud using Unreal Engine 4, did Dance Dance Evolution clone in JavaME and a quiz game for Android, and finished some 2D top-down stealth tech demo on Godot engine.
I did 2D platformer, with scrolling + multiple screens, pixel-level collisions, gravity, and sprite animation, but it was more of a tech demo ( I used Megaman SNES sprites ). I coded everything from scratch in Java, w/o engine.
Some of my projects are lost in time since I had it on an old drive and didn't bother to version control/back it up back then, simply did not care - these were learning exercises.
All these past project, especially writing 2D platformer w/o engine gave me some experience, which leads me to answer your next question: yes I can pull off smth like Challenger, but in a higher-level language, as so far I mostly coded my games using Java, Python (actually gdscript but it's similar) or UE4 Blueprints. I used to code in Java for ~5y and about ~3y in Python for living. I could probably do Challenger C too given enough time, but whether I could do it in plain 6502 assembly is a whole different story.
When I do my coding in 6502 assembly it feels like more fun than any other language I used so far, but also takes longer. You could probably attribute it to my short practice with the language, but I really wonder how do people prefer to create games for NES? I did some C coding about 10y ago in college. For productivity reasons I'm considering moving to this language. Do you think it's a good idea or should I rather stick with asm?
I also need to look up all of the time some details about the hardware on nesdev wiki, as I simply haven't done it long enough to remember things like which memory address corresponds to what in PPU and so on.
I really like your progression advice DRW, making each time a slightly bigger game. The thing I haven't added in Immunatio was a boss fight, so I was thinking that my next game ( or a tech demo ) could be all about fighting different bosses in 2D platformer style. Due to personal reasons, I can't start it soon, so I use this time to gather some valuable information from you guys, who spent years developing NES games.
Once again thank you for your time. I have also created this in the wrong forum, should have been NESdev.
In all honesty, I thought 1-2 frame glitches between levels are to short to cause any troubles and I let them be to focus on delivering game on the deadline.Furthermore, your current game has visual glitches during screen transitions, like frames that consist of nothing but zeroes, visible scrolling misalignments, and palette artifacts. Which shows me that you don't have an eye for those kinds of things yet or that you simply don't mind them. But those are not necessary NES issues. Those are things that a professional NES programmer is supposed to fix. ("Super Mario Bros." doesn't have screen transition glitches.)
Since you overlooked them, you're far from being a professional NES programmer and therefore even farther away from taking money for anything.
Immunatio is my very first NES game, but I've been doing games as a hobby for years. I did some simple 3D platformer with leader boards in the cloud using Unreal Engine 4, did Dance Dance Evolution clone in JavaME and a quiz game for Android, and finished some 2D top-down stealth tech demo on Godot engine.
I did 2D platformer, with scrolling + multiple screens, pixel-level collisions, gravity, and sprite animation, but it was more of a tech demo ( I used Megaman SNES sprites ). I coded everything from scratch in Java, w/o engine.
Some of my projects are lost in time since I had it on an old drive and didn't bother to version control/back it up back then, simply did not care - these were learning exercises.
All these past project, especially writing 2D platformer w/o engine gave me some experience, which leads me to answer your next question: yes I can pull off smth like Challenger, but in a higher-level language, as so far I mostly coded my games using Java, Python (actually gdscript but it's similar) or UE4 Blueprints. I used to code in Java for ~5y and about ~3y in Python for living. I could probably do Challenger C too given enough time, but whether I could do it in plain 6502 assembly is a whole different story.
When I do my coding in 6502 assembly it feels like more fun than any other language I used so far, but also takes longer. You could probably attribute it to my short practice with the language, but I really wonder how do people prefer to create games for NES? I did some C coding about 10y ago in college. For productivity reasons I'm considering moving to this language. Do you think it's a good idea or should I rather stick with asm?
I also need to look up all of the time some details about the hardware on nesdev wiki, as I simply haven't done it long enough to remember things like which memory address corresponds to what in PPU and so on.
Right!? I seriously couldn't agree more with you. I got a lot of feedback from users and 3-4 people send me long lists of things they would want to be added to the game. I have politely refused to introduce most of it. After all this is a simple top down game, no matter how much work you put into this it won't change that.I can't understand people who program a simple throwaway game with very basic game logic and then polish and polish and polish it to no end. Save this for the next game, the one that people actually might play for more than five minutes.
I really like your progression advice DRW, making each time a slightly bigger game. The thing I haven't added in Immunatio was a boss fight, so I was thinking that my next game ( or a tech demo ) could be all about fighting different bosses in 2D platformer style. Due to personal reasons, I can't start it soon, so I use this time to gather some valuable information from you guys, who spent years developing NES games.
Once again thank you for your time. I have also created this in the wrong forum, should have been NESdev.
Re: Published first game - what next?
Well, they might not actually be a problem, and for such a low-scale game, I guess nobody cares.
However, it does show that the way you do things on the NES isn't already the typical, established way it is usually done.
Sprite flickering or those color glitches on the right side of the screen in "Super Mario Bros. 3", those are system-specific issues that are accepted because there's no easy way around it.
(SMB3 has four-way scrolling and a status bar, therefore horizontal mirroring had to be used and that's where the color artifacts during horizontal scrolling come from. In SMB1, those artifacts would have been bad programming since that game has no vertical scrolling, so it uses vertical mirroring. That's why there are no scrolling artifacts in SMB1.)
But screen change glitches never need to occur on the NES if you do it right.
Hence, if you use the disabling of the PPU properly, if you use buffer values for your background data and scrolling positions that then only get written to the actual registers while you're in NMI etc., then those glitches don't appear in the first place.
Those are some of the things that you should organize pretty early in the beginning when you start a new game and shouldn't treat it as "polishing" or cleanup for later. Because as soon as you make it right, these specific artifacts and glitches won't be an issue ever again.
So, for your next game you should read this article:
https://wiki.nesdev.com/w/index.php/The_frame_and_NMIs
If you're already well-versed in general game development, you might be able to skip a pure demo game and start with the one that you want to do right away. After all, much of the stuff isn't NES-specific, but simply requires general knowledge of programming.
However, you should check how much time you want to invest and then check what kind of game you want to do. I worked on "City Trouble" for approximately 1.5 years (working in the afternoons) and it's a relatively simple game. But that's exactly what I wanted: I wanted to do a first game that I can actually finish in a reasonable amount of time. Something like "Castlevania" probably would have required me to spend three years on it.
Regarding the programming language: You don't need to program in pure Assembly. There is a working C compiler for 6502-based systems like the NES: cc65. And despite what some people might say, it isn't that bad.
There are a few things that are not perfect.
The most bothersome issue is the fact that accessing pointer[index] produces highly ineffective code: The compiler copies the pointer to its own internal zeropage pointer since LDA (pointer), Y only works with zeropage variables. But it does so even if your own pointer is already in the zeropage, which is a total waste of ROM memory and CPU time.
But that's what inline assembly is for:
Code: Select all
/* variable = pointerAsArray[index]; */
#define SetVarFromPtrAtIdx(variable, pointerAsArray, index) \
{ \
__asm__("LDY %v", index); \
__asm__("LDA (%v), Y", pointerAsArray); \
__asm__("STA %v", variable); \
}
Anyway, while you should still write some stuff in pure Assembly (for example the whole NMI background update stuff or setting the hardware sprite values based on the characters' meta sprite definitions), you can write most of your code in C.
This is what constants are for. I don't write STA $2006, I write STA PPUADDR and have a general include file that has all those NES-specific registers defined.
A game with just boss fights? I don't know. Wouldn't this be a bit too boring?
Unless you only want to do this as a demo game. But after you said that you already programmed a bunch of games for other platforms, I'd say you can skip the demo proof-of-concept game. This would have been just for someone who hasn't programmed any proper game yet: Let him create a simple side scroller like that "Challenger" train level, so that he gets a feeling for game physics, computer AI, background interaction (platforms and gaps), scrolling etc.
But someone who has already written small games on the PC, that person can go from "test program that lets you learn the NES internals" right to "proper NES game".
The only question is: How big shall that proper NES game be? "Kung Fu" complexity? "Castlevania" complexity?
It depends on how long you can motivate yourself to work on a game without having a finished product.
If you only want to work a year or so, take the smaller game. If you don't mind three years, take the longer one.
But don't exaggerate it. I would advise against something like "Castlevania III", unless you want to dedicate more than half a decade of your life to that game. Or if you can work fulltime on it, eight hours per day. Then it might be possible to finish such a huge game in a reasonable amount of time.
But as a side project for evenings and weekends, "City Trouble" alone took me 1.5 years for the ROM and a few additional months until the manual and box was finished and the game could go into production.
And if your game is a really great game, for example if you program a true NES game that looks like the original plans for the retro-inspired PC game "Steel Assault" (minus the things that are simply impossible on the NES):
https://www.youtube.com/watch?v=ILE-eNMxpaE&t=1m50s
If such a game of yours is 99% finished, then you may want to start a Kickstarter campaign for financing the physical production.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Published first game - what next?
Boss rush games exist. Street Fighter 2010 is arguably one, as is every one-on-one fighting game. Some Mega Man games have a room near the end that replays the bosses of the same game or a previous game.
Such as myself. Though I wrote every line of code in Haunted: Halloween '85 and its sequel except for the sound driver, I cheated in a sense because I had someone else as the director, sprite artist, background artist, etc. My biggest solo works have been single-screen games that don't scroll and a TV testing program. I'm impressed by Challenger having the train level and an 8-way scrolling adventure game in NROM. (I'm also a bit disappointed that its map hasn't been ripped on vgmaps.)DRW wrote: ↑Mon Feb 15, 2021 7:10 am This would have been just for someone who hasn't programmed any proper game yet: Let him create a simple side scroller like that "Challenger" train level, so that he gets a feeling for game physics, computer AI, background interaction (platforms and gaps), scrolling etc.
Re: Published first game - what next?
Have you played The Wander and the Colossus for PS2? It's more than just a boss rush, but there are no "zako" type of enemies. The 15 bosses makes up the whole enemy list. The previous game, Ico, instead had almost only identical zako enemies and only a single boss.
As for C vs 6502, a lot of people here, including me, likes to stick to assembly. But we are usually mainly doing personal hobby projects, if you are planing a kickstarter project, I guess you might need the speed of C. C still requires a lot of assembly for the more time critical stuff and you need to get used to the NES hardware anyway.
No matter your previous programming experience it may be hard to predict how much problems you will stumble on if making a larger project in assembly. You seem to have good judgement, I'm just saying that you will probably run into many unexpected problems which will slow down development no matter what. That's why something like a kick-starter should be decided on after you have gotten a good working and somewhat polished prototype so that you have something to show off and get a better feeling on how hard it is to make. Even then, when trying to finish it, you will probably run into entirely new unexpected problems.RJM wrote: ↑Mon Feb 15, 2021 4:10 am All these past project, especially writing 2D platformer w/o engine gave me some experience, which leads me to answer your next question: yes I can pull off smth like Challenger, but in a higher-level language, as so far I mostly coded my games using Java, Python (actually gdscript but it's similar) or UE4 Blueprints. I used to code in Java for ~5y and about ~3y in Python for living. I could probably do Challenger C too given enough time, but whether I could do it in plain 6502 assembly is a whole different story.
When I do my coding in 6502 assembly it feels like more fun than any other language I used so far, but also takes longer. You could probably attribute it to my short practice with the language, but I really wonder how do people prefer to create games for NES? I did some C coding about 10y ago in college. For productivity reasons I'm considering moving to this language. Do you think it's a good idea or should I rather stick with asm?
I also need to look up all of the time some details about the hardware on nesdev wiki, as I simply haven't done it long enough to remember things like which memory address corresponds to what in PPU and so on.
As for C vs 6502, a lot of people here, including me, likes to stick to assembly. But we are usually mainly doing personal hobby projects, if you are planing a kickstarter project, I guess you might need the speed of C. C still requires a lot of assembly for the more time critical stuff and you need to get used to the NES hardware anyway.
Re: Published first game - what next?
Yeah, partly. It does have some levels though. Also, it's not the best game anyway.
Well, a fighting game doesn't have typical videogame bosses with their relatively easy and predictable patterns. Fighting games have the same characters that the player can choose as well, with movements that are supposed to mimic human play. There's a difference between fighting an opponent in "Street Fighter II" and fighting a robot master in "Mega Man".
If he wants to create a proper fighting game, I'm all for it because we don't really have that for the NES yet, except for "Turtles Tournament Fighters". ("Karate Champ" and "Yie Ar Kung-Fu" are just those old-fashioned, primitive, pre-SF2 fighting games.)
But imagine if you have "Contra", but only the bosses and nothing else: Would this have been a successful game?
That's a small section in a much larger game. It's not the exclusive contents of that game. What's your point?
I haven't played it and I don't know whether it's fun. But in any way, do you think the experience of fighting these larger than life characters in a vast 3D area can be replicated with an NES game, so that a pure boss rush game could stand on its own and wouldn't just seem like a demo project?Pokun wrote: ↑Mon Feb 15, 2021 8:54 am Have you played The Wander and the Colossus for PS2? It's more than just a boss rush, but there are no "zako" type of enemies. The 15 bosses makes up the whole enemy list. The previous game, Ico, instead had almost only identical zako enemies and only a single boss.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Published first game - what next?
Ico and its sequel are both very experimental games that tries to do things commonly not done in games by putting restrictions on themseleves. Ico for example removes the life bar (meaning you basically can't die from enemy attacks, only be pushed away from the girl you are trying to save) and keeps enemies limited to the same type of shadow monster thing. Wander does use a life bar (and a grip stamina bar) but instead removes enemies, sans bosses, making it a very large game with a lot of emptiness and a focus on very complex boss fights. They are both excellent games though.
The concept in Wander would probably not work very well in a NES game without becoming a simple boss rush game. You ride through beautiful and very large but empty 3D landscapes with nothing but birds, lizards, rocks and trees in. The only purpose it serves seems to be to make you feel the wanderer's burden to travel alone with his horse in a forbidden land on his quest to destroy these mysterious demi-gods and revive his lover. The fact that there are nothing there makes you feel very lonely. I have a hard time picturing how to make something similar to that on the NES.
As for SFII-like VS Fighting games on the NES, there is Joy Mecha Fight and the notorious and unlicensed Kart Fighter, but that's about it.
The concept in Wander would probably not work very well in a NES game without becoming a simple boss rush game. You ride through beautiful and very large but empty 3D landscapes with nothing but birds, lizards, rocks and trees in. The only purpose it serves seems to be to make you feel the wanderer's burden to travel alone with his horse in a forbidden land on his quest to destroy these mysterious demi-gods and revive his lover. The fact that there are nothing there makes you feel very lonely. I have a hard time picturing how to make something similar to that on the NES.
As for SFII-like VS Fighting games on the NES, there is Joy Mecha Fight and the notorious and unlicensed Kart Fighter, but that's about it.
Re: Published first game - what next?
Shadow of the Colossus was pretty cool, and it consisted basically of finding bosses and figuring out how to kill them.
EDIT: Ugh, should have read the rest of the posts before writing this. Anyway, Shadow of the Colossus is pretty cool.
- Controllerhead
- Posts: 314
- Joined: Tue Nov 13, 2018 4:58 am
- Location: $4016
- Contact:
Re: Published first game - what next?
Alien Soldier for Genesis is amazing. Brutally difficult and a technical tour-de-force.
NOW IS TIME TO THE 68000 HEART ON FIRE!
https://en.wikipedia.org/wiki/Alien_Soldier
Re: Published first game - what next?
Here's a detailed look at how Zelda I implements sword combat including the status of the sword slashes and sword-to-enemy hit detection, with walkthroughs of asm code. If nothing else it shows the complexity of programming a game like this.
https://www.youtube.com/watch?v=FBk-QkzMeIk
Re: Published first game - what next?
Apologies for the late response.
I've found out that 1 year long projects work the best for me.
Question about time is probably the most important of all right now. A bit about me, to give you some context. I'm a working father of 3 little boys. My wife has just returned to work after a maternity leave and we're slowly figuring it all out in the new reality. I'm not starting any new project until we have a healthy split of responsibilities in place.DRW wrote: ↑Mon Feb 15, 2021 7:10 am It depends on how long you can motivate yourself to work on a game without having a finished product.
If you only want to work a year or so, take the smaller game. If you don't mind three years, take the longer one.
But don't exaggerate it. I would advise against something like "Castlevania III", unless you want to dedicate more than half a decade of your life to that game. Or if you can work fulltime on it, eight hours per day. Then it might be possible to finish such a huge game in a reasonable amount of time.
But as a side project for evenings and weekends, "City Trouble" alone took me 1.5 years for the ROM and a few additional months until the manual and box was finished and the game could go into production.
I've found out that 1 year long projects work the best for me.
This is another great idea. I always enjoyed fighting games and wanted to make one for years.
Thanks, I'm going to switch to C with a bit of assembly as most of you seem to mention this solution. Will https://shiru.untergrund.net/articles/p ... s_in_c.htm be a good starting place? I know that I learn the most from tutorials with some code snippets.Pokun wrote: ↑Mon Feb 15, 2021 8:54 am No matter your previous programming experience it may be hard to predict how much problems you will stumble on if making a larger project in assembly. You seem to have good judgement, I'm just saying that you will probably run into many unexpected problems which will slow down development no matter what. That's why something like a kick-starter should be decided on after you have gotten a good working and somewhat polished prototype so that you have something to show off and get a better feeling on how hard it is to make. Even then, when trying to finish it, you will probably run into entirely new unexpected problems.
As for C vs 6502, a lot of people here, including me, likes to stick to assembly. But we are usually mainly doing personal hobby projects, if you are planing a kickstarter project, I guess you might need the speed of C. C still requires a lot of assembly for the more time critical stuff and you need to get used to the NES hardware anyway.
Interesting, I never played these games. I thought TMNT Tournament was the only decent fighting game on NES, I'll try them!
Re: Published first game - what next?
Yeah, as a family man with a day job, writing a larger game might actually be a futile approach. I have a job as well, but I live alone, and even I took many months until a very simple platformer was finished. Those games can eat up a lot of your time. So, in this case, if you actually want to finish a game and don't plan to work sporadically on it over a period of 10-15 years, I'd suggest some pre-"Super Mario Bros."-sized game.RJM wrote: ↑Sun Feb 28, 2021 9:33 am Question about time is probably the most important of all right now. A bit about me, to give you some context. I'm a working father of 3 little boys. My wife has just returned to work after a maternity leave and we're slowly figuring it all out in the new reality. I'm not starting any new project until we have a healthy split of responsibilities in place.
I've found out that 1 year long projects work the best for me.
The engine for a fighting game might be easier than other games since you basically only have the character movement and nothing else. Sure, the movements are more complicated than in a platformer, but you save the time for levels, items, level buildup, bosses etc.
However, programming a good computer AI might be the bothersome part.
Also, think about the inherent NES limitations: Eight sprites per scanline means a lot of potential flicker.
Yeah, that's a good starting place.RJM wrote: ↑Sun Feb 28, 2021 9:33 am Thanks, I'm going to switch to C with a bit of assembly as most of you seem to mention this solution. Will https://shiru.untergrund.net/articles/p ... s_in_c.htm be a good starting place? I know that I learn the most from tutorials with some code snippets.
Since you already know how to program the NES, you don't really need a tutorial. You can just program your stuff as in your last game. And single functions can be written in C.
The NMI, controller reading, all the PPU stuff, music and turning your game characters to the hardware sprites should still be done in pure Assembly anyway.
And for the rest: Well, you simply write your functions in C instead of Assembly. For someone who knows the NES and C, there's nothing really that you need a tutorial or code snippets for. It's simply this:
Code: Select all
@gameLoop:
LDA WaitForNmi
BNE @gameLoop
; Read controller input here.
; This function is written in C:
JSR ProcessNextFrame
LDA #true
STA WaitForNmi
JMP @gameLoop
"Joy Mecha Fight" has those strange abstract characters and is therefore not really a suitable replacement for stuff like "Street Fighter II" or "Fatal Fury".
As far as unlicensed games go, there are many more. There are a bunch of "Street Fighter II" and "Mortal Kombat" bootlegs. Most are crap. One of the few half-decent games is this:
https://www.youtube.com/watch?v=lo2ubnjDmqU
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html