You will note in the "CASE 0" line, I remarked both lines out, this was because, with that line it had a kind of olive green back ground, and I did not want that, I want the black back ground.
It was not intended for the user to rem out a line of code in that way. Although you are free to do that if you so wish. There is a better way to NOT display a particular tile if thats what you wish. The tile image file contains 8 tiles. The sequence of each tile inside this file can be changed. You could place the tile you dont like at the last tile position. The tile that you dont like can be replaced with a picture of the tile you make to replace it.
By remming out a line in the select case you reduce the amount of tiles that can be shown by 8 to 7. Also if you have made other "maps" that use that "line in the select case" then they will no longer display correctly.
Alternatively when you compose a new map simply dont use that tile number that you dont like and new map will display correctly as well as old maps. A better solution may be to offer inside the editor an opportunity to change the default tile number.
In the "code " thread, you mention as a reference, PacMan, and a ghost. Later I can make a data map, with a pac man and a ghost, and a maze,...
Yes thats correct. The PacMan comparison was to illustrate the idea compared to your already understandable knowledge of how pac man worked compared to the VSGE. However this could be used to create a pac man game. The tile , hero and enemy image files would need to be changed to suit this new idea.
As you have demonstrated many things can be done with this fixed simple idea. And so this is a building block to test your idea. Once idea works and finished game is done you may wish to improve it with a beter engine like the GDK. The only difference would be that when you get GDK to do it you look to see how GDK works compared to how VSGE works. In this way you build your understandings.
At this point in time the code blocks to define how hero and enemy exist inside the map and how user input creates "behaviours" have not been coded. The reason is that there are several methods that require different ideas. These will be discussed later and coded. For every particular method it has advantages and disadvantages and part of the VSGE is to make you realise those differences. This way the user chooses the method that they best understand. Once understood they will know what they can and can not do.
I really appreciate this feedback. I have gone into great detail inside the code thread explaining line by line what is happening. This is the way your understanding builds and improves.
