Pylons-tech / pylons

https://pylons.tech
Other
25 stars 123 forks source link

DevTool 2.0 #883

Closed StefanB90 closed 2 years ago

StefanB90 commented 2 years ago

Summary

Problem Definition

The DevTool is not ready for external consumption. The fact that you have to have the pylons node installed on your system to run it sucks, and the lack of any features for modularity/reusability means even very simple recipe systems like the current flutter-loud ones can be miserable to debug and consistency check.

Even if something nicer would be out of scope, it'd be well worth looking at trying to put a very simple text preprocessor layer in place so you can store common elements as macros and then just include those instead of making sure twelve recipes that include the same item all agree on what that item is by hand.

Proposal

DevTool Rewrite

  1. Tx broadcasting
  2. Recipe validation
  3. Cookbook validation
  4. put init
  5. put validate
  6. put remote
  7. put create
  8. put update

Arguments/substitution for #include macro Currently, the #include directive supported by the Pylons dev tools splices some JSON directly and unaltered into a document. It’d be significantly more powerful with some basic templating - so that’s what we’re doing.

The #include directive should take an arbitrary number of tokens, separated by single spaces, after the name of the module to include. Each token should be substituted for the appropriate placeholder in the module - if the tokens are red blue green, %0 is replaced with red, %1 is replaced with blue, etc.

Validate command should provide useful errors in the event validation fails due to a module include

At present, if including a module causes a recipe or cookbook to be invalid JSON, it will fail to validate (which is correct) with some sort of weird JSON parse error, because we don’t validate until after macros are expanded.

This makes it difficult to trace the source of validation failures. We should instead identify that the module is the source of the validation failure and, ideally, tell the user what’s wrong with it.

Additional testing for module import/parse

We have one very simple test case for module importing, but we’ve already managed to hit weird behavior that doesn’t occur in the test on our own. We need a big suite of torture tests that do as many horrible things with our macro system as we can think of, so’s to ensure it behaves as correctly as possible.

Create flag on dev update command

Batch updates can be kind of messy at present; there should be a flag for the update command that makes it fall back to creating the recipes in the case where they don’t exist.

Design note for demo app

This is a single-page note (not really a proper design document - demo app is deliberately incredibly simple anyway, doesn’t really warrant a full design document) covering the goals/flow of the demo app. Design notes, not really a design document:

Goals

a) adapt existing example project as much as possible (don't get too far out in the weeds) b) minimal, text-based c) mechanics must be sophisticated enough to show utility of tools - needn't be more than that

map a) make a character - this is free b) punch goblins for coins, spend coins on sword c) slash trolls for shards, spend shards+sword on lv2 sword d) slash dragon w/ sword, win

complications a) enemies each deal damage to character - if you hit 0 hp you are Dead - hp can be recovered by resting (one of three time-delay recipes, recovering 25%/50%/100% over 5min/7min/10min)

losing a) fight a higher-tier foe than your character+gear can handle - you die, lose everything, must restart b) hit 0 hp during normal combat - you die, lose everything, must restart

recipes

  1. start game
  2. fight goblin (unarmed)
  3. fight goblin (armed)
  4. fight troll (unarmed)
  5. fight troll (armed)
  6. fight dragon (unarmed)
  7. fight dragon (armed)
  8. buy sword
  9. upgrade sword
  10. rest 25
  11. rest 50
  12. rest 100

BE: Demo app recipes --> Recipes outlined in design notes must be built, tested, and created on-chain

FE: Demo app designs --> Front-end for demo app is a simple console application that presents players with a numbered list of options based on current context (ex: 1) fight a goblin 2) rest for a moment 3) rest for a bit 4) rest for a while ) and executes a recipe based on the provided input.

Following completion of the demo app, devtools badly need a refactoring/code quality pass to address both previously outstanding issues and newer kludges resulting from ongoing hotfixes made in the course of dogfooding.


For Admin Use

MikeSofaer commented 2 years ago

One thing I would like to add is an instant full rest for 9 Pylons Points.

afti-githobo commented 2 years ago

One thing I would like to add is an instant full rest for 9 Pylons Points.

implemented this