Sector 2.3 has been submitted to the app store. This fixes the cause of the main crashes in the app - memory usage and multithreading.
The mapping code has beein completely re-written to draw the map much more quickly and efficiently, using far less memory. This means the map will display more quickly, you’ll be able to scroll more smoothly, and the app as a whole will be more stable and less likely to crash. I’ve also taken the chance to tweak some of the presentation of map elements, to make things closer to canonical Traveller maps whilst still retaining the high level of information density unique to Sector maps.
The calculation of trade routes was also a cause of bugs and crashes, and this has been cleaned up. There should now hopefully be no crashes cause when the app calculates trade routes between systems.
26 Oct 2017
Sector version 2.2 will be hitting the App Store today. With this update, I’m happy to say that I’ve completed all the main features I wanted to support when I started this project.
You can now import and export sector files - export options include text based listings, and best of all PDF. Now you can share a PDF of your game map with your players!
I hope you enjoy it, and don’t forget to leave a review!
17 Oct 2017
I’ve started working on a few new features for Sector. First up, something that I think people will be very happy to see:
If you’re a Traveller fan, you’ll probably recognise those names - they are worlds from the Spinward Marches, one of the most iconic sectors in the official Traveller universe. That’s right - Sector will soon be able to import standard format sector files!
This means you’ll be able to import the map for your existing Traveller campaign right into Sector. I’m very excited about this feature!
One thing to note is that the import process only supports the main information fields - some of the additional T5 data is proprietary and not part of the Traveller SRD. Sector will import the hex location, name, UPP, travel zone and 3 digit ‘population, belts and gas giants’ data. Anything else above that will be procedurally generated - most notably trade routes. The import tries to be as flexible as possible, so as long as these fields are present in that order in the data file, it should work.
Trade routes do take into account the usual factors, as well as the ‘importance value’ if that’s present in the import data.
The other side to import is export. This is less important, but I’m hoping to add this too, so that you can export out the full listing of your generated sectors for reference.
I’m still working on ways to create a image or PDF version of the map for export. This is a much requested feature. Unfortunately, it’s technically quite hard to implement with the way the map is currently being generated. I’m hoping I’ll find a solution that allows me to export an image or PDF without requiring me to rewrite the entire way the map is created.
The main problem is that Sector uses a lot of views to create the map - so many that it actually has to be a bit sneaky and does things like unload hexes that aren’t visible on-screen. In order to generate an entire sector or even just subsector map I’d have to load lots and lots of hexes at once, and doing this without crashing the app with an out of memory exception is quite challenging.
The approach I’m hoping to take is to instead render each map hex into an image, and use that to display the map. This will reduce the memory overhead immediately by something like a factor of 10 or 20. This should also greatly speed up map scrolling, and possibly also allow me to zoom the map right out instead of restricting it as is currently the case.
I hope you’re enjoying the app - keep on Travelling!
23 May 2017
At the end of March 2017, NASA published a new website for searching their entire, consolidated image archive. Along with this, they also published a new public API that allows access to the search engine.
Being a native app developer, I naturally started experimenting with writing an app to search this API. It also helped that the web app was pretty crummy.
Couple of weeks later, and I launched Endeavour as a free download on iOS.
I’m pretty pleased with how it turned out, although there are still some tweaks to make and things to add. I went free-with-ads as opposed to paid-download because I’m competing directly against another app from NASA themselves, and that’s a hard sell. Interestingly, though, it doesn’t seem as if the NASA app has been updated to use the new API, and it actually returns far fewer images for the same search terms.
I also think my app offers a better experience, as the NASA app will just leave you at a black screen with no progress indicator while it downloads a full size image. I took a different approach to this: I take the existing thumbnail you’ve already downloaded, and display that while the full size image is downloading. Then, when the full size image has been fetched, I transparently replace the thumbnail version with the full size one - the only thing the user notices is that the image quality suddenly increases.
There’s a huge wealth of incredible photography available to view - from the very earliest unmanned probes and early manned missions, to the very latest photos from Pluto and Saturn, as well as tons of launch photos from the shuttle era.
To date, downloads have been disappointing. I’m not sure of the reason for this - I’ve promoted it in a few obvious places, and it’s free to download so I would have expected a higher number of downloads.
Please download it and enjoy exploring our solar system and beyond!
23 May 2017
Sector - adventures in procedural mapping
Back in 1988 I was studying for my computer science A-level. At the time, this meant writing relatively simple apps in BBC Basic on the BBC model B computer. Things weren’t going so well, because we were quite distracted in class by a game someone had copied - Elite.1
In Elite you played a space ship captain, flying between space stations in different star systems, trading to make a profit and fighting off pirates - all rendered in groundbreaking 3D line graphics. But what was really amazing to me wasn’t the graphics or the gameplay, it was the sheer amount of game that had been some how squeezed onto an 880KB floppy disk.
There were eight galaxies of 256 different worlds you could fly between. Each had descriptions and names, and active trading markets. You couldn’t fit that much content onto a disk that small. How did it do it? Was it using some kind of compression? No.
The secret to this magic of course was procedural generation. Instead of storing the details for every world, the game stored rules about how these details could be generated on the fly. When the game run, the galaxy was created in memory there and then. When you visited a star system, the worlds and stations, names and commodities were generated on the fly as you hyperspaced in. And although based on random generation, computers will, given the same started ‘seed’, generate exactly the same details every time.
The idea that entire, complex structures could be generated from a simple set of rules fascinated me. It turns out it wasn’t exactly a new idea. Another space game was already using this technique to generate entire galaxies of stars and worlds. This game, however, used dice and paper : Traveller.
Inside this collection of ‘little black books’ you could, with the help of nothing more than a sheet of paper a pencil and a couple of regular 6-sided dice, roll up vast ‘sectors’ of space and populate them with worlds and cultures of your own creation. The only drawback was the time it took - but I remember spending hours rolling up subsectors of worlds just for the fun of it.
The results were plotted onto a hexagonal grid map that ended up looking something like this:
Several years ago I started playing around with a web app to generate sector maps automatically, using the rules encoded in the various editions of Traveller. The script I build in Ruby used ImageMagick to draw the maps, and running on a G5 Mac Pro took several minutes per subsector (a maximum of 80 worlds). Nevertheless, the images it produced were pretty attractive:
I embellished the standard maps with colour - using the colour of the world to indicate the surface type, and the border of it to indicate it’s atmosphere. I also added icons for various bases and travel codes (additional details you generate for a world, a kind of short hand saying if the place his rich or a desert or a garden world, etc).
Although the project languished after that, I still retained a fascination with procedural generation and mapping. Years later I decided to revisit this idea, and see what I could do with current technology.
Sector is my Ruby Traveller mapping app brought up to date and build for iOS. It’s been completely re-written in Swift 3, and running on the latest devices it will generate an entire sector (that’s 16 subsectors of 80 hexes) in an instant.
In the years since I wrote the original Ruby code, Traveller has been published in an open source ‘System Reference Document’ - and this is the basis of the rules that Sector uses.
In addition to the basic mapping and colour coding, Sector also draws in ‘trade routes’ - lines of communication or commerce between the worlds. This gives more context to the map, and you can get some idea of the relationships between the worlds. It also generates names for everything - the worlds themselves, and also the clusters and voids that exist on the map are named. Names are created based on a dictionary of real English worlds as well as place names from around the world, so the generated worlds have names that at least sound familiar and pronounceable.
There are still things I’d like to add - printing out the map or sharing it as an image are top of the list. But, as it stands I’m very pleased with the result, and it was a fun project to work on - even if I never want to see a hexagon again!
You can download it on the App Store
12 Feb 2016
iPad can’t replace my computer, but I don’t care
There’s an assertion doing the rounds lately that the iPad can’t replace your laptop. Well, for me that’s certainly true : I need a Mac to do my job.
As an iOS app developer, when I sit down to work it’s invariably and necessarily in front of a Mac. MacBooks seem to be the favoured weapon of choice for developers of all persuasions these days, but I personally work better at a desktop machine - so an iMac is my preferred tool. App developers need a Mac because Xcode - the tool for building Mac and iOS apps - only runs on Macs. Other powerful tools compliment this, the Unix command line, GUI clients for source control, and design and graphics apps - making the Mac a productivity powerhouse.
But any time I’m not ‘working’ at app development, I pick up my iPad. In fact, I’m writing this on the train using my iPad. I haven’t bothered to connect to the slow on-board WiFi because the iPad has it’s own 4G connection. I’m typing as fast as I can on my laptop because I’m using the Smart Cover keyboard1.
I work away from home during the week, and usually pack my iPad and my personal single port MacBook (I have a work-owned machine that I use during the day). But I rarely, if ever, crack open the Macbook. The only times I turn it on are when I need to do some coding on my own personal apps, and the odd occasion that some task really require the additional flexibility that Mac OS offers. But those times are rare.
Not only is the iPad a capable productivity and entertainment device, there are things it does that the Mac can’t hope to compete with. Start listening to music on your AirPods, and chuck the iPad in your bag and head out. Guess what - the music keeps on playing. Try that on a Mac. Want to sketch out some ideas? Pull out the Pencil and fire up Linea (or on iOS11, just tap the pencil to the screen and start drawing).
My default machine is the iPad. It’s the thing I reach for when I want to write and email or a blog post, browse a web site or read the news, watch a movie or listen to music2. I only defer back to the Mac if I hit some roadblock where I know I could do the task more easily on a Mac.
Don’t get me wrong - I love the MacBook too. It’s tiny and lightweight, and has a great keyboard and screen. But I think it might be the last MacBook I own. In future I think I’ll stick with an iPad for portability, and a desktop Mac for work.
So for me, I couldn’t completely replace my Mac with an iPad. But - like any developer - I’m an outlier. For the majority of people and iPad can, and does, excel as their only computing device.
28 Jan 2016
Xcode - the developer's worst best friend ?
David Barnard posts a thoughtful piece about how Apple shapes the The App Store as an Economy.
It’s mostly spot on, but this off the cuff comment was a little harsh:
Tooling - It may seem far fetched, but the capabilities of Xcode shape the App Store economy. By pushing interface builder and auto layout, Apple has encouraged developers to build universal apps and made it more cumbersome to build separate iPad/iPhone apps. Bugs, crashes, and other deficiences of Xcode likely cost developers millions of hours of productivity each year, which has obvious implications for the App Store economy.
I think it’s a little egregious to claim that ‘millions’ of hours of developer time is wasted due Xcode bugs, crashing and other failings. I use Xcode for a minimum of 8 hours a day as part of my job and I don’t recall the last time it crashed on me other than maybe when switching git branches that altered the project file in a major way.
It Xcode perfect ? No, of course not. I can list a number of things I’d like to see urgently - not least real refactoring tools and a better debugger (and the list goes on…)
But I think we have to also acknowledge the huge amount of time and effort that Xcode saves developers. Apple’s big push to use Autolayout has undoubtably saved me tens, even hundreds of hours personally, and new features like
UIStackView will continue that trend.
Xcode’s recent improvements to units test support has also been a big benefit, encouraging developers to write tests and keeping them informed about their testing history. UI test also got a huge shot in the arm with Xcode 7.
I know that Apple know that developers have a love/hate relationship with Xcode. But they are obviously working hard on improving the tooling and the results are bearing fruit. I think the perception that Xcode is a buggy, crashy nightmare is at least a couple of years out of date.
What do we want ? “Better tooling”. When do we want it? “Yesterday” ! But in the meantime, Xcode actually does a pretty decent job.