TA Review - Stretch goal modifications

[John-Popovici]

Artifact Under Review Problem Statement and Goals

Rubric Section and Grade Goals are selling points - 2/3

Description of Issue

• Local multiplayer/Single-player/Online matchmaking can be condensed into one stretch goal. Ideally, if you have an online multiplayer system already implemented from the goals in section 2, then it shouldn't be a problem to achieve any of these three with not-too-difficult modifications to the code.
• Why is multi-platform support a stretch goal? The development plan lists Godot as the game engine of choice, which has multi-platform support out-of-the-box. Further justification is required for this to be a stretch goal, e.g. what modifications does the game require to run on other platforms? If no modifications are required, this shouldn't be a stretch goal in the first place.
• Dice customization and dice highlighting can be condensed into one stretch goal, as they both involve modifying the appearance of the dice, which by itself should also not be too difficult.

[John-Popovici]

We strongly believe each of our stretch goals has a valid reason to be separated, but it would make little sense to explain all of our stretch goals in the document. Perhaps we can ask for more clarifications and if our justification below makes sense @Necried

• Local and online multiplayer cannot be condensed into one stretch goal because the use of a LAN server and of an online central server is very different. The networking structure is different and would require dedicated work to make one or the other work. For example, as of writing this message, we have local multiplayer working but do not have the infrastructure set up for online multiplayer. As an example, hosting a minecraft LAN server is simple and built into the game, yet hosting for friends online would require port forwarding or the use of an online server. These goals are vastly different even though the end user might not make as clear of a distinction. If we were to have online multiplayer we could theoretically ignore local multiplayer and even local play could be done online, but having offline local play would require a new networking system be put in place, which again, would be justification for having it be its own stretch goal.
• Single player, again, cannot be compared to multiplayer variants. While multiplayer must have networking work done but no decision making algorithms required, singleplayer would require this new system be implemented. Having all these stretch goals collapsed into one would have a very high threshold for completion and each needs a new system that would not be reused in others.
• Multi-platform is a stretch goal because we have never used GoDot and have no easy access to any apple devices. While it may be easy to compile for multiple platforms, considering our resources, as well as our unfamiliarity with the GoDot process of designing and compiling, we have given it its own stretch goal. We do not see all goals as equally large or difficult, but they are all uniquely different and wanted to keep important things clear and separate. No code-based modifications are required for this stretch goal, but additional testing would be. For example if this were not a stretch goal, we would have no official reason to even compile for the mac OS environment, but there is a personal ask and having it be a stretch goal shows and serves as a reminder of what we want to do.
• Finally, when it comes to dice customization and dice highlighting, they might seem similar but would make use of very different mechanics and serve wildly different purposes. Much like in the above point, a stretch goal itself need not be difficult for it to be a goal. In this case, these are both unique functions that the game would be implementing but are not required and have no interdependence. Dice customization would require that the dice modelling be done such that the texture or surface or numbering be customization, which even this could get complicated, if for example the numbering and the skins have to all be compatible. This would differ from dice highlighting, which would require game logic to determine which dice are used in each hand pattern and highlight them for ease of use. Other than the fact that they have a visual effect on the dice (or around them), these stretch goals are unrelated and testing and implementing them there would be little to no overlap.

The issue can remain open until we get some feedback, but we could also look to explain these factors in the documentation. How such comments would best fit into the documentation is not too clear, however.