Character Movement

[DarthBurrit0]

• When screen is touched character moves to that touch location
• The correct png / sprites need to cycle for the appropriate direction that the character is moving
• If an ENEMY is touched then the character moves to the enemies location
• If an ITEM is touched the character moves to the ITEM. The ITEM disappears and is now in the characters INVENTORY

[jxson]

http://qiao.github.io/PathFinding.js/visual/

[emkay]

I have an a* implementation in a branch right now, but this might be easier to work with. I was reading about jump-start and some cases you needed to have the map and obstacles pre-processed for it to work.

Michael Matuzak

On Apr 25, 2013, at 12:25 AM, Jason Campbell notifications@github.com wrote:

http://qiao.github.io/PathFinding.js/visual/

— Reply to this email directly or view it on GitHub.

[DarthBurrit0]

This is awesome. It seems like it takes a while to find the path - Is that just to demonstrate how the path finding works? Or is there away to speed it up?

On Thu, Apr 25, 2013 at 7:52 AM, Michael Matuzak notifications@github.comwrote:

I have an a* implementation in a branch right now, but this might be easier to work with. I was reading about jump-start and some cases you needed to have the map and obstacles pre-processed for it to work.

Michael Matuzak

On Apr 25, 2013, at 12:25 AM, Jason Campbell notifications@github.com wrote:

http://qiao.github.io/PathFinding.js/visual/

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/DarthBurrit0/nomadaxe.com/issues/2#issuecomment-17011725 .

Evan Campbell evan@indestructibleart.com 805-657-3600 @DarthBurrit0

[DarthBurrit0]

Never mind the jump point setting is pretty fast.

On Thu, Apr 25, 2013 at 10:58 AM, Evan Campbell evan@indestructibleart.comwrote:

This is awesome. It seems like it takes a while to find the path - Is that just to demonstrate how the path finding works? Or is there away to speed it up?

On Thu, Apr 25, 2013 at 7:52 AM, Michael Matuzak <notifications@github.com

wrote:

I have an a* implementation in a branch right now, but this might be easier to work with. I was reading about jump-start and some cases you needed to have the map and obstacles pre-processed for it to work.

Michael Matuzak

On Apr 25, 2013, at 12:25 AM, Jason Campbell notifications@github.com wrote:

http://qiao.github.io/PathFinding.js/visual/

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/DarthBurrit0/nomadaxe.com/issues/2#issuecomment-17011725 .

Evan Campbell evan@indestructibleart.com 805-657-3600 @DarthBurrit0

Evan Campbell evan@indestructibleart.com 805-657-3600 @DarthBurrit0

[emkay]

http://iioengine.com/docs/iio-basics

Need to look back to see if pixi offers doing movement and animation as easy as this does.

[DarthBurrit0]

@emkay @jxson

Here are the things I am concerned about when it comes to the engine:

• What will be the easiest for me to look at and understand what is going on
• Being able to fine tune or adjusts effects and animations
• Basic collision (doesn't need to be complex for this game)
• Layering multiple assets for environments(example animated environment props like fog or water)
• Parallax scrolling eventually
• How Sound will interact with the engine - need to make sure sound and animation sync up tightly

In terms of this list what do you guys think is better? I ran through some of the documentation on iio and I could actually make some sense of the tutorial - but is there a way to tell which will do better under pressure? (for example calling and animating lots of different assets simultaneously). I definitely appreciate all the documentation on the iio engine site and it does seem really simple so I am inclined to lean that way.

From what I read pixi.js is more of a 2d renderer than an engine. Does that make it better suited for what we need or doest it just make things more complicated because then we have to build our own collision?

[emkay]

Honestly iio makes way more sense to me too. Yeah pixi is not a game engine, but you could certainly build a game engine with pixi. It might be a good idea to try iio out and see if it makes things clear and easy.

Michael Matuzak

On Apr 30, 2013, at 1:01 AM, Evan Campbell notifications@github.com wrote:

@emkay @jxson

Here are the things I am concerned about when it comes to the engine:

What will be the easiest for me to look at and understand what is going on Being able to fine tune or adjusts effects and animations Basic collision (doesn't need to be complex for this game) Layering multiple assets for environments(example animated environment props like fog or water) Parallax scrolling eventually How Sound will interact with the engine - need to make sure sound and animation sync up tightly In terms of this list what do you guys think is better? I ran through some of the documentation on iio and I could actually make some sense of the tutorial - but is there a way to tell which will do better under pressure? (for example calling and animating lots of different assets simultaneously). I definitely appreciate all the documentation on the iio engine site and it does seem really simple so I am inclined to lean that way.

From what I read pixi.js is more of a 2d renderer than an engine. Does that make it better suited for what we need or doest it just make things more complicated because then we have to build our own collision?

— Reply to this email directly or view it on GitHub.

[jxson]

Yeah, I'm with @emkay. iio seems like just the right amount of api to work with.

@DarthBurrit0, Regarding your list:

• What will be the easiest for me to look at and understand what is going on

Until you get some more time working with code and actually comparing/ building things with the engines we wont know the answer to this question.

• Being able to fine tune or adjusts effects and animations
• Basic collision (doesn't need to be complex for this game)

It looks like iio solves these two, although most of the engines provide apis to animate so it's more about how the libs provide this ability.

• Layering multiple assets for environments(example animated environment props like fog or water)
• Parallax scrolling eventually
• How Sound will interact with the engine - need to make sure sound and animation sync up tightly

These are all eventually/ maybe things which should probably not fold into the decision making just yet. iio looks like it might be able to be used for these things when they become a priority above getting the game to work in the most basic way.

[DarthBurrit0]

@jxson @emkay Awesome. Yeah it seems like a no brainer then. Lets roll with iio.

On Tuesday, April 30, 2013, Jason Campbell wrote:

Yeah, I'm with @emkay https://github.com/emkay. iio seems like just the right amount of api to work with.

@DarthBurrit0 https://github.com/DarthBurrit0, Regarding your list:

• What will be the easiest for me to look at and understand what is going on

  Until you get some more time working with code and actually comparing/ building things with the engines we wont know the answer to this question.

• Being able to fine tune or adjusts effects and animations

• Basic collision (doesn't need to be complex for this game)

  It looks like iio solves these two, although most of the engines provide apis to animate so it's more about how the libs provide this ability.

• Layering multiple assets for environments(example animated environment props like fog or water)
• Parallax scrolling eventually

• How Sound will interact with the engine - need to make sure sound and animation sync up tightly

  These are all eventually/ maybe things which should probably not fold into the decision making just yet. iio looks like it might be able to be used for these things when they become a priority above getting the game to work in the most basic way.

— Reply to this email directly or view it on GitHubhttps://github.com/DarthBurrit0/nomadaxe.com/issues/2#issuecomment-17235596 .

Evan Campbell evan@indestructibleart.com 805-657-3600 @DarthBurrit0

[DarthBurrit0]

@jxson @emkay

Saw another HTML 5 engine went open source today. It seems like overkill for what we would need...and I don't really know what type script is. But you can check it out here.... turbulenz

I am happy with iio but if this were to make things easier I wouldn't be able tell so I wanted to show it to you guys.

---

Actually in there it has stuff set up for sound and multiplayer....Let me know what you guys think.

[jxson]

seems like overkill it wants to own everything, even on the server side...

On Thu, May 2, 2013 at 11:27 AM, Evan Campbell notifications@github.comwrote:

@jxson https://github.com/jxson @emkay https://github.com/emkay

Saw another HTML 5 engine went open source today. It seems like overkill for what we would need...and I don't really know what type script is. But you can check it out here.... turbulenzhttps://github.com/turbulenz/turbulenz_engine/blob/master/README.rst

I am happy with iio but if this were to make things easier I wouldn't be able tell so I wanted to show it to you guys.

— Reply to this email directly or view it on GitHubhttps://github.com/DarthBurrit0/nomadaxe.com/issues/2#issuecomment-17355454 .

[emkay]

I've almost got a pathfinding demo working, but I'm having trouble with figuring out the right cell in the grid that the blocker object is at. I can fake it for now, but it seems like grid.getCellAt() isn't returning the vector coords I thought it would. Probably doing something wrong.