3. Discussion: Contract system

Discussion: Contract system

  • Culture

    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.

    👍
    1 Reply
  • Dev Team

    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:

    1. You write code, create a contract (manually).
    2. You set up this contract to be public rather than directly invited (manually).
    3. The contract is then listed in the Public Contracts UI.
    4. An interested party views your contract and accepts it (manually).
    5. You finish the deal (either manually or automatically).
    6. The contract starts, you track the progress (either manually or automatically).

    Still looking forward to hearing some feedback on this.

    1 Reply

  • @artch

    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.

    1. Pick up 1000 energy in Shard0 by tick 200.
    2. 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:

    @artch

    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.


  • This sounds cool to me. A few thoughts if someday this revives:

    1. For the folks asking for 1st class support of parameters that are distinct from the contract, I think the community can build that capability without needing anything extra from @artch. Just define a community convention that contracts look something like this:

       const parameter =
 { "arbitrary", "json", "here" }
 // -- END PARAMETER -- 
 module.exports.loop = ...

      Instead of thinking of contract string as code (which it still is), think of it as a serialization format for a tuple (parameter, contractTypeId). This format can be both programatically formatted and parsed/validated. For example parse/validation looks like this:

      a) The string starts with "const parameter =" and contains somewhere "// -- END PARAMETER --"

      b) The string in between those two is a valid json object

      c) The string after "// -- END PARAMETER --" hashes to a SHA512 that you recognize, presumably from a white-list of contracts you have manually vetted before inserting them in your AI.

      d) Based on recognized code SHA512, validate the parameter object conforms to any additional input requirements for a contract of the given type

    1. I'm definitely in the camp that probably wouldn't use this unless contract issuance and acceptance was automated. I think of this similar to an advanced terminal. I'd have to write code to decide when it is appropriate buy ghodium, but once that code is written my AI can buy/sell ghodium automatically indefinitely into the future. If the community defines a new contract called PAY_FOR_A_NUKE I'd have to code my AI to determine when its appropriate to issue/accept PAY_FOR_A_NUKE, and now its automated. Working with the PAY_FOR_A_NUKE contract, given an comunity supported OSS code base that wraps it in a terminal-like API, doesn't seem much harder to automate than the game's actual Nuker or Terminal. I don't believe that contracts in general are unautomatable snowflakes even if some subset of them are.

    1. I don't see how you would avoid needing to run contracts in an isolated VM, otherwise the contractee can cheat. The isolated VM would presumably could still charge its cpu/memory usage to the contractee, as well as have some access to the contractee's game objects and memory.

    2. As an alternative to formal contracts, you might encourage players to make informal contracts that they have to police themselves. Public segments already provide a communication system for arranging deals, but I think it would currently be tough to monitor a deal, or to provide payment. Those issues might be resolved via an API that shares visibility of a room with another player, and with an API for private terminal transactions. Its probably a lot cheaper to implement than contracts, but it also probably wouldn't facilitate as much deal making, especially among untrusted parties.

    1. Priority relative to other things - I'm neutral. Contracts sounds like a feature that would offer a cost-to-coolness ratio similar to other things I've heard you might be working on.

  • This seems like an idea that would be fun to program for the devs, but not very usable in practice. If this is added to your todo list, I hope it will be with the lowest priority possible, there are so many other things that would be better to spend your time on. Just my opinion.