Subtopic	Posts		Updated
	Archive through September 21, 2004	25		09/21 04:49pm

Hmm, this is prolly not the place to ask, but is kinda is too...

If I were to post my suggestions for a single player module/rules section on one of my websites, would this be ok? Or would it be breaking ADB's online policy?

By Joseph R Carlson (Jrc) on Tuesday, September 21, 2004 - 11:00 pm: Edit

Would the "robot ship" rules just control the other ship or both?

By Peter David Boddy (Pdboddy) on Wednesday, September 22, 2004 - 06:24 am: Edit

I am aiming for the robot rules to be able to control a number of ships, so you could have two robot ships go up against each other, or you could play a single player fleet battle, and so on.

But first, I am just trying for a single ship...

By David Lang (Dlang) on Wednesday, September 22, 2004 - 08:16 pm: Edit

Joseph, if the rules are good then they should work if you pit two ships each controlled by these rules against each other. (if this doesn't work then a player doing the same thing would cause the same problem )

By Joseph R Carlson (Jrc) on Wednesday, September 22, 2004 - 10:18 pm: Edit

David,

Thanks for your response. I suppose what I was thinking a solitare module would allow ; me the player to follow the SFB rules (make my own decisions) and have a system that guides the enemy ship. I am not against robot rules for both sides but it is another set of rules that controls my ship(s). My concern is as a new player the experience won't translate to games with real people as it is a seperate gaming system using SFB.

I hope I am clearly expressing my thoughts here. It appears robot rules are a different direction than solitare rules. Alternately I maybe confused and not understanding the development direction.

By Peter David Boddy (Pdboddy) on Wednesday, September 22, 2004 - 10:46 pm: Edit

I believe that robot rules and solitaire rules are one and the same. I think people are dreaming ahead, and imagining two autonomous players (what I've called the "robot" in the scenario) fighting.

If the solitaire rules work, then they could quite possibly be translated to work on SFBOL.

http://www.geocities.com/pdboddy

It's definitely a work in progress, I've a mess of notes, and as I'm typing things in, I'm making changes. People's thoughts and ideas on what I have so far would be spiffy.

Energy allocation for the AP should appear during the course of the day tomorrow.

Movement is going to be interesting to do I think, and combat even more so.

Writing up a flow chart is going to be... different. It'll likely end up being at least two charts, possibly more. You'd just pick the one suited to the opponent you are playing.

By Jeff Johnson (Jeffro) on Thursday, September 23, 2004 - 09:57 am: Edit

If Peter can write decent playable robots for the CA and D7, then it should not be that hard to build on his efforts so that we can have decent Solitaire rules for Sabotage, Surprise Reversed, Basic Privacy, and the Aux CV scenario.

I'm really looking forward to it, Peter!!

By Seth Iniguez (Sutehk) on Thursday, September 23, 2004 - 02:56 pm: Edit

Peter,

Not sure I understand the point of the Mission table. If an AP drops your #1, and that was its goal, then what? Did it win? While another AP has to capture you to win? Capture isn't even viable in many ship combinations. It seems like it would make more sense for the goal to be your standard tourney goal, Destroy the Enemy!

Do you spend 1 bpv per space of drones for medium drones? That sure is alot of fancy stuff, I'd be suprised if someone was able to cram that much in to one drone rack.

By Peter David Boddy (Pdboddy) on Thursday, September 23, 2004 - 03:22 pm: Edit

I did say I wasn't up for the math at the time I was writing the part about the drones. :P Not that I spend 1 BPV for a medium drone, but it's about there. Depending on the configuration, some might be more expensive, some might be much less... It was a rough number so that you can allow for a decent loadout of drones, to pick a base point value relatively quickly.

The mission table is just a rough idea, what is there isn't final by any measure. It might make more sense when I have the energy allocation, movement and combat sections completed. If your goal is to down a ship's #1 shield, you are going to play differently than if you are trying to blow the enemy to smithereens. The energy allocation, movement and combat sections will reflect this. I wanted to provide an "AI" of sorts that wouldn't just overload photons and rush to range 3 or 4 every single time.

By Peter David Boddy (Pdboddy) on Thursday, September 23, 2004 - 03:25 pm: Edit

And, perhaps it's not clear enough, and I will fix this... the player on the single mission chooses a goal as well.

By John Kasper (Jvontr) on Friday, September 24, 2004 - 11:12 am: Edit

The idea of some sort of mission for the robot is good, but there is a problem with the player knowing what it is.

How about a deck of cards, with goals assigned for each card. At the end of each turn, draw a card and see if the robot has achieved its goal. If so, it wins and will disengage. If not, the robot addopts a battle policy that is appropriate for that card, and you draw a new card next turn and check again. The downside of this is, of course, that the robot will have shifting goals and that might make the play a bit random.

By Peter David Boddy (Pdboddy) on Friday, September 24, 2004 - 03:27 pm: Edit

That's sort of what I had thought as well, but it would likely get the AP killed, since the goals could change every round, it might find itself improperly armed/powered at an inopportune time.

By David Lang (Dlang) on Friday, September 24, 2004 - 03:36 pm: Edit

for the first pass make a robot that works with a single goal, don't worry about the other player knowing the goal, just worry if the robot functions.

after this works you can go back and worry about how to deal with the player knowledge (having a program that plays it on SFBOL would be one way of hiding the info from the player for example)

for testing figure that you will sometimes need two players. one to fly a ship, and one to run the robot ship

By Richard C Magee (Fltadmrich) on Saturday, September 25, 2004 - 08:47 am: Edit

Boy, I really started something! i hope to see a module come out of this!

By Spencer Rathbun (Spencerr) on Wednesday, October 20, 2004 - 11:51 am: Edit

I would suggest that the first design should have 1 or 2 desisions for the robot. Get those to work and then expand upon that. The great problem with a game like SFB having a solitaire opponent is the players ability to determine what the robot is going to do before the robot does this. So we have an advantage to the player which is immpossible to remove without something, like a computer, to move the robot. However, we can give the robot an advantage to balance out the player's advantage. Such as the robot only completes part of its ea at the beginning of a turn. So the player, who does thate ea, only has a limited knowledge of what the robot is doing. Then during the turn, have the robot complete desisions. For the first test, have the robot power house keeping, arm phasers, standard load all heavy weapons, and move at an estimated speed. You would use a function to calculate this speed. It's only objective is to get within range four of it's opponent. Then all left over power is discretionary for the robot to use any time it wants.

This creates "what-if" situations. Say I'm flying my Fed CA towards a Klink D7 controlled by a robot. I know how he armed weapons etc. However, various decisions are made during play at the time they are needed. This is the only way to keep the player from having total knowledge of the robot and turning him into a puzzle. Once the anwser is found he can be beaten quite easily.

Back in the test, I would then have a function at the mid turn point where the robot decides if it had a mid-turn speed change allocated. This surprises the player in the same way a human does, except a human allocates it at the beginning of the turn, which a robot cannot. Finally, once the robot gets to range 4 a function would decide whether it would fire weapons or not.

I am in the middle of designing all the functions described above. But anybody who has a suggestion to this design would be much appreciated.

By Jeff Johnson (Jeffro) on Wednesday, October 20, 2004 - 12:19 pm: Edit

I see what you mean:

The energy could be steadily allocated through the turn based on die rolls in response to various option points.

For instance, the Klink has maybe three or four main options: an attack outside of overload range, an attack just inside of overload range, an attack at range 3 or 4, and an overrun.

He's going to be trying for one of these every turn. You don't want the player to know what he's picked. You need some kind of criteria to determine the odds of an attack at each point. You also need a base EA that each attack could conceivably build off of.

Once an attack is made, you roll a die to determine how many disrupters how many overloads, and how many phasers are fired. The energy for this is allocated right then.

If the Klink is attacked first, you roll a die to determine how much defenses are allocated. When the Klink finally does attack, any roll that uses too much energy can be ignored and rerolled. That leaves a balance of unallocated energy that can be used for shields and mid turn speed changes.

Good idea! I look forward to testing out the results.

By Spencer Rathbun (Spencerr) on Wednesday, October 20, 2004 - 02:50 pm: Edit

You guessed exactly how I had it planned out in my head. And thanks for the complement. I'll try and post a rules writeup soon.

By Joseph R Carlson (Jrc) on Wednesday, October 20, 2004 - 09:52 pm: Edit

Spenser,

Interesting approach. I also look forward to how this works out.

By Spencer Rathbun (Spencerr) on Thursday, October 21, 2004 - 02:11 pm: Edit

Ok. Repeat this section every turn.
Player Completes eaf.
Robot pays housekeeping, charges all empty phasers, holds charged heavy weapons, standard charges uncharged heavy weapons. (lets stay away from overloads right now) Use Function 1 to determine energy for movement. All leftover power is discretionary.

Each impulse in which the robot moves, the player moves first. Then the robot moves as a drone turning to keep the player's ship facing the #1 shield.

Then just use the functions and procedures at the time they list.

Function 1. Energy for movement. Take the distance between the robot and the player. Divide this by 2 and subtract 1d6 from the result. This is the most likely distance to be traveled by the player. The robot's speed equals the range minus the player's speed plus 1d6.
Example: 30 hexes between ships. 30/2 = 15 + 1d6 =
19. 30 - 19 = 11 + 1d6 = 17.

Function 2 midturn speed change. At impulse 15 determine whether the robot had a midturn speed change allocated. Roll 1d6 plus 1 for every 10 hexes away the player is. if the result is 1-3 then no midturn speed change. if the result is 4-6 then the robot had a midturn speed change of 2d6 to his current speed. Change the eaf to show this. However, if discretionary power runs out pay as much as you can.

Procedure 1 if range <= 4. Once the robot gets to range 4 determine whether he will fire. First the player decides if he will fire. Then calculate the robots maximum df output and the players maximum df output by adding the maximum damage all df weapons in arc can cause. If the players damage total is 6 or greater than the robots total determine minimum damage output for each by adding all df weapons minimum damage together. if the players output is still 6 or higher than the robot's then calculate range 0 maximum damage output. If it is 6 or higher than the robot's damage then add 2 to the die roll. Add 1 to the die roll per unfired drone rack, f or g plasma, 2 for an S plasma, and 3 for an R plasma. Roll 2d6 plus modifiers. if the result is 2-7 then the robot will not fire this impulse. if the result is 8-12 then the robot will fire. If the robot does not fire, repeat for each impulse the robot remains within range 4. Once the robot fires switch to escape plotting. The robot will move as a drone except he will attempt to keep the player facing the number 4 shield.

This is a test to see whether the basic principals will apply. Note that the robot has no procedure for ecm, shield reinforcment,overloads, or using different shields if #1 or #4 are down.

Finally, do not use the hydrans, the robot doesn't "see" the fighters, the lyrans, the esg isn't a plasma a drone or a direct fire weapon, the tholians, web will devestate the robot, and the ISC might be a problem. For the above reasons avoid using the Orions with anything from above. There is a multitude of ways to annihilate the robot by taking advantage of the way he moves and how he has no way to deal with certain things. Such as incoming drones or plasma. He won't see them and will drive right through them. Flying ships that use these will provide insights into how to make the robot see this stuff. But right now I just want him to be able to fly, no matter how stupidly, a fed ca versus a klingon d7.

I'm going to try and test this system tomorrow or the day after but if you get any results before than thats great!

By Chris Smith (Casmith1) on Wednesday, December 22, 2004 - 01:42 am: Edit

How did the solitaire game go?