INTRODUCTION
TRADING AND STAR CHART
3D ENGINE AND SPACE FLIGHT
COMBAT AND ARTIFICIAL INTELLIGENCE
SAVED GAMES
MISC MEMORY NOTES
Firstly, this is just a list of thought from off the top of my head that I've had over the past few days regarding creating an Elite clone. It is in no way comprehensive, and will contain errors and things that other people will probably easily think of better implementations for. So then, a document intended to cause discussion.
1999-12-30: I try to edit this document to reflect the current status of developement.
If each planet has only four unique 4 bit numbers and its name, which is limited to 6 characters, 5 bits a character (alphabet + space + a few numbers to give 32 possibilities), and two 8bit location bytes, then we are looking at only 8 bytes to store a planet. Which has a spare 2 bits, which could be used to set the planet colour within four possibilities. So that would allow us to store 128 planets per kilobyte, and at least a universe worth in < 10kb. Quite useful since Lynx development to use cartridge space above and beyond the 64kb of RAM seems impossible from where I'm sitting.
Karri added table while trying to understand this:
| government | policing | industry | size | name A | B | C | D | E | F | status | x loc | y loc | |||||||||||||||||||||||||||||||||||||||||||||||||||
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alternatively, we could use a pseudo-random sequence and each planet has one word seed from which to generate however many bytes we need to create our planet. The result is much greater variation, but greatly reduced control. Saves us 6 bytes per planet though, and increases the number of planets we can store in 1kb to 512. How desperate will we be to save RAM is the question.
2000-01-06: Marika created a pseudo-random naming code that combines 2 or 3 syllables from a table of 16 syllables to form a name of a planet. It saves a lot memory and sounds pretty good. If the naming code is accepted then I am going to replace the 4 name-bytes with 2 seed-bytes. I may also generate the location of the planet with the same seed. After thinking about this for a while I am even prone to give up control of the universe and hope for a good galaxy be letting the random number generator take over.
Supposing we do store 4bit factors, I suggest the factors could be :
1) government
2) policing level
3) rough GDP and industry type
4) planet size and distance from sun
2000-01-06: I would rather store just two factors: government and economy. All the other factors could be calculated from these. With some added pseudo-random variations of course. Otherwise we may end up with an anarchic system with high police control - does not make much sense to me.
Propensity to be attacked is affected by factos 1 and 2 (clearly an anarchic system with no policing level is going to be harder to travel through than a satisfied communist system with high policing).
Stock pricing is influenced by factors 2 and 3 (presumably a low police presence will encourage people not to carry expensive cargo, pushing its price up - high policing will make carrying illegal things more difficult, pushing those prices up, rough GDP will affect how much people will pay for things)
Factor 4 is really only to make systems feel at least slightly different.
1999-12-30: Currently I have implemented a scrolling list for showing available items with prices.
The 3d shapes must all be convex, and the main CPU cost is point geometry. Line drawing is handled by one of the coprocessor parts which we wouldn't really be using for anything else anyway.
The line drawer that comes with the C compiler appears to be storing its x co-ordinate within in a signed byte, so we are limited to the leftmost 128 pixels of the display for 3d, unless a replacement drawer is found. That would leave 32 pixels on the right for some sort of compressed status display if we wanted it. Maybe a screen high energy bar, and 24 pixels each of gun temp, altitude, fore shield and rear shield? Each bar 14 pixels across and with its function XOR'd over the top of the bar, as in the demonstration image available for a full screen cockpit.
16bit values gives us quite a limited z range while the C compiler refuses to allow signed over unsigned divides. However, since a divide by z is used to correctly model perspective, the relative sizes of lines tends towards a limit at a distance. The result is that once the object moves beyond our specified range, drawing it as small as we can and then doing a 2d scale downwards for another many units before replacing with a dot (as in real Elite) would probably go unnoticed by most people.
Although, in that circumstance, the 3d model would have to be drawn off screen and then one of the co-processors would have to use it as a scalable sprite. Is this possible, or is setting up a sprite table for the Lynx hardware a significant cost? If it is just passing a pointer and meeting size requirements, I don't theoretically see any problem. Anyone know anything about this?
If we are setting up an off screen draw -> on screen sprite setup anyway, we could use this in order to achieve object clipping at only a small extra cost for all objects less than the screen in size. As far as I'm concerned that is everything except the space station. But then as clipping code has to be written for the space station anyway, at least we can try it both ways should the off screen sprite method be implemented.
Also, be aware that we should be able to fit around 25 3d objects into about 10->12kb of RAM.
1999-12-30: The space is modelled as a projection from my craft. All items are bitmaps as Thomas vector engine is not here yet.
COMBAT & ARTIFICIAL INTELLIGENCE
I think the difficulty of this code is over-rated. There are only a
few small cases that need to be considered :
| computer is in front of player, and facing towards |
| BEST MOVE : swoop attack, positioning computer behind player - alternatively the human turns, and the computer again finds himself behind the player |
| computer is in front of player, and facing away |
| BEST MOVE : various swoops, turns and rolls to try and throw the player from his tail. If he succeeds, he can try to get behind the player, otherwise he continues until either he does succeed, or else he dies |
| computer is behind player |
| BEST MOVE : try to get player in sights, and try not to let him 'escape' - players turn to try and throw computer |
Also, the computer might want to look at these things :
| computer energy is low |
| try to aim up a missile. Maybe define low as underneath a preset base value plus a small random value to prevent predictability |
| missile is coming towards computer |
| use ECM if available, otherwise try to shoot missile as soon as possible |
And that should do for the basics. For trying to throw the human from his tail, the computer could just grab a random number and look up a manoevre in a table filled with all those barrel rolls and scissor type things you see detailed in Flight Sim manuals. Plus a few more that would work with no gravity, of course!
1999-12-30: I have implemented a PID-controller and modelled the values to resemble a Cobra III from the original Elite game.
If maximum cargo size (with extension) is 40 units, and we have twelve stock items (original Elite has 17), then to store what you are carrying will require at most 12*5bits. Add your skill level (another 4bits), location (probably 12->16 bits), upgrade status (another 16bits if we offer 16 seperate upgrades) and wealth (better make it 16 more bits), and we need around 60+4+16+16+16 = 112 bits to store a saved game.
If this is broken in 7bit sections, we get 16 values. Which, if we can think of 128 different symbols to use gives passwords no longer than Bill and Ted. Alternatively we could have 19 6bit secions or have 23 5bit sections, though that may be pushing it a little. Assuming we store these characters as 1bit bitmaps, each at 8x8, storing 128 different characters will only be an extra 1kb. If necessary, they can be blown up to Lynx-friendly 4bit in some temporary memory while being displayed as long as they are only for use on status screens and so on.
2000-01-06: The target hardware has 1024 bits of EEPROM that we can use. I abandoned the idea of keeping track of which planets have been visited. Bastians libraries access the eeprom as 64 words. One word is 16 bits. My suggestion is to use 8 words/game. Then we have an extra word for storing the initials of the commander. This would allow us to store 8 games.
Worst case : assuming we extend 16kb on 3d shapes, 24kb on graphics buffers, 10kb on the universe map and around 1/2kb on current status, we have less than 16kb to fit the program into!
Best case : 10kb on 3d shapes, 16kb on graphics buffers, 5kb on (smallish) universe map, still 1/2kb on current status, gives us just under 31kb in which to fit the program. The original went into 22kb, with data, so I think we can manage that.
Actual case : Aim for at least 25kb program, or we don't have a chance!
If we could store stuff on cartridge that would help significantly, otherwise
I don't think we'll be using any bitmaps or especially clever input code!
1999-12-30: The complete code fits in 0x3000-0xb200 right now.