|
Sorry I haven't chimed in here in awhile. I am glad that at least a few other Palm users out there might be interested. I think It would be great if whatever we end up with is at least nominally compliant with the checklist Palm wants developers to use. A few issues immediately spring into even my non-programming oriented mind, however. The processing power/RAM of the WebOs devices is pretty anemic compared to all but the oldest personal computers for which current OTTD development is happening. This probably wont be too much of an issue early in the game on small maps, but can we realistically expect it to be as responsive as Palm wants applications to be (starting in 3 seconds etc.) Palm allows for exceptions to this, but OTTD does not currently have anything like a loading screen that might work for this situation that I am aware of.
A lot of the interaction issues may or may not be problematic as far as I can tell. Palm would like specific types of transitions between "scenes", but OTTD doesn't really have "scenes" like this, that is, everything is taking place on the map, so there is no need to try to program a cross-fade to other content. However, given the size of the screens on these devices, it may not be helpful to have several windows popping up all over the place. Ideally, I feel like the smallmap should appear as another card that pops up over the entire screen, and can then be hidden again when the user is done consulting it. This could work well for other large windows like the train list as well, but it would likely require a huge departure from the way OTTD works now, and may well be out of the scope of this project.
The application checklist also addresses saving, and I feel like this could be helpful as well. I think autosave should be disabled by default for the webos version, as the slowdowns caused would be very noticeable, and likely frustrating if the user only has a short amount of time to be playing per session (on a train, in a waiting room). Furthermore, navigating a huge list of autosave files would be a pain on the tiny screen, and rarely helpful to the average casual user. Instead I think it would be best to save automatically when the card is thrown away, or maybe when it is minimized, in keeping with this checklist point: " When the user edits content in a scene and throws the card away, the changes are saved." If the behavior was more like a "save" than a "save as", overwriting the last saved instance of the file, so much the better.
As far as look and feel is concerned, this is where I might be able to provide the most help. Buttons should be at least 48x48 pixels, not for Palm's sake so much as ours, as tapping small small areas can be very frustrating. Does this mean there will need to be new button graphics drawn? If so I am happy to help. Can this be changed in newgrf, or will it require serious patching? If we do decide to seriously rework menus, we should try to nest many of the buttons, so as not to have too much of the screen occupied with buttons.
Current OTTD users already have an emotion investment in the game and can generally put up patiently with a lot of its quirks. Personally I would expect a slow and awkward experience on my Pre, and would just be happy to have a mobile version at all. If we decide to use this as an opportunity to reach out to new users, however, it will likely be necessary to make a serious effort at optimizing the game for the platform insofar as that is possible by a handful of people. Something as simple as having the default map size be very small, and bundling a newgrf of very few, generic vehicle could go a long way in lowering the bar to entry, and maybe improve performance for new users.
Anyway, these suggestions are pretty ambitious, but might be helpful in thinking about whether a polished "app store" approach makes sense for OTTD.
Best,
|
Login
Register
FAQ
Donate
Search
Members
Chat
Didn't think it would be so simple!
