7th Sea Dice Roller

Version: 1.0

Description

A dice rolling application for the now-defunct AEG game 7th Sea (website unavailable: domain has lapsed).

Users choose a number of dice to roll, a number of dice to keep, and

whether the dice explode. The results are displayed and the user can choose to add Drama Dice to increase the total.

Availability

Android Marketplace (search term: 7th Sea).

Requirements

OS: Android 1.6

Hardware: screen resolution 320x240 or higher (recommended 480x320 or higher).

Data usage: none (may be updated in future versions to use Random.org's randomiser)

Storage usage: none

Known bugs: none

Known issues: on altering screen orientation, current dice roll is removed.

Recent changes

Updated portrait mode layout to stop the Add Drama Dice button disappearing on some smaller screens.

Release Candidate #1

So, I've opened up the wallet and shelled out for the developer login over at Android Marketplace. Now it's time to put my mouth where my money is, so to speak, and actually get some content up there.

Now it gets to that point, it's all very intimidating! But sure, what is there to worry about? Apart from, you know, having any mistakes I made exposed to the general public? Um...

I've also been wondering quite heavily on the testing of apps. This first one, see, isn't really going to need that much testing: it doesn't do a great deal, see? But I've only tested it on the Android emulator bundled with the SDK, and then on one handset (and a powerful one at that). I know several people who would almost certainly help with the testing (and might even use it from time to time!), but none of them can easily connect their phone to my PC with a USB cable for debug purposes. The only real solution here, it seems, is to release it as quietly as possible, and hope that people won't flame me horribly if it doesn't work first time round. Not ideal, but hey.

You know what? A blog post would probably serve as a useful standby page for the app website. I should fix that up now...

Rather random

Someone got me thinking earlier about the random number generator that I've been using for the various dice rollers that I've written. Now, usually I'd just go with the default RNG for whatever platform I've been writing for, and that'd be that. I realise that randomisers can only generate pseudo-random numbers, though, but most of the time that's plenty good enough for our purposes.

However, I found a useful looking site today: http://www.random.org/, being operated from Trinity College Dublin. They generate truly random numbers from atmospheric noise, and there's an API to plug into to that can be used to pull sequences of random numbers over the Internet. Now combine that with a smartphone's data connection, and that would be a perfect dice roller! Of course, I'll have to think about things like user permissions (and give the user the choice to go online or not - particularly if they happen to be roaming at the time), but this could be an interesting little project to make sure that I'm reading data correctly from Android's http connections.

Not sure how much of a rewrite this'll end up being, though. Possibly fairly extensive...

Fragmentation

Usually a problem considered to occur to hard drives, I'm beginning to hear this addressed at the Android OS as well. It's a totally different context, mind: in this case it means the difficulty in developing applications for a supposedly unified operating system that in fact runs on many different devices of wildly differing specifications.

Take, for example, the dice roller app I'd worked on for a while. It was developed for a pretty standard screen resolution of 320x480, and the interface seems to fit quite nicely that way. Scale this up to the oh-so awesome HTC Desire, with a resolution of 480x800 (or whatever it is: it's ludicrous, for a phone!), and it looks even smoother.

The other day I tried to pop the same app open on the emulator running the specs of the HTC Wildfire. Oh dear. The screen is a tiny 240x320, which seems minute for a smartphone, and the app is unusable. Having looked at average screen sizes when I began the development, and settled on 320x480 as a useful size, it's a little frustrating to now discover that a newer device can't run the app. I can only imagine what other development teams who have put weeks and months of work into apps, now to discover that the new range of budget smartphones will require them to rewrite sections of the interface to make sure that they fit onto them cleanly, or they'll just have to put a minimum resolution requirement onto the app itself (I'm lazy: that's the approach I'll be taking, I'm afraid).

New Project: HealthWhere

I've got another Android project on the go at the moment: HealthWhere. It's an adaptation of a utility by Russ Philips to help find local hospitals and pharmacies, using the data from OpenStreetMap.

The plan for the project as a smartphone app is to use the positioning tools available to smartphones (satellite positioning, or just approximate cellphone mast positioning) to get the user's current location, rather than just asking them to input an address. The OpenStreetMap database can then be queried, and the results returned for quick and ready reference. It should also be possible to fire those co-ordinates over into a navigation app to provide instant directions. Just add water - or something!

Plan:

The interface is roughly divided into two halves. The first half is to determine the user's location (or a location to search in, if you want), and the second is to display the results of that search in a usable and meaningful way. Of course, there needs to be a bridging part which actually gets those results, but that'll be behind the scenes.

My plan for working at the moment is to consider the app in order.

1) Determine a position to search from.

2) Carry out a search, and parse the results.

3) Display those results.

4) Give an option to upload location data if it's not there already.

I'm sure that other ideas will occur to me as I go, as well, so we'll have a (5) Other interesting stuff.

Progress:

The first stage of the app is just about complete. The opening menu screen fires up and gives the user the various search options:

• choose between searching for hospitals or pharmacies.
• choose a search radius
• choose to input a location, or to use the phone's positioning features to find the current location.

From this point, the geocoding and reverse geocoding work as well, to either determine co-ordinates from the address entered, or to determine a local address from a set of co-ordinates.

The second stage is going well: the search query is constructed, and an XML file is returned which contains the results.

Next steps

The next step is to write up the classes for the different healthcare amenities, and to parse the results file into something meaningful.

Lastly, I'll be working on displaying those results as a list for the user to scroll through.

At some point, I'll also need to have a look at how to upload data as well.

Platformer blues

"I've got a great idea for an app - but what phones should I write it for?"

It's an interesting question and - as it turns out - the answer is harder than I thought. Now, in an ideal world, you'd just write and release it for all the major smartphone OSs - Symbian, iOS, Android and RiM. But that's quite a lot of effort for just one person! So how do you maximise your returns or exposure for minimal effort?

First of all, it's probably an idea to think about what language you're comfortable working in, and what operating systems that the language plays well with.

• Nokia -- a whole variety of languages supported, so you'll pretty much have to pick the one you want and grab the relevant package for it.
• RiM Blackberry -- Java
• Android -- Java
• iOS -- one of the C languages. You'll also need (yes, really - it's mandatory) a Mac.

Next up, let's look at the different platform distributions (data from Gartner).

• Symbian: 41%
• RiM: 18%
• Android: 17%
• iOS: 14%

It might be worth noting, though, that the market share for Android jumped from 1% in 2009 to 17% in 2010 - obviously this might not be indicative of future trends, but Google have put a lot of effort into getting it onto as many handsets as possible. Also of note is that Oracle are currently taking legal action against Google for unlicensed use of the Java platform - though the future of that action is somewhat uncertain.

Lastly, we'll need to have a look at the different distribution systems for the different operating systems. (This is just a summary, though - there are multiple delivery platforms for most operating systems, so you don't have to follow the well-trodden path - it might just be a lot easier! Also, having not personally explored them inch by inch, there may still be pitfalls to discover...)

• iOS: Sign up for an AppStore developer account - this is $99 per year, and lets you distribute your apps through the AppStore, after they've been checked out by Apple.
• Android: Sign up as an Android Market developer for $25 (one-off fee), and this lets you distribute your apps through the Android Marketplace. However, there are caveats here based on countries - the list of countries where you can charge for your apps is currently quite small.
• Nokia's Ovi store: Sign up for $50 to register yourself as a publisher - this lets you upload content for distribution via the Ovi store.
• RiM's Blackberry AppWorld: I can't find a price for signing up as a developer, but again, there's a central hub for app distribution.

Most seem to offer a standard 30% distribution charge.

So, where does this leave us? Personally, I'm going to carry on working with Android for now - I think that it has a good future ahead of it, and I'm far more comfortable working in Java than with C. At some point, I'd like to give the iOS development thing a go, but it would mean buying another computer, which would be a little annoying.

Android app: details

Seventh Sea dice-rolling application
This is something that I've been working on for a little while. The dice rolls in the role-playing game Seventh Sea are not the most intuitive or easily calculated sometimes, particularly later in the game when you can be sorting through handfuls of dice, frantically adding some - but not all - of them together to get a total. This isn't exactly adding to the fast and frenetic nature of the genre. Therefore, I've been working on some kind of application to help speed this up.

History
It started out as a purely Swing based Java application, and since developed into a Java applet for ease of access. Finally, it has evolved into an application for Android platform phones, purely as a development challenge...
The development has taught me a good deal about developing for Android - and mainly that it's actually not that hard (particularly for something as simple as this)! There are plenty of good tools available, and the UI creation tools are a breeze - certainly much easier to get into than Swing.

UI
The UI is very simple for this app: there is a main menu screen with a few options available. The only one of any real practicality is the Roller screen, which contains the nuts and bolts of the application. There are two keypads, one of which selects the number of dice that you want to roll, and the other selects the number of dice that you want to keep. There are also buttons available to choose whether the dice "explode" or if and Drama Dice are added to the roll.

• Splash screen
• Menu screen
• Roller screen: Portrait 1 -- Portrait 2 -- Portrait 3
• Roller screen: Landscape 1 -- Landscape 2

The layout files are all quite simple XML files, detailing the page elements available to each page of the app. Each layout file comes in two "flavours", one for the portrait orientation of the phone, and one for the landscape. On a change of handset orientation, the phone switches between the layouts. (This does, however, call the onCreate() method of the layout again, resetting any options that have been chosen.)

Problems
There haven't really been many problems in development at all. The most challenging part was to develop the object-oriented approach to the dice-rolling, as there are some slightly awkward options and corner-cases to be handled.

Future tweaks
There are still some tweaks that I'd like to make to this app, though.
Firstly, it would be nice if changing the orientation of the phone didn't cause the app to forget any dice rolls that it had just made - this, I assume would be handled by a new implementation of the onCreate() or onResume() methods of the particular activity.
Secondly, it'd be nice to check out the RNG for the engine as a whole. This probably isn't essential, as I'm using the Random class, which should be more than enough of a random generator - each single die is given a 48-bit seed based on the system time when it's created - but it might be an interesting experiment to run some tests on how random it actually is.
Lastly, it'd be nice to add some extra touches from the mobile interface itself - perhaps some (optional!) sound effects. On the other hand, they are rather gimmicky, and would probably become extremely irritating rather quickly. (On the other hand, it would be a good reason to start working with storing user settings, so that's a good reason to implement them by itself!)

Thank the Maker!

It finally works! My first Android application - the 7th Sea dice roller that I've been going on about for a while and that has seen simultaneous development as a Java applet - is up and running. It's not available online yet, but depending on how confident I feel (and if I can convince anyone to be part of a beta test) I might end up forking out the $25 to sign up for Google's Android Marketplace and set it out in the real world.

The UI on the Android app is considerably nicer than the UI on the Java applet. I think I might need a little bit more practice using the Swing controls.

More detail will follow, when I'm not shattered :-)

7th Sea roller

I'm going to be starting a new roleplaying game up in the near-ish future, and I'd like to try and develop some kind of dice-roller to speed up the game, and take away a little bit of the slow dice-rolling that can go on.

RandomRolly isn't quite up to the job - we're playing face-to-face round a table, rather than on Wave, so it's going to have to be a project from scratch.

Ideally, I'd like it to be accessible over web-enabled phones, so that players can use it on them - if they want. Which means it's got to be pretty simplistic, and also universal.

Currently I'm leaning towards a simple web page to start with, probably powered with JavaScript. After that I might aim for a Java application (and then an applet) that I could host somewhere. If all of those work and I'm still feeling ambitious, I might even end up trying to create a full-on Android app (though that would mainly be to see if I could!).

Thoughts:
- I'd like this to be both flexible and expandable, so I'm going to try and really use the object orientation lessons that were drummed into us.
- I'd also like it to be quite user-friendly, so there'll be lessons from the HCI side of things showing up here as well.

Plans:
- First of all there'll be a few screenshots for the interface going up.
- Then, we start planning the data types and overall structure of the app.

More news as it comes...