AWS deployment.
Hey community, Rick (Lead Game Dev) here again to share with you some of our development progress.
I hope you will be understanding of my “smaller” update, as I wasn’t available for some of this week as I went through the stressful and exhausting process of moving to a new city. I am happy to say that I am settled in and have got back into full-speed development
So to recap, in last week’s update, I shared some of our methodologies by describing how an emergent issue might present itself and what our process is to address it. We covered how we are constantly evaluating our development strategy so that when new data emerges we can ensure that we are optimally working toward our goals.
I’ll be continuing that theme by explaining my workflow in how I optimise the “prototyping phase” that is so often required in the creation of these systems.
For those who are unfamiliar with development “prototyping”, it’s often an iterative process with many attempts, dead-ends, and significant amounts of trial and error. As a result, the majority of the 1st order refinement and optimization of the design emerges.
This is typically not something you can eliminate entirely. (Following the ideology of “The best part, is no part”). This is almost always a time-heavy process and with elimination, not an option, optimization of that process is the key.)
So in the case of the AWS deployment, the way that I have optimised the prototyping phase is by moving up a layer of abstraction, allowing me to use a much faster design tool that is available at that level. In this case something as simple as digital flow-charting software (Miro).
The link will show one of my many “Depreciated” AWS design iterations (version 8 in this case). I have left some of my process notes that I thought would give some interesting behind the scene information, plus I left in a few indicators of “unreleased” planned functionality that you might scope out. Note: Download the image or open it in a new tab to zoom in fully.
This particular design prototype was “cut off” when “enough” limitations and dead ends in the general design flow had emerged. In addition, by the inclusion of some relevant user input decisions in the flowchart, it highlighted that if I was to continue with this particular “prototype” design, future “lobby” issues would be inevitable. (Something that might have only become apparent during player testing).
By doing the “mental gymnastics” of comprehensively working through the logic flow ahead of time, and the addition of utilising a flowcharting software to document that process, I’m able to (in comparison to coding each prototype) rapidly iterate through versions, collaborate effectively with other Shiryo team members, reducing the potential of future issues significantly.
Once again, I hope you’ve found these BTS peeks and general updates interesting. We look forward to sharing with you again next Sunday.
