It is currently Sun Nov 19, 2017 3:43 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Oct 18, 2017 8:09 am 
Offline
User avatar

Joined: Fri Sep 22, 2017 10:13 am
Posts: 9
Location: Netherlands
@ 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


Top
 Profile  
 
PostPosted: Thu Oct 19, 2017 12:59 pm 
Offline
User avatar

Joined: Fri Sep 22, 2017 10:13 am
Posts: 9
Location: Netherlands
@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


Top
 Profile  
 
PostPosted: Thu Oct 19, 2017 1:45 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 243
Location: Central Illinois, USA
iamerror wrote:
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.



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


Top
 Profile  
 
PostPosted: Thu Oct 19, 2017 2:16 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
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


Top
 Profile  
 
PostPosted: Thu Oct 19, 2017 11:14 pm 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 52
rainwarrior wrote:
the only NES game I can think of right now with vertical scrolling and a top HUD is Battletoads, but it doesn't even try to hide sprites up there.

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?


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 5:41 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
I believe that was the initial suggestion :D


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 5:43 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
iamerror wrote:
I took a first stab at showing flickering waypoints to show the movement path. It's a nice feature, thanks for the 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.

Lazycow wrote:
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 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


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 7:49 am 
Offline
User avatar

Joined: Fri Sep 22, 2017 10:13 am
Posts: 9
Location: Netherlands
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.


Last edited by iamerror on Fri Oct 20, 2017 1:45 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 11:21 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 52
Ah, I understand now why you cannot use a SPR0-hit to check for the end of the HUD... :roll: That was the missing link.


Top
 Profile  
 
PostPosted: Sun Oct 29, 2017 10:31 am 
Offline
User avatar

Joined: Fri Sep 22, 2017 10:13 am
Posts: 9
Location: Netherlands
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 ;)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Atelier-Betoux and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group