The mindless ramblings of a Software Engineer.

As some of you probably know, I finally managed to pick up Skyrim a few days ago. In fact I was one of the sadcases waiting for it to be unlocked on Steam at around 1am on Friday morning. I played it for a few hours after that point, but then had to set aside the rest of the day for various social obligations. On Saturday morning, however, I managed to get started on it properly – whilst, it has to be said, battling the mother of all hangovers.

Initial impressions were good – the NPCs do seem to have risen out of the uncanny valley to a certain extent – conversation feels much more natural, they have the ability to multitask whilst still maintaining a conversation, and the chatter is much, MUCH more varied and intelligent compared to the previous game’s efforts, which inevitably boils down to the same repeated lines about Mudcrabs and Oblivion gates, much like a broken record.

As for the scenery – it really is astounding. There are some truly stunning vistas that you’ll see throughout the game. There are also a lot of new enemies and monsters to deal with, and most of them seem to fit in with the whole ‘frozen north’ theme; wooly mammoths, walruses, bears and wolves to name a few of the more mundane sights, to say nothing of the trolls and giants – or any of the mid-to-late game mobs. Some will be familiar, though; our old friend the mudcrab is as persistently irritating as ever (although he does have a new trick up his…shell), and of course there are your standard elemental Fire, Frost and Shock atronachs, various Daedra and so on.

Another plus point is the new combat and magic system. The concept is fairly straightforward; you have two hands, and you can use both of them for pretty much whatever you want. Want to dual wield a shortsword and a dagger? Sure. Or how about dual fireball spell? No problem. You could even try the more pedestrian combinations of sword and shield or two-handed weapon if you prefer. In any case, it’s vast improvement over the previous game; everything feels very fluid and easy to control, and the animation is brilliant.

However, as with any Bethesda game, there are some down sides. And the biggest, most glaring one of them all – for the glorious PC gaming master race, that is – is that Skyrim was clearly developed pretty much exclusively for consoles, and then ported to the PC as an afterthought to appease the masses. I mean, I’m not exactly surprised – after all Oblivion was one of the release titles for the Xbox 360 and Bethesda made no bones about it being a console-driven title, but the new game just feels awkwardly obtuse in certain places. Take the inventory system, for example. In Oblivion it was extremely well thought out; everything was neatly ordered and categorized and you had a number of sorting and filtering options to make dumping loot extremely easy – plus it worked just as well on a console as it did on the PC. Skyrim’s entire menu system, however, is all to hell – there are no sorting options anywhere to be found in your inventory, and the quest log has now been moved to  a completely separate area. Usable on a console? I would hope so. On a PC, with a mouse and keyboard? Not so much.

The world map has also been overhauled; now instead of the tried-and-tested parchment-effect map it’s just a zoomed out 3D projection of the entire province, complete with terrain and weather – the whole shebang. Now, I don’t know about anyone else but for me the usefulness of a map is directly proportional to the amount of land that is visible on said map – which, on a typical day in Skyrim, is not a great deal, what with all the snow and the cloud. There are also no clearly defined markers between territories (or ‘holds’ as they are technically known), and since any bounty you have is hold-dependent you might find yourself accidentally venturing into the wrong one – and paying the price. Instead, you’ll have to use the map markers for any cities, towns or dungeons you discover as reference points. The custom waypoint marker is also fairly useless; it might let you place one vaguely near where you want to go, it may not.

There’s also the issue of bugs – in the ~28 hours I’ve played so far, I’ve experienced at least 10-12 CTDs, and almost as many texture bugs and general glitches. But, as I said – this is a Bethesda game, which are by definition horribly unreliable at launch. No doubt some patches will be released in the coming weeks and months to address these issues as they are raised by the community, but for now it’s still a bit of a bug-fest.

So to summarize: I like it. It’s extremely fun, the quest lines and back story are engaging, the combat is brilliant and the scenery and environment is…forgive me for using the word…epic. It is, however, not without its problems.

I’m on a roll, it would seem.

This is a route planning application for the London Underground. Its sole purpose (other than to help clueless people such as myself work out which train to catch to get to work) is to prove – if only to myself – that all those months of graph theory lectures at University were not a COMPLETE waste of time.

The dataset that it uses to calculate routes can be found at this FOI request page. Essentially, the idea is to pick whichever route has the shortest travel time, depending on the time of day, without making TOO many changes. To do this, I’ve written an implementation of that old chestnut, Dijkstra’s Algorithm. Remarkably elegant way of solving graph problems, and reasonably efficient too.

At the moment it does have a FEW bugs, which I suspect are caused by some glitchy data which I had to painstakingly convert from the Excel spreadsheet in the link above to a set of SQLite tables – no doubt I’ve fouled up a few foreign keys somewhere, so I’ll have to look into that. Once the bugs are ironed out, I may well integrate the whole thing into my other Tube application and push out an update to the Android Market. Until then, watch this space.

Well, it’s a busy time of year (hence my lack of updates), however now that I’ve completely finished my work on AndronTime, I thought I might speak briefly about the final stages of the project.

A few weeks ago I finished the final documentation and project report for the application to the tune of 80 odd pages and about £20 in printer credits and binding fees (much to my irritation), so with that done the only hurdle left was the project presentation and demonstration, which I had a few days ago.

It actually went very well! I arrived about 10 minutes early, along with the only other student booked to present his project in the same session, and spent most of the time trying to get my laptop to connect to Brookes’ recently “improved” (read: broken) wireless network, and then work around a known bug in the version of ADT that I am using which handles GPS data from the emulator console to only a few decimal places; the upshot of this is that if you pass in a perfectly valid latitude and longitude to the Android emulator, it may actually think you’re anywhere up to 1 kilometre from the position specified, which made preparing the GPS functionality demo particularly tricky. However, I managed to coerce it into co-operation for a few minutes, which was all the time I needed. The assessors all looked suitably impressed, particularly my project supervisor, and I even managed to get a round of applause at the end.

Okay, okay, I’ll stop blowing my trumpet, but I have to admit – it’s a nice feeling when something you’ve been working on for a not-inconsiderable period of time pays off. I won’t know my actual grade until the results are released along with the exam marks, which won’t be until some time in June, but I do have high hopes.

AndrOntime now works in a new and – in my opinion – better fashion. With the old application, searches were done on-the-fly – that is to say, we had no idea whether or not we could return any results until we queried the OxonTime servers. This is now no longer the case.

Now, the first time AndrOntime is installed, it will download and process information for ALL bus stops and store it for future use. This means the only things it now pulls ‘live’ are bus timetables and service information. You can see it in action below:

The AndrOntime update feature in action.

I mentioned in my last post that I was going to implement this functionality with SQLite. As it turns out, however, it’s actually a lot less hassle to serialize all the information to a file, and load that file on startup. Now I know that I mentioned in an earlier post that Serialization is nasty and slow and horrible, especially on Android – and frankly, it is – but that said, it turns out that adapting my data structure for use in SQLite wasn’t exactly a walk in the park, so I was literally stuck between a rock and a hard place. And to be honest, as long as you’re not passing data between activities, Serialization is a perfectly sensible approach.

The application does now have a small load time on startup (somewhere around 5-10 seconds, depending on the speed of your device) during which you are greeted with a ‘Please Wait’ dialog. Once the initial load period is over, though, almost everything else is practically instant. Looking up NAPTAN codes is now done in seconds, as is a manual area search. The only remaining wait times are when looking up ‘live’ data such as timetables; obviously it doesn’t make sense to serialize these along with everything else as they change so frequently.

So now the only thing left to implement is a Bus information view and I’m pretty much finished, aside from the inevitable bugfix here and user testing there. Once those are taken care of, I can move on to the several thousand word (not sure exactly how long it’s going to be) final project report. Fun times ahead.

I’m still not exactly sure what the endgame is for AndrOntime once it’s finished – or perhaps I should say, once it’s a ‘Release Candidate’. It’ll definitely be assessed by the University and it’ll fulfil its job in that regard, but I’m uncertain as to whether I should release it publicly or not. I’d definitely need to consult with OxonTime first, and a commercial release is almost certainly out of the question, but I’d have no qualms uploading it for free on the Android Market – provided, of course, that OxonTime do not disagree. It’s their data, after all.

On a somewhat related note, I’ve just started a module at Uni in – what else – Mobile Software! And guess what platform we’ll be developing on! At least I can be fairly certain I’ll have a decent grade in the bag for that one.

AndrOntime finally becomes useful!

I’ve managed to cut down on HTTP requests (and therefore, marginally reduced the prospective user’s mobile data budget – every little helps) to the point that the application will only get stop data for the subset of areas that the user searches for. Furthermore, it does not look up timetable data for a stop until the last minute, otherwise the user would face a noticeable wait time while the application populated timetable data for every bus stop that their search results encompassed. This has the additional benefit of ensuring that the timetable data for a stop is always up to date when it is requested.

Still on the to-do list is data about the buses themselves – how many are in a given area at any time, their current positions and which way they are travelling. I’m not sure how useful this data will be on a day-to-day basis (I may end removing this feature from the final build if it seems unnecessary after testing), but it’ll be an interesting exercise anyway.

In any case, it’s certainly now at the point that it would be of some use to Joe User who just wants to look up bus times. Plus, I’ll be returning to Oxford tomorrow, so I’ll be able to give it a proper field test whilst on the way back to my flat.