In my 2D tile-based game, I have NPCs that move around on a fixed path. I am putting the information about the NPCs in a .plist file that is loaded on startup. The thing is, I'm not sure how to format the data specifying the path that the NPC moves on. What I was thinking was to have an origin
property, a horizontalMovement
property, and a verticalMovement
property, so when the starts at its origin, then walks right the number of tiles specified by horizontalMovement
, then walks the number of tiles down specified in verticalMovement
, etc. However, this doesn't seem like the best approach. Is there a better way to store the movement data?
\$\begingroup\$
\$\endgroup\$
4
-
1\$\begingroup\$ If it doesn't seem like the best approach, what does? There's nothing wrong with that unless you've identified problems. Do what works and don't worry about making things overly complex until you have to. :) \$\endgroup\$– Richard Marskell - DrackirCommented May 23, 2013 at 1:33
-
\$\begingroup\$ @RichardMarskell-Drackir - But my point is that what I am doing may be overly complex and there may be a simpler solution. \$\endgroup\$– pasawayaCommented May 23, 2013 at 1:40
-
\$\begingroup\$ Seems pretty straightforward to me. I suppose a "simpler" option would be to just store all of the tiles on the path individually and move from one to the next. But, that doesn't seem necessary when you can just do what you said in your question. \$\endgroup\$– Richard Marskell - DrackirCommented May 23, 2013 at 1:42
-
\$\begingroup\$ Sounds less like storing and more like implementing. \$\endgroup\$– user75521Commented Dec 18, 2015 at 0:06
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
It all depends on how flexible you want to be. I dont think the approach you suggested is bad, in fact its one of two main possibilities i would consider in your case:
- store a list of checkpoints that the NPC walks through (once it reaches the last checkpoint it goes back to the first and repeats). Once arriving at a checkpoint, the NPC will find the best path to the next checkpoint (using A* algorithm for example). This has some advantages, like for example the map can change (obstacles can move around etc.) but also can break down if there is no path between a pair of checkpoints. It is also a bit more complex to code.
OR, as you said:
- store a list of fixed actions: 1) walk 3 tiles south, 2) walk 4 tiles east... etc. Something very similar to what you suggested. Simple and easy to code, but not very flexible. Thats not necessarilly a problem though.
Its up to you to decide what works for you the best. There is nothing bad in trying something you made up yourself, in fact its better than just always looking up a "perfect" solution on the internet.
Good luck!