NPC movement in a Top-Down 2D tile based map?

Games
#1

I’m working on developing a top down 2D game set on relatively small (screen sized 16x12) tile based map.

I’ve sorted out building a nice tile based grid.

I have a solution I’m pleased with to move my PC by shifting x and y location based on user input.

The challenge I’m facing now is that I don’t know how to approach NPC movement.

Does anyone have any advice on how to do this?

I’ve been able to generate pathing info using the Jumper pathing library (in community code). This generates a table of x,y coordinates that I can reference.

How would you move NPCs about this grid that I’ve set up? Would a person use the transition.to functionality or a pixel by pixel approach (as I’ve done with my PC)? Is there some other technique I’m missing entirely? I’m not using gravity since the perspective is top down but I do have my PC and NPCs set with physics properties if that is a consideration.

I’ve been “rocking and rolling” on this effort but have hit a wall in trying to figure this out… Thanks in advance for any help :slight_smile: [import]uid: 105707 topic_id: 28133 reply_id: 328133[/import]

#2

It sounds like you are over thinking it… You could use a transition or you can use translate on the object(basically pixel by pixel). Once your NPC hits it’s target coords just make it translate or transition towards the next set.

[import]uid: 147305 topic_id: 28133 reply_id: 113678[/import]

#3

Thanks for the tip. That’s what I was attempting but unfortunately was having some challenges with the implementation. I continue to work on it so hopefully I’ll sort it out sooner than later.

I’ve been reading the Jon Beebe article and it seems like I’m on the right path using the transition.to() function…

http://www.coronalabs.com/blog/2012/06/12/applying-basic-animation-with-transitions/

I’m still glad for any feedback anyone has regarding moving NPCs on the map! Thanks :slight_smile: [import]uid: 105707 topic_id: 28133 reply_id: 113681[/import]

#4

Just want to chime in and say that I definitely think transition.to is the way to go for tile-based stuff…with the obvious caveat that it depends on if it’s live (physics) or turn based (not). Translate is really great when you can hook it up to a runtime but can be difficult to rig when you’re making a turn-by-turn iterative approach.

With tiles transition.to is very user friendly, as it makes it easy to calculate exactly where to go next, at which point you can just attach the animation to the sprite itself.

object.move = transition.to(object, {x=tile\*tileSize})
#5

I recommend transition.to as well. There are several advantages including storing all of your active transitions in a table so that the game can be paused.
It is the method I used in the Rotten Apples game in my book (chapter 16). [import]uid: 34131 topic_id: 28133 reply_id: 114537[/import]

#6

Richard and Brian, I appreciate you both chiming in.

@ Richard, I am doing a “live” game with physics, so if I understand you you’re saying that transition.to() should work well in that circumstance (where as turnbased can be trickier). I like your point regarding how easy it is to specify location, although since Lua tables start by default at an index of 1 rather than 0 as one might expect from other languages, it’s been a little wonky to work with. Am I missing anything in regards to that?

@ Brian, I do own a digital copy of your book. I had only really skimmed it to this point so I got back into it last night after reading your post. Not only is chapter 16 especially useful but I also got a lot from the second appendix on Lua. I’d like to better understand how to work with metatables because that seems central to being able to create a more modular, object oriented solution. There’s a good blog post by Jon Beebe (http://www.coronalabs.com/blog/2011/09/29/tutorial-modular-classes-in-corona/), do you have any other advice on how to better understand using metatables?

[import]uid: 105707 topic_id: 28133 reply_id: 114612[/import]

#7

Well, I would think runtime has some advantages in physics games because you can probably do per pixel movement easier with translate…transition.to is perfect for turn based, however, since you can boil down everything to specific movements.

Lime previously had an issue with starting at 1,1 instead of 0,0 but I believe the latest 3.5 beta fixed that. It’s not really that much of a problem to deal with in practice; just set either a global or local offset and always factor that in when you need to do tile math vs. table math. [import]uid: 41884 topic_id: 28133 reply_id: 114801[/import]

#8

@Richard - Thanks for clarifying regarding runtime and translate for a physics game, I hadn’t quite followed that the first time around. My game ins’t a pure “physics game”, but it is important to me that characters don’t overlap and the physics engine seems like an easy way to do this. The game will run in real time, not turns.
The best way to discuss the issue would probably be with some concrete examples.

For the sake of discussion, how would people move NPCs in a game like the original Legend of Zelda (on NES) or the original Gauntlet (cabinet arcade version)?

I do want to keep NPC movement from tile to tile and for my prototype I am focusing on only moving in the four cardinal directions (no diagonals).

I’ve been experimenting with making each tile on my map (15 x 10 tile map) a collision listener and having that update a master matrix of whether a cell is empty or blocked (by terrain or NPC). It sounds good in theory but I’m still working out the implementation.

I do own a copy of Lime. I had some weirdness going on when I was working through some of the tutorials and would prefer to generate my own solution unless there is a really good way of doing this with Lime.

[import]uid: 105707 topic_id: 28133 reply_id: 114859[/import]

#9

OK first things first:
I would neither recommend transitions nor physics.

Moving in a static grid is very easy, and you started to ask the right question regarding zelda and other types of games, so I’ll try to give you a quick rundown.

Some assumptions based on what I read:

  • Each room is the same size
  • A tile is either solid, or not (eg is wall, which you can’t move through, or floor which you can).

Then all you do is set up an array the size of the room (in tiles), and populate it with the collision info (eg 1 = wall, 0 = floor), and use that data to check if a tile is solid before attempting to move into it. If you also maintain a list of what enemies are where, you can prevent movement into a tile already occupied.
That alone won’t prevent direct overlap, but it seems like a reasonable starting place - particularly since one movement / collision code would suffice for the player and all the enemies as well. [import]uid: 46639 topic_id: 28133 reply_id: 114981[/import]

#10

Lime works, I assure you. But some of the stuff the tutorial says to do is junk at this point. If you need any help let me know. It’s not impossible to make your own setup using that excellent new Image Groups functionality though, I just wanted something where I could use Tiled. :slight_smile:

What I do for collision is basically this:

  1. Make a table of the four possible directions you can move in.

local table table[1] = { name="left", collision = false, type = nil, xTile=2, yTile=14 } table[2] = { name="right", collision = false, type = nil, xTile=4, yTile=14 } -- etc...

  1. Run the entire table through a test for each of the modes of collision testing. Whenever there’s a positive, mark collision = true and, if you like, set the type (eg: enemy, tile, whatever). For example, I would look at tile, object, enemy, player in that order.

  2. When doing any further checks, always test for table[i].collision first - that way you skip any collision checking at all for tiles that have already are known to have collision anyway. Since there’s only four tiles to check obviously the process can speed up quickly.

A master collision table is an interesting idea too; my worry with that is just setting up something to properly queue updates. Hmm. [import]uid: 41884 topic_id: 28133 reply_id: 115070[/import]

#11

@rakoonic - I like your recommendations regarding not using physics or transitions. I’ve been steadily working on this challenge and that resonates with what I’m currently investigating.

Would you recommend translate in place of transitions?

How would you handle the concept of keeping tack of what enemies are in which grid squares? It sounds easy but I’ve been having a real heck of a time solving this. Some of the subtleties I’ve been grappling with regarding NPCs is when do you mark a square as occupied (currently I’m thinking as soon as an NPC “selects” to move into it to prevent simultaneous moves into the space before a move is complete) and when unoccupied (I’m guessing once a move is done incase the NPC can’t move into the square it’s attempting to move into)?

Thanks :slight_smile:

@richard9 - Your illustration regarding the use of a local table is very helpful. I hadn’t considered how useful managing parameters of this nature could be. The .type parameter could be used to decide whether an NPC would attack an adjacent player (if there were one) or move (if there wasn’t). The .name parameter could be referenced to select the appropriate animation direction (whether the NPC attacks or moves). What other nice tricks can you share? :slight_smile:
Thank you both and I look forward to hearing more input from the community :slight_smile: [import]uid: 105707 topic_id: 28133 reply_id: 115208[/import]