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.
“A lost King... A mysterious mountain…, and…Timmy. Play as
Timmy to help the King of Mystic Mountain.”
Game Description/Executive
Summary
King of Mystic Mountain is a mobile RPG game where you play
as a boy named Timmy who wants to help his king return to his castle. The king
has fled to the local mystic mountain because he lost his family heirloom that
claims his right to the throne. Timmy will have to complete quests, collect,
buy or sell items, and fight through the evil forces that roam the land in
order to help his king.
Inspiration
The inspiration for King of Mystic Mountain comes from
classic RPG’s that were made during the 1990’s. The idea was to make an RPG
that has different ending according to the different quests that you do in the
game.
Ideal
Ideally, King of Mystic Mountain would be a full RPG that
would take more than 10-30 minutes to play and beat. The story would be much
more in depth and with better character development. This would give room for
more levels, more enemies, more items and more characters.
Demo Screencast:
The Critique: What went right:
Design &
Aesthetics
I feel the music turned out to be a major part of King of
Mystic Mountain. The music chosen for each level and its smooth transition
between each, I feel went very good with the game.I think it helped to create an atmosphere for
each environment.
Project Management
Setting up the project milestones and keeping track of
progress helped me to make strides with King of Mystic Mountain. Doing this
gave me more time to fix bugs I encountered and address issues my instructor
had. I was also able to make more improvements in between each milestone.
Development
Making an RPG gave me a lot of development to do.The part that went best in my opinion was the
quest system. This allowed me to link quests together and make different
endings as result.
Testing
A lot of the play tests went very well. Because of them I
was able to identify and fix problems I did not know existed.
The Critique: What went wrong:
Design &
Aesthetics
The art was hard to find and did not turn out exactly how I
wanted it. With the help of my friend Eric, we were able to find art good
enough to fit what we wanted.
Development
A lot of development issue arose when I would get feedback.
Most of it would require me to backtrack through milestones and fix issues that
would be found. One of the main issues found was the player control. This was
fixed by allowing the player to slide their finger from button to button to
change direction.
Testing
One of the issues with tests for me was that I had to
approach strangers at my friends store to get new people to play it. This
involved awkward conversations and sometimes, awkward feedback.
Other
Using the ORK Framework was a disaster at first. I was not
able to get anything to work, and when I did, something else went wrong. It
took me a bit to get the hang of the framework.
Summary:
King of Mystic Mountain has satisfied my goal to create an
RPG. Though it is not as big as I want, it does show that I can do it. In the
beginning it was fun to watch come together. With each level I would find the
right music, test sprites, add blockers and test, test, test. Then it came to
designing characters stats, items, and abilities. This is when work stopped
being fun. It took many frustrating nights to get everything in place and
working. It wasn’t till I got my first battle working that I began to celebrate
again. After that I did my best to celebrate with each success.
References:
Sinwich, R.
(June 2015). King of Mystic Mountain. Raymond Sinwich.
Zygobot. (2018).
Dinotank [Android game]. Orlando, FL: Zygobot Herington, C.M.
(2018). Dinotank AR [Android game]. Winter Park FL: Full Sail University
Dinotank
Backstory:
Summary
I had a
unique experience while going through the capstone project process. I didn’t
come up with a game idea to use for my own project, which was because I really didn't think that what I could come up with would really be good enough for my degree. So I was given the option
to work on another project. After a few months of working on that project I was
given my own project to work on which I worked on for multiple months.
I was
given the option to work with the Zygobot team on their game Dinotank. I worked
with them for 3 months making the daily rewards feature and helping with putting
their tanks together. It was a new experience for me working with a team
remotely and helping develop their features. There were some communication
issues due to being remote but eventually those were fixed. A lot of the issues stemmed around the lag between emails. Either me or whomever I emailed might take a day or so to respond. This caused some issues when asking questions on what needed to be done. This was eventually resolved by checking emails more frequently and finding other ways of communication like Discord or other chat services.
Throughout
the time I was working with them I was given specific tasks to complete and
designs to follow. I was not given the freedom that a student normally would’ve
had if they had been working on their own game idea. I do feel that this reflects on how it will be working for a company though. I will not have full control over most if any projects I might work on. So I have gained some more experience following others designs and learned how to do so effectively. I learned a lot while
working on the daily rewards feature. I learned that it wasn’t as easy as I
initially thought it would be and that I had a lot to learn when it came to game
development. I struggled managing my time with work and school while first
working on the project. My time management skills were being tested very hard.
After a
while I ended up having situations where I would have to wait on someone else’s
work to get done to finish doing what I was doing or before I could get
started. This led to me being assigned the demo project of Dinotank AR.
Below are some videos of the Daily Rewards system that I worked on for the Dinotank game. There are 2 games, the spinner wheel and slot machine. The game would be chosen randomly when the player started the game. The player was given one free spin per day. If they watched an ad after a spin they would get another spin after that spin they were able to purchase one more spin. The sounds and particles are just placement assets there to be replaced with the final assets later on. The first 2 videos show the first iteration of the daily rewards games.
These next 2 videos are of the last iteration of the daily rewards. There was a button placed on the main menu to allow the player to access the games. They were able to switch between games before they used their first spin. The games are also spinning waiting to be stopped unlike before where they needed to be started.
Dinotank
AR Backstory:
Sound
Bite
Build
your battle arena to help you defeat your enemies.
Executive
Summary
Dinotank
AR is an augmented reality game based off Zygobot’s Dinotank game. It allows
the player to play anywhere with the marker and make it seem like the real-world
effects the game world.
Inspiration
The
inspiration for the game came from Zygobot’s game Dinotank and its main feature
came from seeing Vuforia's smart terrain feature. Dinotank AR is a demo to help
pull in users to Zygobot’s Dinotank game. Vuforia's smart terrain showed the real-world
objects being put into the game world and made the idea of having the tanks be affected
by them seemed great for the game.
Ideal
The
game is a multiplayer game where the player sets up the play area and adds
obstacles before starting the battle. Having the players build the play area
and even adding real objects to the play surface is meant to have them feel
like they are hiding behind and dodging around real objects.
Demo Screencast:
The
Critique: What went right
Design
& Aesthetics
The
design was an easy kid friendly design based off of Dinotank. I was able to work with the
Zygobot team and use their assets. Having
Dinotank to work with made this process easy and all I needed to do was bring
the assets I was going to use over to Dinotank AR.
Project
Management
Being
assigned the Dinotank AR game allowed me the freedom to manage myself and the
whole development of the game. I wasn’t relying on anyone else and they would
hold me up if I needed their work to complete my work. This gave me a lot of valuable
experience with managing my time and tasks better.
Switching
advisors allowed me to be able to change my focus from the surface detection feature. I was able to work on gameplay and the user experience more. I was also able to manage myself better afterwards since I was given some more freedom to what I was able to work on.
Development
Throughout
the development life-cycle I learned a lot about AR and computer vision. I found out the multiple algorithms that can be used for marker tracking and plane detection. I also was really interested in how the different SDKs that are used for AR have so many differences in how they are implemented and their tracking capabilities. I also
learned about my strengths and weaknesses. Such as I'm still not able to do graphics programming effectively, but I am able to make gameplay mechanics rather quickly. When needed I was able to add changes and fixes fast as well. I
was excited when I was able to put a new feature in the game and see that it
worked and improved the quality of the game. I was really excited when I put together my touch input code. I found a way to make the touch gestures be used and any custom functionality I wanted. For example I could make a function that uses the vector created by swiping my finger and have it called when the user swipes the screen. It was something that is really simple to use and allows for complete customization. Another feature that was exciting to make and get working was the obscuring of the tanks behind invisible objects. This was something I was able to find the answer to online. I ended having to use multiple cameras and the edge detection camera effect to pull this off effectively. It ended up looking really good. The tanks actually look like they fell off the table or are hiding behind a soda can.
Using
Unity was an immense help as well. I had prior experience working with Unity,
so I was able to put things together faster than learning a new engine. Also,
being able to use some of the tools and things from the asset store helped quicken
the build process. Such as Photon Unity Networking which helped get the game to be multiplayer with out me having to do all of the networking.
Overall
the development of the game gave me a lot of great experience and knowledge of
how to develop multiple areas of a game using Unity and C#.
Testing
I
found people who gave me good useful feedback. This helped me improve the game
to what it is today. Using people with some technical backgrounds allowed my
feedback to be more precise and help me determine things that needed to fix
more accurately.
Business
Model/Plan
The
plan all along was free to play. There was never a thought of adding purchases
or a price to the game sense it is meant to be a demo for the real Dinotank
game.
The
Critique: What went wrong
Design
& Aesthetics
The
design of the game was based around the surface detection feature that was
based off Vuforia's smart terrain feature. This caused a lot of issues since I
was unable to successfully replicate the feature. I had minor issues with the
visibility of the game objects to allow it to seem like the tanks are hiding
behind real world objects too.
When
I worked on the Dinotank game I didn’t have too much control over what was going
to be done. I had to follow someone else’s designs. This made sense because it
wasn’t my game. When I was tasked with working on Dinotank AR I was given more
freedom, but I still using the Dinotank assets. Then when I was tasked with the
surface detection feature I had no real control over how this was going to get
done and what it should look like. So, throughout the process I didn’t have a
lot of control over the design initially.
Project
Management
I
ended up having to switch advisors part way through since I was being
unsuccessful with the surface detection feature. Focusing on the one feature
was causing the game to lack in other areas of development which I didn't like.
I had multiple issues working with my advisors in the beginning. The miscommunication
only partially went away and then the problems with the surface detection
feature brought everything over the edge.
I
also had issues with time management in the beginning of the capstone process.
I had a tough time making sure I worked when and the max amount I could. So,
since I didn’t spend as much time as I should’ve my work wasn’t the best
quality it could’ve been.
Development
There
was a lot of learning I needed to do to be able to make this game. The main
thing that went wrong was the surface detection feature to put the real-world
surface and objects into the game was too advanced of a feature for me to
develop properly. I failed to do this for multiple months and ended up just
changing things to make it better for the user to finish the game.
It
was also hard for me to try to do so much work in such a little time. When I
was assigned the Dinotank AR game I had 2 months left of development. So, I was
rushing to try and get everything I could in as fast as possible. Then the
final month I was tasked with the surface detection feature. I focused just on
that and couldn’t really do anything else but that feature until I finally was
able to change it.
I
am not a graphics programmer and I have very little experience working with
shaders. This is what I needed to complete the surface detection feature
though. Since I couldn’t make shaders properly I was having to find work
arounds for how I was doing everything. I didn’t like doing it this way but I didn’t
feel I had enough time to learn how to write shaders and learn how to debug and
make sure they’re working properly. Since it ended up taking me a lot longer than
was intended to complete the game I should’ve tried to do it the right way by
learning about shaders and using them to complete the feature.
I
ended up having to use multiple AR SDKs throughout the lifecycle of the game. I
started with ARToolKit 5 since it was free and open source. This worked great
until the second month when it stopped working and just showed a black screen instead
of the camera feed. I then tried out ARToolKit 6 which was in beta and that
worked but the camera feed and tracking were not good. I then switched to
EasyAR as it was another free SDK. This worked well, I had no problems with
this. The only thing was that it didn’t have a lot of extra features to help
with the AR of the game. So, I finally switched to Vuforia. This was the right
option. It has great marker tracking and is already integrated into Unity.
Testing
It
was hard to find testers in the age group that the game is built for. I ended
having to use people over the age of 20 for most of my testers. This also
caused scheduling conflicts and delays because of people being busy or not
remembering they were supposed to help.
I
was able to get the feedback I needed just not in as timely as a manner as I had
wanted it. I had to do a lot of my testing remotely. Which made it harder to
see everything that was going on and see the users reactions properly.
Business
Model/Plan
There
weren't any issues with this area. The game is a promotional demo for the actual Dinotank game,
so it shouldn't cost anything to play.
Summary:
The
capstone process has been a great learning experience for me and taught me a lot
about the development process and myself as a developer. I learned a lot about
AR and about different SDKs. I also found out how badly I am when it comes to
graphics programming. I still feel like I am a strong gameplay mechanics
developer though. This experience has helped shape me and made me understand
how to manage myself and be more productive.
I
was able to show how creative I can be when it comes to finding solutions to
problems while working on Dinotank AR. I ran into multiple issues with the
surface detection feature and later with the build process of the battle arena.
I have always enjoyed figuring out hard puzzles and thinking outside of the
box. I believe that I have been able to show this in my work on the game.
I
feel glad that the game has turned into what it has now that I’m at the end of
the capstone process. It has grown a lot and changed quite a bit throughout
this process. I do feel that with it being a multiplayer AR game where the
players build their own battle arena gives the game some more replay ability.
References
ARToolKit 6 [SDK]. (2018). Retrieved from https://artoolkit.github.io/portal/index.html
EasyAR [SDK]. (2018). Retrieved from https://www.easyar.com/
[Unity]. (2014, Aug 29). Unite 2014 – Developing with Vuforia Smart Terrain [Video File]. Retrieved from https://www.youtube.com/watch?v=l7o9H31lI0Q&feature=youtu.be&t=258
aldonaletto. (2012, September 11). Can I obscure an object using an invisible object? Retrieved from Unity Answers: https://answers.unity.com/questions/316064/can-i-obscure-an-object-using-an-invisible-object.html
KnightRiderGuy. (2015, March 1). Webcam Edge Detection C# Script Needs Converting. Retrieved from Unity Forums: https://forum.unity.com/threads/webcam-edge-detection-c-script-needs-converting.305046/
Exit Games. (2018). Photon Unity Networking. Retrieved from Unity Asset Store: https://assetstore.unity.com/packages/tools/network/photon-unity-networking-free-1786
PvTGreg. (2014, December 20). pick random point on navmesh. Retrieved from Unity Answers: https://answers.unity.com/questions/857827/pick-random-point-on-navmesh.html
Rego, C. (2012, January 10). DetectTouchMovement. Retrieved from Unity3D Wiki: http://wiki.unity3d.com/index.php/DetectTouchMovement
Unity Technologies. (2018). Unity® 2017.3.1p2. Unity Technologies.
Vuforia [SDK]. (2018). Unity Technologies.
Zygobot. (2018). Dinotank [Android]. Orlando, FL: Zygobot
Game Summary:
Game App Icon
Title:
Fantasy Blade: Pilot
Barnibles
Full Space
Genre:
Fantasy Blade: J-RPG
Barnibles: Children/Educational
Full Space: Arcade
Platform(s): Android and iOS (all
games)
Revenue model:
Fantasy Blade: $3.99 in Android,
iOS, Windows, and Mac
Barnibles: Free to Play
Full Space: Free to Play
Development tools/Language:
Created using RPG Maker and Unity, programmed in C#
Game audience:
Fantasy Blade: Middle-to-upper
class young men aged 12-45
Barnibles: Children aged 3-7
Full Space: All ages
Team
Fantasy Blade: I was on my own team for this project.
Barnibles:
Executive Producer –Gerard Merritt
Producer – Pablo Rosero Art Lead – Laura Sardinha Art – Nykira Parham Development – Richard Vasquez Design – Alex Roff
Marketing – Pablo Rosero
Title:
Fantasy Blade: Pilot
Barnibles
Full Space
Genre:
Fantasy Blade: J-RPG
Barnibles: Children/Educational
Full Space: Arcade
Platform(s): Android and iOS (all
games)
Revenue model:
Fantasy Blade: $3.99 in Android,
iOS, Windows, and Mac
Barnibles: Free to Play
Full Space: Free to Play
Development tools/Language:
Created using RPG Maker and Unity, programmed in C#
Game audience:
Fantasy Blade: Middle-to-upper
class young men aged 18-35
Barnibles: Children aged 3-7
Full Space: All ages
Team
Copyright/Reference -
Backstory:
Sound Bite:
Fantasy Blade: An Epic Tale of Nation building,
friendship and Betrayal.
Barnibles: Match the animal to its
correct home!
Full Space: Team up with friends
to fend off space invaders.
Executive Summary:
Fantasy Blade: Fantasy Blade:
Pilot is a JRPG high fantasy adaptation of the Arthurian Legend. Players unite
tribes and gather their own allies to form their kingdom.
Barnibles: Barnibles is a
children’s game where children match animals to their habitats with a cutesy
feel.
Full Space: Full Space is an
update of the classic arcade game, Space Invaders, with multi-player support.
Inspiration:
Fantasy Blade: My inspiration was Arthurian
legends and other J-RPG games, such as the Final Fantasy and Suikoden series.
Barnibles: Barnibles was a
pre-existing series for small children that allows them to learn early
childhood skills, with fun and loveable characters.
Full Space: Full space was a
pre-existing game based off of older arcade games such as Space Invaders.
Capstone Game Scope
Fantasy Blade: The first three
levels of the game, which was met.
Barnibles: Five quickly advancing
levels increasing in difficult, with repeat on the last level. The scope was
met.
Full Space: One level with
multi-player support, which was met.
Ideal
Fantasy Blade: The ideal of
Fantasy Blade was met and exceeded during the redesign. The ideal was three
levels with multiple players and story-driven game play. The ideal was met.
Barnibles: The ideal for Barnibles
is multiple levels with adorable graphics and sound effects, where players
match animals to their homes. The ideal was met.
Full Space: The ideal of full
space was to create a multi-player interactive game based off of vintage arcade
games. Ideally it went well.
Demo Screencast:
Barnibles:
Fullspace:
Fantasy Blade:
The Critique: What went
right
Design & Aesthetics:
Fantasy Blade: I was able to
design realistic characters and used sprite sheets to allow them a wide array
of emotion. In addition, I kept a
working database of art and sound assets to find the correct asset for the
appropriate situation.
Barnibles: We were able to design
and incorporate smooth animal and habitat assets. User testing found that
players described the assets as “cute” and “adorable”.
Full Space: I was not part of the
design team with this project.
Project Management:
Fantasy Blade: Multiple redesigns
led to a reformed approach that has increased development efficiency.
Barnibles: We were successful in
working with a team and coordinating with them, utilizing everyone’s unique
talents to get the project developed on time, meeting all goals, and with the
appropriate assets.
Full Space: From beginning to end,
Full Space was an efficient process. In under a week, we got the project,
researched and incorporated necessary assets and tools, and delivered it
completed.
Development:
Fantasy Blade: The project was
developed as part of my Capstone project and was developed on a MacBook Pro and
Nvidia Shield using RPG Maker and Unity. I feel that I was able to learn new
programming languages and new software to create three successful games.
Barnibles: Barnibles development
was successful from start to finish. We got assets on time and incorporated
them will, the scripts that needed to be delivered were simple enough to get
them working with time to spare.
Full Space: This was mentioned in the prior question.
Full space was an exercise in efficiency.
Testing:
Fantasy Blade: We were able to get
a diverse team together for user feedback and test the game in real
environments with members of our target audience and improve player interaction
throughout.
Barnibles: Advanced testing
allowed me to deliver the product with almost no bugs and little external
review. User feedback delivered several great ways to improve the game, if
desired.
Full Space: Testing the
multi-player feature in full space was fun! It also had success in exploring
which assets should be sent over the network versus being managed locally.
Business Model/Plan:
Fantasy Blade: We needed to change the business plan from
one that was exclusive and ad-based to one that involved a flat purchase.
Getting this context was a good example of what went right because it allowed
us to correct problems before it hit the market.
Barnibles: I was not involved in
this business plan
Full Space: I was not involved in
this business plan.
Other:
The Critique: What went
wrong (Please include screenshots
where appropriate)
Design & Aesthetics:
Fantasy Blade: Early concept work
involved complicated systems that needed to be redesigned.
Barnibles: More environments were
needed to better fit the animals.
Full Space: Different people may
have made different choices about synchronization.
Project Management:
Fantasy Blade: Fantasy Blade was a
long learning experience with project management. Having too wide of a scope
meant that multiple redesigns were needed. My lack of experience meant that
redesigns took longer than expected.
Barnibles: Towards the end, we
should have budgeted time and assets for more incorporation of user feedback.
Full Space: Because it was such a
short project, there was little room to add personal touches.
Development:
Fantasy Blade: As previously
mentioned, my lack of development experience meant that redesigns were needed
and that the overall goals took longer than expected.
Barnibles: Barnibles was largely
successful. The only thing I would change would be to add more user feedback.
Full Space: Development was mostly
successful but extra time for more testing and expansion would have been a good
idea.
Testing:
Fantasy Blade: Decenteralized user
testing had growing pains and there was a need to overcome differences in
communication styles.
Barnibles: We weren’t able to
recruit many testers, leading to a small sample size.
Full Space: Time Constraints led
to limited testing.
Business Model/Plan:
Fantasy Blade: Initially, I was
looking at best practices for general mobile, and I am now looking for more
successful income strategies, leading to replanning.
Barnibles: I was not part of this
business plan.
Full Space: I was not part of this
business plan.
Other:
Summary:
Fantasy Blade: N/A
Barnibles: Executive Producer – Gerard Merritt
Producer – Pablo Rosero Art Lead – Laura Sardinha Art – Nykira Parham Development – Richard Vazquez Design – Alex Roff Marketing – Pablo Rosero
Full Space: N/A
Copyright/Reference:
Fantasy Blade: Vazquez, Richard K. (2015). Fantasy Blade: Pilot (Version 1.0) [Android Game]. Winter Park, FL: Full Sail University.
Barnibles: CelleC Games. (2015). Barnibles Home (Version 1.0) [Android Game]. Winter Park, FL: CelleC Games.
Full Space: Full Sail University. (2015). Full Space (Version 1.0) [Android Game]. Winter Park, FL: Full Sail University.
Backstory:
Sound Bite:
FantasyBlade: An Epic Tale of Nation building,
friendship and Betrayal.
Barnibles: Match the animal to its
correct home!
Full Space: Team up with friends
to fend off space invaders.
Executive Summary:
Fantasy Blade: Fantasy Blade:
Pilot is a JRPG high fantasy adaptation of the Arthurian Legend. Players unite
tribes and gather their own allies to form their kingdom.
Barnibles: Barnibles is a
children’s game where children match animals to their habitats with a cutesy
feel.
Full Space: Full Space is an
update of the classic arcade game, Space Invaders, with multi-player support.
Inspiration:
Fantasy Blade: My inspiration was Arthurian
legends and other J-RPG games, such as the Final Fantasy and Suikoden series.
Barnibles: Barnibles was a
pre-existing series for small children that allows them to learn early
childhood skills, with fun and loveable characters.
Full Space: Full space was a
pre-existing game based off of older arcade games such as Space Invaders.
Capstone Game Scope:
Fantasy Blade: The first three
levels of the game, which was met.
Barnibles: Five quickly advancing
levels increasing in difficult, with repeat on the last level. The scope was
met.
Full Space: One level with
multi-player support, which was met.
Ideal:
Fantasy Blade: The ideal of
Fantasy Blade was met and exceeded during the redesign. The ideal was three
levels with multiple players and story-driven game play. The ideal was met.
Barnibles: The ideal for Barnibles
is multiple levels with adorable graphics and sound effects, where players
match animals to their homes. The ideal was met.
Full Space: The ideal of full
space was to create a multi-player interactive game based off of vintage arcade
games. Ideally it went well.
Demo Screencast:
(Embed your demo screencast video
in the blog postmortem. You can do this after your presentation)
The Critique: What went
right (Please include
screenshots where appropriate)
Design & Aesthetics:
Fantasy Blade: I was able to
design realistic characters and used sprite sheets to allow them a wide array
of emotion.In addition, I kept a
working database of art and sound assets to find the correct asset for the
appropriate situation.
Barnibles: We were able to design
and incorporate smooth animal and habitat assets. User testing found that
players described the assets as “cute” and “adorable”.
Full Space: I was not part of the
design team with this project.
Project Management:
Fantasy Blade: Multiple redesigns
led to a reformed approach that has increased development efficiency.
Barnibles: We were successful in
working with a team and coordinating with them, utilizing everyone’s unique
talents to get the project developed on time, meeting all goals, and with the
appropriate assets.
Full Space: From beginning to end,
Full Space was an efficient process. In under a week, we got the project,
researched and incorporated necessary assets and tools, and delivered it
completed.
Development:
Fantasy Blade: The project was
developed as part of my Capstone project and was developed on a MacBook Pro and
Nvidia Shield using RPG Maker and Unity. I feel that I was able to learn new
programming languages and new software to create three successful games.
Barnibles: Barnibles development
was successful from start to finish. We got assets on time and incorporated
them will, the scripts that needed to be delivered were simple enough to get
them working with time to spare.
Full Space:This was mentioned in the prior question.
Full space was an exercise in efficiency.
Testing:
Fantasy Blade: We were able to get
a diverse team together for user feedback and test the game in real
environments with members of our target audience and improve player interaction
throughout.
Barnibles: Advanced testing
allowed me to deliver the product with almost no bugs and little external
review. User feedback delivered several great ways to improve the game, if
desired.
Full Space: Testing the
multi-player feature in full space was fun! It also had success in exploring
which assets should be sent over the network versus being managed locally.
Business Model/Plan:
Fantasy Blade:We needed to change the business plan from
one that was exclusive and ad-based to one that involved a flat purchase.
Getting this context was a good example of what went right because it allowed
us to correct problems before it hit the market.
Barnibles: I was not involved in
this business plan
Full Space: I was not involved in
this business plan.
Other:
The Critique: What went
wrong
Design & Aesthetics:
Fantasy Blade: Early concept work
involved complicated systems that needed to be redesigned.
Barnibles: More environments were
needed to better fit the animals.
Full Space: Different people may
have made different choices about synchronization.
Project Management:
Fantasy Blade: Fantasy Blade was a
long learning experience with project management. Having too wide of a scope
meant that multiple redesigns were needed. My lack of experience meant that
redesigns took longer than expected.
Barnibles: Towards the end, we
should have budgeted time and assets for more incorporation of user feedback.
Full Space: Because it was such a
short project, there was little room to add personal touches.
Development:
Fantasy Blade: As previously
mentioned, my lack of development experience meant that redesigns were needed
and that the overall goals took longer than expected.
Barnibles: Barnibles was largely
successful. The only thing I would change would be to add more user feedback.
Full Space: Development was mostly
successful but extra time for more testing and expansion would have been a good
idea.
Testing:
Fantasy Blade: Decenteralized user
testing had growing pains and there was a need to overcome differences in
communication styles.
Barnibles: We weren’t able to
recruit many testers, leading to a small sample size.
Full Space: Time Constraints led
to limited testing.
Business Model/Plan:
Fantasy Blade: Initially, I was
looking at best practices for general mobile, and I am now looking for more
successful income strategies, leading to replanning.
Barnibles: I was not part of this
business plan.
Full Space: I was not part of this
business plan.
Summary:
Fantasy Blade: Fantasy Blade was a massive project. We were
ambitious. We experimented with different facets. I learned a lot through
redesigns and I was able to finally get the project to a scalable size with a feasible
business plan.
Barnibles: Barnibles was a great project that gave me
wonderful experiences of working on a team. While it was a simple concept, we
had a great deal of success implementing it.
