LYCEUM ALABANG

College of Computer Studies

Ai Shiteiru Kara
(Because I Love You)

A Game Proposal

Presented to the Faculty of the

College of Computer Studies
Lyceum Alabang
Muntinlupa City

By

ANGELICA ROSE HADAP

MARLON SANCHEZ
CESAR DEGUIDOY
MICHAEL JAIRRO EMILIA

In partial fulfillment
of the Requirements for the
Game Development

AUGUST 2010
 LYCEUM ALABANG
College of Computer Studies

Introduction

A. Planning Phase

The primary objective of this phase is to determine the various variables that make a
game. Here you will have to determine the story, the characters, the world, the
music, the graphics, the battle system, the database, everything.

 System - What would your game be? Is it an RPG? A First person shooter? A
Real time Strategy Game? A Puzzle Game? A Fighting Game? An
MMORPG? Will it have to use the whole keyboard? Will it use the whole
screen? Everything must relate to each other. Why use a mouse when you
can just use the arrow keys? Why use the arrow keys when you can just use
the mouse?

 Writing - You need to determine the whole story and all plot twists in the
game. How would the character be introduced? How about the villain? How
about the world? You need to make a solid an unique story in order to fulfill
your goal. This might be applicable only to RPGs.

 Graphics - You will have to determine what kind of graphics you need to use.
Will you need anime sprites? 8-bit sprites? fully rendered 3D models?
Portraits? Parallaxes? Will you stick to one art form or swap from time to
time? Think about what your game would look like and how the players will
see it.

 Music - What music shall be used? Retro? Rock? Solemn? Emotional? What
instruments do you need to use? Wind instruments? Strings? Percussion?
 LYCEUM ALABANG
College of Computer Studies

How should the music be played? Fast? Slow? Think of the game and make
sure to apply a proper music for every scene.

 Technical - What language would you use? C? Java? Python? Ruby? In what
platform would your game be? PC? PSP? PS3? Wii? NDS? What would be
the recommended system requirements? Will a slow PC be good enough? Do
we have to use a game pad or controller to play it? Do we have to swing the
Nun-chucks to play the game? Do we need to tilt the hand-held console for it
to move? Do we need extra accessories to play it? A microphone? A Stylus?
Does it require internet connection? Use only things that your game will need.
Why require a microphone when you don't even use it even once in your
game? Once the planning phase is done, you are ready to move on. Note that
you don't have to actually plan everything at first but it would be better if you
can. If you want, you can do small releases from time to time and plan from
what feedback you get. Once you are done planning, continue on and finish
your game. Unplanned events are only fun in real life, but in Software
Development, it could mean trouble.

B. Analysis Phase

In this phase, you have to ask yourself, "Can I really do it?". There are many people
that does things without even asking themselves if they can actually do it. Most of
the time, people just do things on the way and when a problem occurs, fix it and just
continue on. Yes, it is okay when it comes to small projects, but it is unforgivable
when it comes to large-scale projects, especially if it is a commercial project.
Basically, you'll have to determine if the project is feasible in this phase.
 LYCEUM ALABANG
College of Computer Studies

 System - Can this be actually done? Does my programmers possess the skill
to do it? Will they finish it on time? If you are working on a team, consider your
team mates' strengths and weaknesses. It will help you along the way. If you
are working alone, consider your skills.

 Writing - Does the story make sense? Will the readers/players like it? Is it
confusing? Can my writers actually write it with the details I've given? You
need to determine if the story can be done. Failure to have a complete story
sometimes lead to downfall.

 Graphics - Can you afford to buy 3D models? Does your artists have the skill
to do the Graphics? Is the art form clear? Can you easily recognize an image
with just one look? Does it comply to your needs? Consider your graphics
skills (as a whole) and determine what each of your team mates can do. If a
certain art form is difficult for one artist but really easy for the other, you might
want to reconsider your art form. Each and every one of your artists should
agree on which art form you will need to use. If not, a conflict will occur.

 Music - Can your musicians actually play it? Can your composer make it?
Does it sound good? Will it give you an eargasm? You and your musicians
should determine who does what and who plays what. You can't have your
drummer play the bass guitar at the same time. All of you should agree on the
instrument, music style, mood, everything.

 Technical - Will your programmers have enough knowledge on the language

you use? Can they program software on the PS3? Do they have experience in
playing the Wii? Your programmers whould be able to know what your chosen
platform can and cannot do. While the PSP has bad ass graphics, it
 LYCEUM ALABANG
College of Computer Studies

doesn't have touch screen like the NDS. Make sure your programmers know
the language really well so that when everything is gathered together, the
pieces will fit perfectly with each other. It is better if they have a standard for
naming conventions like an integer variable must be prefixed with int- while a
string variable must be prefixed with str-.

If you find that you cannot do anything you've planned, better return to the
first square and think about it again. The impossible will never be possible. If
you can't do it, don't do it. It's just that simple. However, if you still want to
insist, try thinking over it again. For example, you want to do a 3D game but
your artists (and you) can only do 2D images. It might be better to drop off
the 3D idea and just stick to the 2D idea, where most of your team members
are experts and/or adept.

C. Designing Phase

This is where all work begin. Make sure you have a schedule on who does what on
when and don't let a single second go by with any one of your team mates doing
nothing but sit idly on the chair (except for breaks). Try to have a goal for each day of
development. This is where the fun starts.

 System - Make sure not all people are doing the same thing. Have one work
on the controls and the other on how the interface would look like. Other guys
should pair up and setup the database. Only two people (at max) should be
working on the same job at the same time.

 Writing - Writing should be done far before the planning phase. However,
there are some instances that the writing is still not done even on the start of

the development. If that cannot be avoided, make sure everyone are

brainstorming and one jots down every piece of information. Then dedicate
 LYCEUM ALABANG
College of Computer Studies

some time to combine them all and read it aloud. If anyone has objections or
comments, he or she should not be ignored. Every piece of information will
help you make a good story.

 Graphics - If you are working on 3D, have one work on the model, two on the
texture and another one on the environment. In 2D games, have one work on
sprites, one on map, one on interface. Again, make sure only two people at
max must be working on a job at the same time. If one finishes earlier that
scheduled, he or she could do the next plan or he/she could help others finish
their work. As for the team leader, you have to supervise their works. If you
see something wrong, don't hesitate to ask. Don't hesitate to boss around, but
also don't abuse your power as a leader. Get your other team mates'
comments before accepting a work.

 Music - Listen carefully as to what the musicians did and imagine yourself
plying the game with that piece playing as background music. If you feel you
need to change it, say so. If you feel the tempo is too high, say so. Do not
hesitate to tell your composers and musicians all the details. Even the small
details like "I want an extra note here" or "Remove this bass note and replace
it with a nice drum beat". Everything must go your (and the team's) way.

 Technical - If one of your programmers find it hard to do a certain thing,

switch programmers. Each one must be proficient in what they do. If this guy
is really good at math, give him the part where complex calculations need to
be done, like damage calculation. If this guy is really goos when it comes in
manipulating the mouse, then have him work on the mouse controls. Also,

one of your programmers need to supervise them all (if the team leader does
not know programming). He/she should constantly check each and every
one's work. Another thing, your programmers should comment important parts
 LYCEUM ALABANG
College of Computer Studies

so that whoever will read their code knows what does what. This helpful
especially for the one who will combine them all.

This is the busiest phase. Make sure you have a deadline. The team should
work hard but not too hard. Have a set schedule for the day and make sure
you fulfill the chores for each day. It might take weeks, months, or even years
but when you finish it, you'll see that all hard work is all worth it. Besides, the
only place where success comes before work is the dictionary. Work hard and
do your best each time.

D. Implementation and Testing Phase

This is where all your work become one. The team will need to put all their work in a
single, working program. Does the music match the scene? Does this image go well
in this background? Are the enemies imbalanced? Are the items useful? Does the
mouse work? Does the battle system work? Does the damage pop-up work?
Everything should work correctly and efficiently together. If one thing didn't look
good, return on working and test it again. Your project should be as bug free as
possible. Bugs, when they come in HUGE amounts, can destroy a whole farm, and
in this game, can destroy the whole game. If you feel something is wrong, tell it to
the team. If you see a missing polygon, tell the artists. You heard a static on the
background music, tell the musicians. You suddenly got infinite HP, tell it to the
programmers. The weak little slime just did an OHKO, tell it. Every flaw you see, tell
it to the team so it can be fixed. The mouse doesn't work if the keyboard is attached?
Tell them to fix it. There is no harm in saying the flaws of your projects. Learn from
your mistakes and try not to do it again.
 LYCEUM ALABANG
College of Computer Studies

E. Distribution Phase

This is it. You had finally made a working prototype of your project. Post it on the
forums. Blog it. Show it to your friends. Have a professional reviewer review your
game or maybe not. Ask. Was it good? Did they enjoy it? How much negative
feedback did you get? Did they find any bugs? Note that I called it a prototype. Why?
Unless you have loyal beta-testers, you won't be able to track all the bugs (even
those with beta-testers have bugs in them, DotA for example). While testing, you did
everything to find bugs, everything and you even spent a whole day just debugging.
You thought it was fine but when you posted it on the net, a damned decimal point
made the game crash. One might discover a bug better than you, because they think
simpler than you, the creator, who thinks ahead and looks for the complicated part.
You cannot really say

your game is finalized until all the bugs are destroyed. When one of your players find
a bug, fix it immediately and post a fixed version. It is better to use numbers in
naming program versions. One can easily tell if the program was the latest version if
the program was named 'Black Hole v1.67' rather than 'Black Hole Version
Blazeheart'. Although it sounded cool at some point, think of the users. If you have
an index of all your released programs, then it could be fine. What if you don't have a
personal blog or website and you are just posting in different communities? People
might find it hard to tell which is which. Keep your blog/post/site updated. Do a check
on a daily or weekly basis. Hell, play your game when you have free time. You might
find bugs that are easily accessible to you as a player than as a developer.

F. Finalization Phase

This is where everything comes to a full stop. This is the part where you put the word
'FINAL' in your game. A game can only be finalized if there are no more bugs and/or
glitches. This is the part where you stop doing beta releases and prototypes. You do
 LYCEUM ALABANG
College of Computer Studies

no more updates in your game for there is nothing to be updated. Everything is in

place and it's as if all puzzle pieces are glued on to the board so that whatever you
do, the puzzle remains intact. This is where all your hard work pays off. AS you can
see from the diagram above, you cannot go back once you are in this phase. There
is no turning back. If you find another bug, then consider your project still in the
testing phase.

The Story

Once upon a time, in a far land where its name was just a hearsay to other
places, a village stood known as Zypersiand. It was a place where nobody would
think finding it there. So remote and yet in abundance of everything they were
needing, enough to let the day pass without remorse and heavy toil.

One day, there silence were shattered, there sacred land were invaded, and
fear resided in everyone’s heart. They felt hopeless, they did not know where to run
for help, their great warrior, Arokshu, were traveling south in search for adventures.
Their wise old men associated everything to their gods’ punishment for wrongdoings
and disobedience.

Shikazi, an evil ruler notorious for his black magic, envaded there land. With
his great power, nobody would dare to fight and fight back. He caused undescribable
fear among villagers. His wishes are rules to follow. His desires really mattered. He
knew no excuses, he got no heart. His commandment made their heartbeat to a halt.

Elfhira was taken by force. Shikazi chose her as his offering and a sacrifice to
the gods to keep his power and control over the land.. Kithara was engaged to her
boyfriend who traveled south with a promise of good things for their future. She was
 LYCEUM ALABANG
College of Computer Studies

badly needing him, who would never let anyone touch and hut her the way Shikazi
did.

Kithara had to pass the forest maze but it was not as simple what he thought.
Forest Maze is a labyrinth of trees and underground passages found in the map. It
included another map that he could access by finishing the dungeons, but the main
part was a maze infested with limited enemies. It was being guarded by Foster, the
god of forest.

Next, Kithara had to sail until he reach the desert. A desert named by the villagers
”Desert Scream”. He showed no fear after hearing the stories that Elfhira is in the
hands of the evil magician. The desert includes an underground cavern with infected
monsters that are needed to be killed. The obstacles doesnt ended here, there is still
the master who Kithara must defeat the guardian of the desert, Orin.

Shizaki knew already that Kithara will save Elfhira. But he will not allow him to take
his beautiful sacrifice easily. He had the power to stop those who will stood against
him. His power is undeafatable. Nothing on Earth could defy him, even to make
even with him. He is Shizaki, the evil, the powerful, and he would rule all over the
world. This mighty warrior was no compare to his greatness. They would die soon.

Kithara was determined to defeat them, those who wished death for him- but no man
on Earth could separate them. He had nothing but the greatness of his love. The
heavenly God would never allow such villainous man to stand between them. All of
the sudden, he defeated those who served the evil man. He saved his beloved
Elfhira. He killed Shizaki. They were together again, sailing home and a promise of
endless love.
 LYCEUM ALABANG
College of Computer Studies

Locations

Our world will be reduced to the island of Zyperia. Inside this island, the player can
travel to these different locations:

 Village of Zypersiand

This is the place of Kithara, the main character.

 11
 Forest Maze

This is a forest inhabited by infected creatures such as plants, spiders,

bats, etc.

 Desert Scream

This is a desert includes an underground cavern with infected monsters

such as plants, rats and the guardian of forest,

 Castle Of Shikazi

This is where King Shizaki, the evil magician resides.

Quest

The game has only one main quest, but this quest can be split in two smaller ones,
which must be completed in order:

 Go to the Desert Scream and fetch Excalibur, the magic sword.

 Go to the King’s Castle and kill the evil King Shizaki, who will be the final boss
of the game.

Events
 LYCEUM ALABANG
College of Computer Studies

Events are a method of causing a wide variety of automatic or interactive elements

within the game. The vast majority of things which occur outside of battles are
controlled by events designed by the game's creator. There are 90 event commands,
allowing the creator to perform actions such as movement of characters, special
effects such as music or color tones, and complex mathematical calculations. Such
events can be intricate or simple. Variables can store information such as numbers
or text to be used by events. Up to a total of 5000 variables can be created. Events
are executed as Ruby and RGSS code which can be read through an interpreter in
the program's database which then executes the code.

Mapping

Mapping is the name given to the creation of the characters' environment and
surroundings by using tiles that contain eight 32 by 32 pixel frames lined up
horizontally. According to Enterbrain:

These files contain tiles for map making. Each tile contains at least one block of eight
32×32 pixel frames lined up horizontally, but can go on to contain as many blocks as
necessary. There's no limit on the file's vertical size.

These tiles can be placed in any order to pattern such as a field of grass or a desert
depending on the tileset. The resulting graphics are displayed on the game screen.

RPG Maker XP has a way of identifying certain tiles and how flat or tall a specific tile
is going to be. For example a tileset that contains trees and grass both have different
heights. A tree is typically tall and must stand above the player, and grass is usually
below the player's feet. Two important features RMXP uses to identify these are
 LYCEUM ALABANG
College of Computer Studies

passability and priority. Passability tells the system where the character can pass
and where he or she cannot. For example if a rock has a passability of X that means
the character cannot pass through the rock; on the other hand, if the rock has a
passability of O the character can seemingly step through the rock.

Priority is what tells the system how tall something is and how much higher it is than
the character. A priority of 1 tells the system that the specified tile is just above the
player. A good example would be a table. A table is usually not taller than a person;
therefore it would have a low priority. The higher the priority the taller the tile would
look. A tree which tends to be taller than a character would have a priority of 5 (the
highest priority) because it is the tallest tile out of the set. With this system, players
might look as if they were stepping through trees or moving under tables.

Mapping also uses four layers: the three tileset layers, and an event layer. There is
also a fog layer, which adds an alpha compositing effect to the game. This can be
used to create fog, or the shadows of trees or clouds, for example.

Most games have a graphic file that holds text. Text can be displayed on this graphic
file called a window skin. This graphic file typically measures 192 by 128 pixels.
Window skins carry the basic window which will house the text written by the user for
the character. A second part is the window frame which notifies the player of the
game that there is more text to be displayed through 16 by 16 arrow icons. A
command cursor which notifies the player of what has been selected, a pause
graphic is also present, to notify the player that they have stopped cycling through
the text of the character. It contains a four frame animation which makes it seem like
its moving. Finally there are arrow cursors, very much like the ones used in
computers. These are used to make to point decisions when a player is faced with
multiple options.

Transitions are graphic files which transition a player from one scene to the next.
Typically transitions are used in the program to transfer the player from their map
 LYCEUM ALABANG
College of Computer Studies

environment to a battle. The sign of the transition is usually used as a notification to

the player that there is an upcoming battle. However, transitions can be used for
anything, such as transition to a bed or from one place to another.

Images can be displayed in-game. Images are kept in a image folder and must be
directed in x and y coordinates to tell the system where to display the image. Images
can be any size and can be any format -- including JPEG, PNG and GIF -- allowed
by the program. An 'image' is displayed about the 5th layer -- it has higher priority
than any other game effect, including text windows.
 LYCEUM ALABANG
College of Computer Studies

Maps

Figure 1 : World Map

LYCEUM ALABANG
College of Computer Studies

Figure 2 : Village of Zypersiand

LYCEUM ALABANG
College of Computer Studies

Figure 3 : Adventure Part 1

LYCEUM ALABANG
College of Computer Studies

Figure 4 : Last Adventure

LYCEUM ALABANG
College of Computer Studies

Figure 5 : Grandpa’s House

LYCEUM ALABANG
College of Computer Studies

Figure 6 : Forest Maze

LYCEUM ALABANG
College of Computer Studies

Figure 7 : Forest Maze Final Map

 LYCEUM ALABANG
College of Computer Studies

Figure 8 : Sea Adventure ( Desert Scream)

LYCEUM ALABANG
College of Computer Studies

Figure 9 : Desert Scream

 LYCEUM ALABANG
College of Computer Studies

Figure 10 : Desert Scream Dungeon

 LYCEUM ALABANG
College of Computer Studies

Figure 11 : Sea Adventure ( Castle of Shizaki )

LYCEUM ALABANG
College of Computer Studies

Figure 12 : Castle of Shizaki

 LYCEUM ALABANG
College of Computer Studies

Figure 13 : Castle of Shizaki ( Final Battle )

LYCEUM ALABANG
College of Computer Studies

Figure 14 : Ai Shiteiru Kara