Capstone Game Post Mortem: RedBeard Run

Capstone Game Post Mortem: RedBeard Run and Curriculum

Gabriel Walters

MGMS Program

Full Sail University

September 16, 2018

Game Summary:

Game App Icon

Title

RedBeard Run

Genre

The Zelda-like clone is a 2d top-down RPG style game designed like the retro classic NES game Zelda

Platform(s)

Android systems version 22 or newer.  

Revenue model

None

Development tools/Language

Java

Android Studio

LibGdx - Frameworks Library

Tiled - Tiled Map Editor

Gimp - Image Manipulation Software

Bfxr - Sound Effects Creator

BeepBox.co - chiptunes creator

GitKraken/Underdog

Game audience

Ages 8 to 18

Curriculum audience

Ages 15 to 18

Team

Gabriel Walters

•  Designer

•  Developer

•  Sound and Music Creation

•   Art Design

•  Sprite Animation

•  Map Creation

Alena Walters - Assisted with paper testing character asset creation

Copyright/Reference 

Walters, G. (2018). RedBeard Run [Unpublished mobile game].

 Backstory:

Sound Bite

     "Learn how to make your game from start to finish using a Zelda-like Clone to understand the process (Walters, G., 2018)."

Executive Summary

     RedBeard Run is a demo game primarily for Computer Programming IV students at Licking Heights High School that is part of a year-long curriculum designed to instruct students how to create a mobile video game from initial design to gold using only freely accessible software and their knowledge of Java.

Inspiration

     When I started working as a Technology Teacher at Licking Heights High School, I realized that my students were motivated to learn code best when making games using the code that they learned. Students that I had in Computer Programming III wanted to know the next progression for them in programming. Jointly, we came up with the idea to spend a year to develop their own game from start to finish, creating everything themselves.  This would be used as a portfolio item that the students could use for internship, or for college applications.  The original idea was to make a NES-era Super Mario Bros. or Zelda game, but evolved into RedBeard Run which is similar, but has several differences in order to teach additional coding to the students.  My daughter, Alena Walters, helped with the initial creation of the characters for paper testing and RedBeard Run was born.

    The curriculum delivery was decided to be primarily through screencasts as most Youtube videos that could be found had such a small sliver of a game that it was difficult for anyone to understand how to create a complete game with a user-interface, menus, screens, transitions, and an end game scenario.  The curriculum was decided then to include the entirety of game creation from initial setup with the software to asset creation to game development using only freely accessible software.

Capstone Game Scope

     The original game scope was to have the game to be designed all the way up to the first dungeon.  This sliver of a game would include: All screens, asset management, sound effects, Creative Commons music usage, graphic asset creation, dialog trees, AI for two different enemies and for the player's movement, in-game economy, game save profiles, screen transitions, camera management, and map creation.  The design would also include several design patterns including: the observer pattern, singleton pattern, state pattern, and object pooling.  The game would also be created using an entity component strategy.  The original curriculum would include written instructions and screencasts for every detail of the game. The focus of the curriculum would focus on every aspect needed, and would be complete.

     The game has additional features that were added to enhance gameplay.  Particle effects were implemented in the game, a final boss was created to finish the dungeon, and music was created for all screens.  Screen transitions and a more thorough puzzle solving feature were removed from the final build as it would not have fit in the final timeline. The curriculum was also rescoped as their were several unforeseen screencasts that would have to be implemented, and the pacing of the curriculum still needed to be beta-tested with a real class.  Curriculum was only completed to approximately the first two months of class.

Particle effects using pooling for the dragon breath and the fireballs

Capstone Curriculum Scope

     If everything was done as originally envisioned, the game and the curriculum would be complete with written instructions and screencasts that students could follow, and use the physical classroom to design their game while I assisted them with their specific implementations of the guided walkthroughs for their particular game.  However, implementation of the screencasts proved to be more labor intensive than originally planned, and had to be scaled back.  Editing of the videos with introductions and outros had to be pushed to a backlog as the curriculum had to be run before proper order could be finalized.  Current classes could also suggest new features that they wanted implemented which could create new instruction modules for future classes using the original RedBeard Run game as a demo.

NPC dialog trees implemented

 Demo Screencast:

RedBeard Run Demo Screencast and explanation

 The Critique: What went right

Design & Aesthetics

     I designed all of the graphical assets myself using Gimp which is an image manipulation tool.  The color palette that I used adhered to the color wheel.  I used sets of triad colors with analogous colors as supplementary colors.  I wanted to have a cohesive color palette for all maps, characters, and items in the game. I stuck within these color choices fairly well, but did deviate by adding complementary colors that were darker or lighter to increase contrast.

Color triads with analogous colors as supplementary colors for contrast (Created with Gimp)

     The tiles sets that were created blended well with each other and provided just enough contrast between the characters' color palette to help the characters stand out in front of the background.

Tileset used for world building (Created with Gimp)

     

Project Management

     I was fortunate to get to test out Trello for managing my project.  Trello was huge in helping to find a good flow for each aspect of my sprints. There were times when I realized that I had overscoped a sprint, or had to rewrite my code base.  When this happened, I dedicated the time that I needed to make sure that I would get it done.  I work as a teacher at a high school, so most of my development of my capstone occurred during summer vacation.  This allowed me to dedicate more time than what was originally projected to still meet most of my sprint goals if I had over-scoped.  My adivsors were able to load screenshots or videos of bugs to Trello, which helped me to better understand what issues they were seeing that I could focus on fixing. 

Trello board using Agile/Scrum management

     If I was not developing during the summer months, my successes could have turned out very differently.  I can remember a couple of the milestones, I just would stay up and work all night because I was in the flow, and didn’t want to have to come back to the problem.  I would just work until I fixed the problem, or finished that part of the milestone. When I decided that I was going to rewrite my code to focus on using Ashley ECS, my wife and the kids were out of the house for a week.  I literally worked like a robot coding all day, and breaking only to eat and watch a movie.  I did this for an entire week and had my entire code rewritten.  I even had time to start making my own music for my game once I finished the code rewrite and the milestone that I was on.  That was very rewarding to me, and helped motivate me to want to continue to push through to finish my game.

Beepbox - Chiptunes creator **Warning - Wildly addictive

Development

     Most project activities took place on schedule.  There were a couple of times where some rewrites to my development goals needed to happen.  One in particular was designing the boss battle.  When I did my initial GDD and development goals, I just planned on having a dragon as the boss that the player would fight.  What I never considered is what the boss battle would look like.  I realized that I needed to do a lot of research on boss battles, as they follow different states.  I didn’t end up designing my boss how I originally intended as it would have been a lot different than the rest of my game in design and code implementation.  I had to push my boss design to the second development course, and just focus on the different states that I would need and how to balance the boss against the player.  When I did design the boss it went more smoothly.  I also created the dragon using layers in Gimp which was much faster for building the animations instead of the original workflow that I was doing with the previous characters.  It was also good that I redesigned the boss graphically because the initial feedback from my advisors on my original dragon design before going back to the drawing board was that it looked more like a chicken.

Cost Effectiveness

     This project was very cost effective as it cost exactly $0 dollars.  I used LibGdx as a framework to develop on Android Studio.  I implemented Ashley ECS and the GDX AI which were already a part of the framework.  I created sound using Bfxr, and music using a chiptune creator called Beepbox.co.  I created all artwork assets using Gimp which is a image manipulation tool like Premiere Pro.  None of these products cost anything.  This was intentional, as I wanted the experience to share with my students exactly what goes into making a game with little to no budget.  Time was the greatest cost as everything had to be developed from scratch, but I feel that it was time well spent.

World building with the Tiled Editor using my tileset created with Gimp

Sustainability/Scalability

     The project was sustainable and scalable, but only to a certain extent.  I designed my game around a game that students could emulate for their own game design, and would have all the necessary training to eventually finish their own game. The game was designed in a retro-style that was not pushing the boundaries on graphics or sound generation. Designing in this way would allow a student to be able to develop their own game in a year. 

RedBeard animations

If I went to 3d, or the graphics were more intensive then students would be spending a lot more time developing a much smaller sliver of a game.  I wanted them to understand the mechanics of developing a game with everything that it entails.  This could be scalable to make a much larger game as long as the focus is on the same type of graphics and audio.  It would not be scalable to originally do this for 3d, as it would dramatically over-scope their projects outside of a year.  

   

Roving NPC animations

Curriculum

     I started the Computer Programming IV: Game Design curriculum this school year.  Currently, my Computer Programming IV students are finishing up their Game Design documents (GDD) and have planned out their sprints for the rest of the year. That alone is a skill that not many high school students have.  For the second part of my capstone – the curriculum – I can say that it is not complete, but I believe I am currently meeting the objectives of teaching them how to make a game through the successes and failures that I have had.  For example, looking at their GDD, I noticed that several of them thought that implementing some of the features would be a very quick process. I had to explain to them the issues that I faced and what that did to my project.  I repeated the Storyboard class because my milestones were not broken up correctly, not granularly enough, and over-scoped.  I realized after I went through that ordeal that the features needed to be broken up so that the developer would know if a feature was accomplished, and what part of the feature was giving problems.  I had my students focus not just on writing the code, but planning time for researching their implementation, and designing their code. Their GDDs have become much more detailed after that, and they have a lot more user stories to use to measure success.

 The Critique: What went wrong 

Design & Aesthetics

     I am not an artist, but I know what right should look like.  When it came to the design of the characters, there was a disjointedness in the design of the characters.  This is an excerpt from my art analysis: 

     There appears to be a difference in style for the snake and Roving NPC compared to the skeleton, [and] RedBeard ... Some of the characters look more witty while other characters look more serious.  The snake and Roving NPC appear to have more rounded edges compared to the other game characters.  This brings disjointedness to the game characters.  The color scheme does tie in the various elements however, and there does appear to be a base set of colors that the artist is working with which does help with having a cohesive set of characters in the game (Walters, G., 2018). 

Notice in particular how the NPC and RedBeard are a different design

      I had originally figured that designing a character and their animations would be a fairly quick process.  I could not have been more wrong.  Designing the characters only using a square with 16 pixels on each side was difficult.  This is one of the reasons that I originally fell behind in my scheduling and had to repeat the Storyboarding class.  Having this extra time helped me to front-load most of the artistic design of the characters and their animations and start building them in code.  This is what helped me to stay with the development process, and meet my future sprints.  It was crucial that I had my assets ready to use. 

Project Management

     I had planned out all of my sprints using the curriculum that I created as a guide.  My advisors suggested that I should focus on creating the demo game first, and then work on the curriculum.  I am really glad that they suggested this.  If I focused on the curriculum first then my demo game might not have been done for the start of the school year.  There were a number of pitfalls that I didn’t realize when creating the curriculum.  I didn’t realize how I designed the curriculum would have caused issues when creating the game based off of it.  I coded myself into corners several times. 

Here is the link for my original curriculum:

Original Curriculum

Development

     I have had to go through several major versions of my game before arriving on my current version.  The first major rewrite was due to the way that I had originally set up the game made it extremely difficult without extensive coupling to add additional features.  I realized this problem was coming up, and heavily researched for a better solution. I arrived on Ashley which was an entity component system.  I originally set up the project with my own entity component system, but was using json files as a way to send and receive messages.  My original version technically worked, but it did not feel very responsive.  I dedicated several days to completely rewrite all of my code, and restructure it with the focus that I will have to be able to make additions in the future. That really helped me, and I feel improved my game development.  I did some more rewrites down the road to make it even easier to create entities and to customize their interactions.  

     Being willing to destroy something that you spent so much time on is crucial to really hone your game into something that you are happy with when it is all done.  However, I would have liked to spend a lot more time on research prior to coding as I feel that I could have avoided several of the problems that I had.  My initial problem was not looking far enough ahead.  I was too focused on getting my current aspect of the game working, and was not planning on what I would have to do with that code in the future when I had to make changes.  This aspect alone will help me to change how I develop in the future. I will spend a considerable amount of time after designing my game researching the libraries, and design how to implement the features prior to starting to code.  That way I won’t code myself into a corner again.  

Curriculum

The second part of my capstone was the curriculum which I had to scale back as it was too much to try to develop all of the pieces needed for an entire year’s worth of the curriculum. I settled on doing just the first two months.  Even scaling back, there were a number of considerations that I didn’t originally consider.  I had to create walkthrough videos for the software that the students would have to use and set up on their own computers outside of the school lab.  I had to create training videos for using management software and source control.  The curriculum may not be complete like I wanted it to be for the start of the school year, however, it may be better this way as I can see issues that my current group of students running through the course will have and can tweak the final version of the curriculum for future students.  

Source Control

     My use of source control was weak through most of my capstone. This caused me several problems. Instead of trying to add a feature as a branch and merging back into the master, I implemented all of my code on the master branch. Even though I was the only one developing, I found that this was not a smart workflow.  Towards the end of my project, I decided that I was going to change conversions in my code to make my game work better with Box2d and to make it easier to resize to several different sized screens.  However, this should have been something that was planned better earlier on in the project. When I implemented the changes, I introduced several bugs that took forever to get rid of.  Had I just created a branch for the implementation then I could have just checked out the master and continued as if there were no issues.  I spent way too much time trying to fix the code to get back to the pre-implementation state that I could have used elsewhere.

 Summary:

  

     My capstone was meant to prepare me and my curriculum for my computer programming students.  I feel more than ready for my computer programming students, and feel that I am a more solid programmer.  There were a number of bumps in the road.  However, learning from these mistakes will help me to be a better instructor to my students as I can help them to avoid those same mistakes in their game creation.  

     An unintended impact is that the videos that I have been screen casting for my students were searched for by outsiders on YouTube. I have been receiving comments and subscribers from those screencasts.  This was an unintended impact especially since the videos are still largely unedited and are fairly long in length.  However, this does help to confirm that there is currently a void that can be filled with the same information that I am giving my students. 

 References:

[increpare]. (n.d.). Bfxr [Software]. Retrieved from https://www.bfxr.net/

Kimball, S., Mattis, P., & Natterer, M. (n.d.). GIMP [Software]. Retrieved from https://www.gimp.org/

Lindeijer, T. (n.d.). Tiled Map Editor [Software]. Retrieved from https://www.mapeditor.org/

Nesky, J. (n.d.). BeepBox [Online Software]. Retrieved from http://beepbox.co/

Walters, G. (2018, September 2).  RedBeard Run: Art Analysis.  Newark, OH: Author.

Walters, G. (2018, January 28).  Capstone Game Proposal: High School Game Design Course with a Zelda-like Clone. Newark, OH: Author.

Walters, G. (2018). RedBeard Run (Version 4.0) [Android Software].  Johnstown, United States: Unpublished.

Zechner, M. (n.d.). LibGdx [Software]. Retrieved from https://libgdx.badlogicgames.com/