Z level done. Players can move up and down ladders.
for now it uses Alerts for the player to choose if they are moving forward on an UP ladder or the retreat button signals one if they are on a down ladder.
I think I've said before I would like to use "swipes" to move up and down and although it is intuitive for smart phone users to do this I think I would have to teach them their use for ladders. This is for a later time as the code I've found for noting swipes is long and I think I would have to rewrite my onClicl code.
—
this proved to more and less difficult than I expected.
Overlapping the ladders on the walls was really a challenge. I had discovered the LayerDown technique which is a view that stacks images in an array. This proved really flaky - it kept picking up the wall images too late (or not at all - not sure which) so the bottom most layer was empty. I broke down and did my original plan of creating multiple layers of stacked images.
Android is warning me that performance may suffer by having more than 80 views (I have 54 images now - the walls and one for each depth of ladders), however I won't be adding many more and I will be removing debug automaps etc eventually so that should be fixed.
I had created functions to have the walls delete any ladder images behind them but they were flaky too - probably a problem with my logic. I ended up deleting them directly in the wall creation routines and it was alot more consistent. It was easier to see as well because with the naming I used I could easily see which ones needed to be deleted. It proved a lot simpler to do it this way.
-
Adding the third dimension to the array was simpler than I expected thanks to good find and replace and good naming. (I recall the old games only had 2d arrays and loaded any 3rd dimensions in dynamically - heck I remember them loading in just sections of the map from disk).
Getting the ladders to go up and down proved straightforward enough. I wanted to create a table initially for them to move to different sections but this proved troublesome. Having it just change the Z variable was much easier. I will still have tables for the future but I'll keep it simple for now.
I had to give the player the option to move through the ladders and that meant a popupmenu and this lead to no end of hair pulling. My attempts to add the dialog were ignored so some research showed me they weren't available on my build level.
I found this list of users and their build levels so I've thought about upgrading the user requirements.
http://developer.android.com/about/dashboards/index.html
(Good idea - allow it to work for only 26% of all users. However, now I'm thinking of rolling it back to 2.2 to include that extra 12.9% of users I'm not compatible to.)
--
So to do this I was working on Context Menus which come up on the bottom on my level (ugh! I wanted it in the middle of the screen for easy access to my thumbs). I got it to display a couple of black screen choices and I eventually got it to partially work. Its kind of ugly because it needs to code in its own function outside of the display - you have to call it.
So more research suggested I use Alerts.
Perfect!
Since Android is an extension of Java of course it has to be backwards compatible. I found some straightforward examples and the screenshots you see are the results. I can't center it or get ridden of the buttons without some major work - I won't bother.
—
In my research fro Context Menus I also discovered its best if I call different activities for different actions which makes a lot of sense. This will be the Activity for movement and I will create new activities for "camping" and user options, and for combat.
—
I'll throw in up/down ladders this afternoon, but first I have to mow my lawn.
—
The code for ladders work for specials so it should be "forward-compatible" for things like statues and fountains.
—
I'm not happy with the up ladder color. its proved to be a pain against he black roof.
—
Now I can begin the game in earnest. What to do first? Combat or Camp menus? Hmmm.