@tigga said in Season #2 concept:
Or old players from joining the season. Personally I feel a player's performance should be measured by how well their code performs, not how many freinds they have.
One way to fix this and turn it more into "global coop" would be to re-enable the market. I'm not really interested in trying to coordinate between a ton of neighbors who live in different time zones & speak different languages. We all "speak the same language" when it comes to the market.
Honestly, this idea makes a lot of sense.
@SemperRabbit has a working branch of the code, and I can't see a single thing that would break if done properly (since seamless inheritance like this is literally the point of objects)
@artch can you name a single thing that would actually break with this change?
I would also love to see something like #2 implemented. (Possibly as something to put in the center of the ring of source keeper rooms?)
Can be both. Code is proposed by the party creating the offer, and an offer can be created by any party. When you create an offer, you write code and choose one of two options:
I am the client (I pay) I am the contractor (I execute the code)
Glad to hear. Is there any plan to support "catalog" contracts? (i.e. the contractor creates a "catalog entry" for remote mine defense), and players are free to accept that offer with certain terms (e.g. {room: "W12N14", whitelist:["Alice","Bob","James"]}), and the contract module contains a function to calculate the cost for different parameter sets.
Little example pseudocode I wrote for a module:
//@param options.room: string (Room name of room to be defended)
//@param options.whitelist: string[] (People to not shoot at)
module.exports.loop = function(options) {
if no creep exists
spawn creep
return false
if creep.room != options.room
moveTo room
return false
else
hostiles=find creeps not in options.whitelist
if (hostiles.length>0)
attack(hostiles[0])
return true
}
module.exports.bid = function(options) {
myroom=find my closest room to options.room
range=distance between myroom and options.room
if (range>10) {
return false; //No-bid on this one.
} else {
//bid 100*range credits as a contractor's fee.
return 100*range;
}
}
Without at least automating simple contracts like this with variable parameters, I can't see contracts becoming very useful. (This lowers the barrier to entry so that even small 1000-tick-long contracts could be practical. If 2 people need to be online at the same time and negotiating, working with contracts would be a massive effort and inconvenience.)
While I understand that automated code-review is not something that you would be interested in allowing, if a module like that could be setup as a non-editable offer in a player's "catalog", then other players could manually review the code, and have their code automatically request quotes/bids for tasks.
I don't see contracts being very useful if you have to negotiate them every time. Imagine if you had to negotiate the price of food with the manager every time you went to the store! Trade would be impossible.
It is handled as usual, you will see an error in your console.
But if contracts are "read-only", is there any way to fix this error? Perhaps have something like: if a contract fails an assert(), then it dies at no cost to either player?
I have a couple of questions/concerns here:
Terminology: Client=Guy paying $$$, Contractor=Guy doing work.
Is the code for a contract proposed by the contractor, or by the client?
Is the client able to cancel his contract? If so, does the contractor get paid in any way when the client cancels?
If a contractor is locked-in to a contract, and is unable to edit it, what happens if there is a bug that makes the contract unsatisfiable? Is the contractor doomed to waste CPU on a fruitless contract forever? In this case, I doubt that any rational person would ever accept a contract. It would make far more sense to me to allow players to break contracts (potentially with some kind of penalty system, such as credits kept in escrow or similar).
What happens if the contractor runs out of CPU on a tick or encounters an error? Is the contract code still executed?
What if a contract throws an exception? How is this handled?
What happens if a player gets wiped out and needs to respawn? Many of his contracts may no longer be applicable to the new location, and it seems unreasonable to saddle players with obligations that may out-live their empire's lifetime.