![]() |
Forum Index : Microcontroller and PC projects : Dev Diary: Space RPG - Definitely not Star Trek.
Page 1 of 2 ![]() ![]() |
|||||
Author | Message | ||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
I'm going to ramble a bit here about mental health, so please forgive me. Recently I've been using BASIC programming therapy to improve my mental wellbeing. See, it works like this, I have a CMM2 setup in a spare bedroom, hooked up to a lovely mechanical keyboard. There's no other computers present, and my phone tends to stay in my pocket - so no modern distractions. I have a bunch of different CMM2 projects on the go - but my one rule is that I'm not going to get stressed about finishing any of them. They are there to provide me with a simple distraction from my current work and family pressures, and it is working wonderfully. One of these projects (which I am under no pressure to get finished) started out as a Star Trek game, but has morphed into something else (hence the ambiguous name in this thread title). I figured I'd keep you all updated on the progress in this thread, and maybe convince myself that it is okay to just tinker at a program without any actual end goal. Some background: I have fond memories of typing in and playing the mainframe version of Star Trek back in 1980 (on the HP workstation my dad used to occasionally bring home from work). I loved that game - and spent many hours poking at the source to learn how it worked. Fast forward a couple of years and our family got a Dragon 32. This was really exciting - finally a computer that we could play on every day. Of course, we bought the official Dragon Data Star Trek game (called Dragon Trek). It was a bit ….. woeful. I looked longingly at the cool versions on other contemporary computers and our Dragon version just didn't compare. In fairness, there were warning signs. Look at the amazing graphics on these cassette covers for the C64 and Atari 400 versions. ![]() Now compare that to the quality art on the Dragon cassette cover: ![]() Despite this bump in the road, the original Star Trek game held a fond place in my memories. Fast forward to the present day, and while I'm dabbling with the CMM2 I decide to write a version of Star Trek, with the aim of seeing how far I can push it on modern hardware without straying too far from the nostalgia of the game I fondly remember. As a mental exercise, I set myself some limitations - it's got to run on a Gen 1 CMM2 (although I'm programming it on a Gen 2 - I have a Gen 1 to test on) - It's got to use MAX-SCII graphics (i.e. text only like PET-SCII), although I do allow myself pixel point positioning and transparent backgrounds. - Limited use of colours - because I want it to feel like that old HP workstation (which was green screen) So, I quickly cobbled together the main part of the program (movement, phasers, torpedoes and local and long range maps). See below. ![]() It was about this time that I realised that the Star Trek game itself is a bit… well …. sh*t. It was great back in 1980, but my expectations have moved on massively since then. I also realised that the game's premise doesn't fit at all with the Star Trek philosophy. Flying around slaughtering Klingons doesn't really tie in with the optimistic vision of the future that Star Trek represents. And where were all of the other federation vessels? The Enterprise alone against an entire Klingon invasion? Back to the drawing board. I had always loved the idea of the Traveler RPG, but never played it back in the day (we were AD&D fanatics - buying another game's rulebooks was beyond our finances). Therefore, I've resolved to make this new CMM2 game a sort of Traveler inspired CRPG, where space combat was only a part of the experience. This would scratch my Traveler itch - and give me an excuse to buy the old rule books that I couldn't afford back then. I also had to do something about the lack luster game play. Step 1 was to introduce directional shields (Front, Rear, Left, Right - or Fore, Aft, Port and Starboard if you want to be nautical), which also led to giving the player ship and enemies the ability to point in any of 8 directions (N,NE,E,SE,S,SW,W & NW). Step 2 was limiting the firing arcs of the weapons, so the player has to bring weapons to bear. Right away, this greatly improved the gameplay - giving it more of a naval feel. Maneuvering around the enemy to keep your strongest shields facing them, and in turn to try and get a bearing on their weakened shields, introduces far more depth. In keeping with the look and feel of the old HP workstation, I remapped font 9 to be a 10 by 20 VT Terminal font, with scanlines between the pixels. I also created some Pet-SCII like characters that I could use for simple graphics. ![]() I added a fake monitor bezel, to further tickle the nostalgia neurons. Up until now I had been using two 10x20 characters for each 20x20 pixel grid on the main map (shown above). To simplify this I created a 20x20 font of exclusively Pet-SCII like characters (mapped to Font 10) that I use to draw the map. Because I also have fond memories of the amber VT Terminals from one of my first jobs, I put in the option to use amber instead of green as the main colour. But I still prefer the green. ![]() So, that's where we are at currently. I'm having an absolute blast just trying out different mechanics and seeing what works. I would never do this for a real project, but it is liberating to be working without any set design or deadlines. Edited 2025-01-05 13:23 by PeteCotton |
||||
panky![]() Guru ![]() Joined: 02/10/2012 Location: AustraliaPosts: 1102 |
Fascinating post Pete, will watch development with interest, Regards, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
Thanks Doug! I really appreciate it. |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4136 |
Nice work Pete. My playing with MMBasic started for similar reasons, though just at the moment it is beginning to feel more like a mental health problem than a curative ![]() Happy New Year, Tom Edited 2025-01-06 04:13 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 4529 |
Looks great Pete, a soon as I read your explanation of the project I analyzed if this could be ported to PicoMite. Maybe for the 2350 and mode 3 in 640x480. Or (with some redesign) in mode 1. But it would require custom fonts different from yours. I'll keep a good eye on this. You inspired me. Although there is a CMM1 version (MaxiTrek) that I also tried to port (got shelved for now). Volhout PicomiteVGA PETSCII ROBOTS |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
We do appreciate the work you put in Tom - ![]() Thanks! Because I'm using 10x20 fonts at 800x600, I think it would work well using standard 8x16 fonts in 640x480 (same relative text size). I am double buffering the screen (not sure how much spare graphics memory you have with the 2350), but even if you don't, then that's only for minor animations. 99% of the time, the screen is not being redrawn. I don't think I'm using anything CMM2 specific, so hopefully it should be fairly straightforward (famous last words). Even the processing speed is fairly irrelevant being a turn based game. Edited 2025-01-06 06:21 by PeteCotton |
||||
vegipete![]() Guru ![]() Joined: 29/01/2013 Location: CanadaPosts: 1113 |
Cool graphics, especially the fake bezel for the rounded CRT effect. Just remember what Spock said of Khan: "He is intelligent, but not experienced. His pattern indicates two dimensional thinking." Visit Vegipete's *Mite Library for cool programs. |
||||
Malibu Senior Member ![]() Joined: 07/07/2018 Location: AustraliaPosts: 253 |
Brilliant work Pete, love it! Bringing back the days of the 'old' gaming styles can't be a bad thing ![]() Looks to me like it could easily finish up being one, I think you'd be onto something there (while still being able to keep the stress-free rule as the Prime Directive) I know you set yourself some limitations and I think you've nailed 'the look', but going down Volhout's thought process I wonder if it could incorporate some Okudagrams by using the LCARS format for the gameplay? ![]() No idea if it's possible, it's just an idle Start Trek thought on my part ![]() Either way, love what you've done there ![]() John |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
Thanks! There's no reason why it couldn't be "re-skinned" with an LCARS interface. It would certainly look cool. I've always loved that look. |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
Thanks! The irony of that quote is that the entire history of Star Trek has ignored the third dimension. Ships always meet up on a flat plane, all facing the same way up. ![]() Maybe that's what makes it ideal for a simplified space sim like this. It's really more akin to a sea based naval battle. |
||||
Malibu Senior Member ![]() Joined: 07/07/2018 Location: AustraliaPosts: 253 |
I'll second that! Michael Okuda did wonderful things with those designs. If you could do an Okudagram gameplay, and fit it into a Tricorder style box that goes 'fwee-weep' when you open it, you'll have bunch's trek-miters building these all over the place ![]() (Good luck with Paramount copyright on that one! ![]() John |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
That would definitely be a cool wee project. ![]() Luckily Paramount and CBS actually seem pretty cool about the Trek IP, as long as your not trying to make money off it or pass it off as your own. When it comes to cos-play and fan stuff, they recognise that it's usually just people geeking out and not some nefarious plan to sell Star Trek branded products. |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
Dev update: My current problem is that the screen redraw is very slow, taking about 250 milliseconds to redraw the full screen. Normally this wouldn't be much of an issue for a turn based game (the screen isn't being redrawn 99% of the time), but I want to improve it for two reasons. 1. When the player moves their ship, there is a 250ms lag between the keypress and the ship moving. I know that sounds small, but it is noticeable and makes the whole program feel sluggish. 2. I want to do some fairly high speed animations (explosions, warp etc.). And 4 frames per second just isn't going to cut it. On that note - one of the things I'm trying to achieve with the retro-ASCII graphics, is to lull the player into buying into the old VT terminal interface, and then when something spectacular happens, an ASCII ship explosion for example, it has far more impact. If you ever watch the movie Galaxy Quest, it uses this downplaying method to great effect. The first part of the show, when they are on the TV show is shot in 4:3 ratio. You don't really notice it. Then it opens up to slightly widescreen when they are out of the show and in the real world. But when Tim Allen's character first sees the hanger doors of the space ship open to the void of space, the image matches the doors opening to expand to full widescreen. That's the kind of wow factor I want recreate - where we're showing people what looks to be a text based display - but is in fact a fully bitmapped display. Of course, I could just go straight to using 65K colour graphics, but that would ruin the effect. I have to walk the fine line between this being a retro-text terminal display… but also able to do some cool things with those text characters. Before I dive into specifics of my speed issue, I figure that some very basic knowledge might help if you're new to the CMM2/games programming. Therefore, I'm going to give a quick overview as to how the graphics are organised. If you're familiar with double-buffering and blitting, then you can safely skip this post and go on to the next one. You won't be missing out on anything. We're using Mode 1 - 16 bits for the graphics. That is 800x600 pixels with 65,000 colours. Because we are using a font that is 10x20 pixels, this gives us about 80 columns of text across the screen and 30 lines. It's slightly less because of the Bezel image I'm using around the outside to make it look retro. The 1st Generation CMM2 can store 3 of these Mode 1 graphics pages in memory (numbered 0, 1 & 2). I could increase this to 6 pages by dropping down to 8-bit/256 colour mode - but I really like the bezel (which doesn't look as good in 8 bit mode), and because we are using fonts instead of bitmapped graphics, we don't really need the extra pages. We can think of these three pages of video memory as three blank sheets of paper. We can show any of them to the user at any time. If we were just to use page 0, then we would be using one sheet of paper - drawing each frame, then erasing it, then drawing the next frame over the top of it. Unfortunately, the user would see the page being cleared for a split second before everything is redrawn, and this would be an annoying flicker on the screen with each redraw. So, to get rid of this flicker, we alternate between drawing on pages 0 and 1, and we show the user the other page. So, if I want to refresh the image on the screen, I show the user page 1, and I draw on page 0. When I have finished drawing, I swap the sheets of paper over and show the user page 0 and clear page 1 ready for the next image. We keep swapping back and forth like this and the user sees a seamless animation with no flicker. The call to change which page the user can see is almost instantaneous - so you can achieve very high frame rates with this method. This is very common in games programming and is called double-buffering and is critical in action games where sprites are moving around the screen many times per second. Next, I'm going to mention Blitting a lot. Blitting is simply the method used to copy one piece of graphics memory to another. So, I could have an image of a space ship on graphics page 2 at position 0,0 with a width and height of 50 pixels. I can "blit" that rectangular image very quickly from page 2 onto any location on the draw screen. The original copy stays on page 2, but by doing this I can quickly "draw" multiple graphical elements on my screen. So, for something like space invaders for example, we would have one image for the space invader on page 2, but we would copy it 20 or 30 times on to the draw screen to build up the image of a swarm of separate invaders. A typical sprite sheet is shown below. By blitting portions of it on to the game screen we can quickly build up quite a complex image. ![]() The final thing to know about blitting is that it's very quick if you're overwriting the entire rectangle. However if you want to blit a rectangle with a transparency (for example, a player sprite walking in front of a building), then one of the colours (black) will be designated as "transparent" and will not be copied over to the new image. In the images below, you can see what would happen if we didn't use transparency (left image) when the player character starts to erase the door image. So we would draw the player character with transparency, so that we can do not destroy the image behind the player sprite. ![]() The only thing you need to know about this is that transparency does slow down the draw speed a little bit. That's it - you're now up to speed on everything you need to know to understand my next post. |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
As I mentioned, we have three mode 1 graphics pages available on the Gen 1 CMM2. We are using pages 0 and 1 for the double buffering, which leaves us one more page to play with. Normally we would use this for storing sprites etc. which we would blit onto the main screen as needed. But because we are remapping fonts and using text only, we don't really need this page just yet. So I use it to hold the bezel image, and when I want to clear page 0 or 1, I just copy the bezel from page 2 over the new screen that I'm about to write to. This clears off any old graphics, ready for a new frame (note the F-buttons are also part of the bezel - as they are the same for every screen in the game). ![]() Back to my slow update rate problem. I just assumed that this was because text writing is relatively slow (I was wrong by the way). But this is a dev diary - so I'm recording my mistakes as well. Time to do some testing: It takes 16 milliseconds to copy a full screen of 800x600 pixels using Blit. To write out a screenful of text takes 66ms. Here is the command I am using to write my characters to fill the screen. TEXT X%,Y%,"A","L",9,1,RGB(0,0,0) Removing the colour at the end drops the test time from 66ms down to 55ms. That's pretty significant. Removing the scaling factor shaved another 2ms off the time. And finally I remove the alignment "L" which dropped the time to fill the screen with text to 45ms. So I'm left with this line: TEXT X%,Y%,"A",,9 Which is pretty much the bare minimum I need. Well - it looks like writing text to the screen isn't the problem after all. It's a testament to the efficiency of the Blit command and the sheer raw power of the CMM2 with MMBasic that we are hitting these speeds. I also do recognise that I am trying to use the machine in a way that it wasn't necessarily intended to work. If I was throwing large sprites at the screen, this would be child's play for the CMM2. But by copying one text character at a time, I'm really making it work much harder than it should have to. Hmmm, why is mine taking 250ms? The biggest bit of real estate on the screen is the 21x21 grid of space. I'd been looping through the Y and X axis to draw the background grid - I decided to write out each X line as just long strings of data. This got me down to 140ms to draw a screen. Still some way off the 45ms I could get in the test, but a significant improvement. That's when I started commenting out parts of my logic - and it turns out I was making one very time expensive call when I was looping through the grid squares getting ready to plot enemy ships. It wasn't brutally slow, but because we have a 21x21 grid to loop through , it was being called 441 times on each redraw. I fixed that with a more efficient call and now the redraw time of the screen is down to a pretty decent 120ms. Looking further at the nested loops, there are some other significant improvements I can make: It looks something like this: FOR Y% = -10 TO 10 absY% = PlayerSectorY% + Y% FOR X% = -10 TO 10 absX% = PlayerSectorX% + X% if absX% >= 0 AND absX% <= 99 AND absY% >= 0 AND absY% <= 99 THEN .. Do stuff ENDIF NEXT X% NEXT Y% But this means for every loop, I'm doing 4 comparisons to make sure it's not out-with the bounds of the playfield array. If I set the start and end values of the loops to make sure they are within the array, and also set them to be the absolute grid positions to begin with, then I can save myself a lot of comparisons and calculations. This gives us the much neater code below - and shaves 20ms off the re-draw rate (100ms) startX% = LIMIT(PlayerSectorX% - 10,0,99):endX% = LIMIT(PlayerSectorX% + 10,0,99) startY% = LIMIT(PlayerSectorY% - 10,0,99):endY% = LIMIT(PlayerSectorY% + 10,0,99) FOR Y% = startY% TO endY% FOR X% = startX% TO endX% .. Do stuff NEXT X% NEXT Y% Next up: I effectively have three 100x100 arrays that hold the contents of the sector. One for ships, one for random objects and one for starbases. Each time I draw the grid around the player, I need to check all three arrays. To speed this up, I created a fourth array which tracks which squares are empty. Given that most of space is empty, I only need to check this single array to see if I can skip looking for ships items or starbases. This shaved another 10ms off the scan time. I just need to make sure I keep the array updated every time I move or destroy a ship. At this stage I'm down to a fairly respectable 90ms. I think the lesson here for me is that I jumped to the conclusion that the slow Text writing was the issue - but when I started to test that theory, I quickly realised that I was mistaken. Normally I would have looked at the nested loops first- but in the back of my mind I was prejudiced against the text draw speed - as this was famously slow on old 8-bit computers. But it turns out that it's not an issue on the CMM2. I have learned something here. Finally, I decide to be a bit smarter about using that spare Display Page 2. About half of the draw time for the screen is drawing parts of the tactical screen that are always present (e.g. the 21x21 grid). See image below: ![]() So I add some logic to draw the static background and save it to display page 2 (see image below). Now, whenever I need to clear page 0 or 1, I copy the background from page 2 - and just draw the foreground text and now the draw time is down to a respectable 45ms - or 22 frames per second. Which should be good enough for animations. The ship movement also feels far more responsive. ![]() Edited 2025-01-08 11:10 by PeteCotton |
||||
Malibu Senior Member ![]() Joined: 07/07/2018 Location: AustraliaPosts: 253 |
Of course, the 'fan' film Prelude to Axanar had a couple of problems along the way ![]() (Well worth the watch if you've never seen it!) Edited 2025-01-08 14:35 by Malibu John |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
Ha ha ha. Yeah - I've been following that saga since the beginning. It's a testament as to how tolerant CBS and Paramount are that they let them get away with it as long as they did. After they raised over 1 million dollars and then just kept going back to the fans for more and more - all the while selling their own Star Trek branded merch. I think the final straw was when they got too bold and started sub-licensing the Star Trek brand (and pretending they were legally allowed to it - which of course they weren't). They sold licenses for Star Trek Coffee, models, board games. Ignored a few cease and desist letters, and finally got sued. The background story is even more fascinating - far too long to go into here - but wow - it's a roller coaster. |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
I can't keep calling this game 'Not Star Trek' - I need to come up with a working title for it. Star Trek, Star Wars, Star Raiders, Star Citizen, Star Lord - I should follow this theme and start with the word Star. Then there's the thought that I could do a pun on Star Trek and have Star Walker…. Wait that sounds a bit too familiar. I could put it up for the popular vote - but then I would end up with Starry-McStarface. I could go for Stargasm - but don't really want to explain to my kids that the game I'm working on is called that. Way back in '81 I used to look at adverts like the one below - and drool over what I thought was a fully fleshed out space sandbox. Experience (or cynicism) has taught me that these were possibly the only graphics in the game, but I quite like the idea that my game would be a spiritual successor to this sort of game. So Star Trader it is. ![]() |
||||
Quazee137![]() Guru ![]() Joined: 07/08/2016 Location: United StatesPosts: 584 |
late to this here is my 2 pennies Star Fleet or Star Defender. Quazee137 |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
Quazee137 Oh I do like those. Thanks. I might go for Star Defender!. ![]() |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 431 |
I've been working on the gameplay this weekend. It's going to be an on going mechanic to balance the power usage of the ship. So you will have a set amount of power that regenerates partially every turn. You are also restricted to using three actions each turn (moving 1 space, turning 45 or 90 degrees, firing phasers or firing a torpedo each take 1 action). Other tasks such as balancing shields etc. won't take up an action point. The count of Action Points is shown at the bottom left of the screen. If you buy bigger ships, or upgrade your crew, then you might get more actions per turn. ![]() So you can move up to three squares in a turn, or in another turn you could fire phasers, move, then fire a torpedo, or you might fire three torpedoes in a turn. Each of those options would take up all of your 3 Action points. But if you want to conserve energy you might just do one or two (or no) actions. At the end of the turn, the enemy ships all move/attack. Phasers and moving use up energy, so although you might be able to move three square to escape an attacker, you might find that you only have enough power to move two squares next turn - or no power to fire phasers. Because torpedoes don't use energy, these are a great option - but they are a fairly rare item you have to find/buy, and they can only be fired when you are absolutely dead on pointing at the other ship (0 degree angle), which can be difficult when the other ship moves just one square over. Here's some video footage of the player ship taking on a lone enemy (firing phasers and torpedoes), and then running into trouble right after it. The enemy logic is very simple currently, and they don't shoot back (yet). https://1drv.ms/v/s!AnkZn9N9Pt1fyYMvkWUdnRP8Bb_O0Q?e=Ols6iF In the original Star Trek game I thought the Klingons didn't present any challenge to the player, it was more about how you manage to move around fast enough to kill 36 enemy ships within the allotted time. The actual ships were easily dispatched with a single torpedo. In my game, I want it to feel like a naval battle, with two or more mighty warships slugging it out, with each battle being about maneuvering, tactics and licking your wounds in between fights. i.e. There should be real jeopardy that your ship will be destroyed. I haven't tuned the power usage yet (in fact, despite what it says on the menu, firing phasers doesn't consume any energy currently), but it's starting to get that big naval ship vibe that I want. Each ship has 4 shields, and punching through the shields is essential to getting a kill, so I provide a white line marker on each ship's scan that shows where the other ships shots will hit (see image below). Infact in the video above, you can see that once I get through the port shield, the enemy turns so that I am facing their full strength front shields, forcing me knock those out as well. ![]() If I'm going to make the player work for every kill, then I want to reward them when they succeed. Therefore I've worked in a satisfying ASCII ship explosion animation, (still shots shown below). ![]() That's the progress so far. I'm very happy with the look and feel of the ASCII/Font mapped graphics. They are a stimulating challenge. Thanks for reading. Edited 2025-01-13 09:26 by PeteCotton |
||||
Page 1 of 2 ![]() ![]() |
![]() |