Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  aid with A* and graphics for a (slick) 2d game please!  (Read 1715 times)
0 Members and 1 Guest are viewing this topic.
Offline Trosters

Junior Member


Projects: 1



« Posted 2011-04-17 15:53:29 »

So I've read through "kev"s tutorial on the A* algorithm with tiled maps, and I understand the ideas behind it, but as it seems it is implemented with nodes, one for each tile on the tiled map. I however want my game to have smooth moving, a pixel at the time, and am wondering if this is possible, would it take too much of my CPU to calculate a new path every pixel - and calculate a path with each nodes just being a pixel apart (that'd turn out to be a whole lot of nodes and calculations wouldn't it?). So before I start trying to write it, am I right about this? Would it work? Have you got any other tips on it? It'd be my first time implementing a path finding algorithm (apart from the dijkstra algorithm which I implemented with a perfect node (bus-stop) system for school).

I am also dying to get some aid with the graphics of my latest game. As you can see from the image below my skills with sprites is really awful - and to me Paint just does not seem like the best way to draw them. If anyone has some tips for programs or basics behind making sprites I would very much appreciate that! What should I think about? What tools can I use to make my sprites feel more alive? (Or if anyone already has some basic sprites which I can be allowed to use without me feeling like I'm stealing!)

Thanks!



Offline JL235

JGO Coder


Medals: 10



« Reply #1 - Posted 2011-04-17 18:32:51 »

My recommendation, keep it as a tilemap but animate movement from one tile to another. That way it is tile based, but looks as smooth as per-pixel movement.

One issue with building a proper per-pixel movement system is that now the player has to line the character up to go around corners and through doors. This is something can be very annoying on some games!

Offline Trosters

Junior Member


Projects: 1



« Reply #2 - Posted 2011-04-17 19:01:12 »

I don't know if you've played Tibia but I think they use the system you are describing. It looks as if the character is moving one pixel at the time but it is actually moving from square to square with an animation for each movement - if this is it, I think that is so horribly ugly and destroys so much of the gameplay:/ But indeed I have considered it because it just seems so much easier to implement most of the things with a system like that.

I am not sure what you mean with the second part with "has to line the character up to go around corners and through doors" - care to elaborate?Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2011-04-17 19:17:02 »

You might consider using a names instead. Once generated you can use per pixel movement combined with a star across the mesh.

Kev

Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2011-04-17 19:19:29 »

http://www.cokeandcode.com/node/1282

Kev

Offline Trosters

Junior Member


Projects: 1



« Reply #5 - Posted 2011-04-17 19:33:22 »

thanks, Ill look into it and see if I can understand it!:)
Offline Gudradain
« Reply #6 - Posted 2011-04-17 20:16:10 »

Hmmm I would take a different approach. I watch a video of Tibia and it's true that it doesn't look good. I would go with the way that I think RTS pathfinding is made. Ok never read it anywhere but here is my guess.

If you observe carefully how RTS map are made you see that there seems to be 2 different grid. One grid for the buildings and the ''doodad'' (ex.: tree). These elements can only be place on a grid with big cell. The second grid is the grid for the unit where the cells are much smaller to allow the unit to move more freely.

When come the time to find a path between two very close points you just need to use the unit's grid and check if you can go directly (in a straight line) to your destination. That way you get very good movement that dont feel like if you are moving around a tiled map. Anyway, the cell of the unit's grid should be small enough that the player don't notice it.

Now if you need to go to a very distant point, you use the building's grid. There is a lot fewer cells to check so you will find a path much faster. If there is no path in the building's grid there is no path in the unit's grid either. When you get near your destination you can simply use the unit's grid to find a straight path to the end.

Ok, all that is well but one problem will occurs. What happen if you have a building is build in your path while you are traveling amongst it? You need to detect this sort of thing to get a new path as soon as possible. The chance are that this building will stay there for a long moment so you can't just continue and hope it will disappear when you will have to pass through it.

Finally, the biggest problem what to do about unit that are moving around the map and might block or disturb the movement of your unit. Well, there is no easy or optimal solution. If you check an RTS like Warcraft III you will see that the way they handle this problem is very stupid. Your unit won't try to find another path unless it really hit the unit block the way or crossing the way. Even worst, since the pathfinding is mostly made using the building's grid, it won't even try to find another path if some unit are blocking the way and there is no other really really obvious path he could take really close to the point he is block. Ok that seems bad but do I ever realized that it was a problem when I play? Not at all so it's good enough even for commercial quality game.

The general idea about avoiding other moving unit is to click look a bit overhead when you are moving to see if the path is still free, if it's free continue walking otherwise get a small new path to avoid the moving unit and continue following the big path.

If you really want to go overkill, you can check how they solve that problem in Starcraft II. Your unit can push your other unit and ally's unit if they need to pass. But that may become way harder.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!