Page 4 of 11

RETROTrek - Early Development Thread

Posted: Wed Sep 09, 2020 10:41 pm
by Starsickle


1 hour ago, rje said:




Back to RETROTrek.



These retro space games need a purpose.  As I recall, the Trek games I played way back when involved hunting down and (ahem) neutralizing enemy ships -- cleaning out a region of space.  Starbases would be available for repairs, reloading, perhaps for refitting, or whatnot.



Is that RETROTrek's mission?



Yup! I spent more of today doing the README, so here's some snippits.


Quote




There are three planned game modes for RETROTrek:

    

        1. Explore - The objective is to explore all the bodies in the game.

        2. Secure - Destroy all hostiles in the game.

        3. Contact - Make contact with each other species.



    Explore will be the primary supported game mode and will be worked on first, followed by the other two.



These will be tracked by an objective variable. PHASE I will simple have it advance each time you successfully finish a single sector. After the maps are ready, then it'll get much better.

Here's what I got for the Attack sequence:

 


Quote




THE ATTACK AND DEFENSE SEQUENCE:



    For this example, we will use the example of The Endeavor versus a Klorg Heavy Cruiser - which have equal stats.



    1. The Endeavor issues a command to Fire (FIR) its

    2. Phase Cannons

    3. At the Klorg Heavy Cruiser.

    4. The game determines if it is hit. For this, it needs a few numbers.



    Firstly, we need two numbers representing ToHit and Evade. For every point of the the user's WEAP, that is 16 percentage points. For every point of the Target's ENGI, that is 5 points.



    If the target's Engines (ENGI) are operating, it consumes Power (PWER) to attempt to evade automatically. If it doesn't have this power, it gain the defensive points.



    5. Upon Hit, damage is applied to a target's shields (SHLD). If no shielding is available, a random System is damaged.

    

    6. Also upon hit, an amount of CREW are injured. Crew are Injured depending on weapon type.



THE BOARDING ATTACK SEQUENCE:



    Boarding attacks can only be done if a target's shields are down.



    Using the Away Team (AWY) command, the attacker spends energy to send crew to board and attack the target. The game does some random number stuff, and defenders and attackers take casualties. If the enemy crew are 0 at the end, then the target ship is captured.



This could open the way for capturing as objective, but - as always - baby steps and base cases first.

Here's how ships will generally work:


Quote




Before you get yourself into the Captain's Chair, it's important to understand how every ship works:



CRITICAL STATS OF A SHIP:



    Firstly, every ship a base number called a Scale (SCAL), which is a general measurement of size and capability. Scale determines several other things about a ship, including its:

        - Shield (SHLD) Strength (SCAL*1)

        - Total Crew of a ship (SCAL*30)

        - Compliment of Torpedos (TORP) (SCAL*6)

        - Power (PWER) Storage (SCALE*1000)

    

    Shields (SHLD) protect a ship systems and Structure (STRC) from harm. If a ship's STRC reaches zero, it is considered destroyed.



    The CREW (CREW) of a ship are critical to its operation. A crewless ship is dead in space, and an angry crew can mutiny, resulting in a Game Over on successful Mutiny.



    The available Power (PWER) of a ship is the available power for hard activity. The CREW use PWER to carry out several actions both passively and actively.



SHIP SYSTEMS:



    All of the subsystems of the ship can survive up to 6 points of damage.    At 5 points of damage, they are rendered inoperative. At 6 points, they are destroyed.



    The Engine (ENGI) system provides the ship with power and flight ability. Disabled and Destroyed Engines are very bad for the ship.



    The Sensor (SENS) system allows a ship to see and detect what is happening. If Sensors are disabled or destroyed, the ship cannot see or scan.



    The Weapons System (WEAP) allows ships to defend themselves.



    The Communications System (COMMS) allows a ship to Hail Objects (HLO) in space. This can be used to:

        - Demand surrender (DMD)

        - Ask permission to dock (DCK)

        - Parley (PLY).



Make sure you take turns to engage with Repairs (REP) in order to fix damaged or disabled systems!

Systems that are destroyed are only repairable at a starbase. Make sure to protect your engines!



ALERT CONDITIONS AND OPERATIONS:



    As well, you need to know about how the alert condition of your ship influences its operation. The alert condition of the ship will (eventually) influence how the ship's systems and crews will operate



    CONDITION: NORMAL - The ship operates normally, focused on normal operation. CREW and PWER will attempt to fix the ship and keep systems running nominally.

    CONDITION: YELLOW - The ship is operating under risk. CREW and PWER will only passively be used to protect critical systems and prevent loss of life.

    CONDITION: RED - The Ship is operating as if it is under danger. CREW and PWER will at risk every time the ship is at risk.



So, every turn there's stuff happening actively and passively. That's the goal, at least. As of now, I'm implementing subroutines to act as accessors and mutators for some of the basic parts. I have a LOT to test, so I might have really messed up today by making such good progress.



I like this, so far, as it's a great mixture of all the trek games I've played in my youth. There's Crew, there's power, there's sim aspects, and it makes you think before you act.


RETROTrek - Early Development Thread

Posted: Thu Sep 10, 2020 4:28 pm
by Starsickle

Github project is up, although I'd like to use the Issues and Release functions of the site in order to help people submit bugs and issues. I am not sure if I can do that.

https://github.com/users/Starsickle/projects/1

Speaking of bugs, I sure did call it: After the code cleanup and some additions I definitely broke it. The game is currently doing everything fine up to drawing the screen like it used to, but it gets to a certain point when drawing various elements before - of all things - returning to the normal X16 color scheme and clearing the screen - and showing READY.

Wow. Okay. That will require some tracking down. I've already spent a lot of time on it, but I'm at the point of commenting out sections, but yikes. The loop and parts seem to be linked up fine, but I simply cannot explain the screen clearing and READY. - in the original startup color scheme - without hitting ANY of the designated program termination lines.



EDIT: Found the offending subroutine.

Anyways, secondary activities today involve setting up the bottom status bar, even though I'm having trouble with displaying them properly. I've come up with a solution to problems with constructing the sophisticate line. I'll simply write the line twice. Once for the bar, once for the text. Easy.


RETROTrek - Early Development Thread

Posted: Fri Sep 11, 2020 3:15 am
by Starsickle

I have LOTS to show off today! Today i finished 14 tasks, and can show off the working data generation, new command series, and something getting closer to a game!

First shot is of the current game screen. Everything's coming along. The bottom Status bar has been finished, but it could use some polish, as you can see with those final two troublesome spaces at Y59 and Y60. Second, a shot of the debug report of 3 of the 10 static data ships in the game. Here you can see they are read perfectly and ready to rock.

Finally - the thing I'm most happy about right now: The random generator for our mysterious space region works. Sadly, the array is referenced like AR$(Y,X), which is beyond confusing for all the double loops I will need, but it is what it is.

Mechanically, the spacial region designated "SUBQUADRANT BETA-3" is about 78% empty. This might require some adjusting, as there's a few problems with placing at least 1 of something I may need to solve to balance out gameplay. I think there's too many combined Starsystems (*) and Planetary Systems (O). I think I should adjust it down to favor Starsystems with more diverse features. This will need some work, but the general proof of concept looks good as far as empty space to non-empty.

Look at it, though! It works! IT WORKS! From here, I have a few choices to make with how to improve this design, including adopting a trinary representation of a Sector, and reserve what's here for a Local area in a sector much like the other trek-clones.

PHASE 1 seems to be coming along, though. I am currently chipping away at implementing a very basic set of features, but sometimes I get something more advanced done, so I'm moving faster than I think. I will eventually EDIT the OP and clean up these posts for the sake of Forum Cleanliness and Efficiency. I just want a bit more done.


RetroTrek-WIP13.png
RetroTrek-WIP12.png
RetroTrek-WIP14.png

RETROTrek - Early Development Thread

Posted: Fri Sep 11, 2020 2:03 pm
by rje

Once you get the feel of it, and get a cheat-sheet, you'll find the PETSCII graphics could be useful for defining the screen panels.  More pretty than rows of ========== and ************.

 


RETROTrek - Early Development Thread

Posted: Fri Sep 11, 2020 2:34 pm
by Starsickle


25 minutes ago, rje said:




Once you get the feel of it, and get a cheat-sheet, you'll find the PETSCII graphics could be useful for defining the screen panels.  More pretty than rows of ========== and ************.



The problem is that I'm more likely to have programmed this whole thing on a Windows 10 64 bit system with some millions of times more RAM available, and in UTF-8 or ASCII - before the X16 is even available to us. I'd be using a lot of functions to stand in for those special characters, and while I'd love to take advantage of the PETSCII characters, I also know that there's ASCII characters I'd want to use to represent things I'd like to show the user. I definitely want to make it look nice, but I'd also want to make sure I can program quickly and cleanly. If we had the X16 right now, I'd of course be using its own keyboard, and perhaps drivers for its own keyboard on a modern system.

Speaking of which - I might wanna ask about/put that as a Driver/Software feature request...


RETROTrek - Early Development Thread

Posted: Fri Sep 11, 2020 3:10 pm
by rje

I get that... and yeah, at one point this summer I started writing assembly language that will draw a panel with a specified position and dimension.  Just another project to dust off and finish, because I want to use it myself.

I've got one in BASIC though, attached here, for your amusement.  One version you can load from the emu, and one that's ASCII.

 

WINDOW2.BASpanels.bas


RETROTrek - Early Development Thread

Posted: Fri Sep 11, 2020 7:35 pm
by Starsickle

WELP

WELPOOM.png.2462c0b9acf7c0922a66af866df69412.png

OKAY...Time to cut some features and learn how to somehow offload...

RGN$(9,19,2) (Would like it 9,19,4)

SCTR$(9,9,4)



To other parts of memory. I do not know how to do this, but willing to hear ideas. I haven't looked at manipulating the High Ram, but I suppose it's time to learn.



Strings seem to be too heavy, and there's no way to define these as character arrrays, instead. A single character is 2 bytes, but a string is 3+? and that's a little mystifying because I'm reading different things, here.



After cutting a few things, I'm back up and running but I don't know how I'm going to link up Planets and Civs or Manage Ships...


RETROTrek - Early Development Thread

Posted: Sat Sep 12, 2020 12:57 am
by TomXP411

On a 512K system, you have 63 banks of memory available, with 8192 bytes in each bank.

Star Trek typically has an 8x8 quadrant grid, with 64 8x8 sectors.

So what you'd do is transfer data into BASIC memory each time the ship changes sectors. 

If you use 32 bytes per ship, starbase, or star, and you limit each sector to 8 objects, you could store the entire game grid in 16K of RAM, or 2 upper memory banks. 

The simplest way to deal with this is to store your data in fixed-length fields. For different types of objects, you can use object type IDs to separate them. So for example:

0=Ship, 1=Starbase, 2=Star

Then your records might look like:


  1. Record Type (0=Ship) *1


  2. Ship Name *16


  3. Ship coordinate X,Y *2


  4. Health *1


  5. Energy *1


  6. Torpedoes *1


  7. Cargo *16


    1. Type *1


    2. Qty *1




So how do you get this into and out of upper memory?

Let's allow for 48 bytes per object. If we have 8 objects per sector, we would use 384 bytes per sector. That doesn't evenly work out to 8K, so let's make it 16 sectors per 8K bank. 

With 64 sectors, that would be 4 banks. 

So to address a sector, we need S (sector), B (bank), P (start position), and (object Number in sector), and BS (bank size)

5000 REM GET UPPER MEMORY ADDRESS. S=SECTOR

5010 BS=16:OS=48

5020 P=S/BS:B=INT(P)

5030 P=P-B:P=P*BS

5040 B=B+1

5050 P=P*OS+$A000

5060 RETURN

if S=0 then P should be 40960.

Set S=1 and P should be 41008.

Set S=17 and B should be 2, and P should be 41008

 

First, we get the bank number by dividing by 16. (should be 1)

Then we multiply the remainder back out to get the offset within the bank.  (

Finally, the first bank is used by the KERNAL, so we need to add 1 to get the next free bank.

This assumes your sectors are numbered starting at 0, so: 

image.png.f01bd13d1331f815d172ca09e470e159.png

So....

17 is in in the second bank (B=2)

16 is the first block in bank 2, so 17 is the second. This is 48 bytes in. 

$A000 + 48 = 41008

 

At this point, you know the Bank number and Peek/Poke address of each object. 

So you'd read an object in like this:

2000 S=0:GOSUB 5000

2010 FOR I=0 TO 7

2020 POKE 0,1

2030 ST(I)=PEEK(P):P=P+1

2040 SN$(I)=""

2050 FOR J=1 TO 16

2060 SN$(I)=SN$(I)+CHR$(PEEK(P))

2070 P=P+1

2080 NEXT

2090 SX(I)=PEEK(P):P=P+1

2100 SY(I)=PEEK(P):P=P+1

2110 SH(I)=PEEK(P):P=P+1

2120 SE(I)=PEEK(P):P=P+1

2130 SM(I)=PEEK(P):P=P+1

2140 FOR J=0 TO 7

2150 SC(I,J)=PEEK(P):P=P+1

2160 SQ(I,J)=PEEK(P):P=P+1

2170 NEXT

2180 NEXT

 

Hopefully, we'll soon get improved BASIC commands to deal with transferring data into and out of banked memory. I created an enhancement request a while back for just this purpose:

https://github.com/commanderx16/x16-rom/issues/17

With things like PEEK$, you could simplify the inner loop at 2050-2070 with SN$(I)=PEEK$(P)

I've attached a simple BASIC program that simply loads and reads a sector of space.

BANK4.PRG


RETROTrek - Early Development Thread

Posted: Sat Sep 12, 2020 1:00 am
by TomXP411


10 hours ago, Starsickle said:




If we had the X16 right now, I'd of course be using its own keyboard, and perhaps drivers for its own keyboard on a modern system.



The keyboard is simply a USB and PS/2 keyboard. You just plug it in to a PC and run the emulator, no special drivers needed.  ?

 


RETROTrek - Early Development Thread

Posted: Sat Sep 12, 2020 4:09 pm
by Starsickle

@TomXP411 Thanks - I'm a bit groggy, but let's take a look:

For clarity, the special region is as posted above: 10x20 with 10x10 sectors. the real problem is storing the data associated with them either as tables or as the third index. I'm opting for the third index, but this DOES explode memory cost.



What you are proposing is pretty technical and I don't have much experience with it. I would prefer to wait for the keyword to be finished before hammering out functions to bitwise poke into the X16's novel memory banks.

Of course, I'd also ask for the interpreter to recognize the character format, as I'd be perfectly happy NOT wasting what seems to be the C64's method of allocating strings when I could just have characters.

That said - I could probably use some amount of banks for the 200 sectors. Sleepy-brain-without-coffee tells me that's quite a lot of contiguous memory, and I'm having a hard time visualizing where it's going because I've read some things.

http://microheaven.com/FastC64Basic/tips.html (ASIDE: "Don't do bubble sort" kinda tickles me)



For now, at least, I'm back up and running having cut (9,9,9) to (9,9,2) and (9,19,5) to (9,19,2). Unfortunately, I'd also like to add information to tag objects like planets or ships ownership, but alas - that requires an index or ID and another table, which is essentially the same problem but fractured. It's a design thing, so I'm just cutting things and returning to making the game be a working game for the time being. The good news is that the data as is now fits.