Welcome!


Welcome!

This site showcases the thesis capstone projects for the Full Sail Mobile Gaming Master of Science program. Students completing the program post their end of program project self evaluation here examining what went right and what went wrong during production.

The site provides examples of all completed projects, without regard to the quality of work. Final faculty evaluation of your project is separate from your postmortem. It is a place to share student work and start dialogue with faculty about completed and upcoming projects.

If you are adding a postmortem for a completed project to this blog, please do your best to provide a meaningful meta-level evaluation of your project. This helps students currently in the program have a better understanding of the critical points related to independent production, game development and design and project management. The template for the blog content and instructions can be found in the first post from July 2014.

Thank You,
MGMS Faculty

Sunday, September 1, 2013

Capstone Game Postmortem: Spell Book

Capstone Game Post Mortem: Spell Book

Game Summary:
Game App Icon




















Title

Spell Book











Genre

Educational

Platform(s)

Android and iOS



Revenue model

There is no revenue model associated with this game. It will be released free through the Apple App Store and Google Play.

Development tools/Language

The development tools used was Unity for the overall development and implementation. I used Photoshop for some more art modifications or additions along the way.

Game audience

The intended audience is children in grades Kindergarten through Fifth grade.

Team



I worked alongside CelleC Games as a developer intern. CelleC Games is owned and operated by Gerard Merritt (Executive Producer). The following team members contributed to Spell Book’s design and/or development of assets.

Original Concept By – Matthew Hirtenstein
Producer – Pablo Rosero
Lead Designers – Rodrigo Santelices
Programming – Will Whittaker
Designers – Nicholas Reynolds, Dylan Smith, Pablo Rosero
Lead Artist – Laura Sardinha
2D & 3D Artists – Aarnel Castillo, Nykira Parham, Will Whittaker
SFX Artist – Silvia Padron
Music Artist – Marlon Castro Rivera





Copyright/Reference

CelleC Games. (2015). Spell Book (Version 3.1) [Android Game]. Winter Park, FL: CelleC
Games.

Spell Book, Spell Book Icon, Spell Book Banner, and the CelleC Games Logo are Copyright ©2015 CelleC Games. All Rights Reserved.

Capstone Screencast


Backstory:
Sound Bite

Be a wizard! Complete the spells in this Spell Book to create your own magic! Learn as you play!


Executive Summary

Complete spells and spell words as you swipe letters. In this game the player must choose spells that they want to complete from the Spell Book and are then given the words that are in the spell. Once the game starts they must swipe letters to complete the words in the spell(s). Players can also complete alternate words by swiping letters that would finish a different word than in the spell.

Inspiration

I’m unsure what the motivation was behind this game. The game was meant as a spiritual successor to another CelleC Games title, called Math Slash in which players would slash number to complete simple math equations.



Capstone Scope

The scope originally was to provide an educational learning experience to children while they were at play. The scope was fulfilled completely.

Ideal

Honestly, everything did go as perfectly as it could have. All of the ideals were met as originally designed. The only thing missing from the game in its final state was a couple camera animations to add a bit more depth to the space/game environment. Originally it was planned to have the camera zoom in slightly to the Spell Book on a podium and await the player to tap the screen to open the book. Then the player would be able to navigate through the book by tapping the menu options in order to flip through the pages of the book. Once the player navigated to the point of the game starting, the camera was supposed to zoom out away from the podium and rotate upwards to face the gameplay background.

In its current form, there aren’t any camera animations, as it would have required a bunch of additional 3D environment assets to fill up the space to provide something other than a blank/black empty background when the player started the game. While the above would have been nice to have to provide a bit more effects and a clever use of 3D space with a 2D game, it was more of a polish feature than anything and did not hinder the functionality on the game in any way.

The Critique: What went right…

Overall most things went right in the process of developing this game. This is one of the better projects that I’ve been a part of. As far as the development itself, the programming that I was responsible for, and the implementation of the functionality, there wasn’t a whole lot that didn’t go right. Aside from the bugs that popped up along the way, most of which weren’t hard or time consuming to fix at all, everything came together really well throughout all 3 months of development. I enjoyed this project and working with the team quite a bit.




Design & Aesthetics



There were a lot of things that went really well in regards to the design document, the mechanics, and the balancing of the game. The artwork in its final form seemed to work really well and was very consistent to the theme and style that were intended in the very beginning of the design. I came into the project after the design was already created so I had the pleasure of going through the design document and providing suggestions and requests for clarification where needed. The audio is very smooth and fits rather well with the rest of the game, providing a mystical and magical aesthetic. When it comes to the UI screens and controls, these were carefully planned and tested to be the easiest and most clever usage of space possible for the given circumstances. There was very little narrative except in the way of a very brief tutorial with voiceovers though I believe this works well also.





Project Management

In regards to the project management, I had a lot of fun utilizing the Underdog system. It was quite a handy tool and I especially enjoyed the task tracking and management section of it. I believe the system was based off of Redmine and this was the first time I had ever used it. I would definitely recommend it to others in the future because I found it to be extremely helpful for keeping track of hours spent designing and developing and the tasks with deadlines especially.

In regards to the scope, weekly sprints, and development roadmap, I believe this was carefully calculated, delegated, and distributed evenly throughout all three months. With the way this was handled it allowed me to be able to get the most done each week as possible without creating an overloaded task list. The scope ended up being pretty accurate though a lot of things came up during the last couple of weeks which I will explain below in “What went wrong”.

Development

I wanted to keep everything as clean as possible in the code early on while allowing myself the most flexibility for the systems as possible.  Everything seemed to come together really well each week albeit the bugs that came up. The bugs are to be expected though. The network functionality in regards to the connectivity and authentication was a bit troublesome which I’ll explain below but other than that once we got past the hurdle everything functioned great and the leaderboards received and stored scores perfectly. There wasn’t any documentation for any of the code that I did or that was required so there’s nothing to comment on there.

Some of the algorithms used for storing and searching for data seemed to keep the optimization quite high. From the time I began development to the time that I had assignments that required me to do performance testing, there was never a time that I wasn’t considering the best performance or optimization possible for the given circumstances. Due to this consideration throughout the process of development, when I finally did come to those assignments for performance and graphics testing, the tests passed with flying colors. I never had any problems with performance or otherwise according to the profiler in Unity.

Testing

Throughout development I was constantly testing the game as I implemented new features to make sure everything as working properly. I was able to catch most issues that would have come up through actual play testing so that was something that I was rather proud of in the long run. There are things that I wish I‘d caught ahead of time but I understand that we can’t always be perfect, nor will anything ever be completely perfect. You win some and you lose some unfortunately.  Most of the debugging that had to be done came through rather smoothly.


Business Model/Plan

N/A.

This is something that will be or is being handled by CelleC Games. There isn’t any proposed business model or commercial plan that I am aware of at this time.


The Critique: What went wrong…

Design & Aesthetics

In regards to challenges, there weren’t any real challenges for me because I wasn’t responsible for anything to do with the design, the mechanics, the balancing, or any of the aesthetics behind the game. I was responsible for implementing same design, mechanics, and aesthetic assets but weren’t responsible for creating them.

There were some minor problems or inconsistencies that I noticed with the design along the way though. There was some missing information in regards to some things that required me to wait for design decisions in order to proceed with implementation. Some of this was very minor such as the amount of health the player started with and some of it was pretty major such as an incomplete level and misinformation with certain mechanics and how things operated. These were taken care of within a week or two of bringing the issues up but occasional there were some things that caused delays in me being able to get things done. This wasn’t major enough to force me to fall behind on much but was more of an annoyance than anything.

Implementing the UI seemed to cause a bit of problems though early on. I couldn’t get the UI to scale properly with different resolutions. I had never used Unity’s new UI system so I was unaware of exactly how it worked. I was trying to scale things with resolution in the code itself, which was proving to be a bit more difficult than it should have been because I had to keep calculating new bounds depending on the height and width of the display. Using the new UI system within Unity 5 was a whole lot easier and seemed to work rather well once done properly.

With regards to implementing the aesthetics, we had some pixilation issues with some of the artwork. So in order to fix those issues we had to enable some lower compression settings that caused storage space to rise quite a bit. This also happened with the audio. Since using higher compressed audio formats caused the music tracks not to loop properly, we were forced to use the lowest compression format possible and that also caused storage space to rise a lot. Near the end we were approaching a nearly 135MB APK file which is completely unnecessary for the type of project we have. I’ve personally seen games with way better graphics and quite a larger scope with a lot smaller storage usage.




Project Management

There wasn’t much of anything that went wrong with project management. The system put in place was awesome. However in regards to personal project management, there were a few issues that came up throughout development where members of the team wouldn’t follow proper chain of command and seemed to want to take authority over the Producer and make decisions without his consent simply because they were also in a lead position. They seemed to not understand that they were in a lead position over their particular department and the Producer had the final say in decisions over the entire project. So this caused some disagreements within the team occasionally but not enough to be a major problem or cause any development delays.

What did seem to cause delays was issues with having a proper art pipeline. The person who was responsible for being Lead Artist didn’t actually commit to doing a lot of their responsibilities. Either because they had no experience or knowledge on how to do some of those responsibilities or because they were busy with other projects. In any case though this proved to be something that caused a lot of delays because I had to step in and also be a liaison between implementation and the artists in addition to my own responsibilities. What should have been taking place is the Lead Artist should have been working more closely with the artists, providing feedback toward their work, and then taking final art and importing it into Unity to test and make sure it worked properly before labeling it “Ready for Game” and giving it to me to implement into the game. Instead I was getting little more than placeholder artwork a lot of times and then having to go back and forth with the artists myself multiple times and then having to wait on the Lead Artist to give the go ahead to get something final. This was a very stressful process and caused a lot of delays and forced me to do heavy crunches in the end in order to even get things properly functional. This almost caused me to fail the last development class had I not stayed up for almost 2 days straight getting things done. I will still missing some things but luckily the instructor say all of the work that I did do for the final milestone and gave me the benefit of the doubt.

In my opinion the final artwork should have been finished and sound/music should have been started way before the last two weeks of development. This also caused some delays because of the issues we had with storage space that was being used up by the audio and artwork. The aforementioned pixilation issues and being forced to use the lowest compression settings for audio forced me to have to spend a couple days on just trying to get the storage usage down. The assets not being worked on until almost the end of development was the major cause for these delays toward the end. Had the assets been finished by the beginning of the final development month, we would have had ample time for additional play testing and debugging and the game would have been released on October 3rd right on schedule. Instead it had to be delayed until October 31st.

Development

The only development issues that I had throughout all three months of development were the authentication issues with the leaderboard system. It took a couple of weeks of messing around on the Google Play Services developer’s console in order to get things working properly. In the end, the problems ended up being that I had to create my own unique key store file and upload everything properly to my developer account, set it up for testing, and then add in the Google Play email addresses that were allowed to access the leaderboards.


Testing

There wasn’t anything that really went wrong with testing. Any of the testing sessions that we had ended rather well with at least a small list of bugs that were added to a Google Docs Excel spreadsheet that we used to track them.  There was a bit of concerns that I personally had with the testing feedback that I received though. It wasn’t anything major I guess, but it would have been really helpful to have more information provided about bugs that were found. In a lot of cases I received very minimal feedback in how the bug happened, how it was to be reproduced, how it should work properly, etc. In one particular case, the bug reported was “The result screen is too big”. Okay, this was a proper bug explanation; the result screen was too big. But then in the section where there is supposed to be an explanation on how to resolve the bug, the comment was “The paper should have the regular size.” I had no idea what “the regular size” was or how to get the regular size. I was using the same size in the same resolution that was provided to me by the artists. Just one other way that me having to step in to do some Lead Art responsibilities caused issues, because the Lead Artist found issues with things that the artists gave me and since she didn’t do her role efficiently, she called them “bugs” and blamed me for things not working as intended.

Business Model/Plan

Again there was no planned business or commercial model.


Summary:

In my opinion this version of the project didn’t differ much at all from the initial ideal. I believe this turned out to be just as good as the intended ideal was supposed to be, aside from the extra polish of camera animations that didn’t make the cut. From here the project will end up being published by CelleC Games on October 31st to the Google Play Store and to the Apple App Store. The only things left to do at this point is to fix up a couple remaining bugs which shouldn’t take long at all. They will definitely be fixed up before the release date. I can’t say that I really learned a lot throughout this project and the development thereof. The most I learned is how to use Google Play Services and the Google Play Developer Console as I had never used it before this project. In regards to functionality, programming, or implementation, I didn’t really learn anything at all because of the extensive programming experience that I came into the project with already.

In regards to project management, I definitely learned that people who are in specific roles in your team need to be fully aware and accepting of the responsibilities of their particular role and have experience with and the ability to carry out those responsibilities in order to make sure the team as a whole operates as efficiently as possible. Also I learned that is does not pay off to wait until the very end to start getting final assets ready for implementation. The earlier we start to get things in place, even if it is placeholders, the better off we’ll be near the end when we need to get final art in. Placeholders are great to test implementation and make sure scaling, resolution, theme, style, and the usage of space all matches up. If this would have been done, I can guarantee that things would have went way smoother in the end.

The things I would do differently revolve more around the project management than any implementation or development on my part. If I could go back, I would definitely make sure that everyone could perform his or her roles properly before starting. But since I was brought into the team, I kind of had to work with what I had. I would also make sure that development was at least started on the assets to get some initial artwork into the game as early on as possible we were rushing to get final art in within the last two weeks.

I don’t have too many plans for the future in regards to mobile development. It’s not something I’ve considered beyond graduation at this point. My main goals of this Master’s program and the Capstone were to get the experience necessary to take a mobile game from concept to release/publish. I actually want to focus more on Environment Art in the future as I’ve been working hard to build a solid portfolio in that area as well. I’m glad I had the opportunity to work with CelleC Games and intern with them and I do plan to do some more work with them if I’m welcomed to do so. If the chance arises, I would definitely take the chance to work in a mobile development company on a more permanent and professional manner.


References

CelleC Games. (2015). Spell Book (Version 3.1) [Android Game]. Winter Park, FL: CelleC
Games.


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.