Capstone Game Post Mortem: The Odyssey
Title
The Odyssey
Genre
2D Sidescroller
platformer game
The game is built for Android and iOS platforms.
Revenue model
The game will be released for free.
The Odyssey was
developed using Unity3D engine in C# language. All the assets were custom made
in Illustrator and Photoshop. Unity Analytics is used to gather feedback and
statistics information from end users.
My game audience will be players from 17 years
to 24 years old because it is in this range in which players are most attracted
to platform and action games. The game is oriented for the Achiever and
Explorer types of players (Bartle) that will want to reach the end of all
levels, know more about the story of Odysseus and collect all the items and
coins that will help them on their quest and reach a higher ranking. Players of
The Odyssey will also like titles in this genre such as SuperCatlevania IV,
Super Mario Bros, etc.
Team
Andres Torres
– Concept, Design, Level Design, Software Development
Ainhoa Salas
– Content Design
Michael Wong
– Main Character Design and Animation
Alejandra
Azpurua – Enemies Design and Animation
Copyright/Reference
The Odyssey © 2015 Andres Torres
Backstory:
Sound Bite
“Not even the gods can stop him from
coming home”
Executive Summary
Play as Odysseus and help him get back
to his home, Ithaca, while the gods are trying to stop him. Odysseus will
go through different levels defeating monsters and sorting obstacles that
will help him get nearer to his objective. Odysseus will run, jump, hit and
shoot arrows while he traverses a long and perilous journey set by the
same gods he worships. Meet this great Greek champion in a story as it is
depicted in one of the great literature classics, The Odyssey by Homer.
Inspiration
I’m a big fan of Greek mythology so
my goal was to make a game that resembled that entire cultural heritage, as
well as its stories and characters. Also, I’ve always loved adventure,
platformer types games with a good storyline so, the clear choice was to
combine one of the great epic poems of Homer (The Odyssey) and make it and adventure-like
sidescroller platformer game. One of the pillars of the game is to teach the
story of Odysseus to players who haven’t heard of it and relive it to people
who has, so I didn’t want the mechanics to come in the way of it. That’s why I
chose a comfortable mechanic for any player with even a little experience in
gaming, which resembles a lot of classic platformer games like Super Mario
Bros. Besides, I’ve noticed that, when playing platformer games, the
environment (enemies, platforms, puzzles, etc.) should be the one posing the
difficulties rather than the controls themselves. The narrative was solid,
since it has been proved for years for every person who has read The Odyssey.
Capstone Scope
The scope for the
capstone project was to provide a fully functional game and mechanics, with 2
to 3 levels (including the tutorial), a system of rewards that lets players
earn chapters of the actual Odyssey to read and a system that allows developers
gather feedback from end users (Unity Analytics)
Ideal
The idea for my capstone project was to create a fully
functional game but with 2 or 3 levels, including the tutorial. I was
successful doing that in the timeframe that was given and even added features
that were listed in the wish list like multilanguage support and porting the
game also for iOS platform. Since one of my goals was to transport the player
to an specific time, place and culture, I would have wanted to add more
elements that reinforced the cultural heritage left by the Greeks in the game,
specially NPC’s characters and enemies that are easily related to Greek culture
by many people, like the gods (Zeus, Poseidon, Athena, etc.), Medusa, Chimera,
etc. Sadly, this imposed a big workload on the designers and me that would have
left us without time to complete other functionality, so we created the assets
that were completely needed to achieve the goal without loosing quality on the
project. Still I think the game managed to fulfill its goal perfectly.
Probably, future efforts will be put on adding these elements and constructing
cinematics that will allow shortening texts on the game as well as giving life
to it.
Demo Screencast
The Critique: What went right…
First time Unity developer
One
of my biggest fears, when starting to develop my capstone project, was that I
didn’t have any prior experience on Unity or any other game engine whatsoever, other
than small tutorials long time ago, so the capstone would be the first project
that I would do on an engine of this type and even on the programming language
chosen, which was C#. This was a big challenge for me because I knew that the
learning curve that I would have to take was going to be very steep, especially
in the first weeks when I would start getting confortable with it and were the
ones that would require the most effort. Thankfully, Unity is a great platform
and very easy to pick up. Unity’s official tutorials are really helpful and its
community it’s superb. So, something that seemed like a big challenge at the
beginning, of course with a lot of effort, turned out to be a great commodity.
Unity’s tools and integrations, like services, collision system, physical
system, editor, etc., makes really easy for a beginner to start developing what
he has in mind and step by step add more complex stuff to the mix. Luckily, I
am a proficient Android and iOS developer, so many of the concepts that I had
to take in account when developing, where already clear in my mind (events,
delegation, etc.) so basically I was just taking care of the syntax and the
whole new paradigm of developing by components. I’m not saying that it was easy
to develop in Unity and it takes no effort at all, but the engine itself has a
lot of advantages and perks that lets the work of developers be easier than with
others IDE’s. This enabled me to complete most of the main functionality before
scheduled and work with time the solutions of more complex situations and
problems. Now that I know a little more on Unity and C#, I would want to go
back and refactor things that I coded in the beginning, interaction between
classes and scripts, better organization, etc. The more you code, the more you
realize how things should be placed, done and even how to make other components
interact between them. These are not patterns that are set or imposed by Unity;
in fact, Unity gives a lot of freedom in this area. These are good practices
that are individual for developers. At least, all these are lessons learned for
future projects.
Assets are a big way to give context
One
of the things that I’m most proud of in the game is its assets. Each asset has
a clear meaning (even without a hint or text) and is easy and quickly
understood by players. Choosing making the assets as vectors was great because
it gave the overall game a neat and polished finish as well as making them very
clear even in smaller screens. Every asset was particularly designed having in
mind Greek elements and colors that would ultimately add to the theme of the
game. Feedback from users showed that even before reading anything, they would
clearly understand that they were in a game related to Greek Mythology. One big
advantage of doing them on a 2D plane was that the assets themselves had the
lightning and shadows that they needed, which comes as a great performance improvement
to not have the engine render them by itself at runtime. Even thought Unity has
great light and shadows rendering system, it still has some cost on the
performance of the game. This way, performance is maintained in great levels
and the game can be seen running smoothly with a high number of frames per
seconds (60 fps approx.). Having made them custom, allow me to put the
designer’s and my imagination to fly. This had as a result some extremely
interesting, original and novel characters (main character and enemies) that
had an awesome impact on the gaming experience of the players. One of the most
rewarding moments was whenever players came and congratulate me on the assets,
it felt as if all the hard work and vicissitudes I went through while developing
them, meant something.
Keeping the project
well managed
The
project had to be well managed since the beginning. The project is stored in
the Underdog repository as well as my personal project repository in Bitbucket.
On the client side, I used Sourcetree, which is a VCS or a Git Client to keep
track of the updates of my project. I kept two main branches, “master”, which
was the stable versions of the game and from where my advisor or anyone who would
like to test the game, would pull the latest tested version, and a “develop”
branch where I had all my recent work yet to be tested. Generally, I would
create more branches for different states or versions of the project, in case I
needed to show my game in a particular manner (and store it) but still keep
working on the develop branch. Near the end of the project, I found out a great
way to work with Git in which you create a branch for each feature you are
adding and then you merge it to the develop branch. This way the project is
more organized and different people can work on different features of the game
and then merge them into the project. Sadly, implementing this near the end of
the project wouldn’t have been much helpful because, beside me being the only
one working on it, the main functionality was already completed and I was
already solving bugs and polishing. I started working in other projects with
this methodology and I completely recommend it to everyone. Having all this
type of organization was of tremendous help in seizing every moment to work on
the project and to keep everything safe and centralized. I had to change
laptops, I move to another house, I work both at home and in the office and
traveled to several places and my project was easily reachable anywhere I went.
It also helped me return to previous states of the project whenever I knew I’ve
introduced a bug in a previous commit or wanted to erase safely everything I’ve
done up to a point. One suggestion for everyone, that brought me some troubles
at one point, is that you should do frequent and atomic commits every time.
This way your project will be more separated in Git and you’ll easily find and
revert to any specific state you want. In one moment, I noticed that everything
that I had done up to a point was not what I really wanted and, instead of
manually erasing the code, I wanted to revert to a specific commit to prevent introducing
new bugs. Unfortunately, I haven’t been doing my commits as small and frequent
as I should have and I had to revert to a commit that erased some code that I
did wanted, and had rewrite it again. I’m sure that with my previous
suggestion, you won’t get this type of trouble.
A scalable and
modular project works well for everyone
I
tried working each and every feature and component of my game as an individual,
to make the project as modular as I could and I was pretty successful in doing
that. This would allow me later to add more freely and without difficulty other
features, like building a structure with Lego blocks. The input from the player
is controlled by a class, which maps the input to the different actions.
Because my game had three ways of controlling the character (desktop, gestures
and virtual buttons), this allowed me to easily integrate each one because it
doesn’t matter the way the input came, if it was from touching the screen,
gestures or pressing keys, my manager class would make the same and mapped it
to the corresponding action. On the main character, each behavior (walk, jump,
attack, shoot arrow, etc.) was controlled by a different script and then there
was a master script that managed and activated each one of them. This way, each
time I develop a new behavior, I could focus solely on what I wanted that
behavior to do, which makes the script smaller, readable and simpler, and then
letting the master script activate it when it was needed. Character animation
was controlled by a whole other script that was still controlled by the master
script. Enemies worked the same way, one script that controlled their behavior,
and extra scripts for special behaviors if needed. This script that controlled
their behavior would let me change their health, speed and damage but their AI
remained the same, allowing me to easily add new enemies with different
characteristics but that internally worked the same. Elements in the level
worked the same way. With this, I could make everything into a prefab, and
simply create new levels, enemies, characters, etc., by dragging and dropping these
elements into the editor, which reduced greatly the amount of work when trying
to escalate the project.
Multilanguage support
One
thing that I didn’t know I was going to have the time to make, was to allow my
game to support many languages. I knew it was not a “must have” feature but I
really wanted it to have it because my native language is Spanish and I have
decided to make my game in English. Adding more languages would help me reach a
broader audience. Additionally, personally, it would be a symbol of having
completed this course in a language that was not my own and was a constant
challenge and obstacle every month. Thankfully, time let me work on this
feature, which was a success. I didn’t want to just built-in the two languages
but what I wanted to do was to build a system that would easily let you add any
language for the game to support it. Unfortunately, this had to be made from
scratch because Unity doesn’t let developers support many languages with a
built-in system. Inspired by how it’s done in Android and iOS (background
knowledge helped me a lot in this section), I created some static classes with
the different texts in the different languages and another class who was in
charge of checking which language was set and returning the correct text. If
another language wants to be added, the developer would have just to add the
texts in the corresponding language to the class and the system will do the
rest seamlessly.
The Critique: What
went wrong…
Lack
of thorough planning pushes deadlines and builds pressure
Due
to the lack of free Greek-theme assets on the Internet and being this one of
the pillars that would let my project fulfill all its goals, my main concern
when idealizing this project was, how were we going to make all the assets
needed in such a short amount of time? I did a quick list of the assets I would
need for my project to be ready and got to the conclusion that with one
designer and a good timeline it would be fine. This was a utopic scenario that
almost never occurs. Once we started the development of all the assets I
noticed that deadlines were being pushed and pushed and the assets were not
ready to be implemented in the game, which desynchronize all the work between
programming and design that was a key factor to complete the capstone project
and all its features and objectives on time, so pressure started building up.
When I sat down again and analyze what could be happening, there were a lot of
factors that I didn’t take in account. First, being freelance, the designer had
other projects in which he had to work too and couldn’t dedicate full time to
my project. I didn’t take in account reworks, mistakes and redraws of the
assets to make them completely perfect, which took more time that what I
supposed it would be. Each project and each stage of the project should have a
timeframe planned to fix bugs, mistakes or do reworks. No project is risk-free
but a good planning of these risks with their respective solutions can let us
be more precise on how long these time margins would be. After this, I hired
two more designers and assigned them specific tasks and deadlines. Their
workload was less than what had the first designer at first, so I had a lot of
time to make corrections, give feedback and even cope with whatever external
delays the designers had. Quickly the pressure was released and the assets came
along great at the right time but with an extra effort. I now understand the
importance of planning and having backup plans to minimize the risks in a
project of this magnitude. For future projects, I will have a list of each one
of the assets needed for each character, NPC, animation, level, element, etc.,
and the time it should take (previously revised by a professional designer)
taking in account any major redraws or feedback implementation. This way I’ll
be planning for the worst-case scenario and every asset done in less time it’s
a gain in the project development time. A good solution, which I didn’t do it
either, is to have a backup plan in case what you intended doesn’t get done. I
should have looked for other assets on the Internet that served well on the
project event though they weren’t perfect or aesthetically exactly to what I
was looking for. This way at least I could get to the deadlines with a better
version of the project and saying that assets will become more polished in
later versions instead of just showing something that didn’t quite resembled
what I want. This is very important especially when the project is going to be
shown to financiers, clients or customers that can easily give a green or a red
light to your project in any stage. It’s important to have solutions for each
and every one of the risks that your project may befall into to make the
process keep going smoothly no matter the obstacles that are in the way. Of
course, what happened to me was specifically for the assets of my project but
this should implemented for any step, which may cause a great risk in your
project.
Code
Organization
As
I previously said, Unity gives a lot of freedom on how you can hierarchize,
organize and structure your code and resources, but this freedom can come as a
double-edged sword if you don’t know how to use it. At the beginning, having a
few folders with some kind-of-corresponding names seamed to do the trick for
what I was looking for. The project came along good at its early stages. As
soon as I started deepening more in complex functionalities, I started having
trouble with the hierarchy I have adopted for the project. Folders started to
have different names but having the same types of scripts inside, scripts
weren’t as easily found as before, there was no cohesion between the
directories. This was making my work progress slower little by little and more
tiresome. Finally, I had to take a pause in the development of my project as
started doing a thorough refactor of all the structure of it. I found out it
was easier to separate each component or element in 8 main folders: Animation,
Artwork, Fonts, Material, Prefabs, Scenes, Scripts and Sounds. Inside “Prefabs”
and “Artwork”, there were the same subdirectories, which were separated depending
on where they were being used (Enemies, Gameplay, Levels, Misc, Odysseus,
Screens). “Scenes” was separated in Screens and Levels and “Scripts” was
separated depending on the functionality of the script (Behaviors, camera,
collectable, collisions, effects, elements, extensions, helpers, input,
interfaces, managers, movement, UI). This is totally to consumers taste but it
can make your developing process and work more effective and easier. In the
end, it’s better to have an already proven good hierarchy and code structure
and then started tweaking it to fulfill each developer’s needs. Doing a
retrospective, I would have structure the code and resources differently. I
noticed that there were some built-in advantages in having all the assets
inside a folder called specifically “Resources”. Still, it worked pretty well
for me and I can be sure I won’t sub estimate the power of the freedom that
Unity provides when structuring the code. “With great power comes great
responsibility”. On the coding side of things, having come with a no-background
in Unity, made things quite challenging because I had no good practices
whatsoever. Due to Unity’s integration with a broad range of platforms, there
are a lot of ways to do the same thing and it will depend mostly on the
conception the developer has when programming each component, which in my case
was none. I realized it was better to construct each component as a single
being with its attributes rather than having many scripts controlling the same
things on the component and making the component tell others that interact with
him, about his status and attributes. This way you avoid having complex and
illogical interactions between objects, which happened to me a lot in the end,
and centralizing the information of each component in them. Having understood
this, I now have the proper background and paradigms to make any other project
right from the beginning, instead of doing reworks or realizing that I must do
big changes to the code at the middle of the project. Still, there is always
room for improvement.
Testing is all about big numbers
Although
I felt that I got a lot of information from user testing, learned a lot about
A/B testing, user testing, feedback, surveys, polls, testing tools, etc., I
expected more people to be involved in these tests that what actually was,
which I couldn’t say that was a significant number. Testing processes require
much more effort put into that what I actually did, especially to find the
rights testers and in significant quantities, which was, for me, the main
challenge. Testing was implemented since day 1 of the development process on
each area of the project. I used Google Forms to take surveys on people, which
was a great tool because it showed the results as statistics right away. I used
Talk-Aloud methods and personal interviews with players playing the game, as
well as discussions and questionnaires, to gather more and insightful
information about their likes, dislikes and needs. I recorded videos of their
reactions, inputs and game screen with an awesome platform called Lookback,
which also centralized all videos into a single spot no matter where they were
recorded (each tester could test the game from their device and Lookback would
record it and store it on the platform). I pushed new versions on the project
to every tester device automatically with HockeyApp to keep them updated on
what was new and to make testing processes easier and smooth. Even though I did
all these tests, I noticed that every time, the same people were the ones that
answered the questions and did the tests. I appreciate a lot what these testers
had as feedback and it help me a lot to polish and find solutions to known
problems in my project but I would have wished to have more and a more diverse
group of people. I think that there weren’t more than 20 testers, which was far
less from what I have in mind when idealizing all the testing process. I think
that people doesn’t want to add more work, to do an extra effort or simply is
not interested if there is no reward in it.
This was something that I knew, but I didn’t take in account, I though
more people would have been be more interested in getting involved in the
process of testing a kick starter game (I know I would have). Still, for future
projects I’ll put more effort on gathering the necessary and right amount of
testers and offering them a reward for their services at least until they feel
so involved in the project that they want to do it for pure interest and fun,
like my testers did. (25 min)
Gesture Input Controls
From the start, I wanted to give the player a novel and
original way to control the main character. I was sure that I needed to at
least try adding virtual buttons to the game screen for the player to push and
interact with Odysseus but these buttons still took screen real state, which is
very valuable especially in mobile devices. Sure I could add an alpha channel
to the buttons to enable the player see through them but his fingers would
still be place on top of the screen most of the time, but it was a solution.
The alternative to these buttons was to device a gesture input method were the
player could control the player by touching, swiping or dragging the finger
through the screen without visual cues that could interfere with the whole
gaming experience. A/B testing was required to see which of these two methods
was the preferred one by end users. In the end, both methods were implemented
as independent features of the game. The gesture method allowed the player to
move right or left if the touch was in the right or left half of the screen
respectively on the bottom half of the screen, because if it was on the top
half, Odysseus will jump. If the player taps an enemy, he will do a sword
attack but if he holds the tap on the enemy, Odysseus will shoot an arrow.
Sadly, this system didn't have the desired impact that I wanted or thought that
it will have. As much as I found it very easy and intuitive to use it, user
feedback, gotten through testing, didn't find it that way. Without a tutorial,
it was almost impossible to know how Odysseus was controlled (it felt as a
series of random movements) and even after teaching them how it was used,
players will often make mistakes or actions that they didn't want. Another
common comment was that once the player got ahold of the timing and how to use
the system, they felt that the movements were not precise and lack of speed,
which are key elements when playing platformer games. Players felt they were
not in complete control of the character while using this system and, despise
of the disadvantages that could bring the virtual buttons, they preferred to
come back to this method which resembled more how they used to play in console
games, etc. The majority of the people would rather play with the buttons than
with the gestures. Although it was a fun and novel way of controlling Odysseus,
it lacked the speed, focus and control that were necessary for platformers.
Also, having so many actions and gestures, makes it very difficult for the
player to internalize the system. Maybe if some actions were automatic and the
main character just needed fewer actions to control (like the title Rayman
Fiesta Run), it would have been a better feature. In the end, what this system
needed was more testing and polishing.
Tutorial
as a way of presentation
Another
thing that didn’t fulfill my expectations was the tutorial of the game. I
always vision my tutorial as a way of presenting all those NPC characters that
gave context to Odysseus and his world and the best way to help players make a
quick connection between the game and Greek mythology. I would have loved for
Athena to teach the player how to control Odysseus (since she was helping
Odysseus through his journey) to give context to the story. Also, it was a good
idea to stop every action to explain the user how to interact with an object,
how to surpass a specific obstacle or how to perform a certain action but
players expected to tap the message for it to go away instead of pressing a
specific button. If the player was pressing a rapid succession of buttons, he could
miss easily a certain part of the tutorial. Coding the tutorial was also a real
challenge. The levels were first built and then the tutorial was made, so the
tutorial basically was a sub-layer of a level, that could be activated or not.
This made it very difficult to allow the tutorial layer to get in the middle of
the different behaviors and elements interactions to have them do completely
different things that what they were intentionally and originally coded up to.
This is why the tutorial doesn’t feel as smooth and can feel invasive at times.
I feel that the best solution would have been to build a separated level with
all the tutorial functionality integrated (not as a separated layer) and tear
apart the different scripts and behaviors so they would work specifically for
how the tutorial was supposed to be. Maybe this can be sort of a rework or a
lot of code repetition but it would give more control to the tutorial, more
flexibility and it would allow it to easily achieve the completion of the objectives
we were after. Besides all these, there was a tutorial for the virtual buttons,
which were the easiest and more intuitive to understand due to their
resemblance to external controllers from console, but there was not a tutorial
for the gesture input method, which, beside being the least intuitive and
difficult to learn, it was the one that players felt more issues while trying
to get use to it. Also, having a tutorial for one system but not for the other
is a lack of congruence on the project. (29 min 30)
What can we learn
from the experience?
After
analyzing all the development process of my capstone project, I’ll surely would
have made two things differently. The first one is adding more effort to the
planning section of the project. I’ve never given the merit technical documents
deserved, but now I know the strong impact they can have on the whole process.
They’ll let you notice the risks and weak points of the project and find the
pertinent solutions to keep the project rolling even in the worst-case
scenarios. Also planning lets you choose wisely your team and how the workload
is going to be distributed between them to give more accurate timelines and
better quality vertical slices or versions of your project to keep the interest
and support of investor, consumers or clients that are behind the project. We
have to be aware that no matter our skills, our team or even the precautions we
take, things can still go wrong and push our deadlines. To minimize these
risks, we have to make sure we have our backup plans and solutions ready to be
implemented and add to our timeline, some frames for bug fixes, redraws,
rework, etc. Everything that is done before the deadlines, can be seen as a
gain to the project and is better to give long timelines and have the project
ready before expected than giving a short timeline but having to ask more time
and push deadlines. The second thing I would do differently is regarding the
coding section of the project. At the beginning of the project, I didn’t have
any background or notion to guide me through how, what and why should I do my
code one way or the other. Realizing advantages and disadvantages of doing
things different ways made me change the way I coded several times, which
brought inconsistencies in the code as a whole and in the end reworks and even
a slower process. Now, with everything I have already learned, I know which
coding paradigm works best for me and for the necessities of the project being
done. I now understand completely how components should be created and how they
should interact between them, which will ultimately make my code more legible,
logic and will allow development processes run smoothly, besides not having the
learning process and steep curve that I did have in the beginning of the
project that took a lot of the time in the first weeks.
Summary:
Summing
everything up, I am pretty pleased and happy with what my capstone project has
become. I think that the project defers from the original in some ways to make
it better, but it pretty much stayed right in track from the conceptual idea.
Evidently, due to time reasons, some trade-offs had to be made to show a fully
developed vertical slice of what would be the complete the game. These
trade-offs came, for the most part, on the design side of things. There were
elements that weren’t designed or included (NPC, environment elements, etc.) to
put more focus or effort in others that had more weight in fulfilling the
game’s objective or in completing other functionality that was missing or was
more interesting. From here, I plan to add one or two NPC’s (one as a tutorial
guide and the other one who will tell Odysseus parts of the story) and build at
least five more levels, which should take me around one month. Then, I plan to
add it to my portfolio and release it to the two major mobile platforms
(Android and iOS) to start getting more feedback and making a name for myself.
This way, I will be able to make my next game or project a lot more informed
and with a better judgment. I’ve realized that is better to make several
“small” projects to tests your abilities and learn the do’s and don’ts of a
platform and coding style, before investing and releasing a full project which
you expect to make a living out of it and having a team behind supporting it.
References
Torres, A. (2016). The Odyssey
[Android video game]. Caracas, Venezuela.
