rwarnking
commented
2 months ago 12.08.2024 Discussion
According to issue #25 we discussed the queue subtree.
Queue game
We began by discussing the two most basic scenarios:
- A. The game gives the player a queue that needs to be processed by the player.
- B. The player defines a queue in the game that need to be processed for example by NPCs.
Scenario A was supposed to be indicated by the queue game tag. Unfortunately we found, that deciding when a game falls into this category was difficult, since ultimately every game gives the player a list or queue of tasks that needs to be processed. Ultimately making every game a _queue game_, which would be a useless information to tag. Originally originating from games like Dorfromantik that for example display a representation of a queue in form of a card stack this tag was found to be badly named and misplaced.
Instead we concluded that it might be more promising to add a tag turnbased as part of the mechanics subtree and or a tag _card game_. The first tag would generally allow to indicate the pacing of a game, while the second one focusses on games that specifically choose to represent a feature in a certain way for example in form of a card stack similar to a skin(Hand of Fate, Slay the Spire). Here it might be interesting to note, that unlike in real life the medium does not have any restrictions that would require the game to present a random queue in form of a card stack and is done purely for aesthetic reasons.
Player queues subtree
Further discussion of the player queue subtree revealed that the depiction of queues in general might be overfitted since it originally seemed to be highly relevant for the externalization question. Based on this we decided to simplify the tree such that is less difficult to choose the tags.
Direct & indirect, parallel & sequential queues
We began by discussing the direct and indirect tag. These are supposed to represent games in which the player can either directly assign tasks to an individual unit (The Sims™ 3) or where the game lists the tasks inside of a queue but assigns the tasks on its own to the NPCs (Prison Architect). Even though we agreed that there is a difference it was unclear why this features needs to be represented by its own tag. It could be argued that this would clearly differentiate games that use this special approach, but it would still only apply to a few games and might therefore be to detailed.
Following this we found further examples that made the classification more difficult: In Prison Architect the game directly adds the commands to a queue, but there are also games like Warcraft or Banished that allow the player to give a selected group a task like harvest trees - these tasks are also managed by the game and most likely implemented using a queue. This on the one hand introduces more nuances (like _queue: continuous_) but at the other hand makes it more difficult to access whether it should be tagged as a queue at all since the game might not provide a visual representation of the queue.
This discussion coincides with the parallel and the sequential tag, since they often appear in combination. Here the important differentiation is, that a parallel queue is processed by multiple units while in a sequential queue only one item is processed at a time.
Based on our discussion we decided to remove all these tags in general. Even though the proposition was made to rename the direct and indirect tag to queue: individual & queue distributed it appeared to be easier to remove these tags altogether after a short review of which games where already tagged with these tags.
Input buffer
This tag was inspired that provide a very short input queue that main purpose is to allow the player to queue actions in a time critical fighting scenario (DARK SOULS™: REMASTERED). When discussing the specifics of this tag multiple problems where apparent: Firstly this type is queue is usually not visually represented, leading to the player not even knowing that a queue is used. This would also make detection difficult, since this must be recognized to be in a game to be tagged. Secondly in contrast to a lot of other tags this is a highly implementation specific feature, where it might be difficult to grasp how the queue works or how many elements can be queued.
Even though it can generally be interesting to represent implementation specific features, such that an analyst might get new information of a game, we agreed that this would be out of scope for this subtree and at most a discussion for the future. Therefore leaving this tag to be to specific for the current subtree and leading to its removal from the tree.
Realtime
Finally the last tag of this subtree was the realtime tag. It was added for games like Dota 2 and opposing to games that pause the game or dilate time to allow the player to queue actions (Fallout 3, Mass Effect™ Legendary Edition, Transistor). Similar to the other tags this was agreed upon to be removed. For this tag the argument was mainly that this feature is only relevant as a game mechanic and for the pacing of a game, not for the queue itself.
Conclusion
We agreed to focus on cleaning up this tree. For this we decided to remove all tags of the queue subtree, such that the tag only indicated whether a game contains a queue or not. We also defined the tag to be only applicable when a game visually represents some player inputs as a queue. Invisible queues will not be tagged via this tag. Regarding the special cases a follow up discussion might arise naturally in one of the next phases, but for the moment we agreed that it is not necessary to differentiate between them.
Proposed actions:
- Delete queue game
- Delete action queue
- Delete direct, indirect
- Delete parallel, sequential
- Delete input buffer
- Add card game to unknown tree
- Add turnbased to unknown tree
- Revisit pause screen or dilate time as a game mechanic
- Revisit special cases later on
Game table
| game | queue | visually | indirect | direct | parallel | sequential | turn based | |
|---|---|---|---|---|---|---|---|---|
| Transistor | :heavy_multiplication_x: | :heavy_multiplication_x: | ||||||
| Sims | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | ||||
| Banner saga | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | |||||
| project highrise | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | |||||
| banished | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | |||||
| starcraft | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: | :heavy_multiplication_x: |
Supplement
Following our original discussion we again discussed games that manage the tasks that the players inputs. Especially games like Banished or Starcraft allow the player to assign tasks like harvesting resources, where the tasks itself are managed by the game and assigned to the individual units by the game. Here the important distinction must be made that these queues are usually not visible to the player. Furthermore this is a highly specific and technical aspect of the game functions.
The currently most important factors for a queue getting tagged as a queue are:
- A. visual representation of the queue
- B. the player chooses the content of the queue
Other features would need to be represented via a technical aspect subtree, which most likely should not be added at all, since this would be highly speculative anyway. (Example: Internally this game uses queues.)
Previous Issues:
2
Open questions
07.04, Tag Iteration A-Z:
Investigate the queue in Slay the Spire in particular.15.04, Tree Iteration IV:
merge actionqueue into queueplayer, rename queue: game, rename queues to action queues