nesdev.com

@ FrankenGraphics

Yep, BMO helped me out when I was figuring out how to control multiple mechs on the screen and switch control between them. I might need him again in the future

Great point on the one tile units. Once I have a working AI I will create more unit types I will try it out. I like the idea of flying units with a shadow. It also depends on how much memory I've left to keep track of them.

btw if you press select in the title screen you can see the animation of the unit types (b toggles types, a makes them move).

On the subject of AI, this is going to be my logic:

; 1 select the most attractive player controlled target
; consider all player units
; lowest score wins:
; (100-ranged attack hit probability) + target hp + distance
;
; 2 determine available options
; - ranged attack 1 on target
; - ranged attack 2 on target
; - close combat on target
; - charge target
; - move / pivot towards attack position on target (this is complex)
; - cool down
; - move towards defensive position (this is complex)
;
; 3 score all available options
; - based on relevant factors (AP, HP, expected DMG etc)
;
; 4 some randomness: pick best option 70%, second best 20%, third best 10%

The challenge is to minimize the number of times that you need expensive subroutines such as calculating the shortest path and calculating if there is line of sight.

So for example, once the AI decides that the best available action is to move to an offensive position, the AI will need to find a grid node that puts the AI controlled unit close enough to the target that it's within its range, has line of sight to the target and is reachable from the AI units current position.

Would appreciate any insights folks have to offer

@FrankenGraphics
The rain is less intense. I started using 4 tiles instead of 1. You were right, this is better. I feel I should be able to pixel a more convincing rain but maybe its just not possible with only 4 frames

@rainwarrior
I took a first stab at showing flickering waypoints to show the movement path. It's a nice feature, thanks for the suggestion

Even with the slow NES processor, you can probably get away with a lot of slow calculations since it's a turn-based game. An extra half-second of processing during an enemy's turn is an eternity in terms of processing time, but wouldn't impact the game much at all.

_________________
My games: http://www.bitethechili.com

That's a really good point. With a little luck/effort, you may be able to silently perform the calculation all while signing the turn transition to the player. I'd just recommend keeping the transition as short as needed be and let the calculation spill over if it needs to. That would appear as the enemy thinking/deciding. I imagine that should be less jarring than dragging out the transition sequence visually/functionally.

(Old) chess games will often make you wait while the computer is thinking. Playing some of these oldies in emulation might help get a feel for how long is too long. Besides the fact that i could never beat a particular game when set at its hardest difficulty, i also avoided that setting because the cell phone in question took way too long.

_________________
http://www.frankengraphics.com - personal NES blog

Hm... How do you hide sprites that are touching the HUD? The only way I can think of is putting 8 empty sprites at the row of the HUD. Is there another way? Disabling sprites in PPUMASK at the correct y-pos, maybe?

I believe that was the initial suggestion

This is good! I think this really helps a lot to teach the player how pathing works, and how the hex grid is connected.


I briefly suggested a couple of possibilities in my earlier post but here's some more explicit explanations:

• Using an IRQ to enable sprites via $2001 at the correct scanline is probably the easiest way. This game in particular seems to be using mapper 25, so IRQ might be an option?
• Manually remove sprites coarsely above the split point, and then put 8 hidden sprites on the bottom row to more finely block sprites that overlap there.
• Write a cycle-timed NMI routine and just create a timed wait until the split point to enable sprites.
• Just move the HUD to the bottom and continue to use sprite 0 hit.
• Just don't bother solving the problem.

TBH, in this particular game the main problem I am seeing is that the sprites disappear before the should be hidden by the edge at both the top and bottom; on both sides this creates situations where it can look like nobody's standing there on cells at the top of the bottom of the screen-- bad information if you're trying to make a tactical decision! The same thing happens at the left and right edges too, actually.

Hiding them above the hud is just something I'd probably pursue for visual consistency but it's not really a gameplay issue? There's another visual issue at the left and right edges too, i.e. if a mech moves from offscreen they will appear briefly at the wrong side while moving across the edge, but at this point I'm assuming it's all subject to change/revision anyway. The left and right edges tend to be tricky on the NES, as I'm sure everyone's aware.


Actually, on the subject of things happening at the edges it might be important to note that a lot of TVs, especially older ones, will cut off some of the edge. Everything at it is currently seems to go right to the edges, like the pilot's face, and this could be a problem. Nintendo and other console publishers have always given guidelines about keeping anything important (especially text) away from the edges of the screen by a small margin, and they still do so even now in the HDTV era. See: Wiki: Overscan

Thanks for putting in the time to help me rain warrior. I very much appreciate it.

Yep, mapper 25. I started with mapper 23 but that didn't work on my powerpak.

You are right that its all subject to change at this point. To keep up the momentum I tend to leave features in a "good enough" state and then move on to the next thing. Perfecting and refactoring things takes forever

I will try to use the IRQ solution. I still have to familiarize myself wit the workings, but it sounds promising. That will take care of the top/bottom cut off.

Currently the game does a very crude cut-off based on the screen coordinates of the grid position (iow not even sprite coordinates) and only for the mechs. I will have to bring it down the the sprite level anyway, because most of the effects (including the new waypoints for movement) completely ignore the left/right. Shame on me!

As for tactical decisions, you are right that its key to know where the other units are. And probably not only the ones that are right on the edge. I have thought about how to inform the player of the location of other units on the field (without having to scroll over the map). One of the things I intend to try is markers at the edges of the screen, but until now that has gone into the category 'perfecting things' .

It is possible to hold B to scroll the map while choosing a facing direction. At least that way you know from which direction you can expect the enemy to show up.

Thanks for the link. I think I did come across it some time ago (I spent a serious number of hours on the wiki and this forum before before I got my code to work to do ... well ... anything ). The challenge is that there is so much information that needs to go into the HUD, while trying to keep the three sections clearly defined (player - action - target). I expect I could make the "action" section less wide have some margin on the edges.

Ah, I understand now why you cannot use a SPR0-hit to check for the end of the HUD... That was the missing link.

Just a small progress update.

I've added a simple AI! I have not incorporated all the factors that I would like the AI to consider, but I've started on the framework and I think it will do nicely. Turns out that computation time is not really an issue at all. The AI will skip some frames while deciding on the next move, but I think it is hardly noticeable (as some folks had already suggested in an earlier post). It starts to feel slightly more like a game now

UPDATE

- Rewrote the engine so that all grid node meta tiles can be controlled individually. This allows for cool stuff like showing debris where units where destroyed permanently, or mark specific map nodes for game effects.
- Each unit is now displayed as part tile/ part sprite, which allows the game to show a lot more units. Up to 16 units, to be exact.
- Added missile attack animation (wpn 2)
- Worked on the map tiles
- Worked on the AI and game mechanics
- New object model

the link is in the original post

all feedback is very much appreciated! Hope you like it!

I'm still working on this game, although I am losing some of my original steam. Next step will be to have a TEAM configuration screen, where the player can combine mechs, pilots and weapons him/herself.

I've been playing a lot of "BattleTech" and "Into the Breach" (both excellent) and took some inspiration from both of those games.

Last Update (06/19/18)

- Added more of everything: new attack (surge laser), new pilots and new units
- Added an event mechanism, e.g., to initiate HUD dialogs upon certain events ; taking a bytestream as input, so that it can be different each level.
- Changed the game mechanics (inspired by the excellent recent game BattleTech), especially the BRACE and EVADE point mechanisms
- Re-desgined HUD to show more information with less tiles
- Fixed many bugs
- Demo now has a 3 versus 3 battle. I'm looking for the ever elusive 'emerging complexity' that make games of this genre engaging