![]() |
Forum Index : Microcontroller and PC projects : Dev Diary: Space RPG - Definitely not Star Trek.
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Thank you very much George. |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Today's update was a bit more involved than I had expected. It started off innocently enough. I only hold the local star system in memory, and keep the star systems not being used, on the SD card. So, if you jump from one star system to another, I save the current star system data (about 1 second) and then load the next star system (about another second). This is an unacceptable delay, so I sat down today and re-wrote the save and load routines, and by compacting the data down (i.e. ignoring bits of space with nothing in it) I got it down to 300ms for save and 150ms for load. Much more acceptable. But this task highlighted something that has been gnawing away at me. I use arrays for everything, and because I'm a C/C# programmer - I use base zero arrays (i.e. the first element in array X is X(0) as opposed to base 1 arrays where the first element would be X(1)). This is no problem for the CMM2, which is happy with either. However, most BASIC languages only allow base 1 arrays. And if anyone ever want to convert Mascii-Trek to another platform they would have to fix this - and these arrays are everywhere in the code. Of course, I could ignore this problem (this is not my issue) - but I figured that as the program grew, this problem would only get bigger and bigger for the person doing the converting. There's also that nagging feeling that by not taking the time to fix it, I was taking a short cut. So I took a backup of everything (just in case) and started "fixing" the whole program to work with base 1 arrays. Here we are, 3 hours later - and it's finally done. It seems to work just as it did before, and now I can relax in the knowledge that it's not something that will gnaw away at my conscience anymore. I also set the "OPTION BASE 1" at the start of the program, to make sure I don't slip back into old habits by accident ![]() As an aside, I couldn't work out how to read multiple variables with the INPUT # command. It's not a big deal, as I just ended up putting each variable on a new line - but I'm assuming I'm missing something fundamental. I'll start another thread for it. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
Interesting... All the BASIC versions I've used have defaulted to base zero, I think. Anyway, taking 2 seconds to fly between star systems seems fairly acceptable. :) Interesting info on arrays EDIT - deleted some wrong info. :) . Edited 2025-02-16 18:37 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Ah - after a bit of research, I think you're right. I wonder where I got that idea from? Not to worry - it's ready now. I know ![]() I have already been giving some thought as to how interstellar travel works in this game universe. We have the usual standard sci-fi options of course. Jump Gates - Used in games like X4 and Mass Effect. This introduces some interesting strategy (whoever has control of the space around the jump gate controls travel to that star), but in reality all that would happen would be that every jump gate would be surrounded by gun turrets (oh - spoiler alert - I'm adding gun turrets). Warp/Hyperspace - Star Trek/Wars etc. My problem with this is that it's a dull experience for the player (just sitting in warp/hyperspace for a length of time). It also means that I would have to introduce some sort of repair time sequence for damaged systems - which might not be intuitive for players. i.e. I've just warped to the next system and my shields have repaired 50% - why did that happen? Jumping/Space folding - In Battlestar Galactica - I like this one most of all. The jump is instantaneous (thus no time to repair shields etc.). But it takes three turns to spool up the jump drive - during which time you can't fire or use shields (but can manouver) - this means it is a possible way to escape a battle that you're losing - but not a "get out of jail free card". You're still going to get pounded for three turns - so have to judge your timing carefully. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
Space Mines Explode at a predetermined distance. Possibly different types? May be old or poor quality and unreliable. Planets of special scientific interest No trading, refuelling or re-provisioning However, one or two may be corrupt! Beacons Automated devices. Limited transmission range. May be interrogated. . Edited 2025-02-17 03:46 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Great ideas - thanks! Definitely going to have mines, but I like your idea of also having old unreliable ones. There was a joke by a Scottish comedian a few years ago when Britain was rebuilding it's nuclear arsenal, and he argued that we shouldn't build new nuclear missiles, but rather just save the money and keep the old ones. His argument was that the only thing scarier than nuclear weapons - is rusty nuclear weapons. He's got a point! He also suggested that instead of having a nuclear submarine fleet, we just make one and just tell everyone we have a fleet - then keep sailing that same submarine into and out of port with a different name badge on it each time. After all - who knows where the subs are most of the time? But I digress! ![]() I am also definitely going to try to have one or two unique planets per system. I love games like Elite, but it's massive universe makes it feel a bit bland. Everything is procedurally generated, and you can go anywhere, but it lacks depth. I would like this little corner of the galaxy to feel alive and populated. As if you are in a Sci-Fi movie. Other stations you can build Satellites which relay long range scan data to your ship no matter how far from the satellite you are. Nebula miners which gather gas (for sale) or refined matter (for building things) Storage pods So you can securely hold supplies (like extra torpedoes) Scanners to detect cloaked ships Solar Collectors Only work near stars - boost ships power recharge rate when nearby Charge Collector Same as Solar Collectors - but must be deployed in type 2 nebulas to pick up the electrical charges there Broadcast Station Attracts Empire ships to attack it, but spreads rebellions message (or vice-versa). Might be part of game mechanic for flipping systems over to your side. Trading Station Manned station that can be used for trade. This would be very expensive to build - but again would help spread influence. The idea would be that building infrastructure in each sector of space is an optional way of playing the game. You don't need to build them (you can just go blasting your way through Karathians), but it's about giving the player choice. And by allowing other factions to also build these units, it's makes the space feel more populated (and gives the player more things to blow up). I also want to have a limited number of unique star ports. So visiting each one would be a curated experience with a unique set of NPCs to interact with. So each station would have a different set of bars/restaurants which you can pick up information "The Old Withered Spoon", "Milliways", "5 Droids Burgers", "The Astronaught's Dog Inn" etc. The one constant throughout all of them though will be the amalgamated banking system where you can get loans (at a hefty interest rate) etc.... called "The Bunch of Bankers." See - this is why I knew I couldn't do a serious, gritty theme - I can't help but make puns. ![]() Edited 2025-02-17 04:43 by PeteCotton |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
As a beginner, with little money, you could possibly buy space mines from a few dodgy characters (AE dealers!) at cheap prices. They might work and might not, but at least they add to your arsenal. It might still be a good idea to remember where you left them though. :) Of course, they weigh the same as proper ones and take up the same space onboard so they might be a liability in other ways. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Malibu Senior Member ![]() Joined: 07/07/2018 Location: AustraliaPosts: 260 |
Then again, a pun-filled game is much more fun to play. A few gags and a few puns is way better than a stodgy dead-serious game play. I'm playing Abe's Oddysee (again!) at the moment and being full of gags, quips and jokes, it's a pleasure to play right from the start (...and frustratingly, I still haven't rescued all the Mudokons ![]() Glad you're making a reference to Milliways. A classy nod to some of the classic sci-fi ideas. John |
||||
phil99![]() Guru ![]() Joined: 11/02/2018 Location: AustraliaPosts: 2414 |
or perhaps the old classic "The Wunch of Bankers." |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
I like the idea that there would be scrap merchants that you could buy things off when money is low. Or maybe the stuff you need just isn't available in the local show room and you have to go to the scrappies for that shield amplifier. It might be good - it might not??? Thanks - I agree. I think it's difficult to make a game that is openly funny (because humour is so subjective), but a few puns, dad jokes and groaners definitely raise a smile from me. Thank you ![]() ![]() |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
There are some weapons that are too terrible to re-invent. The BOSS missile and the STD bomb are two of such, although they were neither missile nor bomb. They were, in fact, members of the (now defunct) class of Flexible Payload devices (colloquially known as "Faps"). These were a type of large, flexible bag containing the payload, which required a very special type of launch equipment. The launch gear was used on ordinary space portal generation techniques but used several portal generators working in synchronism. Only the final portal had a termination point, the others simply projected to a set depth so those generators were slightly simplified. The first generator portal was standard. The second was deeper but had a narrower diameter. If these two portals had started from the same point then they would both have required the same power as you can always exchange length for girth in portal generation. However, the second portal start point was projected to be just within the end point of the first one. The amount of power required, therefore, was the power of portal one multiplied by the distance from the start point to the end point of portal 2. The third and successive portals worked similarly, having to multiply by the distance from the start point to their end points in each case. You can see that within only a few stages the total power required became colossal. To reduce the power requirement the initial portal diameter was kept as small as possible and the portals could only be held open for a short time. This meant that the payload launch system had to be very fast and automated. Rather than large payload modules, which would require larger portals, many smaller modules were used so it was rather like a machine gun. With the portals aligned at the target the payload modules were simply dropped one by one into the first portal. they were initially pushed through until the first portal junction. At this point a suction effect was caused, causing the modules to accelerate down the portal "tube". As the portal generators had to run slightly out of phase to prevent the portals from collapsing backwards, the payload was also given a slight spin at each stage. Heat in the tube caused the flexible containment of the payload modules to disintegrate so by the time the payload exited the final portal it was pure payload. Each successive portal caused longitudinal stretching of the modules and the payload, so after the exit point the payload "snapped" back to form the smallest stable structure, a sphere. Long range sensors had to be used to observe this before the portals could be safely shut down in sequence. If a shutdown was attempted too early then some or all of the payload could be pulled back to the start point, with fatal consequences. The missile, for such it was at that stage, was than a large, semi-liquid mass hurtling through space, imparted with an inertial spin to keep it stable. The result of being hit by either a BOSS(*1) missile or a STD(*2) bomb were horrendous indeed. The target could be completely sealed in some cases, including airlocks and waste disposal chutes. The vehicle would be left entombed for all eternity. By mutual agreement these missiles were considered too terrible to use even in times of war so they were banned. The Stepped Portal Launch And Transfer technology launch system had no other use so it was simply abandoned. Later all manufacturing information for it was destroyed. (*1) Bucket Of Sticky Sago (*2) Sticky Tapioca Distributor Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
....the STD bomb ... I think they made a movie about this. It was directed by Alfred Itch'cock...... * *Sorry, I know that's a really old joke - but I don't often get the opportunity to use it. |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Shoot, I forgot about the "Holly Hop Drive." ![]() But it would probably be too complicated for players to use it. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
A variation on SPLAT, with more efficient portal generation and using Newton's third law to push the vehicle in the opposite direction to the portals? :) I'm sure there must be a Mulholland Drive. ;) . Edited 2025-02-18 08:38 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Oh, I do like that ![]() |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
I've been working on the ship upgrades screen. The floorplan of each ship has designated upgrade slots that can be either Cargo (Solid, gas etc.), Ships Systems (Shields, Sensors etc.), Crew (Crew, Passengers and repair bots) or Weapons. Everything has mass - so the more you pack into your ship, the more power it's going to take to move it. In the design below, I've just randomly placed everything, but in reality you probably want to split systems up, as I'm going to implement location based damage (i.e. a shot on the port side has much more chance of damaging upgrades installed on the port side of the ship). This adds more strategic choices for the player. Maybe you sacrifice the units on the port side to incoming fire, while repairing the starboard engines to escape away from the fight. ![]() My hope is to usually have multiple choices (and prices) for each upgrade slot, but the availability will vary from planet to planet. To implement this, each planet is assigned a Tech Level (0 - Primitive/uninhabited, 3 - Star Trek Federation Level, 5 - Vorlons sort of tech). Each upgrade is designated a tech level of 1 to 5. Planets will only sell upgrades that are their tech level or 1 tech level below. So a tech Level 3 planet will sell upgrades from the Tech Level 2 and Tech Level 3 pool. This will ensure a rich variety of upgrades for sale, and encourage the player to delve deeper into the system to get upgrades from the higher tech inner worlds. ![]() There is an extra tech level of 6 - this isn't necessarily more advanced than the others but just denotes it's an upgrade that can be discovered, or maybe granted by a quest (no planet will have tech level 6 or 7 - therefore it will never appear for sale). I could also use this system to provide unique items on certain worlds. For example, if I made a range of products at Tech Level 8, and then set the Synth World to be Tech Level 8 - it wouldn't be that they were more advanced than other planets - just that they would only ever sell their own upgrades (Remember they would only be selling 8 and 7 tech levels - and there's nothing at 7 - so we've just restricted them to their own product range). This could be an interesting story line where you have to befriend the synths in order to get access to their products. To talk about data structures for a bit, I had a minor quandary when programming this. - If I store the ships upgrades as a 2 dimensional array of x,y points then it's very very fast for me to access any given upgrade point (when the user puts their cursor over it), but it takes longer when I need to do a check of the ships status (e.g. after the ship has been hit by weapons fire - and some systems damaged - I have to go through all systems, including the empty grid spaces, and see how that effects power output, speed, shields etc.). - The alternative is just to store a flat array of all of the upgrades (with no spaces for empty grids) - this is very fast when I want to check the ships status, but when the player is moving the cursor around the map I have to search the list for the x,y cordinates, which is much slower. This is a classic programming problem usually sorted by linked lists etc. However, looking at the memory usage (shown below) even the smaller memory of the Gen 1 has a ridiculous amount of memory space available for variables. So I implemented both arrays (2 dimensional x-y array and 1 dimensional flat array), and keep them in synch. ![]() Now, one of my favourite programming sayings specifically warns against doing this: But by ensuring that additions or removals form the ships inventory go through one and only one procedure, I can safely ensure that both lists always match each other. Edited 2025-02-26 15:53 by PeteCotton |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
An interesting alternative to using arrays is to use strings. a% = PEEK(VARADDR n$) will give you the address of the start of a$ POKE BYTE a%+10, 16 will set the value of the 10th byte to 16 x = PEEK(BYTE a%+10) will give you the 10th byte of n$) This is more efficient than arrays as you are dealing in bytes, not 64-bit numbers. You can also use short integers (16-bit) or words (32-bit). You can even POKE in two bytes and read them back as a SHORT if you wish. So you could POKE in a 64-bit INTEGER yet still access all eight bytes individually later. You can't print these strings as they will contain control characters and tokens. The strings can be in an array. Just watch where housekeeping info is stored at the beginning of strings and arrays. Something like this might be useful for storage compartments, where you can put an item and also flags to carry status information. . Edited 2025-02-26 18:24 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
a% = PEEK(VARADDR n$) will give you the address of the start of a$ POKE BYTE a%+10, 16 will set the value of the 10th byte to 16 x = PEEK(BYTE a%+10) will give you the 10th byte of n$) This is more efficient than arrays as you are dealing in bytes, not 64-bit numbers. You can also use short integers (16-bit) or words (32-bit). You can even POKE in two bytes and read them back as a SHORT if you wish. So you could POKE in a 64-bit INTEGER yet still access all eight bytes individually later. You can't print these strings as they will contain control characters and tokens. The strings can be in an array. Just watch where housekeeping info is stored at the beginning of strings and arrays. Something like this might be useful for storage compartments, where you can put an item and also flags to carry status information. Thank you Mick. I honestly never knew any of that. I had assumed we were restricted to 64 bit numbers. There are a few places in the code where I am doing single character string manipulation (e.g. reading the 7th character from a string), but I'm using MID$. Using PEEK and POKE will almost certainly be far faster (and feels a lot more old school, I haven't used PEEK/POKE since the 8-bit days). Interestingly enough, there are parts of the code where I was reliant on the 64-bit numbers. Because they can be so large, I can store multiple pieces of information in one number eg. for a sector of space, I could store the upper 3 digits for the id of a spaceship on a grid, the next 3 digits for a starbase, then next 3 for the id of an object. e.g. Ship 24 on the grid would be 024000000. Starbase 7 on the grid would be 000007000 and so forth. Peeking/poking shorts would have greatly simplified that process (4 shorts to a 64-bit integer). But ultimately I decided that this would make it hard to convert to 16 bit systems and also didn't really save me enough space to justify the extra complexity - so I went back to a multi-dimensional array. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
I've never attempted this sort of thing with LONGSTRINGs. It may or may not work! Obviously, ordinary strings do restrict the size of your "array" to 255 bytes. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
PeteCotton![]() Guru ![]() Joined: 13/08/2020 Location: CanadaPosts: 527 |
Luckily, I'm just using ordinary strings. It's actually for the ship floor plans. I have an array of strings, with each string in the array representing one complete row of the floor plan. I then index through it looking for where upgrades can be placed based on each single character. The reason for using strings is that because I'm doing an ASCII based game, I can just print each string from the array to the screen and very quickly draw the ship. |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |