Developing Version 1

Write a reflection about your personal reactions to moving into your first development efforts in both Scratch and Portal 2. Which environment are you excited to work in - 2D or 3D? What is the draw of your preference? Which role do anticipate being more challenging - level design or programmer? What aspect of this area do you feel will require the greatest effort and why? What study disciplines might use this technology?

As a dev ops engineer, automation junkie, and programmer, both Scratch and Portal 2 excite and challenge me in different ways. As we progress through the required readings, I’ve been gaining a greater appreciating for the importance of the Mechanics, Dynamics, Aesthetics game design framework. Both Portal 2 and Scratch provide scaffolding, although Portals scaffolding is far more in-depth. Scratch’s scaffolding is more infrastructure allowing the learning of programming concepts without writing any code. Scratch is a blank canvas, while Portal 2 provides a level builder.

While I’m more excited to work in 3D environments, I won’t be spending much time in one for this course. Since this is a Maymester (three-week course in May), we simply don’t have the time to delve into the 3D design portion of this course. However, if I was to assume that we would have time, I would probably still be more interested in working in the blank canvas, than in the confines of teaching Physics in Portals 2.

That’s not to say that designing lessons in Portals 2 is without its challenges. I just believe that Portals 2 has a limited scope of applicability. However, the benefit of working in Portals 2 is that the design aspect is already done. All that is left is coming up with the lesson and puzzles that correspond with it.

I tend to believe that design is easy and programming is hard, but that is coming from someone who really does not like the design aspect of most work. I believe that design and programming are two different intuitive skill sets. Basically, a good game isn’t designed by one person. Rather a team of designers and programmers are hired to collaborate on the entire project. As I’ve stated already, I am a programmer; I can do design, but I am typically not proud of it.

As I watched the tutorial videos, in particular the cat and mouse video, I was not really impressed with Scratch’s available mechanics and aesthetics. Some of the sprite options seem a bit too cartoonish for what I originally had in mind, but after spending a couple of hours playing with the program I started to warm to the process. Pulsipher’s (2011) advice about how to properly approach game design was much more relevant to Scratch. The beginning-to-end game assignment helped me to think through the mechanics; which provided the direction for my aesthetics and I definitely settled on applying this concept here. After reviewing many of my peer’s board game designs, I got the impression that I was trying way too hard. I will be stepping back a bit on the aesthetics of future assignments for this course. Since Scratch is teaching me as I go, I must focus on these two elements first before trying to get fancy with what the game looks like. I will focus on creating variations on important dynamics from some of my favorite games which Pulsipher (2011) recommends. He reminds me of something that I struggle with often: reigning in my ambition. Scratch’s blank slate is tremendously exciting for a creative person. However, given the scope of the class and the need to eat, sleep, and care for my family, I will be holding myself extra accountable for sticking to a game that will help me learn the fundamentals, experience the game design process, and adhere to the requirements for the assignment.

Overall, LeBlanc’s (2006) discussion of the mechanics, dynamics, and aesthetics of game design guided me in applying my understanding of the recent course readings. The board game design helped me realize that I can be creative when I need to be, and while it remains a struggle, I’ve gained some confidence in that area. Hopefully, I will be able to continually refine all of these parts into a cohesive whole and present something that is both challenging, yet mechanically sound.

References

• LeBlanc, M. (2006). Tools for creating dramatic game dynamics. The game design reader: A rules of play anthology, 438-459.
• Pulsipher, L. (2011, May 16). So You’re Going To Make A Game For The Very First Time? [Web log post]. Retrieved from https://www.gamasutra.com/blogs/LewisPulsipher/20110516/7453/So_Youre_Going_To_Make_A_Game_For_The_Very_First_Time.php