Cool charts! I found them easily understandable (which is great), but I can also see that we have been thinking about this differently.
In your own independent chart it struck me that your flowchart does not actually describe the algorithms working the game. I mean, sure, you can definitely see the algorithm in something such as "circles in the background pulse to the beat...". However, I actually see this more as a flowchart of the interaction space. Now of course this interaction space is defined by the algorithms in the end, but in this case your flowchart is communicating how the program is supposed to be used and the layout of the interaction space. I have specifically thought of the flowcharts as a conceptual manifestation of the algorithms. I would then argue that your flowcharts are showing more of the rules concerning the games, and the player's interaction space and experience, rather than describing the specific workings of algorithms.
This is not a criticism btw. It works really well, because you are centering your communication around the user's experience of the game instead of bringing in all of the setup(), the "background" workings of the game so to say. This sort of communication would perhaps be more important in other circumstances, but importance in these cases are determined by the context. I found your flowchart very accessible to read and understand. Games really work well with flowcharts if you want to highlight the rules and the mechanics (but also not getting too much in depth with the algorithmic structure and how the algorithms specifically work).
Your group flowcharts are also good. My only criticism is that by following the flowchart in "Platform Sidescroller", I understand it so that you can only get hit by obstacles if you jump? Otherwise, the flowcharts are also very accessible (good ideas btw). Granted, your conceptual descriptions of your program are also on a very early stage so explaining the basic defining rules can be enough to communicate the concept, but obviously the flowcharts will have to become more complex, in order to represent your work, once you start actually working on one of the ideas. Then I would also argue that your flowchart would take on another role. Rather than communicating an idea it would have to communicate your conceptual understanding of how the game must be built with algorithms.
Lastly, I am missing some reflections about the nature of an algorithm, and the thinking behind taking flowcharts and using them as representations of algorithms, and how this can be an advantage or a disadvantage.
Hello Anne!
Cool charts! I found them easily understandable (which is great), but I can also see that we have been thinking about this differently.
In your own independent chart it struck me that your flowchart does not actually describe the algorithms working the game. I mean, sure, you can definitely see the algorithm in something such as "circles in the background pulse to the beat...". However, I actually see this more as a flowchart of the interaction space. Now of course this interaction space is defined by the algorithms in the end, but in this case your flowchart is communicating how the program is supposed to be used and the layout of the interaction space. I have specifically thought of the flowcharts as a conceptual manifestation of the algorithms. I would then argue that your flowcharts are showing more of the rules concerning the games, and the player's interaction space and experience, rather than describing the specific workings of algorithms.
This is not a criticism btw. It works really well, because you are centering your communication around the user's experience of the game instead of bringing in all of the setup(), the "background" workings of the game so to say. This sort of communication would perhaps be more important in other circumstances, but importance in these cases are determined by the context. I found your flowchart very accessible to read and understand. Games really work well with flowcharts if you want to highlight the rules and the mechanics (but also not getting too much in depth with the algorithmic structure and how the algorithms specifically work).
Your group flowcharts are also good. My only criticism is that by following the flowchart in "Platform Sidescroller", I understand it so that you can only get hit by obstacles if you jump? Otherwise, the flowcharts are also very accessible (good ideas btw). Granted, your conceptual descriptions of your program are also on a very early stage so explaining the basic defining rules can be enough to communicate the concept, but obviously the flowcharts will have to become more complex, in order to represent your work, once you start actually working on one of the ideas. Then I would also argue that your flowchart would take on another role. Rather than communicating an idea it would have to communicate your conceptual understanding of how the game must be built with algorithms.
Lastly, I am missing some reflections about the nature of an algorithm, and the thinking behind taking flowcharts and using them as representations of algorithms, and how this can be an advantage or a disadvantage.