Lucky Day's Wizard War! for Android development thread

I'm starting to see the light at the end of the tunnel for this thing. Its faint but still visible.

I got on a tear and it looks like it will be straightforward to add levels and creatures now. Fleshing them out will be the hard part. Giving unqique features to the monsters and then testing for some balance. Also, the dungeons will want to be interesting and I'll have to think about scripted events in them and how to implement it.

I have to see about building larger dungeons too so I can see how they work overssized on the MiniMap screen. Incidentally, I added a button to the main display to get a quickminimap without having to camp first. I need to stop turning off the music when launching it too so it continues the audio theme of where you are. Its something I couldn't see (hear) in the emulator because audio on VirtualBox still doesn't work.

I have run into a bit of snag. I want to add a Load button to the start screen and have the player be able to continue their autosave. I knew before this was hard but I'm making a stab at it. The problem is several-fold - moving to the play screen starts a new game by defaults and saves itself to the Autosave. The way it has been working is the player would need to start the game, go to camp then load one of the five saves. The Autosave, being reset, is already lost. Part of the problem was that I hadn't originally used the start screen as the entry point. I tacked it on and made it. Its easy to launch the main activity from there but to load a game a load of the data has to already exist.

What I am attempting to do to make it work is a compromise. The load screen get's the user's choice and if its a legit save loads the main activity and prompts the start that they made a new choice (that this is not a new game). The devil is in the details for this. All sorts of issues pop their head like the "Press Middle to Move Forward" image coming up and you have to compensate. The worst is that darn "Original Tile" resetting itself again.

Another problem too is the code is sufficiently mature now that when bugs do come up putting out the little fire can get messy. The code starts to lose its structure and can get disjointed.

Nevertheless, I wouldn't do this if I didn't think it was wanted. At least, that's the way I want it :D.

PS - tracked down a bug in inventory not dropping I thought I fixed. Testing I found it works perfect when a first drop is made so I tracked it down to a persistence flag being ignored. I had worked out a way to call Alert Dialogs generically from a single function and actually return values. However, I didn't know the code completed before its flag could change by the user in the dialog itself.

I reverted the code to be embedded instead of calling a function and doing the task within the dialog. Its creates repetitive lines but its functionality doesn't require you to jump through hoops this way.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
argh - finally got Load Game from the start menu working like I want it. Seems like it was the hardest thing to do as the whole save game structure is like an octopus .

I've also discovered the placing an icon programmatically on the home/launcher/desktop of Android is much more complicated than it seems. For one thing if you don't get it right the first it can leave residuals still looking for it on the old place even when you remove it or reinstall. That won't be a problem at launch but its a pain at testing. There are multiple reasons why this can happen but it goes away if you change the digital signature. And it looks like digital signature are required for the Google Play store and they are a pain t oset up :p.

to do:
add more levels
add more encounters
intro movie
end game
flesh out dungeons and encounters
add scripted events.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
So far testing for up to five levels 20x20 now.

two things have come up

one, a bug involving the acquisition of spells. it seems that obtaining a spell "out of order" will drop the original off the list. I have to understand what's happening completley here. Maybe the the array is getting reset.

the other is a limitation of Android

it seems you can't have both vertical and horizontal scroll bars on the same activity layout. I'm testing the much larger MiniMap on the levels and seeing how it reacts to the screensize. As predicted scroll bars didn't generated automatically so encapsulated the minimap into a Scrollview.

Well, you can mix horizontal and vertical scrollviews I read, but its really bad. There is a large class that has developed a workaround for this but I read its a performance hog. I'd hate to add such a large class for just one feature in the game.

Most people get around this using Webviews instead of Scrollviews. However, the minimap is generated code and dynamic HTML generation isn't documented around the android world. Hmm..I bet its documented for Java in general. This might not be so difficult to create a table with a few divs and background images...

Anyways, the other idea I have is to tag the scrollbars to the rotation of the screen. It basically generates the minimap in a scrollview of a portrait or landscape where the scrollbar is on the shorter side. Its an intersting idea but in practice I don't know if people will find it clever or annoying.

As it is I'm almost inclined to leave it. Getting a minimap for just part of the screen (on small devices) has an interesting character - it still leaves a certain amount of mystery.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
I've finished all the monster Avatars and I have all the levels. There's still a lot of fleshing out to do.

I've been having a mental block on designing dungeons so I called up my buddy. He suggested a number of puzzles and really got on a roll. Only problem with them is they have to be scripted and not break anything.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
I finished the maps and I'm just testing them to make sure the I can go up and down and the ladders line up right.

I've found two bugs in the process. One bug causes the minimap to leave blank spots. I've traced this to combat not replacing the original tile but it doesn't happen 100% of the time. Its also not (directly) related to resting while in camp mode. It doesn't appear to be related to a rare back to back combat issue where it accidentally stacks. I think I can correct it though.

I had my nephews with me on vacation over the long weekend so I had them playtest it. After they got past "no swiping but tapping" controls they started to get into and even started giving each other advice. This is a really good sign! They were happy that the game now had a lot more substance then when I had them test it last year.

I did discover one major bug where the save game doesn't load properly for the first person viewpoint. The minimap seems fine though. Argh! I'm sure it has to do with changing one of the tiles. Y'see I rewrote the map storage as an XML array rather than an array within the code itself.

Developing levels came easiest in MS Word tables of all things. I tried that Wizardry mapmaker we advertisted a few months back but it wasn't quite right.

Anyways, after using 'w' as my wall tile I dound the dash ( '-' ) made my maps much more readable. So, I think my redrawing of the save game is blocked by that. I'll need more research of course.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
OK, I think (hope) I've tracked down these three bugs

The keys are no longer equippable. It simply closes the dialog.

The blank spots showing up on the minimap turn out to be legacy "arrows" (v,^,<,>) from when the minimap was textbased. The original tile variable being used was not getting reset for who knows why (timing issue likely) so simply removing the one line fixes it. Thank God!

Another Thank God! moment is I hope I fixed the save game issue. I tracked down the empty save game not as a load issue but a save issue. I think it got screwed up if I tried to save twice too quickly or somesuch. It now exits the CampActivity outright after save the way Load Game does.

One bug could have been horrible but this save game issue could have been a disaster. I will continue to monitor this.

There are random and rare crashes after boss battles. I need to track down why.

Here's a couple of new images
Jan Van Eyck's "A Man in a Turban":
J9IrcTB.jpg

Odilon Redon's "The Smiling Spider":
IlsgAGS.jpg

and how it appears in game:
Ie4L6LX.jpg


you'll note the different blacks on the spider. In game it works much better as otherwise it was a "cheshire spider".
 
Last edited:
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
Pretty cool. Whenever you are at the stage of needing testers I'll be up to it. Who knows what devices I will have at that time.
 
Thanks Toff. I'll need to test it on as many devices as I can. Right now its strictly internal testing and a hand off to friends who have Androids handy. Of course, when you're developing you lose site of something is fun or not and you don't try things outsiders would consider. It can be really useful. One thing, for instance, is the first thing that people do when I give it to them is swipe the screen. I'm going to have to test that at some point to see if its feasible this late in development. I think it could be as simple as swipes triggering the tap events in place now.
--
Following up on Armor - I had a hard time getting motivated to do it this weekend but when I finally started on Sunday suddenly I don't want to stop.

Its been harder and easier than I expected in different ways.

First, let retreat back to the first page of this thread. I had said that I had planned to have combat different by giving different layers of armor going from shield to armor to base hit points and the weapon to have hit points as well. I had done a tech demo a few years ago in C where this was possible. What I didn't consider is the difficulty of it in inventory storage etc.

So far I've had combat with no armor - just weapons, hit points, death and one spell. Armor from this point adds hit points to the player. This weekend I got it to work.

The "simple" part was exchanging it in inventory. I already had weapons exchange working so it was a modification of that headache. The code is months old now so its a matter of remembering and figuring out how it was done and getting the monsters to drop their armor. That figured out and its persistence comes the real hard part I realized - Hit Points.

I tracked down a bug where the Tunic seems to have a 1hp - that was a pain. I'm still not sure where that's being generated but its best to find out rather than compensating for it. The big thing will be keeping track of the armor's current hit points when its exchanged or else the player will be able to cheat by hotswapping their armor at max.

Part of the solution methinks is to add a condition in the inventory persistence loop that checks if the inv item is armor and to save its current HP. To compensate for a new armor I think I'll need to add a flag so its stats aren't regenerated every time the player equips it. This is legacy thing that 's works for weapons - I may need to rewrite the code entirely. Its an issue that's part and parcel to child objects and lists. Grr. With enough time and coffee I think its solvable.

Then on to finish weapons. I basically need images there.

Then on to spells.

Put in the intro and finale and I've got a finished game.

Anything after that would be extra.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
Progress is looking great so far! I always enjoy ready dev logs like this because they always seem to contain unique ways of solving problems. Funny thing is when I was creating shadows of kalendale, I ran in to a similar problem with repeatedly equipping armor gave infinite defense. Keep it up though! Android needs more of these types of games. I'm looking forward to playing it.
 
Joined
Feb 19, 2009
Messages
2,257
Location
Calgary, Alberta
I think one of the problems is I have no patience for math anymore. I'm more prone to work it out with a computer.

There's two ways I could do this - do the math in Camp activity where the player exchanges inventory or do it in combat where I wouldn't need math, just a condition to first check the armor hit points then create a new variable for base hit points to widdle down after the armor reaches 0hp. That was the original premise for destructive equipment which I've since scrapped. Doing it that way however would still mean I need to track it in Camp and that's what I'm trying to avoid.

Funny this is the first I've seen your game even with your log on this thread. Is it text based? Did you get that VS 2008 issue resolved? I'm guessing you figured out how to embed the driver within the executable instead of depending on an external library.

Philosophical part (typical blog stuff):

One thing that surprises me is why no (few?) people haven't thought of this before: using armor to extend hit points and eliminating AC. In games like Call of Cthulhu hit points could rarely be increased so in D&D terms the player was always level 1 and (I think that was one of the factors why the d20 version wasn't that successful). Increasing hit points has always been a controversy but Gygax and co. explained it away as an abstraction. To Hit was brought in to get past Dave Arneson's Armor Class idea he brought over from ship based games.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
Whew - had big fun on this over the weekend.

On Thursday I got into a groove on developing weapon images and working on balancing. Still a ways to go for balancing but most of the weapons went quick. A lot of the legwork was already done by the time I looked at it again - I got most of the free to use images from one site. Weapon images are pretty popular.

Then I got sidetracked over the weekend. In testing I found the spider gave me her web as a weapon so I started using it. It looked way cool (I'll get you pictures tonight), having been so used to swords and stuff for so long, but taking a spider's web isn't exactly something the player should be doing.

Then I got the idea, why don't I try limiting it? And as usual it turnede out to be real easy; then turned out to be difficult in ways I didn't realize.

The limiting the uses was fine - I could get the player to run out of them and be stuck punching his way through rest of the combat. I could even send said player a message saying how many left.

When I picked up multiple webs I saw they were reloading themselves to full. So there was an issue with persistence. Since I added a few variables to do this I needed to add them to the persistence. This was a bit of a pain because I had to do it in two places - for the current weapon and the inventory loop.

The big problem was "downcasting"

http://stackoverflow.com/questions/380813/downcasting-in-java

This works fine for my Armor class but my Weapon class (both of which are child classes of my Item class) kept giving me fits. I got one of those "magic dreams" in the middle of the night where you wake up with the song "Yesterday" or adding "Mexican Horns" to "Ring of Fire" or some such. In my case it was the solution to the problem: manually cast it.

By doing it manually I just added the variables that weren't defined in the parent cast and had the children equal - most of the first part is done in the contructor anyway. I just had to change the infiniteUse variable to false since a Spider can't run out of webs after one test and you can (ie. The AI cheats!). Hope folks will forgive me for that. The other side to that is you will get a full weapon irregardless.



Okay, running out of weapon then relying on your fists makes for a good challenge - you can try and beat it out of the rest of the enemy 1hp at a time or you can run away. This made for interesting dynamics but I realized, why would anyone equip an item that ran out, so I tried an experiment with equipping items in combat.

I took the code straight from the Camp activity then made some adjustments for the combat activity and it worked right out of the box. I added a button for it. I turned off the option to equip armor thereby reducing some of the code - because let's face it - it takes more than 1 turn to swap your armor typically.

The only issues I had were taking damage or not after equipping and in doing so I discovered equipping an empty item slot (a "none") was not being properly ignored. I managed to fix this in both spots.

My only concern is now I have double the code. Hopefully I won't need to make many changes down the line. Properly I should have one method and have both activities call the same but can get really hairy as an activity is not a normal class.



With that done I thought I'd tackle the issue of full inventories at the end of combat - the loot phase. As it was it just told your inventory was full (tough luck!). This wasn't ideal though.

I ported the drop code over from the Camp activity, and what do you know, it worked almost perfectively too.

Until I discovered you only needed one empty slot to take everything (so far this is just weapons and armor).

Some research found that camp had twice the code checking for this so I dropped it in a method and it checks it a second time if another item is selected and only one slot is available.



Now I was happy and free. I reduced my keys to 0 and we drove over to my nephews to test it (its the oldest's 16th birthday). Unfortunately, combat didn't work and they were stuck with no keys. Oy! For some reason they kept running around banging onto walls on purpose after that so there's still some semblance of a game just in exploring I guess.

I fixed that last night. Combat Activities still has a tendency to stack and the first one will end up being meaningless so its ultimately a waste of time. I tried to track the state and close the activity if there's more than one. This didn't work at all. By the time I had my nephews try it I enclosed the combat into an "else" when it was supposed to work. That actually blocked it, so for some reason it seems to recognize that its stacked but continues normal anyway, when it should just exit. I thought it would be about a 1/400 chance of doing this but the odds seem more like 1/40. Its not a huge deal but its noticeable and people will complain. grr.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
here's my weekend update, the usual, "this is harder and more complicated than it seems" post.

Spells

Attack and Damage spells are pretty straight forward to write. Once you have one the rest are very similar.

Its unusual ones like Invisibility and Hold spells that are problematic. Spells that effect the game outside of combat have to be tracked. Old variables that are used to solve old problems have a tendency to get in the way. Invisibility, for example, I allow use for outisde of combat. At some point this wears off and you have to keep track of that. Fortunately, I've decided not to put the status in the save game so I don't have to make sure that works.

How to announce its warn off. How to tell the player their state. This stuff get's in the way. Since it does no damage I made it different from other spells and skipped that part of the dialogue. However, I get random crashes. It seems its because there's some spell object its looking for to erase and I've made Invisibility a void return. We'll find out. Eclipse isn't smart when it comes to bug tracking.

In the future I think a player state stack would be the way to go and then maybe a method or even class specific to tracking the player state is necessary. Of course, you need to do this in reverse for the Enemy. In combat, why would an enemy want to turn invisible for example.

So after you add these things the balance gets affected. I had this same issue with weapons. It makes for interesting design changes and the building of the game becomes more fluid.

If all your spells were just combat spells it wouldn't be very interesting and you would just spam your best spell. So you need to add spells that do things differently. I think I will add Haste next. I'm going to do something crazy there outside of combat.
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
It seems its because there's some spell object its looking for to erase and I've made Invisibility a void return.

You made Invisibility invisible! Be careful with that. I think that might have some sort of effect on time and space.
 
Joined
Feb 19, 2009
Messages
2,257
Location
Calgary, Alberta
You made Invisibility invisible! Be careful with that. I think that might have some sort of effect on time and space.

LOL - the object Eclipse couldn't find was invisibility mwuahahahahahaha!

such a nerd joke...
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
You still owe us web pictures :p

you're right, you're right - here's a screenshot of invisibility:

pcupKGJ.png

and for kicks, here's my shot Andy Roddick winning Wimbledon:

0QjAFeu.png
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
j/k'g

here's the offending culprit

2KtZ1UD.png


Comet Hyakutake becomes magic missile

3m1iQIq.jpg


And I'm debating between these two for the paralyze/hold spell

SQk9A2P.png


6MFZ6GY.jpg
 
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
and here's the problem: its not an issue with the code per se; its a problem with the memory. The memory is getting throttled by the spell combinations and the drawables and is trying to adjust itself to 4gb which the emulator can't handle!

I have to find a different way to allocate these resources. I think the way its embedded into multiple layouts or nested routines is causing the memory needed to increase exponentially.
 
Last edited:
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
Ok, this is bad. After a few days of researching memory issues in Android it appears that Android two sets of memory, the active and the external heap.

I managed to get the thing to start playing a lot smoother by manually calling the garbage collector ( System.gc() ) but I was still having the same issues when I drew the weaponImage saying I've hit the offending limit of 40mb or somesuch. I removed the above Invisibility status image and thought this took care of it. But after stressing the maching with spells I suddenly run into a 24mb limit.

24mb is the limit on the heap size of the external heap I've gleaned. Older versions of Android limit this to 16mb. Android 2.2 and before and Honeycomb (3.0) and above have ways to increase the heap size, but Gingerbread (2.3), which 33% of all Android users still use, does not. In addition Honeycomb automatically gc's the heap (I think).

Worse, the heap does shrink once its grown. However, I've seen it shrink, particularly when I've finished an Activity.

The main cultprit of an evergrowing heap size are bitmaps. Or, it should be noted, are the chief thing you can clear up by use of .recycle(). Like Windows recycle it just means trash.

So I tried many techniques to recycle the background drawables by first converting them to bitmap but I still got either Out of Memory errors or attempting to use recycled bitmaps.

This was caused from either a) a destroyed image or b) attempting to recycle an image in use. It seems once an image is destroyed it can't be brought back - but I use them dynamically.

Caching the images will increase performance but will still increase the size of the heap. I need to look at LRUCaching to see if this is still true. LRUcaching replaces weakreferences which made them a bigger target for gc in theory but apparently did next nothing in Android.

It has been recommended to use OpenGL textures or the NDK to control memory. The NDK allows for external languages like the libc to connect to Android. They never use external memory and the libc can use malloc and free so you can control the memory yourself. The big problem is is I would need to completely rewrite the code.

Unbinding the drawables once you've destroyed the Activity is a great tip I found. This doesn't work until the Activity is finished so it doesn't help my immediate problem. However, it appears rotating the screen is bad for leaving the drawables still bound to the old destroyed activity (memory leak garbage) so implementing this is still important.

One solution I'm going to try is the BitmapFactory which can take an image and create a bitmap out of it the precise dimensions of the ImageView. This keeps the ImageView from having to adjust the background image itself. On top of that I can try and recycle the bitmap once I'm through with it. This is a complicated process but I'll see how it goes.



I managed to squeeze Munch's The Scream as one of the antagonists. I can use it because even though Munch died in 1944, this is from a lithograph he made and a reproduction's copyright begins on the date it was created. And in the US any print created before 1923 is considered public domain.

Munch_The_Scream_lithography.png

Its pretty much how I feel at this point.
 
Last edited:
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
Got some of the memory under control. Instead of a background Drawable scaling itself to the dimensions of a Weapon Button I changed the button to a standard ImageView.

I then scrape the ImageView for its height and width, then create a Bitmap from the image resource, scale it to those dimensions then make it the image of the new view.

the result

oXrs9DU.png


you'll notice aspect ration stays intact compared the image above.

On top of this I declared only one Bitmap for the entire Activity and recycle and gc it just before I set the new value.

So far I've stressed it and at the worst it seems to get about 21mb. So far so good but I would like to get it better.

edit: scaling fixed, with no noticeable change in memory :)
invisfixed.png
 
Last edited:
Joined
Oct 19, 2006
Messages
5,209
Location
The Uncanny Valley
Back
Top Bottom