That was more irritating…

Then it probably really needed to be. The example that Google gives on the Android SDK page is pretty horrible as far as clarity is concerned and what is needed regarding application run through and process. They have some flashy graphs and flow charts, but the bottom line was it was EXTRAORDINARILY confusing to try and figure out how to make the program do what I wanted.

Finally figured out that in order for the display to change one of the fields, the field had to be adjusted AFTER the call to the layout manager. yeah. Figure that out. Needless to say, though, I am pretty pleased with myself. The dice roller app will roll a specific die (aka a random number between 1 and whatever upward limit dice you want), and spit it back out…then wait patiently for you to press another button.

The random number generation was the least problematic here, and runs exactly like it does in Java…so basically one quick cut and paste from what I’d already done on the game programming and she was good to go. Understanding the way to deal with the buttons and adjust the necessary information though? Far more complicated than it needed to be.

Hint: you DON’T need to call another activity class. Thanks 1000 examples for not explaining that at all. Jerks.

Still though, I am getting a hang of it now, and things are going well. Oh, and before I forget, here’s the dice roller program. She may not look like much, but she’s got it where it counts, kid.

Right click ‘n save.

Uff da.

Well, on the plus side I know enough java to be able to write the rest of the game with minimal problems. I’m looking into the android development now, and it is…something completely and utterly different.

XML files, state commands, manifest files, variable declarations in addition to those in the actual java package itself, it adds another layer to the programming…and it seems to be quite a few additional steps that I’m not convinced are absolutely necessary, but no one asked me.

I’m happy, at this moment, that I didn’t fully program java to be run on my computer…as there are huge differences in how display and user interaction are handled in Android versus in the java IDE (using mainly swing). I’ll still program the main functionality and classes on the computer here, as that way I can test them before fiddling around with the android (or down the line, windows 8/phone controls) and knowing that the other classes work as they should.

When it comes down to it, maybe it won’t be THAT difficult…but we’ll see. The dice program is likely going to take me the rest of the day.

On the plus side, I’ve got my Android phone to do test and debugging on. That cuts about 10 minutes waiting for the emulator with the eclipse SDK to start up (seriously, slow). Silver linings ‘n such.

CosmoViking programming pause

I need to continue the planet descriptions…I got through about a quarter of them last night (I had to lecture last evening). I plan to finish that up today.

On the programming front, I’m going to take a short break from the programming of the game to mess around with the android SDK. I RPG about once a week with some friends (like Keith and Kuha) and since I’m a relative n00b at the process, I have no dice. It’s always a pain to rummage through piles of dice trying to find the one ten sided die (there may be like two of them, possibly, between Kuha and Keith), or to try and find the 8 sided die. Or the caltrops that were thrown to stop a celtic cavalry charge the last week.

Naw, I’m kidding about that last one, but Dice do hurt a lot if stepped on.

Instead, I’m going to use the very small amount of skill I’ve got and program a small dice rolling program for android. That way I’ll have all the dice I need on my phone. Sure it doesn’t come in handy dandy little bag, but it’s better than nothing. And is likely some good training for porting CosmoViking over to android in a couple weeks’ time.

Not a whole lot of programming today.

There were a confluence of things that cut down on the programming. However, I did get around to setting up another subsidiary java script that will allow me to type up all my planet/system descriptions and save them as their own file. I had started doing that and got about 3 files in…that’s when I thought to myself “I’ve got to do this 137 more times?”

It wasn’t the description, it was the task of going new file, then renaming the file, then opening it in the program, editing it, and saving it. I did it three times when I thought to myself “Good lordy, there’s a better way somehow isn’t there?”

I’d already been populating planetary files and game files, reading/writing/creating files per game iteration…and setting up load buttons. It was pretty sweet.

Today involved a little bit more programming/adjusting with textfields and buttons and event recognitions. It was a bit of a pain to figure out exactly what I was doing, but after typing out three sample programs from my java book, I grasped on pretty quick how to handle it. The program is slick. Very pared down graphically, doesn’t look like much, but it does the job I needed it to do (take all of the repetition and pain out of creating new files and renaming them).

Now, it will run through as many times as I need it to, take the description text from the text field, open a new file, drop it in there, and move forward. Since the names of the files will be the numbers of the systems, it makes it really easy to deal with.

Yesterday I mucked about a bit and got a preliminary system map display (with x’s and o’s) to test the movement functionality. Some of the things got fixed from that. This evening I’ll finish writing the descriptions for the systems and planets, and tomorrow will integrate the functionality of the ship battle system with the description and system exploration. Now that I know how to do button events, and set up display frames, it will be much easier to test functionality and bring things up to where I’d like them for slicing in graphics.

After that the space time continuum is programmed and working, then the work on the settlement part begins. Once the settlement and such is figured out, then the mercantile system will be put in place. Then the mission situations will be put in place. I am really excited, this game is coming together almost hand in hand with what I’m learning in the java book.

Also, learning file manipulation is really handy for the web work I’m doing.

HFAIT: Stretchy batteries!

At first, I read the title of this news article detailing flexible batteries in the voice of a over excited child. I never had a stretch armstrong, nor did I really want one, but the idea of the word “stretchy” brings to mind a certain childhood enthusiasm over testing things until they could break.

And stretchy batteries that can be charged inductively? Color me excited. Electronic bricks o’ batteries may be the thing of the past. Huzzah and hooray, science. Huzzah and hooray.

At yeast it had a good run…

I knew I spoke too soon about that yeast project from eHow a couple weeks back. Rat $(#&s.

I quickly found out that it wasn’t really specific on feeding, nor was it specific on how much to take out each day while feeding…or each week. I kind of played it by ear…and the concoction went bad.

We’re not talking knocked a plant over, house cat, style bad. We’re talking threats against the president, al qaueda style bad.

The yeast smelled as yeast should (perhaps a bit more sour), but the liquid forming outside of the yeast/flour mixture was black: black as a nose on an SR-71 blackbird on a moonless cloudy night after the sun had burned out and the stars had died black-hole-esque deaths. It wasn’t right. Oh, and the turban it started putting on was where I drew the line.

Into the garbage it went, going to try again with a more reliable approach.

Odd.

The last three posts started with “So…”

I hope you all appreciate the fact that I was mixing conversational tactics in with my writing in order to make you feel at ease and make it seem like we’d already been speaking about other things.

You’re welcome.

Memories o’ the ride to school

So back in the days o’ my childhood we had one of the worst bus routes ever. It took us about 45 minutes to get to elementary school (an hour and 5 to get to middle school, an hour and 20 to get to high school…we were about a 10 minute drive to elementary) since we were one of the first to get on the bus. And on the ride home it was around half an hour to 45 minutes depending. Consequently, doing the math, at least 20% of my days usually were spent on the bus.

Which may explain some of my back problems….but that isn’t the point I’d like to make.

The point I’d like to make is that we always listened to either the country station, or on the later bus (we transferred at least once), a contemporary music station. I remember liking the song ‘Sit down you’re rocking the boat” by Don Henley quite a bit back in the day when it received a LOT of heavy radio play. Well, I got to thinking I should look it up. So I did. Here it is:

Either my tastes have developed somewhat, or the song was much better when sitting in uncomfortable seating (much like a boat) and imagining being knocked off the bus. Regardless, it just doesn’t hold up for me.

Ship battles

So I finished the list of ships this morning and the way to change/adjust and go about loading the enemyShip class in Java. This afternoon was spent programming the battle system that would pass in your ship as well as create the enemyShip based on what/where the fight is taking place (and whether or not it’s a bounty attack or a ship move).

Once the basics were done, I ran some reports on that (over 100,000 battles “fought” with ship types), then I tweaked some of the attributes of the standard ship classes and ran it again.

Then this evening I programmed in the ability to dodge or to miss dependent on the maneuverability of your ship. It necessitated increasing by about 4 times the amount of munitions increased with each standard ship class. Now I’ve programmed in the “runaway” function (just to test what percentage of battles would work like that, were a human to run when the HP was less than 25%), still a lot of draws happening. I may have to increase munitions again.

I am going to check yet this evening, and then set the program to fight through the ship battles by about 10 fold more to crunch the numbers to see what I can see regarding the tweaks.

I don’t mind some draws happening (when it’s between ships of the same class, for instance) but one third of the battles here were draws and that is problematic for balance issues.

To be completely honest, I never imagined the amount of work that I’m putting into just starting with the balancing out of the ship classes. And to also be completely honest, I never thought I’d have this much fun just looking at raw win/loss rations when looking at classes of ships.

Good times, good times. Soon, I’ll get into the GUI walk throughs in my java book, and have some rudimentary user input to start testing the flight/battle/pinging options.

All in all, this was a very good day.