Looking around for some Southern Railway bits and pieces, I came across Southern Posters, an excellent collection of exactly that.
Great stuff!
2 March 2010
Route optimisation
Switch is a great utility for making curved rails, as well as sets of points. If you can make your own textures, you can also make your own custom rails.
But it's not always the most efficient tool, because it works by dividing the 25m long rail object into 5m lengths. Try this:
Using Switch, make yourself a straight track piece, then compare the coding in that with this straight rail object. You should be able to work out for yourself how you could modify Switch's straight track to use just nine faces as in this example. You can also simplify your file down to call textures and faces as efficiently as possible. Notice how my example uses the face2 command to help to reduce the overall file size.
Now all this was far more important four or five years ago, when most of us were on dial-up t'interweb connections. We had to keep files sizes down otherwise people simply couldn't download our routes! Also, computers were slower; hard disks were smaller and hence storage was limited; and photo-real textures were few and far between, because the file sizes were too big. There was a phrase being bandied about in the BVE world then: "route optimisation." I never got anyone to tell me exactly what they meant by it; but it seemed to mean this:
- Code was kept to the minimum, using things like the face2 command to minimise hand coding; doing things like only calling a bitmap once in an object file, but using the vertices to place it correctly; compromising on photo detail to get acceptable bitmap sizes; removing all redundant code from routes (comments, etc) before publishing them.
This is one reason why I think that RouteBuilder never really took off as a route building tool. The established developers realised that the coding it produced was sloppy. Sandford Mace even went as far as producing a RouteBuilder Cleaner utility! For example, when I finished the first version of Tyne Valley from Carlisle to Sunderland, built largely using RB, I ran it through Sandford's Cleaner program, and it stripped out more than 50% - that's right, more than half! - of the code as unnecessary! In the "dial-up days", this was very significant!
Then there was the frame rate problem. The computers we've got here at home are fairly adequate home/office machines, probably like many other BVE users. Even adding a decent graphics card meant that the machine I use rarely gets more than 20fps out of BVE 4. The more faces you ask BVE and your graphics card to display, the slower it runs. Again, this was a major issue four or five years ago, so the better developers realised that you should "optimise" your route so that BVE was using as few faces as possible, to keep the frame rates up. So that meant that, as new utilities came along, some of them weren't welcomed as much as their developers might have hoped. There was one which generated tree arrays, which looked beautiful; unfortunately, each tree used four faces, and users tended to pack rather more trees into 25 metres than nature does! So a beautiful array of, say, a dozen trees, used 48 faces, requiring BVE to display 288 faces in a 600 metre length. Then the trees uses photo-realistic bitmaps, placing great strain on PC resources as computers and graphics cards struggled to manipulate them all!
I think that Switch is actually a very good utility for producing curves, switches, diamond crossings, and slips. However, its major drawback is that it isn't able to do the maths for a switch where your diverging rail doesn't clear your running rail inside a 25 metre or 50 metre length. It will attempt to do the maths, creating thousands of potential faces. When you try to view it in Structure Viewer, it will throw up thousands of errors, possibly freezing your machine. The way Switch attempted to overcome this was to enable the user to create Switch objects longer than 25 metres, for example, a 75m long object built between +25 and -50 metres long on the z axis. I've done a few quick tests, and this seems to work well with Switches of 25, 50 and 75m length, but not at 100m. Also, the number of faces it's drawing is increasing dramatically, as it works in 5m length sections. You could, of course, careful examine these Switches, and change any straight areas to single faces, thus optimising the number of faces called, but it doesn't make a huge difference.
Which is where the developer's real art comes in - the art of compromise! We must compromise between reality, the capability of BVE, and the capability of the user's computers to produce something that works.
With the exception of high-speed lines, there are very few exceptionally long sets of points in the UK. Have a scout around our railways in Google Earth - most crossovers seem to have a length between 40m and about 100 metres. So, my compromise is that I will usually only build points using two 25m or two 50m sections, so all the crossovers in my routes are either 50m or 100 m long. My other compromise is that I usually place my rails 4m apart - slightly wide for the UK, but I believe its a European standard - which means that to cross from one rail to another one half of a set of points must deviate from my running rail by two metres. And at this deviation, Switch works well, the route looks acceptable and the number of faces required does not place a burden on the users PC.
With regard to distances of things from the route: A mistake I made originally was to use fences and other objects that were supplied with RouteBuilder. These fences were placed far too close to the rails. I've since learned to use my eyes! Railways use more space than you realise - the way is often quite wide - so don't feel the need to crowd things in...
Now the modelling benefit of this is that the further you get away from the cab, the less detail you can see. In fact, you rarely need "proper" 3D objects at all - flat ones will usually suffice. I've used this technique to create a "townscape" in Hartlepool - it looks like the rear of buildings, but only uses single faces. So you might want to think about doing something similar on the approaches to your towns.
Apologies for the lengthy post and the history lesson, but actually I think route optimisation is quite important. It doesn't take much for us to get bogged down in providing lots of detail - but I fear that some developers end up wasting too much time on this, because if no one can either download or run their works of art, what's the point?
1 March 2010
On being organised
I was asked recently how I organise myself for a route developing session, and thought I'd share that here.
Planning is important and I'm trying to do more of it electronically rather than on reams of paper. So when I'm route building, I usually have at least these windows open on my pc:
Google Earth
BVE with the route loaded, in windowed mode
Notepad with the route file open - this is where I'm working
A second instance of Notepad, with a copy of the route file open, being where I was up to before I started building today. I keep this open so that I can see the object indexing without having to scroll back up to the top of the file.
Adobe PDF reader, because I'm fortunate to have pdfs of the five-mile diagrams I'm working from
A digital version of the OS maps for Northern England and Central Scotland. While it's good to use Google Earth to identify features, embankments and cuttings sometime look the same, whereas the map uses different symbols.
That's six windows...
Sometimes I also have the Complete Circular Arc Calculator open in a window to allow me to calculate curves from measurements.
Handy on my desktop I have shortcuts to route folders and object folders, so I can get to them quickly as required.
On the desk in front of me, I have print outs from the digital map which I took with me on field trips, covered in notes, in a plastic binder. I have a scribble pad, a pencil, an eraser and a calculator. To hand is a file containing other stuff I've printed out over the years, the most-used pages being the BRSigs guide and an RGB color chart.
Oh, there's also a mug which I refill with coffee every two hours!
If I'm object building, I'll have the pc folder containing my original photos open, plus Google Earth for measurements and positioning. Structure Viewer, obviously. I'll plan in my mind how I'm going to use the photographs and how I'll place the resulting bitmaps. If the photo just needs trimming or finely rotating, I'll do that in Irfanview; if it needs stretching or warping, I use DTP software to tweak the image and export it. I can usually visualise in my mind where the faces are going, so can quickly type / copy and paste the code. Sometimes I open a second instance of Structure Viewer, and in that one I'll place the object I'm working on together with adjacent objects, such as track and ground, to check that the object will look right in context. Then I'll place it in the route and reload BVE (which can take quite a while on a long route) to see what it looks like.
I haven't yet come up with a "standard" way of arranging the content of an object file - how I put stuff in it depends on how complex it is. I build the main features first - for example, a signalbox's four walls. Then I'll add the roof. Next I'll construct the steps, but by now the file is getting quite long; so, if I add, say, a chimney, I just type it in somewhere where I can check the coordinates of it along with the roof. So when you look at one of my object files, it looks as though I'm not particularly well organised or disciplined! That's why I tend to leave commented-out notes in the file describing what's below. Similarly, if I'm modifying existing objects, I tend to leave all the code in the file, just commenting out those faces I don't want to use on that occasion. Messy files, yes, but so much easier to modify again later...
11 February 2010
Spot the difference
Sometimes it's worth reminding ourselves that, really, BVE developers are 3D model makers. Take, for instance, the BVE object of the Optare-bodied DAF SB220 bus in Northumbria Motor Services livery. When guillyman emailed me the finished object back in September last year, I just couldn't help plucking my Corgi Original Omnibus model of the same vehicle from my display cabinet for comparison:
Top: Corgi model; Centre: my photograph of the real bus; Bottom: BVE object
Frankly, I think guillyman has done a better job than the diecast modelmakers! The rear end of the Corgi model is too chunky, and the front end just hasn't captured this unique style the way guillyman did. They didn't apply the name transfer in the correct position, and the logo is too long. And the modelmakers didn't attempt the wing mirrors either!
(Some years ago, I met the Northumbria marketing guy, and asked him about this livery. He said that they had briefed a design company in the Midlands, and had said: "Anything you like, as long as it's NOT National Bus Company green!". (You may recall that insipid, murky green that NBC used - Green Line received it - horrible!). Despite the fact that the Northumbria livery doesn't appear to follow any of the bodylines on any vehicle it was ever applied to, somehow it's both striking and appealing - which is more than can be said for either Stagecoach's present or original livery! Who in the industry would ever have considered painting their buses in GREY, red and white?)
If we ever needed evidence that guillyman is probably the UK's leading BVE object modelmaker, then this is it. If you still need convincing, download the model and take a look at it for yourself.
10 February 2010
Points on curves
Pointwork on curves can be difficult to implement convincingly. I must admit that, generally, up to now I've put all my crossovers and junctions on straight sections. However, recently I've worked hard at being able to place points on curves. Here's a screenie from my forthcoming Durham Coast route:
Clearly, the track is on a curve and the pointwork looks curved too.
Recently I realised that there are three ways in which you might build a junction or a crossover. The first is to not bother with point objects and just have curved rail objects between the two rails - this was how it was done in the past, and it doesn't look good, as you get z-fighting (flickering) where the objects overlap the track. The second way is to use Switch to build a switch object, then where you want to place it you swap your rail to a null (empty) rail type, place the switch as an object, then swap back to a visible railtype thereafter. As Switch doesn't make trailing points, you have to attach your point object as a freeobj at the next 25m length ahead, and rotate it through 180 degrees. The advantage of this method is that a left-hand facing point (with travel straight ahead) can, when turned, can be used as a right hand trailing point, thus halving the number of objects you need for pointwork. This was the method used by the RouteBuilder program.
The third way (which I only realised late last year) is to actually use the switch object as a railtype, rather than using a null rail. This makes route coding more straightforward, especially for facing points, but it does mean that you need to make proper trailing point objects. You can do this quite easily - you make a left hand point in Switch, then open the object file and add rotate and translate commands to rotate the object and move it 25m ahead (thus preserving where it is in the z axis after the rotation). For a straight section, the rotation is through 180 degrees; for a curved switch, you need to adjust the amount of rotation, but the file header will give you some clues!
Here's an example of a gently curved (radius 2000) switch rail object for you to see how it's done.
Now, back to the screenshot.
The curved trailing points from the crossover on the running rail on the left have been made in Switch. I know how far apart my rails are, so I know how much they must deviate by, and they've been rotated properly. But as for the trailing points forming the other half of the crossover, on the parallel rail, I've cheated and used a straight set of points, because travelling at speed they quite simply won't be noticed. And that saved on a rail type.
I've also cheated on the branch ahead - although it's still on a curve, I've used a straight switch type as a rail, because again, it won't be noticed.
I've managed to get away with these cheats because the curve, at a radius of 2000, is relatively gentle. I would probably have made custom rails if the curve had been much tighter.
So there you go. It can be done, it involves a little work modifying objects generated by Switch, but in many cases I think it's worth doing.
(Having said all that, I haven't yet mastered how to make a route which goes through a curved crossover, rather than simply straight ahead!).
25 November 2009
Seaton Carew platform shelter
In olden days, developers only constructed those parts of scenery objects that could be seen from the train cab. The advent of openBVE, with its exterior views, means that developers now try to build 'walk-round' objects, visible from all sides, to improve the openBVE experience.
Because I got on so well this morning, I was able to complete this photo-real platform shelter for my Durham Coast route before lunchtime:
Yes, Northern Rail really do paint brick this colour!
The object is walk-round, using a photo for the blue brick. The rear inside wall is a flat photo, too, although thanks to the shading the seats look as though you could perch on them! The inside side walls are the centre of the rear wall stretched. The side of the roof is a photo, the ground is a tarmac texture from PlatGen to match the platform. Which just leaves the roof undersides and top as simple coloured faces, which I've tried to colour match. The whole object is just 15 faces in all with just three textures. I must say, it was a very satisfying little object to build and I'm really pleased with myself!
So, that left the afternoon free for my cooking (there's leek and potato soup in the slow cooker) and housework.
23 August 2009
Hartington signal box
I spent yesterday afternoon building Hartington signalbox.
Here it is, plonked on my Aln Valley route.
It's interesting that it only took me half a day to do!
(I've even built the "ball and finials"!)
13 January 2008
The things you miss...
A selection of screenshots from ECML:Northumberland of things that you'll miss when you're going at speed...
As you leave Newcastle, the Tyne and Wear Metro rises on an elegant viaduct then sweeps away to Byker.
Detail of former goods shed building at Cramlington.
Morpeth's southbound platform..
The southbound platform and shelter at Acklington.
The1960s signalbox at Belford had its upper floor removed.
Crossing keeper's cottage (behind) with the cabin in the foreground. The crossing was formerly interlocked with the signalbox at Smeafield.
The base of the former signalbox at Beal, hidden away behind a portacabin. It looks rather remote from the track now, as the track was slewed eastwards in the 1970s to ease the curve.
I use Google Earth to check distances when I'm route building, and couldn't help notice that someone has cut this message into the grass field beneath the Royal Border Bridge at Berwick.
17 October 2007
WORKING SMARTER
I'm always looking for ways to work faster and smarter with BVE 4. One of the things I find annoying is navigating through the directory structure to open a route to run it.
My BVE 4 routes are all in the default locations, that is, c:\program files\mackoy\bve4\railway\route\route folders\. When you open BVE 4, you're presented with the route folder, and must navigate through them to find the one you want.
I've tried putting shortcuts to each of my favourite routes on my desktop, but I don't like all the clutter that causes. I've tried putting shortcuts to them all in a folder on the taskbar, but that adds to the clutter there, too.
Now, I've done two things. Firstly, I've edited my Windows file extension associations. Normally, Windows considers files with .csv extensions to be Excel spreadsheets, so double clicking on one opens it in Excel. Now, Windows automatically opens .csv files with BVE 4 instead. If I want to open a spreadsheet with Excel, I use "Open With...", as described next....
Secondly, I've added BVE to the Windows "Open With..." list for .csv files.
For route developing, I open routes in Notepad, and I noticed that this appears in the "Open With..." list that Windows offers. So, I tried choosing a route, then "Open With..." and found the BVE program, and it opened. Then, the next time I was in Windows, "Open With..." offered BVE as an option in the list for .csv files.
There are a number of ways I can organise the desktop to take advantage of these tweaks. I've got three shortcuts on my desktop to separate route folders: one for Aln Valley, one for Tyne Valley, and one for ECML. That's because I'm in these routes every day. I usually leave BVE 4 in Windowed mode as most of the time I'm developing. So it's one click on the folder shortcut, a double-click on the route I want to run, and it opens; then a right-click on the route file, "Open With" and click Notepad, and the route is ready for editing.
Another useful tip I picked up on one of the forums is that, instead of keeping a separate route file for each of your favourite trains, it's possible to list them all in the Train section at the top of the file, and comment out the ones you don't want. Here's what I mean.... I'm building the ECML north from Newcastle, and I want to ensure that the view from the cab is acceptable from a number of different trains. I've indexed the trains I'm using at the top of the file, like this:
.Folder cl158
;.Folder ONE_class156
;.Folder Cl156_Pro
;.Folder 37901 Empty Steel Carriers
;.Folder HST4
;.Folder Voyager
;.Folder J36
;.Folder BR_Class20
;.Folder Class35
This will run the route with the Class 158... to run it with the Voyager, I simply Comment out the 158 with ";" and remove the semi-colon from the Voyager entry, like this:
;.Folder cl158
;.Folder ONE_class156
;.Folder Cl156_Pro
;.Folder 37901 Empty Steel Carriers
;.Folder HST4
.Folder Voyager
;.Folder J36
;.Folder BR_Class20
;.Folder Class35
Other things I could do would be to make a "Favourite Routes" folder, containing shortcuts to the routes I drive most. A double-click would then open each quickly and efficiently.
Incidentally, before I start a developing session, I usually take a few precautions! Firstly, I make a copy of the file, as a simple back-up, so that if I do something silly, I only lose one sessions' work, and not the lot. Secondly, I open this back-up copy in another instance of Notepad. As I'm developing, adding things to the bottom of the file, I almost always need to refer to what's in the index section, at the top of the file, and having this part open alongside saves a lot of scrolling up and down the file. Finally, I keep these back-ups for a least a few weeks, giving me a range of "restore" points. Regularly, I back up all my developing to a second machine.
February & March 2007
ECML progress
During the spring of 2007, I posted a number of screenshots showing how construction of this route was progressing. I've reproduced some of them here in date order (oldest first).
20 Feb: Alnmouth southbound platform.
20 Feb: approaching Chathill.
20 Feb: Detail of Chathill Station.
20 Feb: screenshot of my model of Tweedmouth box.
11 March 07: A visit to Dunston yesterday allowed me to photograph the bridge parapet so that I could make a more realistic representation of Ellison Road bridge.
20 November 2006
What Makes A Satisfying Route?
I believe there are four elements that influence just how satisfying a BVE route can be: realism, scenery, driving experience and duration.
Realism: By this, I mean that your railway should have the feel of a real driving experience. No UK railway has clear maximum speed of 125mph throughout its length; speed limits vary with the route conditions, so users expect speed limits that suit your curves, and appropriate warning signs beforehand. Dwell times at stations should be realistic, too.
Scenery: If your railway operating environment is realistic, then the scenery should be, too. Digital photography and a vast library of photographic textures available on the web have made building photo-realistic objects and scenery much easier. At the same time, standards have become much higher. Curves look better; stations look more like the real thing! But beware - there are some pitfalls you will need to avoid. Firstly, BVE seems to be not very memory efficient - frame rates will drop dramatically the more objects, with the more faces, you ask it to display. Similarly, load times are affected by file sizes, so when using bitmaps, keep them as small as possible.
Driving Experience: If you're operating environment is as real as possible, and your scenery looks good, next comes the driving experience. (Here, I'm assuming that you're not building your own train, but using an existing one.) By driving experience, then, I mean, does the route feel right? For example, there are very few UK main lines using main line train units that have very large, multi-platform main line stations just three minutes apart. So, if your route involves a main line and main line stations, make them of a sensible proportion and space them accordingly.
Take, for example, the ECML northbound from Darlington to Newcastle (not yet built - a good project for someone?). You leave a large mainline station, drive north on double track for about 15 minutes before crossing the viaduct into Durham's simple two-platform station, then non-stop through Chester-le-Street Station before arriving at Newcastle Central - a journey time of about 30 minutes. On the other hand, my Tyne Valley line includes "all station" stopping trains, semi-fast trains omitting some of the more rural stops, and a diverted non-stop HST!
Duration: In May 2006, I conducted a short poll on one of the BVE forums to ascertain users' preferences. Personally, I like to be able to have the choice of driving, say, about 45 minutes on an "all stations" stopper, or about an hour on a non-stop express; but I also enjoy short, scenic runs such as the ten minutes or so behind the controls of the Oropa tram. Whilst everyone would love to drive the ECML from King's Cross to Aberdeen, in real life no driver does this as a solid duty! Nor do many of us have huge amounts of uninterupted time to drive long routes properly. So where is this leading me? Just to say that you should bear in mind your potential users before you start building your route. The poll suggested that most people enjoyed a game of about an hour in length, but, as I expected, if the mood takes you, then the two and a half hour run to Aberdeen can be just the job!
29 October 2006
Building your own BVE route
BVE is a fascinating hobby. For me, it's one great big train set in a neat little box! However, the community sadly lacks enough people to build routes. I'd love to see all regions of the UK represented; mainlines and branch lines; freight and passenger operations. But for this to happen, we need more route developers.This blog entry provides links to articles about route building, and links to other resources too.Yes, it's time consuming; yes, terrific results cannot be achieved in just days. But you will get the satisfaction of contributing to a growing community!
THE BASICS
There are two ways to build routes. One is RouteBuilder, the other is handcoding. Really, the method you choose depends on how you like to work. I prefer RouteBuilder, because it allows you to scan in a map and "draw" your railway over it. It enables you to draw fairly complex trackwork, then decide which track the train will run on - so it's relatively easy to use different departure platforms from a large station (such as atHexham in my Tyne Valley route). Handcoding doesn't have the same visual tools - you need to make a start, then view your railway as you go, using the Track Viewer option in BVE 4 (or the Track Viewer tool in BVE 2). Yes, you can follow a map or a plan, but you'll need to be mindful of how it relates to what's on the ground.
RouteBuilder allows you to easily change the running tracks - with handcoding, it's more difficult to build route variations. RouteBuilder doesn't support the "bells and whistles" such as UK signalling, or AWS -so, if you want these features, you'll have to manually add them with a bit of handcoding later. RouteBuilder allows you to lay track that's flat very quickly (I haven't tried adding gradients). But for both RouteBuilder and handcoding, the most time consuming activity is adding scenery objects.
Route developing needs not just computing and some mathematics skills; it also needs a degree of artistic ability to help you produce good-looking scenery. A digital camera and a scanner will also be very useful tools.
LINKS:
RouteBuilder Although RouteBuilder development has ceased, it's still a valuable route developing tool!
Dennis Lance has produced an excellent guide to hand coding.
Note: since this article was written, I have since become a confirmed devotee of coding by hand. While RouteBuilder got me interested in BVE development, I later realised that it produces code which, by comparison to hand coding, is very untidy. And as others have pointed out, why learn to use RB when hand coding is relatively simple anyway?
Summer 2006
Tyne Valley progress
During 2006, I posted a number of screenshots showing how construction of this route was progressing. I've reproduced some of the better shots here in date order (oldest first).
25 April: I managed to photograph the 156 set in Leeds-Sheffield Fast livery at Lincoln on Easter Sunday. The set often appears in the North East, so I have modelled it for my route. It is passed here as it crosses the River Wear in Sunderland. The model has since been rebuilt.
29 April: I've spent considerable time getting the old station building at Wetheral right. Only part of its original canopy survives. As the station was built before platforms were invented, the building is at ground level.
29 April: the modern shelter on the Westbound platform at Wetheral is alongside a much older sign!
30 April: I've moved on east to Corby, where I've added this terrace of houses, based on the real thing.
6 July: I've had the opportunity to photograph Blaydon signalbox, so it can take it's rightful place on the route.
6 July: It's a shame that the only buildings remaining at Brampton are this shelter on the Newcastle-bound platform and a "bus" type shelter opposite. After all, Brampton gave the world pre-printed tickets. Thomas Edmondson was working here when he devised his system of card tickets.
6 July: At this time there were still a lot of manual signal boxes on the Tyne Valley line, plus a number of manned crossings. At Denton I've modelled the portacabin and crossing gates plus nearby cottage.
6 July: Gilsland, showing the former railway station buildings. Just part of the building group here; across the tracks is a pub and a terrace. Now, I've only got the buildings at Greenhead to do, and that's the major structures finished...
6 July: The former crossing keeper's house and the present crossing keeper's cabin at Lane Head.
VR Magazine
Back in the summer of 2005, I wrote three contributions about BVE for Al Barten's Virtual Railroad pdf magazine. The magazine has since been replaced by a virtual reading room and tends to concentrate on Trainz these days. However, for those who might be interested, here are links to the magazines containing my articles. Follow the links to find the full articles:
Converting Older Trains to Use BVE 4 Timetables
Version 4 of BVE, Mackoy's superb freeware railway simulator, was released in January this year. There's no doubt that it provides a superior driving experience compared to the earlier version. However, to take advantage of many of the improvements, the army of volunteer developers around the world will need to either develop new BVE 4 compatible trains or make significant amendments to their existing work.
Probably the feature that most simmers need is the BVE timetable.
BVE 4 works differently from BVE 2. It uses a bitmap image of the timetable, which can only be displayed in compatible train cabs. So I delved into how BVE 4 works with existing trains, to see how I could resolve the problem to make trains display the timetable.
Riding to Riding Mill
It's 6.20am on a bright, April Saturday morning. The sun has been up for the last 50 minutes, its warmth gradually lifting the last remains of the light overnight frost. Eezypeazy is on his bicycle, heading to Wylam for the early train west along the Tyne Valley.
All You Ever Wanted To Know about RouteBuilder But Were Afraid To Ask
OK, I'll admit it... Until September 2004, I was a train sim virgin. Yes, I'd had the occasional affair with other computer games, and rather more than a one night stand with Train Dispatcher... "but I did not have relations with any of them", as a former world leader might have put it.
But with BVE everything was different. From the moment my fingers caressed the Z key on my keyboard, gently powering a class 43 HST north from Edinburgh Waverley, I knew this was a relationship that was meant to be. As we glided through the Scottish mist across the Forth Bridge, my thoughts had already begun to think of the future... "What about the children, darling?"
A life partnership without offspring would be unthinkable. Yet the BVE birthrate worldwide was relatively low. Outside London, there are fewer than 20 driveable UK routes in existence. Yes, many people were (and are) trying very hard, but this seemed to be a process that could take years, never mind nine months! There was only one thing for it... If I wanted one of my own, I'd have to find out about the procreation process.