I enjoyed the combat system for LoZ: Phantom Hourglass(and LoZ: Spirit Tracks) for the DS. The touch screen feature could be emulated with mouse procs most likely(If there is a mouse proc for holding it down). But like A Link to the Past, its a pixel movement system on a grid.

I think a lot of games poorly execute pixel-based movement with combat. Ex; Dragonball Z : Legacy Of Goku and some Harvest Moon games. Games where you swear to your grave that you should be hitting or interacting with something but the pixel-collision system is poorly programmed and instead you are cheated out. Harvest Moon games do this a lot. You plant/break/chop/grab by grid-style and move by pixel-style. You'll try to plant in this grid, but it registers the next grid or a different grid tile which could cost you in the game.

If it's done properly and executed very efficiently with no missed accuracy, it's phenomenal. Otherwise, any little fault makes me wish they would stick with grid.

Nope, the game uses regular old 32x32 tiles.

Schnitzelnagler wrote:

So does Proelium, or Tibia, if you want to go a bit bigger scale.

I much prefer games where you have a bit of tactical/strategic thought combined with action than mere mouse/key precision with button mashing.

I am getting annoyed with full on strat games though. Starcraft 2 has a very nice implementation of both Schnitzel. You have to be incredibly strategic to win, but there are so many fun things you can do as well.

Schnitzelnagler said:

it's not much of a concern if you can have 'pixel movement', because a big selling point is knowing your class's advantages when being confronted with an enemy.

I don't feel that example actually adds up as written, even if that selling point were the main focus. It doesn't necessarily mean anything about the gameplay itself (in a specific and not general manner).
Speaking without knowing about the game in question, of course: using your class advantages may indeed require you to move and depend on your ability to position yourself, which could change for the better or worse if the type of movement is pixel-based instead of tile-based. You'll have to be specific about the relevant mechanic for people who don't play Proelim to understand the example (if it is suitable).

About the thread in general, (tile based movement)-based games can be good, even if they're action games. Naturally, it depends on how much the game is suitable for it, and the game has to be built with it in mind.

Actually, that kind of mouse use is currently impossible to implement with what we have to work with, from my experience and others. Believe me, someone would have already used that kind of thing for a shooter if they could.

I don't think so. Grid movement serves its purpose, letting people accurately judge distance for their weapon accuracy as well as making cover seem a lot more simple.

What I think holds it back the most (aside from regular bugs and needing more content) is friggin' key jamming. For some reason with all of BYOND's interface improvements it still has trouble detecting key+up commands during intense gameplay.

He's referring to Zelda: Phantom Hourglass. The system has your sword in the direction of where your stylus is. Think about the concept of a shooter, where your gun might move with your mouse to aim. You can't get that pixel-based with mouse functions. You could get something crappy and tile-based, but it just wouldn't be practical.

There are other serious issues that other people have pointed out as well. I can't name them right now.

Fugsnarf wrote:

Think about the concept of a shooter, where your gun might move with your mouse to aim. You can't get that pixel-based with mouse functions. You could get something crappy and tile-based, but it just wouldn't be practical.

I believe you can get pixel coordinates for every mouse event. The problem is that moving the mouse cursor within a tile does not trigger an event. If you want to show the player turning to follow the mouse cursor I think you'd be limited to update the player's direction only when the mouse cursor crosses a tile boundary (assuming you're only using turf MouseEntered procs). When the player clicks (to shoot) the click event will get the pixel coordinates of the mouse cursor. The system's visual display might be limited but it should function as you'd want it to.

Calus CoRPS wrote:

Sadly, icon-x and icon-y are not avaliable for mouse procedures such as MouseEntered() and MouseExited().

For this hypothetical feature this isn't much of a problem. You only get mouse events at tile boundaries so you can only estimate the position of the mouse cursor (and who's to say that location where you entered the tile is the best estimate?). What's important for the functionality is that you have the pixel coordinates for the mouse click event.