Archived

This topic is now archived and is closed to further replies.

Tutorial for isometric games !!!!!!

This topic is 6031 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hiya all, I''m looking for a good tutorial how to make a working isometric game. Including things like different heights and maybe even shortest-path-algorhythms. Is there anything on the planet being able to explain that to me ?? It would help me soooo much. Thanx

Share this post


Link to post
Share on other sites




Well, I can help with the shortest path, but basically it depends on your actual setup. I won''t explain them here, because it takes a while and it''s done better elsewhere. However, knowing some of the names means you can look for them on the net. A lot of these pages have little java applets that animate the algorithm, which really helps in understanding what it''s doing.







A simple approach is a Bredth First Search (BFS, might be listed under BFS tree). It will run in O(V+E) time, where V is the number of vertices (or paths between tiles on your map) and E is the number of tiles on your map. DFS (depth first search) is related but might end up with worse running times for your maps. Think of it this way: trying to get from A to B, BFS looks in concentric circles around A for B. Once it finds it, its finished. DFS tries individual paths until it finds one, saving state on a stack whenever it reaches an intersection.







Another approach is Dijkstra''s algorithm, which is only really useful if you use a weighted graph (that is, you assign different values to the links between tiles based on some criteria). With a weighted graph, you can get your "things" to favour certain paths over others. An example might be to give a different weight to each terrain type. Roads or grass get a low value, while things like mountains get a high value, so if in your game moving over mountains is a lot slower than other terrain types, your "things" will go around the mountains instead of over them if it will be faster. Dijkstra''s algorithm is a bit slower though, because of this added work, and takes O((V+E)logV) time.







There''s also the A* method, which is sort of like a DFS except it''s a little "smarter", and tries to predict which way it should go. I''m not sure what the running time of A* is but I''d imagine it''s somewhere near the DFS time.






Hope this helps

Share this post


Link to post
Share on other sites




Well, I can help with the shortest path, but basically it depends on your actual setup. I won''t explain them here, because it takes a while and it''s done better elsewhere. However, knowing some of the names means you can look for them on the net. A lot of these pages have little java applets that animate the algorithm, which really helps in understanding what it''s doing.







A simple approach is a Bredth First Search (BFS, might be listed under BFS tree). It will run in O(V+E) time, where V is the number of vertices (or paths between tiles on your map) and E is the number of tiles on your map. DFS (depth first search) is related but might end up with worse running times for your maps. Think of it this way: trying to get from A to B, BFS looks in concentric circles around A for B. Once it finds it, its finished. DFS tries individual paths until it finds one, saving state on a stack whenever it reaches an intersection.







Another approach is Dijkstra''s algorithm, which is only really useful if you use a weighted graph (that is, you assign different values to the links between tiles based on some criteria). With a weighted graph, you can get your "things" to favour certain paths over others. An example might be to give a different weight to each terrain type. Roads or grass get a low value, while things like mountains get a high value, so if in your game moving over mountains is a lot slower than other terrain types, your "things" will go around the mountains instead of over them if it will be faster. Dijkstra''s algorithm is a bit slower though, because of this added work, and takes O((V+E)logV) time.







There''s also the A* method, which is sort of like a DFS except it''s a little "smarter", and tries to predict which way it should go. I''m not sure what the running time of A* is but I''d imagine it''s somewhere near the DFS time.






Hope this helps

Share this post


Link to post
Share on other sites