ice vs fire process book

7/23/2019 Ice vs Fire Process Book

http://slidepdf.com/reader/full/ice-vs-fire-process-book 1/13

ICE VS. FIREDAGD 355

Jonathan Champion



Page | 1

Table of ContentsPreface _________________________________________________________________________________ 2

Planning ________________________________________________________________________________ 3

Theme ______________________________________________________________________________ 3

Audience ___________________________________________________________________________ 3Final Summary _______________________________________________________________________ 3

Elevator Pitch ________________________________________________________________________ 3

Research ___________________________________________________________________________ 4

Controls ____________________________________________________________________________ 4

Control Scheme _________________________________________________________________ 5

Keyboard ___________________________________________________________________ 5

Game-pad __________________________________________________________________ 5

HUD + Menu Concepting ______________________________________________________________ 5

Attacks _____________________________________________________________________________ 7

Player __________________________________________________________________________ 7

Basic Enemies ___________________________________________________________________ 7

Spinning Enemies ________________________________________________________________ 7

Boss ___________________________________________________________________________ 7

Building the Project_______________________________________________________________________ 8

Setting up the Project _________________________________________________________________ 8

The Player __________________________________________________________________________ 8

Enemies ____________________________________________________________________________ 8

UI __________________________________________________________________________________ 8

What Went Wrong? _______________________________________________________________________ 9

Major Setbacks ______________________________________________________________________ 9

Minor Setbacks ______________________________________________________________________ 9What Was Learned ______________________________________________________________________ 10

Art ________________________________________________________________________________ 12

Sound _____________________________________________________________________________ 12

Code ______________________________________________________________________________ 12



Page | 2

This Process Book was created for the Digital Animation and Game Design class Game Programming 2

at Ferris State University. This book will show my process for creating the Unity game Ice vs. Fire. While

the game did not turn out as originally planned, this book will shed light on what I gained in the process

of creating it.

Preface



Page | 3

Theme

I spent a lot of time deciding on how my game would end up. While I knew my game would be a SHMUPI had no other theme or game-play ideas. I started off making a document and listing all sorts of unrelat-

ed themes and subjects. From these lists I could pick interesting combinations of elements to formulate

my game. I knew I wanted to do something semi-unique to the SHMUP genre and I wanted to bring in

elements from other genres as well; so I added in some fantasy themes.

Along with these theme ideas, I also found plenty of image references from other SHMUPS and genera

art styles I liked. Having these conflicting types of images helped me mentally picture adding in fantasy

elements to a SHMUP. A main influence was the wizrobes from the Legend of Zelda: Minish Cap. These

enemies will be similar to some of my enemies.

After reviewing and narrowing down these lists while keeping my reference images in mind, I finally choseIce&Fire and Time as my final theme. A close second to Time was Dragons, however, I didn’t want to have

to worry about creating good art. Not to mention I could do some cool effects/attacks based around Time

AudienceThis game will appeal to those between the ages of 12 and 20. This is because of the generally simple

mechanics of the game. Ice vs Fire will appeal the game pleasures of Challenge, Sensation, Fantasy, and

Submission.

Final SummaryIce vs Fire will be a 2D, top down bullet hell, that places the player in control of a ship powered by ice

magic. This player faces off against hordes of enemy ships that use fire magic. The player must overcome

the natural advantage of the fire ships in order to survive the battles. The player will be able to not only

shoot at the enemies like a traditional SHMUP, but they will also be able to use their magic to create

chunks of ice that act as shields/obstacles to protect the player until they melt or are destroyed. The

game will progress in waves, with an occasional boss fight that will reward the player with new magica

powers. These new powers will evolve from ice magic to time magic.

Elevator PitchIce vs Fire is a 2d, top down, bullet hell that pits the powers of ice against hordes of fire wielding ene-

mies.

Planning



Page | 4

Planning Cont.

Research

I have never made a SHMUP (Shoot-em-up) game before. Nor have I played too many of them. Thus I hadto do a lot of research about them in order to figure out how they work. It turns out that SHMUPS cover a

wide variety of games, such as rail shooters and “bullet-hells”. I will need to narrow my focus from simply

making a SHMUP to something more precise.

I also quickly realized that SHMUPS contain some very complex logic in their bullet and AI classes. Since

unlike other games, the bullets in SHMUPS can form complex and devastating patterns designed specif-

ically to be challenging enough to be deadly, yet have noticeable safe zones.

I spent the next couple weeks refining my concepts, doing more research, and coming up with a [very

small prototype. I quickly created a temporary logo (and just as quickly threw it out) and formatted the

Game Design Document. I downloaded and spent time playing Danmaku Unlimited 2, which is a SHMUPavailable on Steam. I did this to get a feel for the genre, as well as get inspiration for my game. By playing

this game I also learned first hand what SHMUPs need to have, such as easy to read HUDs and easy to

define Hit-boxes. I spent a good chunk of time creating a Game Flow document. This document goes over

how everything in my game is connected and how things move from one event/action to the next. More

time was spent concepting and I decided on some different attacks for the player and enemies to have

My control scheme is finalized as well, until I can properly test the comfort of it while playing [in theory it

should work perfect].

I played Danmaku Unlimited 2, an indie SHMUP available on Steam. Even in the brief time I played the

game I learned quite a bit about Bullet Hell SHMUPs. It is key that the player can keep track of enemy

bullets, thus their need for bright colors. Second it is important that the player’s hit-box is defined wel

and relatively small, else the player will be hit a lot. The HUD must also be simple and easy to read as

well, all vital information should be able to be seen with peripheral vision.

To get a better idea of how to create a game like this, I followed along with a tutorial provided by Unity to

create a space style shooter. While their tutorial was a 3D game, can apply a lot of what I learned from

this tutorial to my own game.

ControlsBecause of the intense action nature of the game, I never want to make the player take his thumb/fingers

off of the movement and aiming controls. While this works fine with a keyboard layout, it proves chal-

lenging with a game-pad as the thumbs are the main input. I intend to solve this problem by adding in a

cycling system for special attacks.



Page | 5

Planning Cont.

Control Scheme

Keyboard • WASD Movement

• LMB Shoot

• RMB Special Attack

• Space Bomb

• Q+E+MMB Cycle Special Attack

• 1-4 Select Special Attack

Game-pad

• L Stick Movement• RT Shoot

• LT Special Attack

• RS Push Bomb

• LB + RB Cycle Special Attack

• ABXY Special Attack Select

HUD + Menu Concepting



Page | 6

Planning Cont.

HUD + Menu Concepting Cont.



Page | 7

Planning Cont.

Attacks

Player

• Basic Attack

• Bomb

• Special Attack 1: Ice Beam

• Special Attack 2: Ice Spikes

• Special Attack 3: Ice Block

• Special Attack 4: Time Adjust

Basic Enemies• Basic Attack

Spinning Enemies

• Basic Attack

• Rotation

Boss• Basic Attack

• Homing Attack

• Fire Bombs

• Fire Circle (rotating and expanding out)



Page | 8

After more than a month of planning I had finally completed my planning phase, which included following

several tutorials for Unity.

Setting up the ProjectTo start my project I set up the Input Settings in Unity according to my planned control scheme. I also

made sure my target platform was set to PC.

The PlayerI started off by creating a player object, I gave it the ability to move and created a health script for it.

created a bullet object and an according controller script for it. I gave it some public values to allow for

tweaking in the editor. I restricted the players movement range to keep the object in bounds of the play

area. I spent most of a week setting up the player and making sure it “felt” right. The player sprite is a

simple triangle shape, however I planned on updating this in the future.

EnemiesI made a base enemy object that would act as my main enemies, this class would be expanded later

when I make more enemies. The enemies will spawn at a random position and move at a slightly random

speed down the screen until they despawn. The enemies spawn in waves from an IEnumerator in mygame script.

UIEric Selover created my main menu, and I later implemented the UI for the player. I planned on creating

UI to show more information about the game itself, such as spawn wave number and enemy health. This

additional UI did not get implemented before the project was due.

Building the Project



Page | 9

Major Setbacks

Over the course of this semester I came across a handful of setbacks. The major problem I faced whilecreating this game was largely personal: Time Management. While I did manage to work on this project

every week, once I had most of the planning done I tended to start to prioritize this project last. Obviously

looking back I realize that I should have spent more time each week working on this project, however it

was difficult to make myself work on this instead of other projects with closer deadlines.

Minor SetbacksThis project, like any project, had a good number of minor setbacks. Most of them were easily fixed, how-

ever they did cost valuable time. Below is a list of problems encountered while working on this project.

• Name changes not syncing correctly with GitHub.

• Collision detection not working because of a missing Rigid-body object

• Being sick for a week

• Runtime error when implementing two players, caused by one of the players returning a Null

• Sprites rendering fuzzy, had to change import settings

• Health Bar graphics not getting setup properly. Had to go into the slider object and change up some

cropping settings

• (Sort of Procrastinating by) Spending four hours creating a base InDesign file to use for this, and

future projects

As with any sort of programming project, the entire process is largely learning how to solve small prob-lems. These problems are some of the more time consuming problems I can remember from this project

A large amount of time was spent learning how to access things in Unity and figuring out the correct way

to organize a project file with its various parts. Many tutorials I came across had dozens of tiny scripts

while I was used to having larger class files. Thus I had to spend time finding a happy medium for this

project that I was comfortable with.

What Went Wrong?



Page | 10

Since I had never used Unity before starting this project, I learned quite a bit from this project. Which is

good, since that was kind of the point of talking a class in Unity. Before starting this project I was worried

about the quality of Unity, having done some stuff in Unreal Engine 4 I was anticipating Unity to be painfu

to use. I was quickly proved wrong as I found Unity has some nice qualities, most notably being able towrite code without using a node based system, which I find gets cluttered and difficult to navigate. This

project, and the research that went along with it, helped me understand quite a bit about Unity. Such as

• Setting up a project in Unity

• Importing assets

• Creating Scripts

• Accessing other components

• Coroutines

• Creating Persistent Data

• How to use Unity’s UI system

• A brief history of Quaternions

• Unity’s sound system

• Crating a landscape in Unity, along with foliage

• Setting up two player input

However these are just basic topics that I learned about, mostly in class. While researching I learned

about quite a bit which didn’t make its way into this particular game. While most of this was learned in-

dependently, I also learned a handful of things while interning at YETi CGI. Here is a list of some of the

unique things I learned:

• How to implement Google Cardboard into a Unity Project• How localization works in Unity, and how it is nowhere near perfect by itself

• How to setup a spreadsheet for localization, and export it to be used by a localization script

• How to setup Master Pages in InDesign

• The Magic of Save For Web in Illustrator

• Google Doc’s have a one click tool for setting up a Table of Contents

• GitHub freaks out a lot, when it isn’t pulling correctly go into GitShell and use the “git pull” command

to force it to download

• Make sure when creating something for mobile that you always test major changes on device with a

release build

• When building for mobile, create a simple script that allows you to change device rotation when test-

ing in the editor window• If you are designing for mobile, account for the fact that Android has a back button, while Iphones do

not

• Make sure temporary art looks decent, you never know if you will have to show your prototype to a

different company

• You can copy things in Illustrator and paste them in InDesign

What Was Learned



Page | 11

What Was Learned Cont.

Besides the various technical things I learned from this project, I also learned a substantial amount about

what to do for my next project, how to set it up, and what to plan for. This project was a great example for

myself of why I need to adhere to my set schedules, and to resist the urge to prioritize things just becausetheir deadline is closer.



Page | 12

Art

All art assets were created by Jonathan Champion

©2015 including:

• blue.png

• blue_magic.png

• bomb.png

• healthbar_back.png

• healthbar_fill.png

• red.png

• red_magic.png

• space.png

• special_box.png

• stars.png

SoundMusic licensed from DeWolfe include:

• Speed_DWLP 3378_11 John Saunders_De Wolfe.mp3 by John Saunders

• Mars Awaits_SYNC 0261_10 Gavin Skinner_Synctracks.mp3 by Gavin Skinner

Code• MainMenuControllers.cs was created by Eric Selover

All other code was written by Jonathan Champion © 2015.

Attribution

ice vs fire process book

Documents