Visual design choices in conjunction with SCRUM
|
Friendship Down is the first form of concrete game development that our group, a squad of first year students, undertake. Lack of prior experience – potentially both within the field of our respective minors and in the processes of development as a whole – was initially present in all of us. It was important to consider this context as we moved into the production of the game. SCRUM encourages an early assessment of risks and potential causes of project failure, so that preventative measures can be taken. Our group identified general risks, such as failure to deliver assets on time, team members leaving, or sickness interfering with development. However, it is reasonable to think that several other – to us unpredictable, due to our inexperience – issues can arise. This thought had an impact upon my character design choices, leading to a decision to have all characters in the game use either hoverboards or some other means of levitation. This was meant to minimise the risk of artistic, technical issues leading to assets being unable to be plausibly implemented into the game, potentially compromising the game’s shippable state.
For example, in the original concept most characters were either moving on foot or riding upon other entities (entities which themselves moved about – on varying amounts of legs – on the ground, see image).
This would require heavy emphasis on proper animation, as the game’s minimal marketable product would require plausible character movement to maintain some degree of immersion and believability. Neither of the group’s artists had prior experience of animation, which presents a risk where unforeseen failures in animation would have major ramifications on the entire project.
To compensate for this, and to reduce the risk factor of animation, all characters were made to levitate above ground. The designs are shown below.
This decision was important because it regulated the game from being overly reliant on a specific element to meet the project’s minimal marketable product, the MMP. Animation could encounter great issues, failing to produce quality results, but the game would still be and look relatively plausible as levitation at the core simply consists of up and down motions. On the other hand, a game with characters that are supposed to move on foot but instead inanimately glide around would be largely unshippable. Furthermore, neither does this design decision have any negative impacts on the possibilities of good quality animation, should things go well; a character using a thruster engine as a means of movement can be animated to the same level of satisfaction as a leg-bound character would (below are images showing the stages of increasing complexity in character animation). In short, this decision has made it so that animation can be considered a natural part of the iterative, sprint-based approach of SCRUM, where in the early iterations animations can be made at a basic, primitive level, yet still reach the project’s MMP, should technical disaster strike in the later stages of production.
Comment on other blog post: Hello, (William Teurnell, Team Poltergeist) I enjoyed your post. It is systematic and comprehensible in an easy-to-follow way. You lead the reader into the text well by having a form of short introduction; your main point is summed up early. The same goes for the ending, where you sum up the points that you’ve made. I do, however, notice certain lacks of clarity at places. The fourth paragraph, regarding Trello, is somewhat unclear to me. I did not understand at first that you were *not* using Trello. You discuss the reasonings why you decided not to, but as I see it there is no counterweight. What *did* you do or use, instead of Trello? It feels like this paragraph lays the groundwork for a point that doesn’t get made. You say that you would likely go for Trello in the future; that half implies that whatever method you used in this project did not work out — but I don’t know what method that was, so the meaning of the paragraph feels lost, in a way. You do a very good job pointing out the flaws of the stand-up structure (and I can tell you that I share the same experience), but I do see some room for expansion on the topic. It feels a little one-sidedly focused on the issues of the execution of stand-ups. What are the benefits of standups, if any? Did they positively or negatively affect you in some way in terms of motivation/productivity, etc)? You get into this in the last sentence, but it seems a little cut short. It would be valuable to hear some thoughts or reflections on the value of standups as a thing, not just about how hard they were to organise. (I love the image. Fishes are fun) Regards,
https://artdevsam.wordpress.com/2018/02/22/scrum-and-sirens/comment-page-1/#comment-3  |
