Register Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
ryleyra

Registered:
Posts: 2,492
Reply with quote  #1 
A post in this thread, https://artemis.forumchitchat.com/post/2-6-0-development-suggestions-8532217, suggested adding the ability to leave a sector and reenter it, while retaining the layout of the sector left. The original post was more along the idea of suggestions for the overall game, but as it applies to the TSN Sandbox and other scripted missions, I began thinking of some script commands that might help create a semi-persistent environment.  

I thought it best to post these ideas here instead of the original thread. In addition, this is future development, and not necessarily development of 2.6 specifically. So these are just ideas for long term plans for mission scripting.

I'll also add that in the past I have suggested the idea of loading "subroutines", or code files which can be loaded from a script and executed, possibly without replacing the currently loaded code. This could be used to create a static sector layout. All you would have to do is write a script file that creates a given sector, and load it from another script file. The sector would be created, and your original script could continue.

Anyway, my idea is to expand on the existing create commands to specify a random location for the object instead of generating random variables and using them to set the coordinates. This would use the same syntax as use_gm_location:

<create type="nebulas" use_random_position="yes" count="20" radius="5000" randomRange="5000" randomSeed="1357" />

My use of randomSeed is important, because I'm only guessing here, but I'll be willing to bet than if randomSeed is the same number, the random distribution of nebulas is always the same. So if I use the same random position and the same random seed, I should get exactly the same nebulas. So I only have to store the seed and the position to recreate this part of the sector exactly.

Now, to make sure I generate the same random position, I have a couple of options. I could use the same seed to generate the same random coordinates, but then I would need a different seed for the next call to use_random_position. What I would prefer to do is use a seed on the random number generator itself:

<set_random_seed randomSeed="2468" />

Now the first time I call use_random_position I will get a set of coordinates, the second time I will get a different set of coordinates, and so on. As long as I start all over with the same seed, I should get the same list of coordinates. It would be nice if this seed influenced randomIntHigh/Low and randomFloatHigh/Low as well.

Why don't I use the randomSeed property to generate the use_random_position coordinates? Well, that would be possible, but I want to be able to use this property to create named objects too. So I want this command:

<create type="enemy" use_random_position="yes" raceKeys="enemy standard" hullKeys="small" fleetnumber="1" />

... to create a Kralien Cruiser at the next random location in the list. The create command doesn't have the randomSeed property because named objects are created one at a time, not in a random cluster.

I'd like to bring up another possibility. Right now, the enemy created above would be given a random name, meaning it could not be referenced by name to change any of its properties. If set_random_seed applied a seed to the random name generator, however, I could initialize the name list with a seed, create some objects to find out what their names were, and then access them. As long as I used the same seed, I could keep using the predefined names.

So in fact the set_random_seed function could have another property to indicate what function it should apply to:

<set_random_seed type="position" randomSeed="9753" />
<set_random_seed type="variable" randomSeed="1024" />
<set_random_seed type="name" randomSeed="3141" />

As implied above, you could even initialize the different random functions to different seeds. However, this depends on how Thom has implemented random numbers, and whether these functions make use of different or the same generators. I don't really know if using randomSeed in create changes the following selection of random numbers generated with set_variable. I'll have to do some testing to find out.

I'm also just using a 4 digit number as an example. In theory a random seed should be any integer value.

Finally, I would add a command to remove all objects but the player ship in the sector, such as clear_sector, or add a "named" type (which would destroy all named objects of any type) to the destroy_near command.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,759
Reply with quote  #2 
I do like the idea of being able to re-create random names for reference purposes. That would be handy. In fact I like all of the ideas that you have proposed.

Nevertheless, most of what you propose could be achieved with the current mission scripting system. It would simply require tens of thousands of lines of code.

In my mind the weakness of the mission scripting system is its lack of methods for the players to communicate with scripts, especially Science. I very much want mission scripts to have ways for players to interact with the game. For example, ideas for the Science Console:

  • Science should be able to scan generic objects. At a minimum they should have a desc and a scan_desc field.
  • The script should be able to control the size and shape of a generic object's position symbol on the Science Console.
  • The script should know what object the Science Console is looking at/scanning just as the script knows what object the Weapons console is locked onto.
  • The script should be able to send robust information to Science, akin to the current pop-ups but more like the new Comms buttons. These would be used to convey environmental information not related to a particular object. For example: "Radiation levels in this sector are at 80% of human tolerance!"
  • Unnamed objects like nebulae and asteroids should have data fields that Science can discover.
  • Monsters should have vital statistics that Science can discover (more than just the lifebar).
  • It would be super cool if a script could show the various custom data fields above in analog readouts like the existing shield frequencies and monster lifebars.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,759
Reply with quote  #3 
The next console that needs to communicate better with a mission script is Engineering. The mission scripts should be able to tell:

  • The current power setting of every system
  • The current coolant setting of every system
  • The current temperature of every system
  • The aggregate damage level of every system (without adding up the various nodes)
  • The physical locations of DamCon Teams

Aside from mission scripts, for years I've been asking Thom to give Engineers "Advanced" buttons that allow them to do things that are not "by the book." The list I sent to Thom includes "Bypass deflector shield safety interlock" and other safety bypasses. Each of these allows a certain system to be repaired in an emergency while sacrificing something else on the ship. The sacrifices would be significant . . . and Engineer that bypasses everything willy-nilly would be crippling the ship.

While the bypass idea is separate from the mission scritping system, it would be necessary for mission scripts to detect the state of the bypass controls.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
ryleyra

Registered:
Posts: 2,492
Reply with quote  #4 
I agree with both of the above. Of course, console interface with a mission script is a different thing from the mission script being able to read important values, and that's a different thing from making sectors persistent, which is what brought about this post. However, I would say that ALL fits under the heading of "future development of mission scripting".

I definitely think that generic meshes could stand to have some additional functionality added, and it could stand to be added sooner rather than later. I'll also point out in response to "Unnamed objects like nebulae and asteroids should have data fields that Science can discover." that you don't really need that functionality if that functionality is added to generic meshes. Just plop down a generic mesh in the middle of your nebula or asteroid field and set the data fields on that mesh.

You can "sort of" control the shape of the generic object's position symbol, but it's kludgy. I noticed Fish Evans was able to make generic meshes appear as silhouettes, but I didn't even know generic meshes could do that. (Or how he did it)

It would be interesting if monsters had data fields that appeared on a second scan. Maybe the data could be involved with resource gathering. For instance, Science could determine which Anomalies the monster will drop, or which it is most likely to drop. Again, if the script can override scan and scan_desc, so much the better.

Scan_desc also needs to work for ally ships, or objects that don't need to be scanned twice. (Although one possible use for scan_desc on generic objects would be to indicate that the generic object needs to be scanned twice)

Did I also mention that player ships on the other side in PvP should need to be scanned, instead of displaying their information to both sides?
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,759
Reply with quote  #5 
On the subject of persistence, over the years I've often heard Thom mention the fact that there is no computational reason why the sector size must be 100,000 x 100,000 or any limited number. In his career as a game developer he has made plenty of games with infinite maps. He knows how to do that. I believe he selected the current game scale to give a certain optimal play experience (mission duration, enemies killed per minute, etc.) for newbie players. The 100k x 100k map is perfect for creating missions in which newbies can achieve a glorious victory after about 40-60 minutes. An infinite map would give newbies a lot more ways to fail, and make it hard for them to tell when victory was at hand.

Consequences for mission script writers:

On the plus side, an infinite map would allow mission scripts to build in a ton of persistence for a much longer game.

On the minus side, an infinite map would instantly make all existing mission scripts worthless.

But what if Thom created two game modes: Normal Map Mode and Infinite Map Mode? Existing mission scripts (and regular games for newbies) would still work with Normal Map Mode. Mission script writers could write brand new scripts for longer-duration missions in Infinite Map Mode.

What would you think of that?

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
ryleyra

Registered:
Posts: 2,492
Reply with quote  #6 
Quote:
Originally Posted by Mike Substelny

But what if Thom created two game modes: Normal Map Mode and Infinite Map Mode? Existing mission scripts (and regular games for newbies) would still work with Normal Map Mode. Mission script writers could write brand new scripts for longer-duration missions in Infinite Map Mode.

What would you think of that?


Sounds like a good idea. I was thinking along the lines of variable size. You could for instance declare a 100kx100k sector, a 200kx200k sector, a 500kx500k sector, a 1milx1mil sector, or a 1.5milx1.5mil sector. However, there's a saying in programming, "You should either allow 0 objects, 1 object, or 'more than one' of an object." For any other value n you can always decide later that you want n+1 instead.

To that end, "100kx100k" and "Infinite" seems like a good pair of choices. With Infinite you can make a sector of any size.

I will say, though, that in my testing with the 10 Times Sector Mod it got VERY difficult to get across the map on the available fuel in a 1 million by 1 million sector grid. Bases would have to be intentionally placed at waypoints across the map to allow for refueling, or some other method of efficient long range travel would have to be developed.

Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 1,759
Reply with quote  #7 
One thing to keep in mind is that impulse engines use minimal energy. If you want to really simulate a space mission, it should take your ship weeks or months to reach a destination.
__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
Xavier Wise

Registered:
Posts: 985
Reply with quote  #8 
I like the sound of an infinite sector size. The sandbox would be adapted easily enough depending on how everything works.

How would an infinitely large sector work with multiple ships, particularly on the science console?

What about getting an overview of the whole area you are in (how do you zoom out)?

What happens with scripting for placing objects at particular coordinates?

What happens if a crew sets course and just keeps flying (this is probably quite straightforward... they fly into the abyss of space) but what about the skyboxes or terrain?

__________________
Captain Xavier Wise TSN Raven (BC-014)
Link to TSN RP Community website
Link to TSN Sandbox
Link to Blog
ryleyra

Registered:
Posts: 2,492
Reply with quote  #9 
Quote:
Originally Posted by Mike Substelny
One thing to keep in mind is that impulse engines use minimal energy. If you want to really simulate a space mission, it should take your ship weeks or months to reach a destination.


Well, technically even at the speed of light it should take you years or decades to reach any destination outside of the solar system. But most space operas don't have that kind of time.

You've got a point, though. Impulse drives take ten times as long as Warp, but take no energy. Fuel, which powers Warp Drive, allows you to get to the scene of the combat before the attackers destroy their target and move on.

In an infinite sized sector, you could pace the attack waves of the invasion so the players have time to get into position before the next way begins. Of course, they would have to have some way (perhaps through Comms) to know where the enemy will appear next.

I think my point is that you can't just scale the game up by 10 or 20 times and expect it to play the same.
ryleyra

Registered:
Posts: 2,492
Reply with quote  #10 
Quote:
Originally Posted by Xavier Wise
I like the sound of an infinite sector size. The sandbox would be adapted easily enough depending on how everything works.


I agree, especially since you will no longer need to implement edge-to-edge sector traversal. You can still have Jump Gates, but that would take you from one infinitely large sector to another. (Or perhaps just another point very far away in the same sector)

Quote:
How would an infinitely large sector work with multiple ships, particularly on the science console?


That depends on whether the maximum range of Science remains the same. I would suggest that the previously implemented Unlimited Sensors range be changed to a finite range of 50k. (The value set for playerSensorRange in artemis.ini) Long Range Scanners would then be limited to the existing sector size even in an infinite sector.

The question then becomes, can Science see through the sensors of allied bases and ships outside of the existing maximum sensor range of 50k, or is it limited to using Comms to contact those targets and ask then for a status report? If the latter, the Science console can be limited to the same maximum size it has now. If the former, there will have to be some way to zoom and scroll beyond the 50k limit.

I would say the question of whether Comms can see targets outside of 50k is a valid one as well, but in a script, there is not likely to be so many targets generated that Comms can't list them all. If Science is limited to 50k, Comms will be able to see objects that Science can't.

Note this comes very close to the way Empty Epsilon manages Science and Comms.

Quote:
What about getting an overview of the whole area you are in (how do you zoom out)?


Well, as I said above, the LRS would be limited to 50k, which is the maximum range the ship itself can see. If there is a "sector" map, then it would have to be a separate function, and somehow, it would have to be able to display the WHOLE displayable area, no matter how large it is. Of course, it could start with the 100kx100k size and be able to zoom out, if needed. But if so, who is in charge of this map, and how is it zoomed with the interface?

In the old Super Star Trek game, for instance, there was the sector map, and the quadrant map of 8x8 sectors. But that was a known, finite size, while we don't know how large our sector is. It could be 2x2, 4x4, 8x8, or 20x20. And if you want a map of the whole region for reference purposes, you will have to somehow figure out what that size is and what point it is centered on.

Alternately, you can ignore a reference map and just use some other mechanism to navigate around the sector. Comms could ask objects outside of the 50k limit what their bearing and distance is from the ship. Or Science could have a navigation feature which lists major objects (like bases) and their direction and distance. I do think players would much appreciate an overview map, though, even if the script writer himself created it. (As you do with the TSN Sandbox)

Quote:
What happens with scripting for placing objects at particular coordinates?


Well, I'm assuming that with an infinite coordinate plane, you would just place objects where you want to. As you place object further and further away from 0,0, the sector would get bigger and bigger. What about people who start the sector at 0,0 and progress it out infinitely in the positive direction, instead of those that center it at 0,0?

And what about the third dimension? Is this an infinite coordinate plane that ranges from 500 to -500 in the y direction, or is it an infinite coordinate SPACE? And if it is infinite in all three dimensions, how do you set course to Warp up?

Quote:
What happens if a crew sets course and just keeps flying (this is probably quite straightforward... they fly into the abyss of space) but what about the skyboxes or terrain?


Skyboxes I assume would remain the same no matter where you are in the sector. (So different skyboxes would require moving to another sector - through a Jump Gate or what have you) No matter how far you travel you will never come close to the "edge".

Terrain I assume will just recede into the distance, unless the script has placed terrain there. Keep in mind, most of space is EMPTY. Gravity pulls objects towards each other, so nebulas and asteroids and such tend to gravitate (pun intended) into a system. And even at that, you could start from an asteroid or something and fly through a whole lot of nothing for a very, very long time before you found something else.

That's in real life, of course. In a game you can program whatever you want. [biggrin] I would say that in general, though, a given system of bodies would form into a rough ellipsoid, and gradually become sparser and sparser as you continued from the center until they gave way to the void of space.

ryleyra

Registered:
Posts: 2,492
Reply with quote  #11 
Let me also note that it's possible that the limitation of an infinite sector is not the size of an infinite sector, but the number of objects in an infinite sector. You could overwhelm the server by creating a whole Sandbox in a single sector, even if you had infinite space in which to do it.
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.