Citizen_Weeb
New member
What difficulties lie in the way of the creation of a module for the creation of strategy games? I'm thinking especially of games like Famicom Wars, Nobunaga's Ambition, and Gemfire.
Strategy module?
- Thread starter Citizen_Weeb
- Start date
kevin81
Well-known member
Oh my, you're in for a ride 
It is possible to make a strategy based module for NESmaker but it isn't an easy feat. The modules that exist are based on top-down adventure or maze games, or variations of the platformer type (arcade, one-way old school plumber scrolling, or two-way megametrovania scrolling). I think you'll be best off basing such a module on the Adventure module that exists already, although creating a strategy module needs A LOT of extensive scripting: random enemy encounters, turn based menu input scripting, player and enemy stats and weighed (but slightly randomized) weapon strengths are just a few of the features that aren't readily present in base modules and thus need to be developed and implemented. And I can't even imagine how (or if) these features tie in with the NESmaker UI.
Forum user Nishi is going at it for about a year and a half now; watch and follow the RPG Time! thread to see where they're at and what challenges have been overcome in the last 15+ months.
Long story short: if you're new at NESmaker, or NES development in general, this may be a feat that is just a bit too far out of reach right now.
It is possible to make a strategy based module for NESmaker but it isn't an easy feat. The modules that exist are based on top-down adventure or maze games, or variations of the platformer type (arcade, one-way old school plumber scrolling, or two-way megametrovania scrolling). I think you'll be best off basing such a module on the Adventure module that exists already, although creating a strategy module needs A LOT of extensive scripting: random enemy encounters, turn based menu input scripting, player and enemy stats and weighed (but slightly randomized) weapon strengths are just a few of the features that aren't readily present in base modules and thus need to be developed and implemented. And I can't even imagine how (or if) these features tie in with the NESmaker UI.
Forum user Nishi is going at it for about a year and a half now; watch and follow the RPG Time! thread to see where they're at and what challenges have been overcome in the last 15+ months.
Long story short: if you're new at NESmaker, or NES development in general, this may be a feat that is just a bit too far out of reach right now.
Citizen_Weeb
New member
I'm aware of the RPG Time thread as well as the currently existing modules, I was mostly wondering what the hurdles would be with regards to this matter.
There are numerous hurdles for such a project, as there are several custom systems you need. I have made multiple prototypes in the past that attempt to overcome these, and have mostly been successful in it, so I will give a brief overview and can dive in further if needed: Bear in mind that 6502 ASM and NES architecture are not strengths of mine, so this will not likely give the best ways to solve them, it will just show how I approached solving them in the constraints of NESMaker. Additionally, apologies for the essay-length read, I just love this stuff and want to help:
----------------------------------------------------
PROBLEM #1: UNIT COUNT -- Unless you want less than 8 units on screen at one time, sprites / objects are not the way to go. Games like Famicom Wars and Fire Emblem, etc. all used tile-based units. Warlocked for GBC took this a step further and had tile-based units that transitioned to sprite-based units whilst moving in-between tiles to allow for the illusion of multiple active units that aren't static background elements.
Tile-based unit movement in NESMaker is doable without too much trouble or expertise (see my recent post on fog-of-war mechanics for an example of tile-movement. The unit you see moving around is not an object, only the mouse that moves around to select them). The main issue you have to overcome (which can be solved with a simple timer, or PRESS then HOLD code block for a button in the case of unit movement), is that using tile swaps limits you to changing one tile at a time (but moving a unit one space means you need to change 2 simultaneously!)-- At least in 4.5 and earlier this means that if you want to change multiple tiles you need to time their changes so they sequentially occur. For unit movement this is easy: The PRESS event for the button can be clearing the tile they are on, and the HOLD event for the button can be changing the tile they are moving to. If you want to get more changes for one reason or another, you will need to use code loops (in my fog of war post linked earlier I used a loop based on X and Y position tests to selectively change the palette of the tiles one at a time really fast in sequence) .
----------------------------------------------------
PROBLEM #2: FOG OF WAR -- If you use a system like the one I describe in my previously linked fog-of-war post and tweak it a bit, you can make an effective fog that mimics those used in Dune II, Command and Conquer, Red Alert etc. where once you explore an area with a unit it is permanently visible. You would simply be changing the palette in a 3x3 area from dark colors to light colors, and not changing anything from light back to dark.
If you want a fog-of-war that instead is closer to my prototype, but for multiple units at a time, like Warcraft II, or Advance Wars, where you can see the terrain after exploring it, but can only see lit up areas directly around units as they move around, you are going to have to dive into some math at the very least and get creative. The way I approached this in building on that fog-of-war demo was through proximity checks. There are some good posts about here concerning enemy behaviors that test proximity before doing something, and this provides the key for this kind of system: if you have multiple units with multiple light radii, their palette loop needs to not only test its X/Y in relation to its own position for the sake of knowing which ones its making dark and which ones its making light (or if you are more clever than me, use an array or something to store a template of values), but it needs to test its own position against its nearest neighbors to determine which tiles overlap.
A cheap method is to simply check their bounds with the BCC and BCS instructions, as these are overlapping squares, i.e. if their X value is less than 48 from each other and their Y value is less than 48 from each other, they are overlapping in some fashion.
If you want to dive further into distance checks that aren't necessarily clean box collisions, I would recommend looking up Manhattan Distance as a calculation method. Square roots are possible and well-documented in 6502 ASM if you want to get even more accurate using the Pythagorean theorem, but it is far more resource intensive.
----------------------------------------------------
PROBLEM #3: MEMORY -- This is one of the larger issues that will take far more creativity and expertise than what I have at present. Maybe someone else can jump in.
In the grand scheme of things, you have plenty of room in all the banks to fit various kinds of strategy games, and if you take a careful and methodical approach (i.e. one thing at a time so you don't break anything too horribly), you can remove most of the useless pieces of the engine you are using to fit more stuff and turn it into more of a strategy module.
The main problem I see here instead lies in the kinds of memory you need to access during gameplay in those types of strategy games that require higher unit counts. The most egregious issue is dealing with the different HP / Ammo / Move status, etc. of each tile-based unit across the map along with their positions. If you strip down a lot of the variable space, you could fit quite a lot of your own variables, but this has a limit. I have not tried testing this to see how many variables you can fit, and whether or not they are able to be used with bank switching or any other wizardry to expand the possible space. I suspect there is some basic element I don't understand here that someone with more direct experience with writing custom systems / memory access stuff could answer.
----------------------------------------------------
PROBLEM #4: BATTLE SYSTEM -- Given the elements shown above, you could make a basic strategy game, albeit with lackluster looking combat (i.e. tiny explosion and hp ticking down on the map instead of fancy cutscene-based stuff like Advance Wars / Fire Emblem). If you want a fancier presentation you are going to have to dive even deeper into the memory problem, as now you need to worry about multiple screens, and saving / holding data for access and bringing the screen worth of tile positions back.
Short of that, a potential workaround in the current set up is to use dialog boxes as a 'battlefield' that pops up, and populate it with basic objects or sprites that show an outcome based on the number crunching between units (i.e. decisive victory, pyrrhic victory, draw, minor loss, major loss). This has the potential to be very effective if done correctly, but it will require a lot of diving into the draw functions and custom objects. Lot of possibilities here that will change based on what you want.
----------------------------------------------------
PROBLEM #5: MAP SIZE AND SCROLLING -- Scrolling and its associated issues are beyond me for the most part, so I won't be able to speak much on this. If you want a map that is larger than a single screen, it will be the ultimate dive into the aforementioned custom memory and tile issues when it comes to strategy mechanics.
----------------------------------------------------
PROBLEM #6: VIRTUAL INTELLIGENCE -- Hoo boy this one is fun. I thoroughly enjoy VI programming, but on the NES this has the potential to get very resource intensive and complicated quickly. Note how even in professionally made games like Famicom Wars and Cosmic Wars, the VI often has to literally sit there crunching numbers for a bit before doing much of anything (covered up somewhat by the devs as the opponent 'thinking / plotting'). This expands exponentially with the number / types of units and terrain / variables involved.
There are a lot of different approaches to this broad topic to the point that I don't want to dedicate that much space to it, but I would recommend starting by looking at the source code of some of the Pico-8 strategy games that exist out there. There are some turn-based ones that use very clever compact code to make interesting opponents. I think overall the concepts that make it up are easy to grasp and execute, but the sheer volume and complexity of an interconnected virtual intelligence that is sufficient for a strategy game opponent make it difficult unless you spend a lot of time experimenting in the framework you are building. The up side is it is super fun and satisfying to make even the most basic of virtual opponents.
Alternatively, you could just make your game's enemy controllable by player 2, and sidestep this whole dang topic. Couch co-op for the win.
----------------------------------------------------
WRAP UP -- does all that make sense? I have left out other topics related to this, but I think I touched on the most serious issues.
----------------------------------------------------
PROBLEM #1: UNIT COUNT -- Unless you want less than 8 units on screen at one time, sprites / objects are not the way to go. Games like Famicom Wars and Fire Emblem, etc. all used tile-based units. Warlocked for GBC took this a step further and had tile-based units that transitioned to sprite-based units whilst moving in-between tiles to allow for the illusion of multiple active units that aren't static background elements.
Tile-based unit movement in NESMaker is doable without too much trouble or expertise (see my recent post on fog-of-war mechanics for an example of tile-movement. The unit you see moving around is not an object, only the mouse that moves around to select them). The main issue you have to overcome (which can be solved with a simple timer, or PRESS then HOLD code block for a button in the case of unit movement), is that using tile swaps limits you to changing one tile at a time (but moving a unit one space means you need to change 2 simultaneously!)-- At least in 4.5 and earlier this means that if you want to change multiple tiles you need to time their changes so they sequentially occur. For unit movement this is easy: The PRESS event for the button can be clearing the tile they are on, and the HOLD event for the button can be changing the tile they are moving to. If you want to get more changes for one reason or another, you will need to use code loops (in my fog of war post linked earlier I used a loop based on X and Y position tests to selectively change the palette of the tiles one at a time really fast in sequence) .
----------------------------------------------------
PROBLEM #2: FOG OF WAR -- If you use a system like the one I describe in my previously linked fog-of-war post and tweak it a bit, you can make an effective fog that mimics those used in Dune II, Command and Conquer, Red Alert etc. where once you explore an area with a unit it is permanently visible. You would simply be changing the palette in a 3x3 area from dark colors to light colors, and not changing anything from light back to dark.
If you want a fog-of-war that instead is closer to my prototype, but for multiple units at a time, like Warcraft II, or Advance Wars, where you can see the terrain after exploring it, but can only see lit up areas directly around units as they move around, you are going to have to dive into some math at the very least and get creative. The way I approached this in building on that fog-of-war demo was through proximity checks. There are some good posts about here concerning enemy behaviors that test proximity before doing something, and this provides the key for this kind of system: if you have multiple units with multiple light radii, their palette loop needs to not only test its X/Y in relation to its own position for the sake of knowing which ones its making dark and which ones its making light (or if you are more clever than me, use an array or something to store a template of values), but it needs to test its own position against its nearest neighbors to determine which tiles overlap.
A cheap method is to simply check their bounds with the BCC and BCS instructions, as these are overlapping squares, i.e. if their X value is less than 48 from each other and their Y value is less than 48 from each other, they are overlapping in some fashion.
If you want to dive further into distance checks that aren't necessarily clean box collisions, I would recommend looking up Manhattan Distance as a calculation method. Square roots are possible and well-documented in 6502 ASM if you want to get even more accurate using the Pythagorean theorem, but it is far more resource intensive.
----------------------------------------------------
PROBLEM #3: MEMORY -- This is one of the larger issues that will take far more creativity and expertise than what I have at present. Maybe someone else can jump in.
In the grand scheme of things, you have plenty of room in all the banks to fit various kinds of strategy games, and if you take a careful and methodical approach (i.e. one thing at a time so you don't break anything too horribly), you can remove most of the useless pieces of the engine you are using to fit more stuff and turn it into more of a strategy module.
The main problem I see here instead lies in the kinds of memory you need to access during gameplay in those types of strategy games that require higher unit counts. The most egregious issue is dealing with the different HP / Ammo / Move status, etc. of each tile-based unit across the map along with their positions. If you strip down a lot of the variable space, you could fit quite a lot of your own variables, but this has a limit. I have not tried testing this to see how many variables you can fit, and whether or not they are able to be used with bank switching or any other wizardry to expand the possible space. I suspect there is some basic element I don't understand here that someone with more direct experience with writing custom systems / memory access stuff could answer.
----------------------------------------------------
PROBLEM #4: BATTLE SYSTEM -- Given the elements shown above, you could make a basic strategy game, albeit with lackluster looking combat (i.e. tiny explosion and hp ticking down on the map instead of fancy cutscene-based stuff like Advance Wars / Fire Emblem). If you want a fancier presentation you are going to have to dive even deeper into the memory problem, as now you need to worry about multiple screens, and saving / holding data for access and bringing the screen worth of tile positions back.
Short of that, a potential workaround in the current set up is to use dialog boxes as a 'battlefield' that pops up, and populate it with basic objects or sprites that show an outcome based on the number crunching between units (i.e. decisive victory, pyrrhic victory, draw, minor loss, major loss). This has the potential to be very effective if done correctly, but it will require a lot of diving into the draw functions and custom objects. Lot of possibilities here that will change based on what you want.
----------------------------------------------------
PROBLEM #5: MAP SIZE AND SCROLLING -- Scrolling and its associated issues are beyond me for the most part, so I won't be able to speak much on this. If you want a map that is larger than a single screen, it will be the ultimate dive into the aforementioned custom memory and tile issues when it comes to strategy mechanics.
----------------------------------------------------
PROBLEM #6: VIRTUAL INTELLIGENCE -- Hoo boy this one is fun. I thoroughly enjoy VI programming, but on the NES this has the potential to get very resource intensive and complicated quickly. Note how even in professionally made games like Famicom Wars and Cosmic Wars, the VI often has to literally sit there crunching numbers for a bit before doing much of anything (covered up somewhat by the devs as the opponent 'thinking / plotting'). This expands exponentially with the number / types of units and terrain / variables involved.
There are a lot of different approaches to this broad topic to the point that I don't want to dedicate that much space to it, but I would recommend starting by looking at the source code of some of the Pico-8 strategy games that exist out there. There are some turn-based ones that use very clever compact code to make interesting opponents. I think overall the concepts that make it up are easy to grasp and execute, but the sheer volume and complexity of an interconnected virtual intelligence that is sufficient for a strategy game opponent make it difficult unless you spend a lot of time experimenting in the framework you are building. The up side is it is super fun and satisfying to make even the most basic of virtual opponents.
Alternatively, you could just make your game's enemy controllable by player 2, and sidestep this whole dang topic. Couch co-op for the win.
----------------------------------------------------
WRAP UP -- does all that make sense? I have left out other topics related to this, but I think I touched on the most serious issues.