For various reasons I will not elaborate on, I have been considering what a linked list fetch modus looks like for a sylladex. For those who do not involve themselves in the sacred arts of data structures, a linked list is a type of data structure using nodes and pointers, where each node contains some data, and a pointer pointing to the next node in the list. Generally, there are separate pointers pointing to the first and last node in the list; these aren’t nodes themselves, just vague ambigious non-entities that do nothing but reference the first and last nodes (head and tail respectively). There are also doubly linked lists in which each node points to the previous and the next node, and circular linked lists, wherein the last node points back to the first node. An advantage to this type of data structure is that nodes can be placed anywhere in the linked list rather easily. For example, in a singly linked list, node 3 just needs to point to the new node, and the new node to node 4, and suddenly the new node is part of the linked list.

My initial guess is that for a linked list modus, each card is a node. When an item is first picked up, this becomes the head (first node) card, and then subsequent items retrieved follow after the head card. Cards at the head and tail (last node) can be accessed freely, while cards in the middle need to be accessed by using each card before it (forward traversal through the linked list) or after it (backwards traversal through the linked list) in subsequent order. However, new items do not necessarily need to be added at the end or beginning of the list; if there are unused cards, the item can be placed anywhere in the linked list at will without much hassle. if there are no nodes (cards) available and a new item is picked up, the card at the end of the list is ejected.

My only problem with this is that it’s essentially just the queuestack type that john makes in act 2 i believe, except with the added mechanic of new items being placed in the middle of the queuestack instead of either the top or bottom. Also, to be really accurate to linked lists, the data (item) in each node (card) doesn’t need to be accessed for traversal, just the pointer to the next node. If that’s the case for the modus, then it’s no different from an array modus, where any item at any position can be retrieved at will. What do you all think?

  • jjj
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    14 days ago

    A linked list fetch modus could pull from a physically based fetch modus like Kanaya’s chastity modus, except each node has a map to the next key.

    We could also pull inspiration from Dave’s hashmap modus, where each pointer is an index into an array. Each element of the array costs a captchalogue card, and the index for the next node is randomly selected from the set of empty cards. Only the last card can be removed when decreasing the amount of captchalogue cards. Only the head card can be accessed, and when the item is used the head is moved to the next node. Items are inserted at the tail.

    An extra ability could be to swap a full card with an empty one on the array (without changing the previous node’s child index, thereby splitting the list). Additionally, the head index can be altered manually. Doing any operation that reads an empty card (e.g. using an item whose node points to an empty card) causes all items to be ejected after. The tail index may be adjusted manually, and inserting an item always overwrites the next index of a node.

    Example
    head = nil
    tail = nil
    __ __ __ __ __
    
    Captchalogue A:
    head = 2
    tail = 2
    __ __ A_ __ __
    
    Captchalogue B: 
    head = 2
    tail = 0
    B_ __ A0 __ __
    (nil is different to 0)
    
    Move B to card 3: 
    head = 2
    tail = 0
    __ __ A0 B_ __
    (captchaloging an item or using A causes everything to be ejected)
    
    Set tail to 2: 
    head = 2
    tail = 2
    __ __ A0 B_ __
    (using A causes everything to be ejected, B is now inaccessible without adjusting the head)
    
    Captchalogue C: 
    head = 2
    tail = 4
    __ __ A4 B_ C_
    (using A is fine, B is still inaccessible)
    
    Set head to 3: 
    head = 3
    tail = 4
    __ __ A4 B_ C_
    
    Use B: 
    head = nil
    tail = nil
    __ __ A4 __ C_
    (head and tail are set to nil automatically when using an item whose next card is nil)
    
    Captchalogue D: 
    head = 1
    tail = 1
    __ D_ A4 __ C_
    (if tail is nil it automatically sets head to the selected index)