MoO1 was released for DOS in 1993. I didn't play it then as I was an Amiga lad, but when I discovered it later it quickly became one of my favourite games. Now I'm sitting here wondering if it could've been ported to the old Amiga 500, mostly because it's a fun exercise (the A1200 which was released around that time wouldn't have had any problems, I'm sure). Anyways, let's take a look at the specs.
MoO1 came on four floppies and used some type of compression like RLE for the 256 colour graphics, though some objects/screens used a more limited local/contextual palette. My GOG/DOSBOX HD install folder totals 12MB. I suspect much of it is animations. RAM requirement was 2-4MB. I don't know to what degree gfx was streamed in from drive when needed as SSDs make no noise. I believe starfields were plotted and not part of the image data.
Afaik the typical A500 back then had 0.5 chip and 0.5 expanded RAM, probably an extra drive. Harddrives came with the 600 and 1200 and were very rare in the A500 days. The main obstacle with an A500 port is probably the complexity of the game code.
It might be hard to fit both the game code and gfx into RAM, but frankly, graphically a lot can be done within OCS colour limits if careful, and often there's an effective solution within reach if stylistic changes can be tolerated. I don't think there's much value in making an exact-but-degraded copy.
It's a static strategy game so there's nothing demanding I know of render-wise, other than the rarely seen intro/extro animations and planet spins. The map view has some palette animation for the routes. The star map view actually has a 3D parallax star plot which updates during scroll. It might have to be omitted or reduced.
I did this test with the GNN screen, going from 106 colours to 16. Space can be saved by mirroring, tiling, and reducing noise to help compression. Starfields can be random plotted (though preferably lumpy and structural in sinus curves). The copper can be used to liven up skies and text boxes. It's perhaps best to keep most stars on lower bitplanes to speed up plotting. Animations if any could be palette and copper-based, with occasional sprite/bob overlay effects. It's best to align tiles to multiples of 16 (wide) to help with blitting. I think some TV on/off effects could be made using bitplane easing tricks and/or noise spam. Perhaps the console/tech under the screen should be more figurative, like an A1000.
A global 32 colour palette for the whole game will result in colour reduction artefacts according to a quick test of mine, and I don't think 64 would fare much better. I remember using the 32 colour + 32 extra halfbrite (EHB) mode back in the day and I guess it would work fine, for a static GUI'ey game, but I strongly suspect the assets ultimately will require too much space.
So, each screen would be done in its own palette with subpalettes for insert-objects (like a character or view). 16 is kinda enough in most cases when using optimised local pals, and there's also the additional sprite palette, though one sprite would have to be a mouse pointer (unless a bob is used?). The Ships might have to be done using the sprite palette, so in 16 colours. They can be cropped and symmetrical/mirrored, saving a lot of space. Actually crops are limited to 16px for widths, or maybe 32px for convenience since they are centred.
The A500 could do (PAL) 320x256, whereas VGA (NTSC) was limited to a claustrophobic 200. Using 3x5 fonts didn't work so well on TVs over RF I remember, so a larger font could be used. Using the extra lines afforded by PAL mode for separate screens with their own palettes plays to the Amiga's strength. I had some idea that the bottom menu tabs could be attached to a screen which quickly scrolls up (if not annoying). The help and info boxes might be better off in a help/info field (there could be a hover-over help mode). So, I think an Amiga version could offer some improvements over the original game in the screen estate department, and maybe sound as PC soundcard audio was stylistically awful.
The maps are not that large and could use screen offset scrolling. The software scrolling in the DOS version is sluggish and a bit of a bottleneck in play. It does have a parallax effect, which I guess could be a low maintenence dual playfield on the Amiga, though It's hard to fit all the star & team colours into a 4bp screen because there might have to be a indices reserved for marching ants ship trajectories, though perhaps those could be done in another way. Honestly, the parallax effect is not something you see as most of the time the screen is static. Keeping stardust in a BG plane might help redraws though. Huge maps are probably some 700+ pixels, or upwards 300KB in 16 colours, so that might put a stick in the wheel. Huge maps kinda suck to play though.
I'm guessing character portraits would have to be reduced in size. I'd like to perhaps use them on the character select screen rather than the small icons.
Clouded planet skies could use the copper for extra hues (might work for a milkyway effect too). The fullscreen planet view seems a bit pointless and would also eat up graphics mem.
If planet spins and cloud movements are absolutely needed, they could be done using vector effects (bitplane tricks?) or palette animations but I think it's not on a priority list.
Colonisation and planetary troop landing scenes are full screen and varies by planet type, so that's a bit of an obstacle memory-wise. I suppose it's possible to do a ground strip, then use copper and re-paletted cloud bits to fill the sky.
The intro could be played from a separate intro disk when prompted (i.e. not automatically). It has a big font and lots of rendered animation. The latter would have to be simplified... the EPIC intro comes to mind. It used dithered 3D models over 2D scenery ant it worked well. MoO1's intro isn't really doing anything important or spectacular, it's just some Not-Klingons attacking a shielded colony. It's too slow paced and could probably be directed better using live 3D models. Additional BG ships could be 2D bobs, with a higher LoD 3D ship in the foreground. Pre-computation is possible as it's not an interactive scene. I'd use one of the ingame ships as a model rather than the Klingon cruisers, something which lends itself to polygonal representation. If you look carefully, the same ships which appear in the raid are also present in character creation (orbit) and on the tech screen, so there's a little narrative continuation there.
The ending (Orion scene) could be redone (e.g. having the brown emperor ship sliding across the screen from the side in 2D), perhaps using star and asteroid parallax to give a 3D effect. Or it could use a 3D model, going on the intro disk and reusing that code.
The title screen is quite simple with the front facing ship, warp swirl with surrounding plots, and a logo which I'd add a copper effect to. I think I'd change the design of the ship as it's a bit simplistic (also, it doesn't appear to be part of the intro storyline). Maybe it should be facing the other way, with an engine effect, possibly heading towards the ORION logo as that's the/a goal of the game, though a ship's butt is not that interesting. It could be mirrored to save space. The menu font has a gold gradient which could be a copper effect, but the gradient is vertical on the ORION logo... which looks kinda off so I'd make it horiz copper too.
Some tests. The intro should maybe represent the game better. I'm thinking... massive battles is a thing in MoO1 in particular, and a cheap effect could be paste ships into big arrays (Legend of Galactic Heroes style). It doesn't need much in the way of assets, just a few ships of different sizes, and maybe one in the foreground to add depth and detail. Quick laser beams could be palette cycling. Maybe it's a battle between blue humans (default pick) and green (Klingon ship) aliens.
Portraits downscaled to 128x160 16c would need 10KB each uncompressed. I believe around ten are needed in play: up to 5 for audience, then 3-4 for player race, but most of the time you only see the scientist so that's the critical one. I guess they could be loaded on demand, then kept in memory until full... would shorten startup loading times. Then there is the invention schematics, which could be 1-bit. I might want to redo the research room to something cleaner which compresses better. Many of the other screens could be drawn using little GUI bits, though the Ship Design one is more elaborate, and also has a BG (space station).
Graphics (& sound) has to be stored uncompressed in chipmem to be directly usable. Most A500s have 512KB on the MoBo, with empty sockets for another 512, but those require a newer Fat Agnus to work. I'm quite sure most users had another 512KB of memory in the trapdoor. Supposedly you can modify the Amiga to use it as chipmem. The modification involves cutting and bridging some JP tracks. Looking at my MoBo, it's a 1988 rev6A MoBo but for some unknown reason it has the older 8371 Agnus (its '88 datecode does match the other ICs), which supposedly won't detect extra 512 chipmem. The more rare A500+ has 1MB chip as default (and a leaking battery, making it even more rare). Anyways, this modification is not something users did back in the day. I think it might work to keep rarely used gfx in expanded RAM, then move it to chip when needed. Here's a rough (perhaps low) estimate for gfx memory usage:
Main game screens, single buffer, retain mode ------------ 320 * 64 * 1 * 4bp = 10240 SCREEN: Top slider GUI 400 * 400 * 1 * 4bp = 80000 SCREEN: Mid map (small-ish), scrollable, 320*170 port. 320 * 20 * 1 * 4bp = 3200 SCREEN: Bottom menu bar 320 * 235 * 1 * 5bp = 47000 SCREEN: Full screen (contextual) -bar Blitter/Sprite assets ------------------------------------ 80 * 56 * 14 * 4bp = 31360 Planet Landscapes (common) 32 * 10 * 14 * 4bp = 2240 + Colony dome overlay (common) 32 * 31 * 6 * 4bp = 2976 Ship variants (common) 128 * 150 * 1 * 4bp = 9600 Scientist portrait (uncommon) 128 * 150 * 2 * 4bp = 19200 Other profession portraits (rare) 128 * 150 * 5 * 4bp = 48000 Enemy ambassador/leader portraits for audience (uncommon) 24 * 24 * 6 * 4bp = 1728 Mini portraits (uncommon) 128 * 128 * 1 * 4bp = 8192 Audience Chamber (uncommon) 128 * 128 * 1 * 3bp = 6144 Generic GUI elements (common) 128 * 128 * 1 * 4bp = 8192 Council screen (rare) 160 * 160 * 1 * 4bp = 12800 GNN screen (uncommon) 160 * 160 * 1 * 4bp = 12800 Ship design screen special GUI + station (common) 160 * 128 * 1 * 4bp = 10240 Research settings screen GUI (common) 160 * 128 * 1 * 4bp = 10240 Discovery screen (uncommon) 64 * 48 * 24 * 1bp = 9216 Schematics display (uncommon) 5 * 8 * 72 * 1bp = 360 Small font (common) 8 * 11 * 72 * 2bp = 1584 Big outlined colour/copper font (common) 320 * 64 * 14 * 4bp = 143360 Planet surfaces for landing/combat (uncommon) 128 * 128 * 1 * 4bp = 8192 Generic clouds (+palette and copper to match location) 128 * 64 * 1 * 4bp = 4096 Lander/transport ship (uncommon) Excluded: Intro, extro, planet orbit screen, not-in-game races, music, code! Total:490960 Possible savings (store on floppy or expanded RAM): -19200 Other profession portraits (rare) -48000 Enemy ambassador/leader portraits for audience (uncommon) -8192 Council screen (rare) -12800 GNN screen (uncommon) -143360 Planet surfaces for landing/combat (uncommon) Total:259408
Clearly filling most of chipmem is a no-no, but 250K doesn't sound too bad. I suspect a few 1-bit blitmasks (fonts, big alien portraits) would be needed in addition, even though they can be calculated. Game code is pretty compact but MoO has a lot of features and I also don't know if huge lookup tables are a thing. However, most of the time the CPU will do very little (GUI stuff) as it's a TBS game. There are a few reverse engineered versions with available source... which I haven't looked at. Music will go in chipmem, but the intro/extro music don't need to be resident.
Quick test in AMOS 1.3 just to verify that I remember how screens work (and verifying chip memory consumption). There's indeed a blank line between screens, I'm guessing because it takes a scanline or less worth of time to set up the new screen, in AMOS at least. The cursor slides under the blank line. Also, since the cursor is a sprite, it'll change palette between screens but it can be mitigated by palette design.