Part 1/3 of the sl-route toolchain. Current deployment here
just run npm run deploy locally and wait 1 minute 👍
The top level object is our map. The idea is to first of all, have a rough overview over the map with our collection of areas, currently still called major locations. Another field in the map object is the items array. All items are declared right here and only referenced by their ID later on (NOTE: Right here items only consist of a name and an ID. Later on, when creating actual instances of them in the areas they also get a count and a condition). Each area gets divided into locations, currently called minor locations, that logically divide the area through doors, fog-walls or similar blockers. Each location may have any amount of
- connections to other locations that may only be available under a certain condition.
- items, modeled by selecting an item-type from the root items-object, a count and a condition.
- enemies. They have a name, drop some souls, may respawn, spawn under a condition and can drop some items (either guaranteed or by chance). The items should also be selected from the root items-object. You add a count and specify, if it always drops.
- objects with arbitrary interaction possibilities. This will probably be the hardest thing to model later on. Maybe start out with just being able to interact once with every object to later be able to use them in conditions.
- npcs. They will also be relatively complex, having different quest-progress states changing their locations, interactions and shop-inventory. Also simplify for now to single state -> just make them have a shop.
- Quest-Line modeling for npcs with interactions, how they travel through the world over time and unlock more shop items / gifts.
- Write specs about NPC questlines and their progression
- selection from condition verbs based on subjectType
- enemy alive && killed
- write down concrete requirements in a user-story like style
- tbd
- Proof of concrept: Model a bonfire with the current OtherObject System (more of a research task)
- Restrict inputs that logically should only accept numbers to actually only accept numbers
- OtherObject with type constraints -> not anything, but select from collection of bonfire, lever etc. with fix interactions
- Enemy templates similar to item types
- Assistance for creating bonfires as other Objects
- edit map names
- finish missing displays, mainly enemy and NPC
- edit atomic conditions
- Rely more on dependency injection -> Reduce unnecessary event bubbling up and just straight up inject map manager service (e.g. on object creation). But watch out: Might not be possible everywhere, since we may need to know details only known on higher locations.
- Use forms
- Possibly split different IDs
- Meta tags and info-dump in root of sml file
- do we really need this 'bubbling', now that the IDs are clear? -> updating minor stuff without reference to major
- work with dev preview conditional templating
- unify create and update methods in map-manager service and upstream event stuff
Past roadmaps etc
- Written down concrete specs and requirements for this app
- Write glossary
- Write down current requirements
- Write tests for some of these requirements (all of them will be progressively completed over the next few releases)
- test extractor service
- test id service
- test parsing service
- test map loading service
- wrap shop item builder in own component
- Make map objects classes with easily-selectable interface implemented
- map from interface to class
- area from interface to class
- location from interface to class
- connection from interface to class
- item from interface to class
- enemy from interface to class
- otherObject from interface to class
- NPC from interface to class
- easily selectable from type union to interface
- don't use weird passing of functions in location card component anymore for to string
- Move toString methods to related classes
- list of available connections doesn't show a connection just by saying its id => use name of 'to' instead!
- de-generalize object manager into different components
- split off connection manager
- split off item manager
- split off enemy manager
- split off object manager
- split off npc manager
- move and unify "extractConditions" to abstract-manager
- move details and other manager unspecific stuff to abstract-manager
- unify createOrUpdate, edit and delete Pipeline
- declare in abstractManager
- move every shared piece of logic into abstractManager
- move related files to new utils directory in sources root
- Revamp item system
- Revamp ID system
- Rework map loading
- load existing atomic conditions into corresponding builder on map load
- Edit functionality
- edit major location name
- edit minor location name
- edit connection
- connection needs ID
- edit items
- edit enemies
- edit drops
- pass starting conditions
- edit other objects
- edit NPCs
- edit shop items
- clear builders on create / confirm edit actions
- connection builder
- item builder
- enemy builder
- otherObject builder
- NPC builder
- Change area / location naming scheme
- majorLocation to area
- minorLocation to location
- select from all doesn't show enough information
- too specific requirement, will change with design, so skip for this alpha
- make condition clearable
- generally clear fields on create and update
- Stop using === equality for objects in map manager and switch to ID equality
- Loading maps doesn't update MapManagement ID Counter
- Can't create connections (probably also other Objects) without conditions
- Loading conditions from save doesn't update abbreviation counter in condition builder
- loading connections doesn't work after ID introduction
- item builder change detection fires always on change during edit, possibly also other builder -> might be fixed due to editing flag
- update connection seems bugged
- deep copy condtions in builders to avoid weird references after clearing