game sample needed
BlitzMax Forums/BlitzMax Beginners Area/game sample needed
| ||
| Hi, i want a sample game. something like Dinner, Pizzar game from yahoo. player can move around screen 800x600 to go to houses. just click on one house, player will go to that house avoiding the houses which block the way. is there any simple program? i would like to learn. thanks |
| ||
| That wouldn't be anywhere near a "simple game" Thats Iso etc etc. A simple game is break out for example and that type of games is within the sample folder. |
| ||
| to sample or too simple, that's the question.. |
| ||
| What you're actually after is example code to show path finding through a randomly laid out map to reach a point determined by the user. I'd agree with the second poster - that's not really that simple an exersize, unfortunately. |
| ||
| Isn't there A* pathfinder example included with BlitzMax? |
| ||
| yes, Samples>Aaronkoolen>astar_demo.bmx edit: Never checked this example out myself. It has a hell of a lot more for flexibility than I have seen in similar examples for other languages. |
| ||
| The problem with that astar_demo is its size. To quote Einstein: an example should be as small as possible, but not any smaller. Look in the code archives for a better A* |
| ||
| what i want to learn is. i know about pathfinding, what i want to know is, i want to learn how to display images on the screen and backgroup map images. i found no simple to learn tutorial for it nor codes.. i dont actually need the simple codes, i want the concept for it. TIN |
| ||
| when a buffer or canvas is activated: local myimage:timage=loadimage("c:\ghost.png") drawimage myimage,40,50 But you'd better read one of the tutorials out there.. |
| ||
| opps!! i know that much. what i mean is. there are things like map image, which shows which area can go , which area blocked. and things like that |
| ||
| As long as you have a "small" Grid (no 1000x1000 thing) you have to check the amount of grids you have to move along from start to goal. You have a startposition and an aimed endposition (thinking of grids you may have 0,0 and 20,20). Now you have a loop/predefined checktime/loopamount: - checking your neighbourgrids for allowed movement - if you already have been there go on with the next neighbourgrid - else: - for each you save the neighbour as a new "here i am"-position and increse the moved-count by one - repeat the steps above for each new position until you reach the end - reached the end you store it as a possible route (each gridmovement in a list for example - so you could count the amount of steps needed by counting the list-items) repeat the whole loop for a certain amount and only overwrite the route if the step-amount is less than before (to shorten the route). This is a small and not very optimized "concept" but I think it explains the principle really well and although on huge grids it could take some pc power - it will find the shortest route. In words: You have a position and then you begin to check all grids next to you. If you already have been on one of those grids, you wont have to check them again, coz you already did it in past. If you haven't been there you again check all surrounding grids... until one of the surrounding grids is the aimed grid (goal). In this case you store the route you have planned (including count of grids you walk over) and then you start again from startgrid. If the new route is shorter than the previous one - save it over. Do this for a predefined amount or until all grids are "checked" (which could take a while depending on the size of the grid - the smaller the faster). Another thing to optimize: check if grid-lines vertically, horizontally or diagonally block the straight way from start to goal (eg a row of buildings) - if not, you wont need to check all neighbour-grids - only the one in the direction of the aimed grid - in our case (start 0,0 - end 20,20) you will have to check for the neighbours to the right and to the bottom. This way you wouldnt need as much checks on not needed grids - but you will have to check for straight blocking lines which also could take some time. Mixing both approaches you can aim some simple human way of pathfinding (if you don't have a map): walk straight into direction of the goal-grid and if something blocks, you try to walk around - even if another route would be shorter. Ok, enough of my thoughts - if you don't care about basic principles just try the mentioned A-star-idea which is more optimized. bye MB |
| ||
| For a simple tile game have a 2d array where each block tells you if it you can move there or not. |
| ||
| if the path is not square based or hex base. like one node may lead to 2 or many nodes and all the nodes are unevenly layout on the map. how could i handle it? |
| ||
| I suspect that for a better answer you are going to need to post actual code or a graphical illustration. |
| ||
| its still the same... instead of checking "top,right,down,left" of neighbourgrids, you check the linked nodes - and their linked nodes with the next linked nodes - and .... ok, I think you got it. bye MB |
   |