One day I decided that I wanted to put some paper models of the Frontier Elite ships on my shelves. I'm a big fan of the Amiga version because of its flat simple colours. The PC version had textures which felt a bit superficial and noisy. I'm also not a fan of spaceship designs with meaningless greebles (mystery surface details, wings, spikes).
In a way, the Elite ships are designed with the same discipline as the first Enterprise ship (The Original Series) from Star Trek. The Elite ships just engines and a hull, with a pretty smooth outer surface. Since it is up to the player to fill the empty hull of a ship with stuff, an anonymous exterior is quite suitable.
There are some paper models of the Elite ships out there already. There are many different versions of Elite and to my knowledge I'm the only one who have made a set of ships specifically from the Amiga version. (2017 note: This was written in 2006).
The original Elite was ported for many different computers. Some versions (Beeb, ZX, NES, MSX, etc) only rendered a wire frame of the ships, whilst other versions (Amiga, DOS, Arc, etc) drew filled coloured polygons. I don't think there was a consistent colour scheme between the different versions though.
Also, the original Elite might have had much larger ships than Frontier (actually, scaling was inconsistent), and you could only fly the Cobra Mk.III. Frontier is more realistic and in some ways maybe a bit stale compared to the original. In Frontier it is possible to figure out the dimensions of the ships by parking them next to other objects in the game.
My scale is based on the '////50 METERS////' sign over the docking bay, but I did not calculate scales or make the ship meshes based on eye observations. I managed to come over the ship data from FFE - Frontier: First Encounters (Elite 3? 2b?). I'm assuming the ship geometries haven't changed much, if any. I do know that some of the ships looks different in the original Elite though, and that some were... decommissioned. It's a pity that the Wolf Mk.II didn't make it to Frontier.
By looking at the binary data from FFE, I figured out that the 50 meter sign is 114 688 units wide (with left bit shift applied). I use this value to make a scale constant which I then use with the ship vertices to come up with some sort of scale. It seems to work, I've measured the dimensions of a few ships as they fly out of the docking bay, and also with the external camera ship switch trick. My program seems to be doing the scaling correct. However, there are some problems with the official scale which I'll get to later.
Actually, you can somewhat tell that the scaling for the ships are a bit off in the game. Ever noticed how the Police Vipers and the Constrictors are really easy to hit? It's because they are really large compared to their 'internal capacity'. Other ships are a bit too small for their volume and are a pain to nail.
Unfortunately I only have screenshots of two red ships here, but what you're seeing is a Constrictor (top) and an Adder (bottom). The Constrictor is a 120t ship, and the Adder is 55t. The equipment on the exterior of the ships, such as landing gears, can be scaled up to double size by the game engine. However, fuel scopes and missiles are always at the same scale!
You can see the absurd scale difference here if you look at the size of the fuel scoop and keep in mind that the constrictor is just (120 / 55 =) 2.18 times larger (cargo space wise) than the Adder. The Constrictor seems to be over 2 times longer than the Adder, but keep in mind that volume doesn't double with length. According to my (admittedly sloppy) calculations, the Constrictor needs 8 times more space than the Adder to store a cargo ton.
Recently I've been playing Frontier using the winUAE emulator with the JIT CPU boost and I get a really nice and smooth framerate, and the whole game behaves more precise. It seems the game was programmed to take advantage of fast processors. I get a steady 50fps everywhere in the game, no 1-2fps stuttering in police crowds or cities. Since the external camera movement seem to be framerate based it's possible to get much more precise viewing angles with JIT on.
I was planning to do most of the ships, but the scales have given me trouble, and I had to figure out a way to come up with a comfortable folding process. In the end I settled for tabs which slip into slits, but there's still work to be done on bleeding (to avoid white along certain edges).
I've written a program which does a lot of work for me. At first I had it output stuff at a 1:220 scale, but in the end I went for a 1:200 scale where the ships are scaled after their internal capacity (5 cubic meters per cargo ton). I chose this scale simply because it looks right to me. I know there's a 3D program plug-in that can measure the volume of 3D models, but I don't have these particular ships as models, or a 3D program, or that plugin. My solution was to use clay to approximate the volumes. It's not a very accurate method, but it's better than wild guesses and the in game scales, I think.
Unfortunately this mean I'll have to go... 'un-canon', not only with the hull sizes, but also with the add-on sizes (landing gears, missiles, etc). I think in the end it will look better with the scale of the add-ons shared consistently between the ships.
Current Work In Progress file - These ships are in 1:200 scale and 5 cu.m per ton. That is, not the 'correct' in game scale. If you view this file with a browser, most of the stuff will be cropped out. Use an SVG editor. The Viper on there is not of my intended scale and should be fixed.
A rather lousy photo of the ships I've been working on, searching for a good scale.
Update: Dec 27, 2017 : More content at bottom. Still haven't fixed the SVG files.
Update: Dec 22, 2017 : This page is over a decade old. Added new content at bottom. Haven't touched old SVG files.
Update: Sep 12, 2010 : Telia server dead. Changed links to SVG files.
Update: Jan 1, 2010 : Still haven't updated the ship sheets. I did rewrite a bunch of text on this page though, and add a bunch of pictures.
Update: Jul 19, 2006 : No update, I kind of got deterred by the scale problem. The Viper on the 'Work in Progress' sheet below has the wrong size (It should be closer to the size of the Viper on the Viper sheets), and I still need to do all the add-ons (landing gear rescaling etc.).
Update: May 2, 2006 : Quick recap. There's no problem figuring out the sizes of the ships in the game. The problem is that the sizes of the game is misrepresentative of the cargo capacity of the ships. Since the cargo is generic and all ships can be made into trading ships there's no reason for a Gecko to be able to fit a cargo unit in 2 cubic meters whilst the Tiger Trader needs 14.6 cubic meters per cargo unit (see chart at the bottom).
Below is a link to screenshots of the ship purchase view. I think I might have missed a few ships here, such as the Osprey (2017 edit: Added some of the missing ships and uploaded some neat planet screenshots I took back then).
You'll need Inkscape to work with the SVG file. Maybe also the Frontier font? Unless I baked that into an object. I forget. Firefox 1.5+ should be able to display the SVG file, but it will pixelate it and make it fuzzy if you're trying to print it. These sheets are A4 by the way, and the scale is relative to that. I won't upload any highres bitmaps atm. The quality and size of the SVG files is superior anyways. I suppose I could use 'cloning' a bit to avoid redundant data and get file size down further.
I ended up writing my own program because 3D programs didn't do what I want, and they have unintuitive and constipated GUIs. Writing my own program was actually easier than learning how to use an existing one. 2017 Edit: Updated version at bottom of page.
So, here's what my program does. It loads the ship points (vertices, but I'll call them points) from the firstenc.dat file (Frontier: First Encounters). Actually it doesn't, it just uses the vertice data output from a data extractor program Theun over at Jongware wrote (he also provided me with the font). I reformatted the data it so BlitzMax can read it as data a'la Basic style.
The program reads in this data as x-y-z coordinates and flips them to make the ship symetrical and stuff. There's quite a bit of data for a ship, but only the first part has the ship geometry so my program can be set to ignore the rest of it.
I don't actually know any 3D programming, but I've toyed around a bit with Sodaplay and I had this idea of writing an unwrapper where I use lines which all try to be a certain length. I get the length by running a 3D pythagora between the 3D points. It works. This spared me the agony of doing 'trig' stuff. As a side-effect, I can also rotate and flip objects by just dragging them around.
The program also scales the ships properly and 'saves' the data as SVG that can be read by a free vector illustrator program called Inkscape. Before saving it takes a look at the lines and tries to figure out where to put triangles (fill). I also made a little thing which allows me to make male and female tabs.
Huge thanks to Jongware Theun for the work he had done reverse engineering the Frontier data. I was really lucky to be able to get the data (without having to hex around in files) and the neat Bezier line font. Stumbling upon InkScape helped a lot too. SVG was perfect for this kind of thing since it's just text although the XML format does make the files rather large).
Once I've pasted the text output from the program into a text editor and saved as *.svg I can load it into Inkscape. The triangles are grouped so I ungroup (Object/Ungroup), then I select and merge (Path/Union) triangles that are meant to be a quad, pentagram or whatever.
What's left then is colouring, rotating and moving stuff into suitable positions. Adding the ship gear like antennas, landing wheels, reg-id etc. There are a couple of different colour schemes for each ship, and I've tried to mimic what colour palettes Frontier uses, there's often a saturated and dull version of each colour.
I'm using screenshots or my program to eyeball the placements of things on the hull. I could actually use the data from the program here but so far I have no function for aligning those points along with the hull. If I add them into the geometry I might distort the hull shape since the points might not be placed exactly along the hull surface (I'd get a bump which would flatten and thus produce the distortion). In any case eyeballing is sufficiently precise here.
After having assembled a couple of ships it seemed to me like Braben grossly miscalculated the scales of the ships. Maybe it was because he only has a signed char/byte for the geometry, and then left bit shifted that value to scale the ships. This might have made it hard to control the scale of the ships. It's also hard to guess volume.
Like I've discussed earlier, I'm leaning towards rescaling all of the ships based on their internal volume, which can be estimated using the gross mass of the ship. Surface area is important in a combat situation, so I'm guessing that the ships are probably pretty dense when fully laden, maybe 5cu.m per ton (200kg/cu.m). (Unless ton refers more to volume...?)
I made a table below to illustrate what's going on. My values here are Cube ratio and 5 cu.m/ton Length (m). I get the Cube value by making a clay cube, then making a ruler based on the length of a cube side. Then I make a ship of the clay and measure it against the ruler. This gives me a 'density' of sorts. Although the results are rather imprecise, it's still obvious that the ship scales are off.
Although one might argue that nothing is known about the densities of the ships, I think sizes based on tonnage seem a lot more reasonable since they reflect actual performance.
|Ship name||Cube ratio||Gross ton||Volume (cu.m)||Volume/ton||Game Length (m)||5 cu.m/ton Length (m)||Length Difference|
|Viper Defense Craft||2.30||65.00||468.01||7.20||17.86||15.81||1.13|
The length of my 1:200 paper models is naturally Length in meter / 2, centimeters. A 20 meter ship is 10 cm. Below is a table of ship lengths using different densities (cubic meters needed to store one cargo ton).
|Ship name||Cube ratio||Gross ton||1||2||3||4||5||6||7||8||9||10|
|Viper Defense Craft||2.30||65.00||9.25||11.65||13.34||14.68||15.81||16.80||17.69||18.50||19.24||19.92|
Other figures: BBC Elite 1 version manual Length (conversion from feet). Note that BBC ships often look a bit different so it's not a fair comparison. Some values are strange like 12feet/3.7m for Gecko. Elite A lists as 40 feet though, and 12 thick. Many length values are multiples of 5 so I'm thinking they were estimated and not incidental.
There are two disks containing "ship sources" in Ian Bell's archive, but very little info on the contents. After some investigation using the BeebEm BBC micro emulator, I discovered:
*CAT List files (but some are omitted for some reason). *VIEW This is Ian Bell's program for viewing ship files.
However, some files would "view", like the GNAT, but not others, like the ASP-3. Eventually, after some probing with *DUMP, *TYPE, and *LIST, I discovered that ASP-3 is actually a BASIC file, whilst GNAT is likely some form of compiled data.
Keys for VIEW (on my laptop keyboard):
Rotate: zx cv ,. Zoom: SPACE and Key over shift next to return. Move: Arrow keys. End: Pause for a crisp rendering. Pause: Return to prompt.
The GNAT is not a part of the main gang, but I kinda like it. In my mind it flies with the antennas pointing backwards (like the TTA Shark?), but I don't think that is the official interpretation.
BASIC on the BBC micro is tokenized, so *LIST ASP-3 produces a garbled output. To view the listing properly:
*LOAD ASP-3 LIST
Ctrl+N and Ctrl+O toggles page mode. Shift to page scroll. Esc to abort.
RUN Runs the loaded BASIC program.
The ASP-3 program appears to calculate game-engine-friendly coordinates/normals (does not draw anything). More on the output after the long listing below.
BeebEm can export files from disk. One can also make new blank disks and copy files to them for experimentation. To produce a file with an ascii listing of e.g. the ASP-3 onto an unprotected disk:
*LOAD ASP-3 *SPOOL TXTOUT LIST *SPOOL
Then export that file using the the BeebEM menu. I suppose SPOOL refers to putting a spool of paper into a virtual printer which captures the screen output. SPOOL creates a new file on the (unprotected) disk, possibly overwriting an old file if not Locked (L).
Here's some SPOOL output as I got it (after exports). I had to run my line-stripper on it as line-breaks works differently between different OSes. I don't know if the <> characters in the code will do weird HTML stuff. Note that BASIC does not need separating spaces (wasting precious memory).
>LIST 5REM - - - A S P - - - 7MODE3 10Q%=2 15F%=2^Q% 20B%=&6000 40DPT=&18 50MAXLI=25 60P1=22:P2=31:P3=3:P5=8 70GUN=8 120GOSUB1000 140GOSUB2000 200PRINT'" Nodes " 210FORI%=0TON%:PRINTI%,FNR(V(I%,0)),FNR(V(I%,1)),FNR(V(I%,2)):NEXT 211PRINT2*A*S1" "2*A*S2 212REMFORI%=0TON%:FORJ%=I%TON%:PRINTI%,J%,,FNR(SQR((V(I%,0)-V(J%,0))^2+(V(I%,1)-V(J%,1))^2+(V(I%,2)-V(J%,2))^2)):NEXT, 230PRINT'" Normals * 2^";Q%' 240FORI%=0TOM%:PRINTI%,FNR(U(I%,0)),FNR(U(I%,1)),FNR(U(I%,2)):NEXT 250INPUT'"Power of two? "A$:IF A$<>"":Q%=VALA$:CLEAR:F%=2^Q%:PRINT'':GOTO20 260MODE1 300REM Pack Nodes 310RESTORE5000 320W%=20 330DIM W%(N%,3) 340FORI%=0TON%:PROCC(V(I%,0),V(I%,1),V(I%,2),31):PROCB(A0):PROCB(A1):PROCB(A2):PROCB(A3) 350READ A0,A1,A2,A3 370PROCB(16*A0+A1):PROCB(16*A2+A3) 372W%(I%,0)=A0:W%(I%,1)=A1:W%(I%,2)=A2:W%(I%,3)=A3 380NEXT 400REM Pack Node Walk 410RESTORE 6000 414P=18 420B%?3 =W% MOD256:B%?16 =W% DIV256 430READ L% 440FORI%=1TOL%:READ P,B0,B1 442C%=0:A0=FNMATCH(B0,B1):C%=C%+1:A1=FNMATCH(B0,B1) 450PROCB(P):PROCB(16*A0+A1):PROCB(4*B0):PROCB(4*B1) 460NEXT 500REM Pack Normals 520B%?4 =W% MOD256:B%?17 =W% DIV256 540FORI%=0TOM%:PROCC(U(I%,0),U(I%,1),U(I%,2),31):PROCB(A3):PROCB(A0):PROCB(A1):PROCB(A2):NEXT 570B%?6=4*GUN:B%?8=6*N%+6:B%?9=L%:B%?12=M%*4+4:B%?18=Q%:B%?5=4*MAXLI+1:B%?13=DPT 580OSCLI("S.ASP "+STR$~B%+" "+STR$~(B%+W%)):PRINT~W% 600END 900DEFPROCN(I%,I,J,K) 910U0=V(J,0)-V(I,0):U1=V(J,1)-V(I,1):U2=V(J,2)-V(I,2) 920V0=V(K,0)-V(I,0):V1=V(K,1)-V(I,1):V2=V(K,2)-V(I,2) 930W0=U1*V2-U2*V1:W1=U2*V0-U0*V2:W2=U0*V1-U1*V0 940S=SQR(W0*W0+W1*W1+W2*W2):W0=W0/S:W1=W1/S:W2=W2/S 950R=W0*V(I,0)+W1*V(I,1)+W2*V(I,2):W0=R*F%*W0:W1=R*F%*W1:W2=R*F%*W2 960U(I%,0)=W0:U(I%,1)=W1:U(I%,2)=W2 990ENDPROC 1000REM NODES -Put coords into V(,) 1005REM No. is... 1010N%=18 1050DIM V(N%,2),P(2) 1060A=45:WF=.3 1070S1=SIN(PI/5):S2=SIN(2*PI/5):C1=COS(PI/5):C2=COS(2*PI/5) 1080CA=((S2/S1)-1)/2/S1:D=ACS(CA):SA=SIN(D) 1090H1=2*A*S1*SA:A1=A*S2/S1 1092CB=((S2/S1)-C1)/(1+C1):SB=SIN(ACS(CB)):H2=A*(1+C1)*SB 1100V(0,1)=-A1 1110V(1,1)=-A:V(1,2)=-H1 1120PROCROT(3,0,2*PI/5) 1130PROCROT(2,1,2*PI/5) 1140PROCROT(4,0,PI/5):V(4,2)=H2-H1 1150PROCROT(8,1,PI/5):V(8,2)=H2 1160PROCNX(5,2) 1170PROCNX(6,3) 1180PROCNX(7,4) 1190PROCNX(9,8) 1200CY=V(2,1):FORI%=0TO9:V(I%,1)=V(I%,1)-CY:NEXT 1210PROCNY(12,1) 1220PROCNY(10,4) 1230PROCNY(11,7) 1300FORI%=0TON%:V(I%,1)=V(I%,1)*WF:NEXT 1320PROCDET(13,5,1,12,.3,.3) 1330PROCDET(14,5,1,12,.3,.55) 1340PROCNY(15,14) 1350PROCNX(16,13) 1360PROCNX(17,14) 1370PROCNX(18,15) 1400RETURN 1700DEFPROCDET(R%,S%,T%,U%,M,N):LOCALI% 1710FORI%=0TO2:V(R%,I%)=V(S%,I%)+M*(V(T%,I%)-V(S%,I%))+N*(V(U%,I%)-V(S%,I%)):NEXT 1720ENDPROC 1800DEFPROCNX(I%,J%):V(I%,0)=-V(J%,0):V(I%,1)=V(J%,1):V(I%,2)=V(J%,2):ENDPROC 1850DEFPROCNY(I%,J%):V(I%,1)=-V(J%,1):V(I%,2)=V(J%,2):V(I%,0)=V(J%,0):ENDPROC 1900DEFPROCROT(I%,J%,B):V(I%,0)=V(J%,0)*COS(B)-V(J%,1)*SIN(B):V(I%,1)=V(J%,1)*COS(B)+V(J%,0)*SIN(B):V(I%,2)=V(J%,2):ENDPROC 2000REM NORMALS - Put into U(,) 2004REM No. is... 2005M%=11 2010DIM U(M%,2) 2015RESTORE3000 2020FORI%=0TOM%:READ I,J,K:PROCN(I%,I,J,K):NEXT 2090RETURN 2099REM Three Nodes for each Normal 3000DATA 0,8,9 3010DATA 0,2,3 3020DATA 0,5,6 3030DATA 10,11,12 3040DATA 8,9,10 3050DATA 5,6,12 3060DATA 2,3,12 3070DATA 3,4,8 3080DATA 6,7,9 3090DATA 3,8,10 3100DATA 6,9,11 3110DATA 1,2,5 4990REM Four Normals associated to each node 5000DATA 0,1,2,2 5010DATA 1,2,11,11 5020DATA 1,6,11,11 5030DATA 1,6,7,9 5040DATA 0,1,7,7 5050DATA 2,5,11,11 5060DATA 2,5,8,10 5070DATA 0,2,8,8 5080DATA 0,4,7,9 5090DATA 0,4,8,10 5100DATA 3,4,6,9 5110DATA 3,4,5,10 5120DATA 3,5,6,11 5130DATA 11,11,11,11 5140DATA 11,11,11,11 5150DATA 11,11,11,11 5160DATA 11,11,11,11 5170DATA 11,11,11,11 5180DATA 11,11,11,11 6000REM NODE WALK 6005REM No. Lines is... 6008DATA 29 6009REM Pr No1 No2 6010DATA P1, 0,1 6020DATA P1, 0,4 6030DATA P1, 0,7 6040DATA 31, 1,2 6050DATA 31, 2,3 6060DATA P5, 3,8 6070DATA 31, 8,9 6080DATA P5,6,9 6090DATA 31,5,6 6100DATA 31,1,5 6110DATA P2,3,4 6120DATA P2,4,8 6130DATA P2,6,7 6140DATA P2,7,9 6150DATA 31,2,12 6160DATA 31,5,12 6170DATA P1,10,12 6180DATA P1,11,12 6190DATA P1,10,11 6200DATA P2,6,11 6210DATA P2,9,11 6220DATA P2,3,10 6230DATA P2,8,10 6240DATA P3,13,14 6250DATA P3,14,15 6260DATA P3,15,13 6270DATA P3,16,17 6280DATA P3,17,18 6290DATA P3,18,16 7000DEFFNMATCH(J%,K%) 7010IFW%(J%,C%)=W%(K%,0) THEN =W%(K%,0) 7020IFW%(J%,C%)=W%(K%,1) THEN =W%(K%,1) 7030IFW%(J%,C%)=W%(K%,2) THEN =W%(K%,2) 7040IFW%(J%,C%)=W%(K%,3) THEN =W%(K%,3) 7050C%=C%+1:GOTO7010 10000DEFFNR(X)=" "+STR$(INT(X+.5)) 11000DEFPROCB(X):W%?B%=INT(X+.5):W%=W%+1:ENDPROC 12000DEFPROCC(X0,X1,X2,X3):A0=INT(X0+.5):A1=INT(X1+.5):A2=INT(X2+.5) 12010A3=X3:IF A0<0 A3=A3 OR 128:A0=-A0 12020IF A1<0 A3=A3 OR 64:A1=-A1 12030IF A2<0 A3=A3 OR 32:A2=-A2 12040ENDPROC >RUN Nodes 0 0 -18 0 1 0 -9 -45 2 43 0 -45 3 69 -3 0 4 43 -14 28 5 -43 0 -45 6 -69 -3 0 7 -43 -14 28 8 26 -7 73 9 -26 -7 73 10 43 14 28 11 -43 14 28 12 0 9 -45 13 -17 0 -45 14 -6 2 -45 15 -6 -2 -45 16 17 0 -45 17 6 2 -45 18 6 -2 -45 52.9006727 85.5950865 Normals * 2^2 0 0 -69 10 1 14 -65 -12 2 -14 -65 -12 3 0 47 -3 4 0 87 39 5 -10 48 -3 6 10 48 -3 7 118 -127 62 8 -118 -127 62 9 158 91 98 10 -158 91 98 11 0 0 -180 Power of two? Escape at line 250 >*SPOOL
I know FFE scales ships using bit-shifting, which is the power of 2. ASP-3 asks for it, so maybe BBC Elite uses similar scaling. The output coordinates seem to contain mirrored vertices ("nodes"?), unlike the FFE vertex data which I used for my paper models. Looking at line 1000 and forward, it seems like the 0-18 points are generated so maybe the ASP wasn't designed on paper, with points then simply entered. It was probably done mathematically to keep the pentagon faces flat (the Boa and Anaconda has them too).
The program appears to be setting up some directions at 1070 then distancing them out, duplicating/mirroring vertices with PROCNX(source,negativecopy). PROCNY mirrors vertically.
Here I've plotted the vertices from the output. It's clearly an ASP (top view). You can see point 5, 6, 7, 9 being mirrored in at 1060. Point 0 is unique for the top (producing the bulge). This ASP looks very similar to the one in Frontier, though the nose appears to be more narrow.
Additionally, this is not the final ASP design. While trying to figure out the ship format used in Elite A, I found a match for the ASP in ship file SN. The last points for the engine rhomboid didn't match. The in-game ship uses less points there (4<>, not 6<=>). Also, the bytes are not signed. Maybe vertice normals (in byte size degrees) decide sign? Also, the NewKind (C remake) also has that simplified rhomboid engine shape. And a gun on the nose.
I found this version of Elite in Bell's archives. It's a fan update of the original as I understand it, but it includes ships referenced in the novel, so it feels semi-canon. Some of the ships are quite nice looking, too.
An encyclopaedia can be brought up using Ctrl+F6. I made my own disk for the 6502 Tube version, using the files in the archive (2T... I think had to toss out 1F or something to make it fit on a disk). The ship files are called SA to SW, but I've yet to figure out the data format. .INF files are for the emulator (meta info), and are what you point at when you import/export (can select multiple files in BeebEm's file browser). I actually run the BeebEm emulator .exe under linux, which apparently works just fine, except for screen and video capture.
"Dodo" space station. It's not as large in the game, as can be seen when a Python emerges.
Some ships maybe unique to Elite A, just in case someone's interested.
I sort of wrangled some bytes out of the "SA" ship file and figured out sign, then unwrapped with my program and made this sloppy model of the Ophidian. I made a few mistakes during unwrapping but if sort of came together at least. Re-discovered that it's best to score and fold lightly over a steel ruler, and to cut the longer lines with scissors for a better edge. This unfortunate ship is featured in the opening chapter of the "The Dark Wheel" novel.
The Archimedes version of Elite is apparently well regarded, but it has almost no online presence. The boxed game came with neat data cards covering most (but not all?) of the ships. I thought it would be cool to generate paper models using the source files (C) that I found in Bell's archive, but ran into asymmetry trouble (points 8 & 7). Perhaps these are not the final files?
I quite like the Wolf MkII. It's in MSX and Amiga Elite, and maybe other versions. Absent from Archimedes source and data-cards but maybe in the actual game? Apparently this is a very deadly ship. As a side-note, I always thought it would be cool if the ship equipment could be miniaturised for a price, so a rich commander can make more ships viable. Frontier did that only with the Military drives. It could also be interesting to allow an on-board mechanic (+ various repair kits and personal quarters) to repair a ship that has broken down (sitting-duck) as tension mounts.
Attempting to extract the Sidewinder ship coordinates from the MSX version, using the DSK image. It's a simple, known ship to start with. There's all sorts of strange stuff on this disk image... cuss words and dev environment fragments. It uses MSB for the last character in a string as a terminator. The ships each come in neat chunks. For some reason certain data is repeated later on the disk.
Anyways, it took a fair amount of time to figure out how the bloody coordinates were stored. It's not the BBC or Frontier format, but instead some sort of... I suspect 6-bit lookup table. Can't find one which fits though, on disk.
Just scaling with x^3.5 here. But it's not proportionally correct. x^4 makes the ships too thin. I want the exact, accurate values. Guessing feels shoddy. I might try to extract this ship from the Amiga version instead.
Well, the Amiga version sure let out its secrets a whole lot quicker! Vertices were just bytes, signed like: if b>127 then b=b-256. I immediately plopped data into my (Frontier) Elite Unwrapper, but have not built the model yet. I don't know the size in tons, but it doesn't feel as large as I imagine. It feels more like it could be a deadly/military, larger Viper (90T?). Unsure how to colour it. I don't like the colour schemes in Amiga Elite 1. Military green top with battleship grey bottom?
The Unwrap program is from 2006, so my old window was small and cramped on a modern monitor. I decided to uprez it. It took me a while to figure out how the program works too (11 years later). Each ship has 3 scales, the basic vertices. Then the bit-shift scaling for the actual in-game size: Then there's my applied tweak scale which uses volume and cube-length, assuming 5 cu.m per ton, to e.g. tweak the 1:200 scale to 1:280 in this case. The scaling gets really confusing because I also have screen coordinates and SVG coordinates and a paper size. I might have made a mistake somewhere, but the program is still evolving. Should draw the paper edge using cm spaced dots.
Oh, I also looked at the cargo crate, which seems to be a rectangular box with the dimensions 1.45*0.725*0.725 meters, which is only 0.76 cubic meters... unless I made a mistake. It's unclear whether cargo tons are weight and/or volume, and whether the ship limits are weight and/or volume. A ton of water can't be compressed so it needs a cubic meter of volume, unless the crate is included in the deal.
Random thought on jettison'ing: It would be more immersive to make this take some time, suggesting internal cargo management mechanisms. Pick a cargo slot at random. If not the selected item, make a whirring/clacking sound. Repeat up to 4-5 times max. This suggests it takes some time to tetris out the crate/container. Sort of like an automated car garage. Pretty spacious on the station, but in the ships there might be tight tunnels, secure racks, rails for sliding arms, and maybe cargo droids.
Looking at the Sidewinder in Frontier, you can see that the fuel scoop (a point of reference) is really large. The ship is quite a bit too small, so I wanted to see how well my rescale does. At first it looked a bit too small as well, but on second thought it's not. Hull, basic equipment and fuel tanks can likely be fitted along the edges (maybe not cockpit for safety reasons, better off in middle of ship). This takes up 8T, leaving 25T, minus the drive, leaving 15T, and those are likely more central where there's a little headroom. Other gear also goes along edges, like ECM, Scanner, Laser. My Tons are each 5 cubic meters (crates are smaller, close to actual Frontier crates), and my rescaled ship has a submersion volume of 165. Original has only 71!(
In Elite dangerous, the Sidewinder is larger, nearly 15m long, and it's quite a bit fatter, so it's probably has a (submersion) volume well over 1000, maybe 1500, at a 72T mass. Density 0.05 if those are weighty tons. When doing some research for Starflight, I got some sloppy values suggesting 0.1 for airplanes which obviously need to be light, and 0.2 for battleships (which need to float). 0.05 is more space shuttle. Tanks are around 1.0 (some float, some sink). The BBC manual (page 31) mentions the Pulse Laster (Ingram Model 1919A4) firing laser rods which can pierce 267mm of Flux-Locked metal, so maybe the ships are more tanky. Big brother M1928A2 can slice through 410mm of FL metal. I don't think the ships have that thick hulls, but maybe they do, counting slope, which is certainly a thing on elite ships! The Frontier Sidewinder has an 8T hull. The surface area of my version is maybe 180-200sq.m, but less inwards... if 5T of the hull weight is armour (rest is internal supports, cockpit and bare systems), that means this "Flux-Locked" metal (if it's actually used as ship armour) has to be pretty light and/or thin. 5T is enough for 1cm thick Aluminium plating (density of 2.7) (a square meter is 27kg or 0.027T). I think armour would have to be at least 5cm for a slope thickness of 25+ to make sense. I know I'm building a house of cards, but then Flux-Locked metal needs to have a density of 0.5... but... maybe? Why not? It's the future and ship acceleration is important. I wonder how the Tiger Trader does (my scale). Maybe 800sq.m and 80T hull... Might give it twice the armour of the Sidewinder but it has more surface area and internal volume to damage.)
The MSX version has a pretty nice font and colours. I think the simple HUD/UI in the ZX version beats that of the Beeb version.
A smattering of colours here on the maps. Shouldn't Lave be green though? And red for Riedquat. Maybe it is sun colours. But suns are not green, unless we're in the Master-of-Orion-verse.
Hmm, cyan lines, then yellow ingame? Varies with system? I didn't check. Frontier's local ambient sun colour makes it very atmospheric. Maybe the coloured (blue) space could match sun? It would also be nice is the nearest few (bright) stars were plotted accurately, along with the galactic plane mist.
Nice font. The MSX could do 6 by 8 pixels text/char mode...
Nooo! Not like this! What are you doing, Amiga Elite?!?
Floppies to calm me down. Upside down though, so upset again.
The Wolf MkII in the Amiga version. I prefer the ship equip/characteristics system in Frontier, but it would be nice if some ships had static, custom equipment which cannot be changed out. Servicing this equipment is a bit harder, but it's more compact, and better than the low grade swappable stuff. This would give some of the ships a bit more character. The smaller fighter ships in Frontier could certainly use some extra spice. Medium size ships like the Cobras are more general purpose though.
I think the lore mentions space station being crewed mostly by humans, who then deal with the planetside population. But I like to think that it's these foolish rodents who attack me in Riedquat (harmless, but in great numbers). Sadly, Frontier phased out all of the fun aliens. I think Elite Dangerous should have entire solar systems phasing/warping in because there's some catastrophe in the other galaxies/realities (sort of like mirror universes and timelines in Star Trek). In galaxy 8, they have line ships. In 5, filled polygons. This reality merging feels like it's a match for "patches".
Idea for low-cpu planet rings: Use a dither pattern, where the density depends on viewing angle and distance. The pattern is randomly offset to produce a sparkle. Flying close to the ring plane increases space-dust (star scroll effect) density, also including occasional larger temporary bits of rock or metal scraps, which plonks on the hull or fizzes against the shields, providing audio feedback. Perhaps only the larger objects are persistent, and likely go in the ring gaps. Rings confuse the scanner, allowing some objects (derelicts, hermits, sneakies) to hide. Maybe asteroid belts work in a similar way, but without the ring effect, and asteroids in a belt are so spread out it's going to be impossible to remember and revisit a specific location. Larger persistent bodies in the belt should have cleaned the vicinity from smaller non-persistent asteroids, because these are spots the player might revisit/target and memorise.
I've added a tension analyser, demonstrated here by making an incongruent connection. The Falcon has no curves, though it's quite small and fiddly to fold I suspect. This ship has a lot of polygons, and I actually don't import the line/poly data and have to guess it. Trivial for the older ships, but here I was wishing I had imported more data as reference. Most of the work lies in figuring out a neat splaying though. Many Elite ships have impossible intersecting geometry when in comes to decor lines and cockpits especially.
Fiddly indeed. The fuselage is about the size of a pen. In doing these prototypes I have rediscovered some old inkscape workflow/methods, which I'll put here as a reminder to future self.
My SVG output has grouped the faces and tabs separately. Ungroup the faces, but lock the tabs. This makes it easier to select just faces for colouring. Apply colours/styles by Ctrl C source object, then Ctrl Shift V onto targets. To merge faces, Ctrl [plus]. Render Frontier font (reg ID) into a path so it's not needed on the system printing.
Rubbish probably needs to come in bags, as it's produced when e.g. drives are destroyed. Would be strange to crate it. It would be handy if the mining machine also had a sort of refinery and produced crates, littering the surface around it. Suit inspiration: rather than doing generic sci-fi bits-of-plate armour, I'm thinking of using the Women of the Future vintage photos as a base.
Pixel-over to make it more cockpit'y. Boring bars. I'd prefer a more F-16'y hardware dashboard, with meters and toggle switches. Frontier solved it well with the OSD/HUD though.
How I roughly estimate spaceship (submersion/displacement) volume using clay: How much longer than itself as a cube is it? For this nonsense ship, let's say (40 meters / 2.15 cube_lengths)^3 = 6440 cubic meters. Maybe accurate +-25%, but at least not off by magnitudes.
I used a larger clay cube for the ships I worked on in 2006. It's probably more accurate. One can check how well the sculpt matches the 3D model by holding it up against the ortho views, eyeing the eclipse of the silhouettes.