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

Tuesday, March 24, 2015

Capstone Game Post Mortem: The Crazy 8

Author
Torrey Daniel

Game App Icon














Title 
The Crazy 8

Genre
Action/Fighter

Platform(s)
Android

Revenue model
Free-To-Play
In-Game Purchases
Interstitial Ads

Development tools/Language
The Engine - Unity 3D
UI - Adobe Photoshop, Illustrator
Sprites – Adobe Fireworks
Version Control – Underdog
Programming – MonoDevelop, C#

API’s & Other Resources
·       Google Play Games Services
·       Photon Unity Networking
·       Cartoon FX Packs 1 & 2
·       MOGA Controller Plugin
·       Set Builders
·       Universal Sound Effects
·       Westar Music Library

Game audience
The intended audience for this game is from teens to young adults. Based on Bartle’s Player Types (Bartle, 1996), TC8 is intended for players who would fall into the Achiever category: Players who seek a challenge and play to unlock all of the characters. With that said, once player-vs-player is added, player’s who fall into the Killer category are expected: Players who play simply to give other players a hard time.

Team
Torrey Daniel - Designer/Developer

Copyright/Reference
The Crazy 8 Copyright © 2015 Torrey Daniel

Backstory
Sound Bite
The Crazy 8: Go In, Go Hard, Go Crazy.

Executive Summary
TC8 is a mobile fighting game with the goal of a classic fighting game experience to mobile devices. TC8 presents a more traditional fighting game play style than most modern mobile fighters.

Inspiration
TC8 was inspired the classic, console and arcade-based fighters. The overall goal of this project was to bring that nostalgic “feel” of playing a classic fighter to the mobile platform, which is a challenge due to the lack of physical buttons.

Capstone Scope
TC8 was a five-month, solo game project, which was completed within Full Sail University’s Mobile Gaming Master’s Program.

Ideal
Ideally, at the end of the Capstone period, TC8 was planned to have a playable roster of 8 characters, 8 playable stages, 6 game modes (Arcade, Time Trial, Survival, Single-Player VS, Multiplayer VS, and Training), all major mechanics implemented, a fully function in-game store, Google Play Game services fully implemented (Leaderboards, Achievement, and In-App Purchases), and multiplayer connectivity.

The Critique: What went right...


Design & Aesthetics:
·       Design Documents:
o   The design documents did well in providing an overall guideline for this project as the contained information that kept this project on track. With that said, I do believe that they could have been managed better (See Below)

·       Mechanics:
o   Out of everything that was achieved in this project, I am most proud of the fighting mechanics. At the start of the project, I struggled to decide exactly how the players should fight. I wanted something that was not too complicated due to device restrictions, while at the same time not as simple as simple swiping the screen to perform actions. In the end, I decided on something that fell between the style of Marvel vs Capcom and Street Fighter. A fighting game would not be a fighting game without combos, which is why I aimed to keep it simple while still requiring a bit of practice, just like the games that inspired TC8.

·       Balancing:
o   Each character has their own strengths and weaknesses. I had to keep this in mind as I created the roster in order to keep each of them from being too overpowered. For example, Sophi and Source Code are capable of performing more elaborate combos than the rest of the roster, but they also deal the least damage. Terrah Bihte and Lance are slower than the rest of the roster, and they’re also less combo-friendly. However, they deal the most damage of them all.

·       Graphics:
o   While the characters are 2D sprites, the stages are full 3D geometry. This gives the game a bit more depth than having a layered 2D background. However, there are a few issues that arose because of this (See Below)

·       Audio:
o   TC8 uses audio that fits the game well. Since voice actors were not an option due to the scope of the project, the game uses simple voices (grunts, yells, etc.) acquired from the Unity Asset Store. The music was acquired from the Westar Music Library, which also fits the game well. There’s different music for different sections of the game. In addition to the Unity Asset store, a few of the sound effects used were also obtained from FreeSFX.com.

·       Narrative:
o   TC8 has announcers that speak a certain points in the game. They are primarily used for announcing things related to the match. There are also loading screens before a match, which tells players their next opponent, and where they will be fighting. Also, character bios are displayed to the players during character selection screen. There’s still a bit more to add when it comes to narrative. (See Below)




·       UI Screens
o   TC8 follows a more dark, less saturated color scheme to fit the serious tone of most fighting games. I designed the overall color scheme of the menus to match the colors of the logo.



·       UI Controls:
o   The UI controls are straight-forward. There are four buttons located on the right side of the screen, and there are directional input buttons on the left side for movement. Players have the option to change the opacity of these buttons.




Project Management
Given what was accomplished within the short scope of this project, I believe that it was managed well. Most of the planned features were added, and what was not added was does not impact the primary features and functionality of the game.

Development
The code is set up well with each mechanic/feature organized in separate scripts. Unity Engine was great to work with. As it stands now, the game is set up in a way that allows additional features to be added with minimal issues. New characters and stages can easily be added with only a few lines of code. The AI has 3 changeable difficulty levels which each behave differently. With that said, there’s still some work needed for the AI.

Testing
During testing, TC8 performed well. The only causes of crashes have been memory issues caused by oversized textures, which were easy fixes by compressing them. Although the tests went well, setting them up was difficult.

Business Model/Plan
TC8 will follow the Free to Play (F2P) revenue model. The game will also use ads that will appear after completing a game mode or receiving a game over. In addition to that, TC8 will also have in-app purchases. The first of which, is the in-game currency. TC8 features it’s own currency called Fight Coins, which is used to purchase additional Sanity Attacks for each character. Players can either ear Fight Coins by playing the various game modes, or by purchasing them in coin packs.
Lastly, at release, there will be an initial playable roster of eight (8) characters. Over time, an additional eight characters will be added. These characters will be released in sets of 2 called Rival Packs. Players will be able to purchase these new characters via in-app purchases.

The Critique: What went wrong…

Design & Aesthetics
·       Design Documents:
o   During the Usability Test, some of the participants made a few suggestions about the layout of the main menu, since then, I’ve been experimenting with other layouts, but at this point in time, I have haven’t decided on a new one. Below is a snapshot of the layout that I’m considering going with for the main menu. Also, I tended to get very carried away with development, which caused me to forget to keep the project documents updated.




·       Mechanics:
o   Although the primary mechanics were added, they are not perfect. There are still a few bugs that need to be fixed, specifically when it comes to collisions.

·       Balancing:
o   The balancing could use a bit more work, but its nothing major. The characters’ strengths and weaknesses could use a bit more enforcing.

·       Graphics:
o   At this point in time, there are still a few placeholder graphics that I had planned to replace by now with other graphics that fit the UI theme better.

·       Networking:
o   One of TC8’s primary planned features was multiplayer. When I began this portion of development, I encountered numerous issues. Because of this, I decided to leave multiplayer out of the scope of the Capstone, and focus on solidifying what was already in place. I still plan to add multiplayer in the future.

·       Narrative:
o   In addition to the current narrative aspects in place, Arcade mode is missing the scenes that tell each character’s story. These scenes would be short, manga-style images that portray the events that lead up to the final boss fight.

Project Management
Although I tried my best to stay on schedule, there were situations where I had to extend the time scheduled to complete a task. This occurred most often during the sprite creation phase, which was extremely time consuming.

Development
The code could have been organized more cleanly with comments and having related methods and variable declarations grouped together for improved readability. The repo should have also been updated more often.

Testing
Although the tests went well, some were quite difficult to set up. This is because I had not planned to test early in development. This made it difficult to isolate the blocks of code being tested because of their dependencies with other scripts.

Summary

Overall, I’m proud of what was accomplished within the scope of the Capstone. The final version of TC8 was not far off from the planned one. The primary fighting mechanics were added, there is a roster of 8 characters, there are 8 stages, and 5 out of the 6 planned game modes were added.

Besides development-related things, I learned quite a lot from this project. My main take-away is project management. Although a lot was achieved, it was difficult to stay on schedule. I also take debugging more seriously after this project. Android’s Logcat debugging tool was essential in finding the dreaded “Out of Memory” error that plagued this project for a while. Also, I learned the importance of making code testable from the start. It saves a lot of headaches when it comes to testing. That would be the only thing I would redo about this project.

For me, the high point of this project was completing the combat system. It took a bit of time to get it working, but once it did, I felt a great sense of achievement. The low point was when I decided to postpone multiplayer. Although I do plan to complete it in the future, I was disappointed that I could not get it working at the scheduled time.

     From here, I intend to continue working on TC8. There are still some bugs that need to be fixed, and features that need to be added. It won’t take much to fully set up achievements, leaderboards, and in-app billing via Google Play. Multiplayer will be added via update after release. Once the game is in a stable condition, I plan to release TC8 on Google Play.

View the Screencast HERE



Thursday, February 19, 2015

Capstone Game Post Mortem: Fantasy Frenzy

Capstone Game Post Mortem: Fantasy Frenzy


Game Summary:

Author

Matthew Tjarks

Game App Icon














Title

Fantasy Frenzy

Genre

Time Management

Platform(s)

Android

Revenue model

Paid - $3

Development tools/Language

Unity3D: v4.6.1f1
MonoDevelop: v4.0.1
C#
Facebook SDK: v2.0

Game audience

My game is targeted to females aged 15-30 years old. My game targets Achievers and Explorers in Bartle's (1996) player types. Achievers will be interested in beating every level and getting the highest scores, while Explorers will be interested in creating and discovering what the different combinations and potions can do.

Team

Matthew Tjarks - designer/developer
Nick Adams - App Icon Artist

Copyright/Reference

Fantasy Frenzy copyright 2015 Matthew Tjarks

 

Backstory:

Sound Bite

A blacksmith must outfit an entire army before the kingdom he loves is no more.

Executive Summary

Fantasy Frenzy is a fast-paced time management game set in a fantasy kingdom besieged by their enemies. The player plays a blacksmith who is tasked with outfitting an army with weapons and armor, and he has the ability to enchant and enhance them in different and perhaps unexpected ways.

Inspiration

The inspiration for Fantasy Frenzy came from my enjoyment of Time Management games, despite being primarily marketed and themed for younger girls. I wanted to create a time management game that had a more neutral theme, as well as adding in another layer of game play in the battle system for more depth. Although my game is still targeting females, I hope the theme is neutral enough to also be able to bring in males as well to this genre.

Ideal

Ideally, when finished, Fantasy Frenzy will have both the Time Management half and the Battle half of the game and they will be tied together for a more fully realized game. The graphics would be completely overhauled to fit together tighter and be more colorful and playful, as this should be a fairly light, fun game.

 

Demo Scrrencast




The Critique: What went right…


Design & Aesthetics

The aspect of the aesthetics that went the most right was the user interface. I feel that the user interface is very clear and communicates to the player what is happening in the game well. Some improvements can still happen in this area for sure, in particular, adding a graphical representation of the time remaining as well as the score. In particular, the "thought bubbles" over the items to indicate where they should go next worked very well. The user interface went through many iterations from the beginning, since I did not have a solid concept of what it should be from the beginning, as is illustrated in the pictures below. The controls also feel very good and appropriate for the game and the devices it is targeting. The music does a great job evoking the right mood. In the menus, it is slow, subdued, and relaxing. In the game, it is upbeat and happy, evoking exactly the mood I want for this game.
Mockup interface (top) vs. Current interface (bottom)

Project Management

The use of Git as source control went very well, and helped me keep tasks short and focused. This helped a lot as I can be known to jump around between features. Forcing myself to make sure one small task, generally part of a larger feature, was done and tested before moving on allowed my game to progress more rapidly. Along the same lines, the weekly deadlines helped ensure that the project was always making some sort of progress every week.

Development

I was able to implement almost every feature that I had scheduled to complete during the capstone. Working in Unity enabled me to rely on a lot of systems already in the Unity engine so that I did not have to reinvent the wheel. Architecture decisions made early on in development, such as using anchor points rather than relying on a specific asset for game functionality meant that I could more easily swap assets and add anchors without too much effort, and entirely within the editor.

Testing

For what i was able to test, it was very successful. Unit testing in particular helped ensure that my classes did what I expected them to do. The Unity profiler helped track down a performance bug that I was aware of from fairly early on, where the game would drastically slow down when opening and closing my recipe menu.

Demo Screencast




The Critique: What went wrong…


Design & Aesthetics

The graphics in particular could still use quite a bit of work. When starting this project, I did not anticipate nearly the number of assets that would be needed for this type of project. I also figured I would be able to more easily find good assets that fit my theme. Not many people, as it turns out, make assets for the inside of a blacksmith shop, and so I had to use what I could find. This meant that many of my assets are disjointed and do not fit well together. Going forward, I would want to hire an artist to completely overhaul the graphics to be more colorful, as well as to stylistically fit together more cohesively.

Project Management

The project I believe was poorly scoped from the beginning for the time I would have to complete it. My initial design was far too large for the capstone, and so we focused it down to just the time management part of the game. Going back, I would likely have had a much more reasonable design for a game that could have been started and finished in the time of the capstone project.

The bloated GameManager
The weekly milestones were also poorly scheduled. Some features scheduled for a week of development were almost trivial, while other weeks there was far too much scheduled. While this ended up being smoothed out over the course of the project by working ahead and rescheduling, better time estimates from the beginning would have greatly helped in creating a better schedule for the game from the beginning.

Development

The majority (>60%) of my code ended up in a single class (GameManager), which was also singleton. This helped me solve problems faster, and allowed scenes to more easily talk between each other, but made many sections of code dependent on each other and on the singleton to function. If I changed one thing, many parts of the code had to change with it. Toward the end, I was better about segmenting my code, and only having dependencies where necessary. In future projects, I plan to make this a priority, and to not allow a single entity to control so much of the game.

Testing

Unfortunately, testing for this project did not come until very late in the development cycle. At this point it became a huge burden to test large sections of my code, and even if they were tested, there would have been too many dependencies to guarantee that it was being tested properly and fully. In future projects, I plan to start testing much earlier in the process, in order to create better tests, better code, and to spread out the work of writing tests over time.

 

Summary:

My goal going into this project was to simply complete a game from idea to design, and through to development. For the most part, I have succeeded at this goal. Although the game is by no means complete, and has a lot of work to be done still, the core idea of the time management game is done. From here, I plan to continue to work on the game, first finding an artist to begin working with on assets, and then developing the battle portion of my game. Although I am happy with my game so far, if I were to start the capstone over, I would have done a much smaller game that could have been done with less assets in order to see it through to completion within the span of the capstone months.

 

References

Bartle, R. (1996). Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs. Retrieved from: http://mud.co.uk/richard/hcds.htm
Tjarks, M. (2015). Fantasy Frenzy [Android game].


Sunday, January 25, 2015

Capstone Game Post Mortem: Wreckage


Capstone Game Post Mortem: Wreckage

 

Game Summary

Game App Icon




Title

Wreckage

Genre

Strategy Builder
Arcade style Shoot-em-up (SHMUP)
Hybrid

Platform

Android

Revenue model

Free-to-Play – Extra life for a token

Development tools/Language

Unity with MonoDevelop and C#
SourceTree – GIT repository management
Trello – mobile kanban-style task notes
Parse – cloud database services
Pixabay – public domain sprites

Game audience

25-50 year old American males

Team

Nick Penney – Design and code
Andrew Trahan – Music and sound effects
Pascal Duverger – Logo and character art

Copyright/Reference

Wreckage © 2015 Nick Penney

Backstory

Sound Bite

"In order to salvage, you must first destroy."

Executive Summary

Wreckage is an arcade style space shooter game, where you are battling against the creations of other players so you can steal their technology and use it to build your own mega boss. The game is a mash up of the shoot-em-up (SHMUP) and strategy builder genres of games. (Ikaruga meets Dungeon Keeper)

Unique selling points include the ability to build and upgrade your own boss character, fighting against player-created bosses, better controls than most mobile shoot-em-up games, and persistent ship upgrades for more comfortable casual play.

Inspiration

The inspiration for this game comes from many different disciplines and experiences, including other games I have played, movies I have watched, and books I enjoyed reading. I wanted to add a spin to the typical shoot-em-up game, which is salvage mining and construction. The bite size game-play of the mobile game experience lends itself well to this idea.

Capstone Game Scope

The development plan for this game was to complete 1/3 of the project during my capstone and have a playable demo to put in front of users. This was done so that I could gain valuable feedback and minimize financial risk. I was able to surpass this goal, getting almost halfway done, and still had time to implement many suggestions given through user feedback. This was largely because I found other people during testing, most of whom I had just met, volunteering their time to work on the project with me.

Ideal

The ideal for this project is to continue development past the capstone and publish. My team is the main driving force in this becoming a reality. If they continue to volunteer their time, I would happily continue working on it with them.


Demo Screen-cast





The Critique: What went right

Design & Aesthetics

The primary game mechanics work well for this game. The input mechanics work well, and people love the idea of touch-up pausing. The majority of work relating to final art was scheduled for post-capstone development, but we managed to get a good portion of it done ahead of schedule and put it into the game demo.

 

Project Management

This project was managed quite well. The time estimates were well considered and I was able to accomplish all my project goals on time. Having weekly milestones and screencasts due each week provided just the right amount of pressure to maintain sustainable progress without getting in the way. Using GIT for source control management was great and definitely saved the day on a number of occasions.


Development

Unity was a joy to work with. I really like working with the new GUI system that was added in the latest release of the product. The anchor system made working in different resolutions easy. I was also able to drop the parse.com module and other third party scripts into the editor with minimal effort.

Testing

The A/B testing we did in the testing class shed some light on the utility of post-deployment tweaks that were possible. This was even further enhanced for my application, because it is already largely cloud based. I got the idea to use a cloud based string table, which can be modified for usability without having to redeploy the application. I also store a good amount of object properties in the cloud so I can A/B test them and deploy appropriate tweaks for game balancing.

The Critique: What went wrong

Design & Aesthetics

Clearly conveying the purpose or message of the game without a lengthy diatribe is something a good number of games suffer from, and this one is no exception. Because the primary selling point of this game is divergent from the average SHMUP, users who picked up the game for the first time had no idea what the point of the guardian character was. I had implemented an in-game help system, but they largely ignored its existence and chose instead to forge ahead blindly. It was foolish of me to assume 25-50 year old American males would bother with directions when they didn’t know what to do.

Project Management

Defining deliverables for artists to produce is something I have never done before. The first few artists who agreed to work on the project with me were inexperienced and ended up drowning in too much creative freedom. It wasn’t until I had a conversation with an experienced artist later in the development cycle, that I realized this was largely my fault for not providing specific enough constraints to give them the push they needed to succeed.

Development

The Unity Editor WWW stack on OSX suffers from a flaw in decreasing timeout durations, which means that I need to restart the program any time I want to run my game more than once. This continues to be a source of endless frustration for me, and I have to rely on hardware or standalone apps whenever I need to do end-to-end testing.


MonoDevelop offered another hurdle for me, because I was using asynchronous threaded tasks to connect to cloud code. When debugging with MonoDevelop, it would freeze whenever it hit one of these task statements. For this reason, I was only able to attach the debugger after the login process was completed. This led me to rely heavily on caveman style debugging techniques to debug any issues with the cloud code, as the debugger was unable to be used.  A free third party Unity plug-in called Log Viewer helped with this.

Testing

Our academic schedule was such that testing was in month 3 of development and I found that bootstrapping unit testing onto an already developed game proved to be largely fruitless. There were only small portions of code that were testable, due to almost everything being already developed as a mono behavior and attached to a Unity game object. Luckily this won’t be the case for future students, because the program outline has already been revamped to incorporate the testing curriculum earlier.

Summary

 

The development of this project has been an enjoyable experience. I knew going into the project that there was only so much I could accomplish, due to my schedule being limited by work and family obligations, so I selected a project with appropriate scope. I picked something I was interested in and knew that I could accomplish, but offered significant technical challenges and learning opportunities. I was lucky to run into both an audio engineer and several artists during the course of testing my game, who volunteered to do some work to contribute. This was not part of the original plan, so I am excited that the game has improved as a result, and I am happy with what we were able to accomplish. 
 

References

Log Viewer. (2014). What you see in the editor console is what you get in the game screen. [Unity Plugin]. https://www.assetstore.unity3d.com/en/#!/content/12047

Parse. (n.d.). The complete mobile app platform. [Website]. https://parse.com

Penney, N. (2015). Wreckage. [Android Application].

Pixabay. (n.d.). Free high quality images you can use anywhere. [Website]. http://pixabay.com

SourceTree. (n.d.). A free Git & Mercurial client for Windows or Mac. [OSX Application]. http://www.sourcetreeapp.com/

Trello. (2014). Trello - Organize anything. [iOS Application]. Retrieved from https://itunes.apple.com/app/trello-organize-anything/id461504587

Unity. (n.d.) Unity – Game Engine. [OSX Application]. http://unity3d.com/unity/download

Capstone Game Post Mortem: Derwood the Dashing

Capstone Game Post Mortem: (Derwood the Dashing)
Game Summary: 


Author 
Dustin Bridgewater

Title
Derwood the Dashing

Genre
Infinite runner

Platform(s)
Android

Revenue model
Free to play. Initially intended to have microtransactions, but it would be inappropriate given the target audience.

Development tools/Language
Unity 2D engine with C# scripting. 

Game audience
The intended audience is for younger children but also appealing and challenging to everyone. I wanted to have the game be challenging but not overly so, especially for kids.

Team
Development Lead/Designer/Developer – Dustin Bridgewater
Artist – Matthew Glaister

Copyright/Reference
Derwood the Dashing ©2015 Dustin Bridgewater


Backstory:



Sound Bite
“They thought giraffes couldn’t run. They were wrong.”

Executive Summary
Derwood the Dashing is an infinite runner for all ages. In this game, players control Derwood as he patrols the ‘Animal Kingdom’, watching out for danger and running around as fast as he can. Players earn upgrades to help them out and can unlock costumes to really make Derwood stand out!

Inspiration
My main inspiration for this game is an older infinite runner called Canabalt. I played this game for hours and hours on end, and always thought it would be fun to create my own infinite runner style game.

Ideal
My ideal version of Derwood the Dashing would be a fully polished, tightly tuned game where players had the feeling of accomplishment and every failure could be their own, not a gimmicky or cheap death. Players could also choose from a wide range of upgrades to customize their game into a version that was uniquely their own.


The Critique: What went right…
Current Derwood


Design & Aesthetics
I set out to make this game simple to play, and have a clean overall art style. I view this as being a great success as it’s simply one button to control the entire game (tap anywhere on the screen) and the art looks very bright and consistent. I also wanted to have a clean UI that looked professional and was easy to get around.

The art and sound was a bit difficult, but after finding some royalty free tracks and also creating my own sound effects, the sound design would also be considered a success.

Project Management
I set week long goals and set them up in enough bite sized chunks that development went along smoothly. I felt accomplished because of the smaller goals I set each week, and it was a real treat to see how far I had come in each development sprint.




First Concept Art

Development
The code was setup to be very object based and nothing should have been jumbled together where it shouldn’t be. This made programming super simple especially in the later stages of development since I knew exactly where I needed to go to change something, and it only needed to be changed in one spot.

The piece of code I am most proud of is the random terrain spawn script. I looked online and looked at multiple algorithms, and then pieced them together in my own creation. This makes for a really random layout of terrain, but everything was spaced and pieced together perfectly.

Testing
I had a very big testing group that were eager to help me out, though a couple things truly helped me: my younger cousins and my wife’s cousin who is in the game industry.

My cousins really gave me the best raw feedback since they are both in the target age (one 8 the other 10). It really made me smile when I saw them fighting over my phone to try and beat the score of the other, goofy giraffes truly have a certain appeal to the younger audience.

I was also able to get great critical feedback with Bryanna, my wife’s cousin. She works in the game industry at Volition and warned me that she wouldn’t give me false feedback and would be completely honest. This honesty helped shape a lot of the later development of the game, changing Derwood from a flat and boring runner to really dynamic game. I love getting real feedback and this was invaluable.

Business Model/Plan
I am absolutely happy with this being a completely free game. While microtransactions would be a good revenue, I don’t feel right having real money transactions in a kids’ game. Yes I had purchases in the development stage, but this was truly to test my technical merit, and on full release these are being taken out. I never aimed to make money with this, just obtain great experience.




The Critique: What went wrong…
First 'major' playable prototype


Design & Aesthetics
I have learned that balancing a game is one of the more difficult aspects to accomplish. The majority of development time has been dedicated for finding a good balance of skill while minimizing luck with a random system, and that turned out to be a very difficult task.  What ended up happening was a mix of precrafted levels mixed with random terrain generation to ease players into the game while also providing challenges at later stages of the game


Back to work! In game enemy.
Project Management
The main problem I had with project management was just juggling a busy schedule and trying to get out the best product I could. I admit I thought that I could get a lot more done in the time given to me, but thanks to both life and programming issues what I do have done, while I’m proud of, pales in comparison to what I planned to have done.

Another issue was getting the art assets in on time. My artist was full on ready to do all of the art, but because of work piling onto him, we didn’t get in the art as soon as we could, and not as many animations. I can’t fault him, because Matt did a fantastic job with the art he did do for Derwood, I still laugh at seeing a giraffe with a knight helmet on.

Development
Going into this project, I wanted a fun, fair, and engaging infinite runner. I knew that I had to have random elements in the game, and because of giraffe height, I was a bit limited in coming up with obstacles. It’s quite the goofy object to work around! The randomized terrain was the first thing into the code, and it was a literal random number generator deciding what prefab to put down, and making sure if was out of the camera view. Previous distance was taken in from the last platform placed so everything would meld together nicely, creating gaps when needed and long stretches of flat terrain as well.

The problem with this is was mentioned in the design section: balance. Balancing the game is still ongoing and will continue on for as long as I support the game. This was truly the main development problem, and it’s been a great learning experience. I’ve gained so much game design experience from all of the trial and error needed to test what a balanced game looks like.

Testing
The main problem I had with testing was getting people to test it in person. Most of my testing was done over Skype, and I would have liked to have more face to face testing.

Business Model/Plan
The original business plan was free with microtransactions, and this was working perfectly. However I always felt like it was wrong since this was intended for a younger audience. After some feedback, I happily got rid of the microtransactions and it is now a fully free game.



Summary:
Overall I’m very happy with how the game has turned out. I wanted a simple yet fun game that was easy to pick up and play and truly feel like it belongs on a mobile platform, not just a game trying to fit on mobile.  Going back I would have cut down the expectations and focused less on extra things such as character upgrades and truly build a fully balanced terrain randomizer.  As it stands now, I feel the game has come a long way and I am proud to call it my first full game.

References

Bridgewater, D. (2015). Derwood the Dashing [Mobile Game]



EDIT
Screencast here