Discussion: Contract system
-
@kraiik said in Discussion: Contract system:
This feature sounds quite interesting, the first (and most interesting imo) use I thought of for this, is for private servers with bots that would offer contracts when they come into contact with the player, as a 'quest'. Upon fulfilment the bot could then offer more contracts. Effectively creating a 'quest line'.
Thats the most interesting think i read in today. I for myself wish more casual npc elements, like events of spawning raiders (a little bit more than the normal invaders, maybe a small base, like a playerroom at rc3-6), other biomes, bosses, small quests/instance shards. Maybe the contract system is a way to more active gameplay. Sharing code can be interessting, but i am not sure how usefull it could be. It can bring more player interaction, but i think a kind of ingame "clan system" would be better/easier for this.
-
Don't know if this was mentioned, but running contracts at the end of the tick might be problematic. More flexible way would be allowing contracts to be listed and executed as part of main tick (maybe as an option, default being at the end of the tick). This will allow better CPU handling (especially in the context of an OS). Contracts can then make executing frequency to be a requirement if it matters. Host can run contracts before own optional and expensive code.
An option for exposing some clearly separated host code would be nice too. Then players can define and implement interfaces for basic things like creep spawning. We already have POSIS (a solution waiting for a problem currently :)) that is implemented by several people and can be easily implemented by anyone running an OS.
For example contract can take in a context object provided by the host. It would be up to contact writer and host to negotiate exact details.
let context = {};
Game.contracts.forEach((c) => c.execute(context));
-
Quick thoughts (@o4kapuk here you go):
-
Contract versioning so that you can run a contract you've verified before without having to check for changes.
-
Contracts where you pay to run them so that you can rent code. Eg buying defense code from someone when you're under attack or renting room startup code for intershard portals. Also automated room planner would be great for contracts. Basically contracts could be NPM modules that you could run for a fee.
-
Automation is a must.
-
Barebones autoreview for contracts that checks for unclaiming/respawn/evals/infinite loops etc will be made either by the community or packaged with it
-
Contract entrance/exit functions. Graceful ways to start and end contracts, eg if a contract stores things in memory to have it clean up after itself and make sure its not overwriting. Eg accept contract, start contract, run contract, end contract.
-
Contract specific memory segment would make contracts cleaner to write and run.
-
Contract permissions: allow for limiting contracts access (eg app permissions) like sandboxing memory to that segment or locking market.
-
-
I think finishing what is already drafted... like power creeps.. should be a priority. Before even drafting new features.
Just my 2 cents though.
-
This seems like a cool feature with some fun possibilities but I do worry about it leading to some undesirable outcomes.
There is already a situation where newbie players can use open source code developed by veterans and have an extreme advantage over other new players.
These re-used code bases can be large and complex. This proposed contract system would incentivize the creation of highly modularized, highly reusable code that is built for highly specialized tasks. There will also be incentive for these contracts to be optimized at some reasonable level if they are to be accepted by those who will be executing them. These pieces of code are intended to be executed for pay and create interesting exchanges between players and in a way expand the reach of every player by using other willing players. This is a fun idea and I think it would be used in some fun and interesting ways that would make the game more enjoyable, but I also see it being used in a much less desirable way.
It doesn't seem an unlikely future where you recognize the way you are getting attacked because you read the code for it in a popular contract, or you destroy a players room and it gets built back up faster and more efficiently than the rest of their code has ever behaved because they copy pasted another popular contract for rebuilding a room.
I personally haven't been super active for a while now but when i was more active I always tried to write my own code for things except for small snippets shared back and forth on slack. I enjoyed the challenge of trying to improve my own code or come up with solutions for things. I also enjoyed being attacked by other players who I could learn from. It is fun to see how others solve similar issues. Conversely, there is little to no fun in being bested by a player who is obviously using known open source code that they did not write themselves.
I can see this contract system making this a bigger issue and causing more copy-paste playing and for that reason I am against the feature in spite of the possible fun uses it could have.
I know that many players do not share my views on this topic. Some may like the idea of being able to copy paste in code for specialized tasks. There are many games out there that are fun and require creativity but eventually become a game where if you want to be successful with little to no effort, you can just look online for popular "builds" pioneered by veteran players and copied by many in the community. I would hate for Screeps to head in that direction regardless of intent.
This is just my personal view and the way I feel about Screeps and what makes it fun for me. I know there are many who have opposing views and thats fine by me, the opposing views are valid. Not looking to spark any debates, I just want to present my opinion on the matter solely as my personal feedback in relation to the contract system.
-
@dignissi Imagine if you had to negotiate the price of food with the manager every time you went to the store! Trade would be impossible. We do that at the market here in Thailand, trade works fine.
-
@starwar15432 Market != store. If you did in every discounter/supermarket it would not work. If you would need to negotiate with every online trader... they would not do. And you do not need to inspect the goods as you would need to inspect the contract (the analogy would the to test the goods with a mass spectrometer, i think )
-
Personally I am not a fan of this feature, but as its so open ended its hard to see how it will be used in practice. I think there are improvements that could be made to combat. But as that seriously off topic I will put it in a new post.
-
I like the idea to pay others to do stuff but the current suggestion is filled with problems.
First forcing the execution at the end of the tick is unacceptable, it is not like your plumber crawls out of your phone as soon as you called him.
Second Automation is a must.
Third any code inside a contract must run within a vanilla environment to ensure safety and consistent execution.
So @postcrafter addresses a lot of my concerns but I like to make one big change, contract scripts should not be modules at all, they should be a function.
Why should they be a function? Because you can give a function parameters even at runtime.
In example the contract specifies the first three fields fixed at creation and the contractor is able to give a creep object at runtime so the script has a creep to do work with.
This method would even allow changes of those fields from the client while it is active if the contractor agrees.
-
I think the value add to the game is less than some of the other ideas I've heard, e.g. power creeps.
Unbreakable contracts seem to go against the idea of a war game, where you can breach contract and then get punished using whatever means your opponent has (including in the metagame, convincing other players to not trust you).
The most interesting nugget of this idea to me is the idea of programmatically executing code on behalf of another user, but this is actually implementable using terminal messages and public memory segments, plus if I breach the contract people can "hold me accountable" however they want.
-
So it sounds interesting with a few caveats:
With some contracts, like courier contracts, I would want to charge extra if my creep got attacked. So it makes more sense that the client puts money in an some kind of escrow and then the contract can return data on how much get's paid out (or paid back to the client).
Additionally, if the escrow is changeable, then the duration of the contracts could be also. It would allow for potentially indefinite contracts as long as both client and contractor agree.
Contracts explicitly allow rental of cpu. With the use of public segments between the client and contractor, the client could offload their pathfinding or other processing only tasks to the contractor.
Also guaranteed processing should put contracts at the start of the loop rather than the end. Not only would this help guarantee enough cpu for the contract, but it might help player's code adjust to the cpu usage.
It's certainly an interesting idea, and one I wouldn't mind getting further thought.
-
People are talking about offloading much larger pieces of code than I had first thought. Postcrafter just said on slack that "contracts are a great way to specify conditions, not execution", and I agree with him. How would people feel about a strong limit on the size of a contract. Say, 512 characters maximum. This would mean you'd be able to specify what you want done, but now how it's done.
-
I'm on vacation so I'm not following this daily. However, if automation is being completely ruled out than it is my personal opinion that development time would be better spent on some of the already announced features (power creeps, arena) instead. Without some way to verify and automate contracts it means people will have to setup a lot of bootstrapping and custom code for each contract, as well as a lot of code review, and honestly I don't think many people will engage in that.
Having some type of "contract catalog", "standard library", or "written by" verification would make this system far more usable, and without it I think this feature would be very niche.
-
I just want to post it here again:
In order to create some "marketplace-like" behavior to popularize contracts usage, we can develop a public offer system, where you create an offer without a direct respondent, and all interested parties can view all such public offers via special UI. When someone accepts a public offer, you're notified (both via UI and API) and should finish the deal to start the contract (again, either via UI or API).
Thus, creation and acceptance would be manual, but dealing could be both manual and automatic.
To make it more clear:
- You write code, create a contract (manually).
- You set up this contract to be public rather than directly invited (manually).
- The contract is then listed in the Public Contracts UI.
- An interested party views your contract and accepts it (manually).
- You finish the deal (either manually or automatically).
- The contract starts, you track the progress (either manually or automatically).
Still looking forward to hearing some feedback on this.
-
If NPCs offered contracts in a standardized form, guaranteeing that if I spend the time to code up the solution, I will have the ability to get paid over time, then that might get more people to use them. I think the ability to get a continual benefit over time is the "must-have" aspect of this feature for it to be used by players.
It still feels like "Code Review: the MMO" to me, which sounds too much like work and not like a game.
-
Am I just missing the point completely? (This is quite probable)
Can users who think they would utilise the contract system detail some example use cases to me?
Considering how few players there are (generally) in range to accept a contract that will impact my game ‘state’.
Considering how easy it is to offload long running heavy CPU tasks to an external process. (Or just save CPU / use bucket)
Considering how easy it is just to DM a user and ask for a trade (help me attack X for Y).
Don’t get me wrong, I really like the concept but struggling to understand where I would use it?
-
The public contract market looks good.
What happens to a public contract after it finishes or the contractor cancels? I would like the contract to persist and reopen as public if it has credits available.
I'd like an api to refill the credits in an existing contract.
My reasoning I'd like to be able to set up perma-contracts. E.g. wipe any room on the edge of shard0 and I'll pay X. But I only want the contractor to have the contract for <1500 ticks to give other players a chance to wipe a room.
This contract would be terribly time consuming on my part if I needed to manually recreate or refill it after each attempt.
-
I know this is kind of old, but here's my thoughts on a contract system:
Rather than contracting for executing commands, the contract needs to be based on fulfilling criteria before a deadline.
The same code should be run by the client and contractor, so they both pay the same CPU cost. The code should run before your personal loop.
If the code returns true, then you advance to the next criterion in the contract, or the contract is complete.
- Pick up 1000 energy in Shard0 by tick 200.
- Deliver 1000 energy in Shard1 by tick 2000.
Then the code for the contract would be to evaluate whether those conditions are met, not specify how to fulfill them.
So it would be tough to burn someone with bad code that just ate their CPU (since you are running it also). But writing code that says "Contractor has picked up 1000 energy units" is tricky in and of itself.
-
@tedivm said in Discussion: Contract system:
I'm on vacation so I'm not following this daily. However, if automation is being completely ruled out than it is my personal opinion that development time would be better spent on some of the already announced features (power creeps, arena) instead. Without some way to verify and automate contracts it means people will have to setup a lot of bootstrapping and custom code for each contract, as well as a lot of code review, and honestly I don't think many people will engage in that.
Having some type of "contract catalog", "standard library", or "written by" verification would make this system far more usable, and without it I think this feature would be very niche.
Agreed 10x, the ROI for both Devs and players is very low without automation built into the design. Many more exciting & powerful features in the pipeline, I think this idea needs to bake for a while still.
-
@shedletsky said in Discussion: Contract system:
I don't think it is off topic. My feedback on contracts is that while they may be intellectually interesting, I think no one will use them and I would rather the dev team spend its very limited time working on things that either make the game more playable (performance) or more fun (new units/buildings to script).
A better way to implement the same thing contracts are driving at would be to let people buy/sell CPU ticks on the market. Then there would be some liquidity and a marketplace. Without both, this feature is dead on arrival.
My 2c
Honestly this... Contracts are a feature we don't need and majority won't use.
