Science fixes

Fouindor

Hello,
I'd like to submit a few ideas for science :

- More science minigames. While it's true that Science is parsecs ahead of the Artemis experience (*click* *wait* *sigh*), I think that having more minigames would add to diversity. One of the issues is that they should be balanced, which is pretty hard to achieve with completely different mechanisms.

The only minigame idea I have for now is "chromatic correction" :

The goal is to synthesize a target color, with 5 buttons (for level 1), each adding a set RGB value.

Let's say that we must generate (128 128 128) and have
(128 0 0)
(0 64 0)
(56 87 93)
(14 52 69)
(0 64 128)

The solution will be 1, 2 and 5 activated.

An improvement of the crude GUI I drawn is maybe to have both RGB values of current color and target represented.


- Fix multiplayer scanning. This is, in my opinion, the major issue with PVP as of now.
What I envision is instead of having the EScannedState for each spaceship, maybe have a vector of ScanInfo. The new ScanInfo type will be a structure, consisting of a faction ID and a EScannedState.

The vector is of course initialized empty.

The function isScanned() will be replaced by isScanned(faction). It will search the vector and return the EScannedState. If the faction id is not found, SS_NotScanned is returned. Setting scanned states will also be changed.

Another change will be in the radar displays to properly account for the aforementioned changes.
This will bring quite a change to already existing scripts but I think it is worth it. I offer to implement these changes, as long as I have the green light

Any feedback on these ideas ?

John Bono

I'm of the opinion that in a pvp fight, the science stations should have to 'lock horns' and constantly fight against each other. I haven't come up with any mini-games themselves, other than the ideal would be some kind of tug-of-war that effects missile tracking.

daid

I think your update on fixing PvP scanning is good. Note that you initially will run into some problem implementing the multiplayer replication code, but do not worry about that, I can fix that. (I just have little time to do it all)

As that does fix a long standing "TODO" in the code on scanning. And I don't think it will change that much code at all.

daid

(The extra science mini-games is another thing. See them as two separate things)

Fouindor

I've commented for now the vector replication code as I have currently my head in scanning mechanisms. It seems to be mostly okay for now, aside a few quirks I'm hoping to resolve during weekend.

Fouindor

I don't have any clues on how to make replication work, though. It seems to be on the SeriousProton side.

TrevorHillHand

Something John and I thought of as a science feature is Decoys. Since "There Is No Stealth in Space", decoys are a pretty common sci-fi trope, and a good abstraction of electronic warfare for something like this. They would seem to be a normal ship, but vanish when you scan them. Maybe better decoys are discovered after the second scan?

It could be paired with the new 'raw data' scan too, and decoys maybe show up in only one band, or not at all.

John Bono

The more I think about it though, the more I think I'd prefer missile jammers. Beam weapons wouldn't be fooled by a decoy. (Since you're close range and they can lock strictly visually.) But said jammers could make it impossible for a ship to lock missiles on a target.
Ideally, they would be launched by relay (they could even be a second function of probes if you'd want to simplify the design), and disabled by scanning them down. Ideally, this would be a separate mini-game to disable them. It would be pretty obvious that these objects in space were the jammers, so scanning them down seems like a fall-back if no one could think of a good, quick diffusing scheme.

This whole shebang would also play well into the missile re-work that T and I have been meaning to propose: to keep Weapons occupied, each missile could be composed of a warhead (the only difference currently), a guidance system, and an engine. We haven't really hammered out the details of what could change, and it's a whole different thread anyway.

Fouindor

A little idea for a Science microgame, ripped straight from a Python gamemaking tutorial :

The game “Flood It” begins with a board filled with colored tiles. On each turn the player chooses a new color to paint the top left tile and any tiles adjacent to it of that same color. [...] The goal of the game is to turn the entire board into a single color before running out of turns.

I think we could use a much smaller grid, and no step limit. Thoughts ?

cmealerjr

I'll preface this by saying I found this during an Artemis search and haven't had time to actually play yet. I am looking forward to it, and am considering doing an event at the library I work for with this game.

I sort of like the idea of the science minigame and database as it has something of the right feel for scanning. (trying to detect a signal) and then comparing it to known entities.

Since sensors would be some mix of active and passive, perhaps science could try to jam the active sensors of an enemy by trying to figure out which frequency their active sensors are using and then sending a signal on that frequency to "white out" the enemy's active sensor, using their own active sensor as the transmitter. Then you could make it take a certain amount of time to reconfigure the active sensors to use a new frequency (e.g. 30 seconds between frequency adjustments) and when you use this trick you can't target since targeting would use active sensors.

Flea11

If you do that, make provisions for visual identification to put that info into sensors if they are jammed and or cloaked. But not constant moving in the radar, say just a spot it was identified, much like battleship