Commander X16

 

PRE-ALPHA VERSION



The "pre-alpha" version is playable.  I'll talk about (a) what it does now, and (b) what I WANT it to do.

I'll attach the "user manual".



WHAT IT DOES NOW



You start in the "pilot" view, which does very little. Access the menu by hitting <return>, and you can see other things you can do.

• 
  "ASTROG" lets you target a destination star system.
  


• 
  "JUMP" takes you to your target destination star system.
  


• 
  "WILDERNESS REFUEL" refuels your ship.
  


• 
  "TRADE" needs work.
  


• 
  "STARPORT" also needs work.
  


• 
  "HIRING HALL" lets you hire and fire crew.
  


• 
  "SHIPYARD" lets you trade your current ship for one available at the shipyards.
  

When you Jump, you automatically take on passengers and freight.





WHAT I WANT IT TO DO



There are several additions and improvements I want to do. The most important to me are:



SHIP DAMAGE. This means ship components can be damaged, and can be repaired at the PORT.



COMBAT. Once ship damage is handled, then I can write combat.



Amber and Red zone worlds are dangerous and should be avoided. The risk here is of being attacked by a pirate. I need to write a combat routine that takes your ship and crew into account.





OTHER THINGS I WANT IT TO DO

• 
  Ship upgrades.
  


• 
  Random ship encounters.
  


• 
  System survey.
  

 

The game relies on exploration and a slow buildup of capability; therefore one misstep shouldn't result in immediate destruction.

In Tradewar 2002, if your ship encountered a superior opponent, it would auto-escape with some damage.  Maybe I ought to do it that way.

 

 

I wrestled with the code a bit, and am feeling tired over it.

I feel like it's all going in wrong directions.  But that's no reason to throw it out.  That just requires some careful UX thought.

 

That's what it needs:  an old-school but effective common user interface.

 

It has a lot of menus.  And I'm sorry to say they don't all work the same way.  This implies that I need a common menu method that the various drivers call on to draw the user's input properly.

 

What do you write it in? Assembly?

It's all in C, using the cc65 compiler.

 

THINGS I DON'T LIKE

I let this project rest for a couple months while r39, r40, and r41 came out.  I looked at it again, and compared its look-and-feel with two other attempts:

(1) Tom's "Space Trader" mockup menus are better. 

Tom's mockup has a very clean and functional look.  Its menu sample is superior to my scrolling-selection menu system, which is slick but less usable.  More subtly, my menu code encourages poor design choices, such as longer menus to choose from.  I suspect the ideal menu size is 5 to 7 items.   If it's got more choices than that, I need to rethink my design at that point.

(2) My earlier BASIC version of my trader game looked PETSCII retro nice. 

My earlier version had clean-but-retro, rounded PETSCII borders.  It split the screen into clear zones, and data was compartmentalized and summarized in an engaging way.  At least, that's what it seems to me.  It still relied on the scrolling-menu theme, which I don't like, but otherwise the overall look was ... well I have to repeat myself and say it looked engaging.

(3) The Trade Engine.

I am working on a third trade engine.  This one follows Traveller's Book 2 to the letter.  I don't know if it's going to work out.

(4) Combat.

I am not sure how to do text combat well.  What I *DO* know is that it can't be long and drawn out, and it must have very limited but important options.

THINGS I DO LIKE

Lest you think I hate my work, there's a lot I am proud of.

(A) Data management.  I have so much binary data stored in RAM banks -- especially the map, and the starship list.  Both of those are large: the map is a couple hundred K, and the starship data is squeezed into one 8K bank.  The map just won't fit in system RAM.  Other banks are used for other "nice to have" things that run from 1K to 8K, and each of which would potentially limit the main program.

(B) Navigation.  The ability to jump correctly through a hexmap of "space" from system to system is a major accomplishment for me, and I'm very happy with it.  A sprite reticle is pretty cool, too, although it might be incongruous to the retro feel.

(C) Data representation.  Going back to data, it took a long time to figure out what data was important for the game -- I couldn't just store every known piece of data, and I do rely on some bitfields.  The result is a satisfactory tradeoff of terseness versus completeness.

(D) Ship crew management.  The menu may need improvement, but the crew naming, hiring, firing, and "automatic" skill use is good enough.

(E) Ship icons.  They seem a little incongruous to the retro nature of the game, but having good-looking ship sprites was a big accomplishment for me. 

(F) The alarm bar.  Having an alarm bar carry ship overall status is something I've had since the BASIC version.  It's terse and retro and concise and useful... it even lends some drama to the game, especially if you see a lot of critical alarms lighting up your screen.... in theory.  Assuming I ever get combat written.

 

I need to simplify the user interface for two reasons:

(1) the game feels too complex.

(2) the game uses too much RAM.

 

I'll follow with screen shots to explain what I'm thinking.

 

Tom mentioned something:

Quote

If you provide a map along with the game, the user could then use the map to plot a route using just the systems close enough to travel to with one jump. (Basically the way you do it in Elite:Dangerous, but obviously with a simpler interface.)

That is a fantastic idea, and in fact I know how to do that really well:

There's an entire scrollable, searchable map application + API online, courtesy Joshua Bell:  https://travellermap.com/?p=-94.629!71.141!7&options=57599&ew=1310&qz=1

A player could simply use that to plot a course.  But it also has a poster-maker, with which I can create two PDF maps to include in the documentation bundle (attached).

Deneb.pdfSpinward_Marches.pdf