Thanks for all the feedback Emelie! I'll try and respond to most of it here.
Status windows
First off, I like your idea of the consolidated status window. My thought is to keep the (optional) popup turn log so you can see what happened since your last turn at a glance, but then replace the info and turn log buttons with a merged version.
Your mockup looks good. My approach has been to avoid showing any information that can be found by looking at the board. I think the status window shouldn't tell you much that your opponents in the real board game don't have to tell you. The big thing is that it shouldn't show victory points - I think a big part of the game is in speculating this for yourself. More importantly, there are the "victory cards" that aren't shown to other players until you declare that you've won. Of course you need the information such as the number of development cards that each person holds so you can make your speculations.
A quick building costs dialogue that is always available would probably be good. I put it under trade and that was good enough for the time, but I'm not 100% happy with it - it's on my todo list.
Interface
I'd like to add an undo option after building. After I added zoom and long press support I found that I don't make mistakes, so this became low priority. Of course this would help with people learning the interface. It would also probably help to have "toast" (the small popups in the lower third of the screen) prompts to tell you what to click ("double tap to zoom in, then long press to build your road" or something.)
When you steal from someone, I decided to show the full list so it is more obvious why it doesn't let you steal from someone. My ideal interface design would be a dialogue like that, but with the 0 resource players disabled and greyed out, however I don't think that's possible without going to more depth. Maybe I'll change it from a dialogue to a full activity (info and turn log are dialogues that pop up, trade and options are full activities - you'll notice that they don't disappear when you rotate the screen; I went to great lengths to ensure that the steal dialogue comes up again if you do this.) Let me know if you have other ideas, or even a mock-up.
Usability-oriented design is important. I'll admit that much of my design is based on what was either most obvious to do while developing it, or what is fastest to use when clicking through the game really fast. My preview-2 release was really quick, but has poor usability.
Rules
The board game has 5 settlements (which I call towns since it's shorter and screen space is valuable on a phone) 4 cities, and 15 roads. This forces you to use a more diversified strategy to get points, so you can't just build 10 towns and win. When you build a city, you do get 1 town back. This is implemented but my game doesn't really tell you about it (except maybe in the instructions if I included that.) I think I'll include something like this in the status window "towns: 3 / 5" or similar. Maybe keep the button when you can afford it, but give you an error message when you click it explaining why you can't build a town.
Translations
In android, you typically put all your strings in an xml resource file. Some of my generated text dialogues are hard-coded though. I'll try and move more of those into the xml file so they can be translated too. The buttons at the top will be more annoying to support translations for.
Here are the countries with the most users: US, UK, Canada (all english) then Germany, Netherlands, France, Sweden, Denmark (order not exact.) I'll try and do a french translation as an example.
For those willing to help, I'll make it really quick and easy. Send me an email at
omnionic@gmail.com and I'll get you set up.
Debugging
About dumping debug info, the easiest way is for you to describe exactly what you did. Include the stage of the game; is it the first turn? where are you in the turn order? how many ai players? what buttons did you click? did you rotate the screen half way through?
If it crashes or hangs, the best way to help me is to give me a stack trace. If you're using the market version, there's a button to submit it automatically. Add a message telling me what was going on in case I can't guess. So far the only person who added a comment just said "the game crashed again."
If you get to a point you don't think is right, you can try to produce a stack trace showing that too. This is a bit tricky though since it actually needs to be in a point in my code, rather than android runtime. The procedure is to run "adb shell" then kill the application (use "ps" to get the PID, then "kill -9 PID_NUMBER") then check "adb logcat" and send me the stack trace if it's useful (check for class names within com.settlers.) If this doesn't make sense, don't worry about it.
Thanks!
