Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by rje


    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.



    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.




    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.




    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.   



    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.




    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

    • Like 1
  7. 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).


  8. On 5/20/2022 at 3:35 PM, TomXP411 said:

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

    I'll take this to the Traveller Trader WIP thread.



  9. Can I use PLOT to position the cursor and then use a PRINT to print the text at that position?

    What I'm seeing is that I can set the Row, but the column is reset before I do the PRINT:

    10 POKE $30C, 30  :REM ROW = 30
    20 POKE $30D, 40  :REM COL = 40
    30 POKE $30E, 0    :REM CLEAR FLAGS
    40 SYS $FFF0         :REM PLOT



  10. But then, there's also this.


    $FEC6: i2c_read_byte - read a byte from an I2C device
    $FEC9: i2c_write_byte - write a byte to an I2C device

    Function Name: i2c_read_byte

    Purpose: Read a byte at a given offset from a given I2C device
    Call address: $FEC6
    Communication registers: .A, .X, .Y
    Preparatory routines: None
    Error returns: .C = 1 in case of error
    Stack requirements: [?]
    Registers affected: .A

    Description: The routine i2c_read_byte reads a single byte at offset .Y from I2C device .X and returns the result in .A. .C is 0 if the read was successful, and 1 if no such device exists.



    LDX #$6F ; RTC device
    LDY #$20 ; start of NVRAM inside RTC
    JSR i2c_read_byte ; read first byte of NVRAM
    Function Name: i2c_write_byte

    Purpose: Write a byte at a given offset to a given I2C device
    Call address: $FEC9
    Communication registers: .A, .X, .Y
    Preparatory routines: None
    Error returns: .C = 1 in case of error
    Stack requirements: [?]
    Registers affected: .A

    Description: The routine i2c_write_byte writes the byte in .A at offset .Y of I2C device .X. .C is 0 if the write was successful, and 1 if no such device exists.


    LDX #$6F ; RTC device
    LDY #$20 ; start of NVRAM inside RTC
    LDA #'X'
    JSR i2c_write_byte ; write first byte of NVRAM
    LDX #$42 ; System Management Controller
    LDY #$01 ; magic location for system poweroff
    LDA #$00 ; magic value for system poweroff
    JSR i2c_write_byte ; power off the system
  11. I just read about this X16 KERNAL function, and thought it would be useful for an efficient file transfer mode:

    Commodore Peripheral Bus

    The X16 adds one new function for dealing with the Commodore Peripheral Bus ("IEEE"):

    $FF44: MACPTR - read multiple bytes from peripheral bus

    Function Name: MACPTR

    Purpose: Read multiple bytes from the peripheral bus
    Call address: $FF44
    Communication registers: .A, .X, .Y
    Preparatory routines: FILNAM, FILPAR, OPEN, CHKIN
    Error returns: None
    Stack requirements: ...
    Registers affected: .A, .X, .Y

    Description: The routine MACPTR is the multi-byte variant of the ACPTR KERNAL routine. Instead of returning a single byte in .A, it can read multiple bytes in one call and write them directly to memory.

    The number of bytes to be read is passed in the .A register; a value of 0 indicates that it is up to the KERNAL to decide how many bytes to read. A pointer to where the data is supposed to be written is passed in the .X (lo) and .Y (hi) registers.

    Upon return, a set .C flag indicates that the device does not support MACPTR, and the program needs to read the data byte-by-byte using the ACPTR call instead.

    If MACPTR is supported, .C is clear and .X (lo) and .Y (hi) contain the number of bytes read.

    Like with ACPTR, the status of the operation can be retrieved using the READST KERNAL call.


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

  14. So Tom showed us his "wireframe" menu for his Space Trader game.  If you didn't see it, it uses the new 80 x 30 display mode reminiscent of the C128 -- and it looks clean and classy.

    But I wanted to comment on his menu system.  If you just look at it, you know exactly how to work it -- it's the classic "one key, one option" thing.  Thus every visible menu option is one keystroke away.  The color scheme is pleasing as well, but not a show-stopper if you're colorblind.

    I think that's an optimal, usable way to do menus on the X16.




    On the other end is my Traveller Trader game.  I opted to go with a scrolling-menu system.  This means the user has to "cursor" to the desired option.  It's not as usable.  It's helpful for when there are many options, and I only use one function to render and manage all menus -- that's how I argued the decision to myself.

    But... there probably ought not be dozens of options in any given menu.  And scrolling is not a fantastic experience.

    So, +1 for the one-key-menu.



    • Like 1
  • Create New...

Important Information

Please review our Terms of Use