Jump to content

New game uploaded: Traveller-Trader WIP


Recommended Posts

  • 10 months later...


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".


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.


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.


  • Ship upgrades.
  • Random ship encounters.
  • System survey.


Edited by rje
  • Like 2
Link to comment
Share on other sites

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.



Edited by rje
Link to comment
Share on other sites

  • 1 month later...

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.


  • Like 1
Link to comment
Share on other sites

  • 3 months later...
Posted (edited)


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.

Edited by rje
Link to comment
Share on other sites

Posted (edited)


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.


Edited by rje
Link to comment
Share on other sites

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.


Link to comment
Share on other sites

Posted (edited)

Tom mentioned something:


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).


Edited by rje
Link to comment
Share on other sites

Posted (edited)


First is the splash screen.  It is one of the most recent additions to the game, and I *think* it's okay borderless..... except for the menu, which I think needs a border, and also needs a one-key selection scheme.

RESULT:  WOW... yes the one-key selector is WORTH IT.


But I have to ask myself: do I really need an experience level?   I use it to gradually introduce game controls.  But... is that really necessary?  Does it actually make it easier to learn the game and the game controls?

I remember where this came from... it came from a guy's blog that I read a couple months ago.  He said that graduating players from the basic controls into increasingly powerful controls can be like a rewards mechanism.

It's better, in other words, than an "Advanced Mode" switch, or piles of help screens (but nothing replaces good documentation).


So then, this initial menu is to allow veteran players access to more controls, while giving beginners an easier onramp.

I guess it's justified.




Screen Shot 2022-05-20 at 4.45.17 PM.png

Edited by rje
  • Like 1
Link to comment
Share on other sites


This will be the fourth re-imagining of the astrogation interface.  My assumption is that a player would enjoy moving a reticle on a small piece of the big map.

But, I'm not longer quite so convinced that it's a good idea.  I also suspect it takes more main RAM than a list -- after all, there is placement code for the features of every system in the view.  But I don't know if that's a major concern; I don't think it would make more than 1K difference.

Here's the current view.  And here's what I am thinking:

  1. If I keep this interactive map, then I need to center it, put a border around it, and find a reasonable way to represent the "metadata" on the left side.
  2. Replace the map with a short but expandable selection list (per Tom's suggestion), and include the current + destination system details in this view.

I'm currently leaning towards #2.



Link to comment
Share on other sites


This screen suffers from not really being anything other than a dumping ground for actions.  It currently holds details of the source and destination systems, but it's not really an appropriate place for these data.  It IS convenient to know that a destination is set, but I don't know if the full details are important here.

Second, the current and destination worlds need to have borders, as does the alarm bar.

Third, like Tom's mockup, I'd like the game's name on the page -- maybe at the bottom.   


Link to comment
Share on other sites


The trade menu is still fairly primitive... it's not centered, and the colors are too dark.  Also, if I'm using borders, I need borders.

I plan to use Tom's mockup as a guide for improving it.


Link to comment
Share on other sites


The starport is where you repair and upgrade your ship.  This needs to be more engaging, centered, nicer... right now it is a mess.

I have no idea why I put the ship's data line at the top of the page, either.  Most of that data has nothing to do with repair and upgrade.


Link to comment
Share on other sites


This bit works well, but has some problems.

  1. If I'm moving to borders, it needs borders.
  2. Needs a little prettying up.  The colors are perhaps too muted.  Maybe an icon would be nice here.
  3. The menu doesn't work like the others.  I either need to use the standard menu system, or else make this one look and act more like the others.



Link to comment
Share on other sites

Posted (edited)


This is where you trade for another ship.  This used to be a flat list, but instead I went to a page-flipping scheme where you see ALL of the stats for each ship on the entire page.  It's great for when you need detail -- and when you're ship shopping I figure you need detail.

HOWEVER... I started out with as much detail as I could fit into a 48 byte structure, in order to give me options.  Now that I've filled up system RAM, I'm thinking there are some details which are not important.  I'll have to think about that for a long time of course.


One major thought I've had lately is that I shouldn't list a ship unless I have an icon for it.  This limits my number of ships down to maybe 19 ships... maybe two dozen if I get a couple more designs squeezed in.  I currently have maybe 46 ships, and I think there's sufficient overlap still, so this is probably OK.  I have over a hundred unique ship designs on hand, but their differences aren't necessarily large enough to be important.



Edited by rje
Link to comment
Share on other sites

Posted (edited)


This is a late addition -- the ability to refuel from either the mainworld, or a local gas giant, or asteroid ice, or oort cloud ice.  The latter two don't have "artwork" yet.  The mainworld and gas giant are procedurally generated, and so are slow but not horribly so, and result in the same pattern given the same world data.

Again, this screen would benefit from borders.


Edited by rje
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

Please review our Terms of Use