Jordan Finley – 2D Game Engines
“Internet Wars” – 2D Game Engines idea for 2D Platforming Game
10/02/2011
THE IDEA
The game follows the story of the Nostalgia Nerd. A super genius beyond his years, he enjoys life in
1994 so much that he built a time loop generator around his house to go back in time and remain in
perpetual nostalgia. Packing a custom supercomputer still running Windows 3.1x, he is famous on
BBS’ and Usenet alike for his contributions in the Meow War of 1993. Relaxing in his room and
watching Nickelodeon, sipping a Sunny D. In this timeline, he is King.
While he lives enclosed in this space away from society, the world
continues as it always has done. Web 2.0 is in full swing and the
Nerds prized software and hardware irrelevant. It would be an
awful thing if his time loop generator malfunctioned... But what
really happened was so much worse.
Overlooking the Nerd’s house was an evil genius. Unknown to the
Nerd, this genius also lived in perpetual nostalgia... But some
things just can’t be dealt with over the Internet. This genius’ name
is Tony van Shaunholme. With an almighty yell, he hurls a lightning
bolt at the Nerd’s time loop generator, destroying it and hurling
the Nerd into present day.
As his Netscape browser begins to crash, and upon loading a few webpage’s he is struck by the
“horrors” of Internet memes and the state of popular new websites. “The Internet is serious
business!” “No fun allowed!” he proclaimed, weeping for his old way of life.
Enraged by this new silly and fun internet, he makes it his mission to destroy the impure place and
bring it back to the days he remembers!
Jordan Finley – 2D Game Engines
Driven mad from the isolation and current state of the world, he installed horrific cybernetic
implants into his body and became mostly cyborg. Whilst destroying his humanity, it granted him
advanced combat and Internet navigation skills, skills he will need for this upcoming “War of the
Internet”
Whipping out a USB 1.0 cable from the side of his head, he plugs himself into his computer, loads up
Netscape and begins his journey to the centre of the Internet.
Will the Nerd find his oppressor? Will he return to his nostalgic heaven? So begins the tale of an
Eternal September.
THE GAMEPLAY
Upon starting the game, the player is presented with a level select screen, showing the website they
can jump into, ala the classic Megaman games. It is similarly presented in a square of 9 smaller
blocks. All 8 surrounding levels must be cleared to unlock the middle square, and the concluding
level of the game.
This game plays out initially like a normal platform game. The Nostalgia Nerd navigates tricky jumps
and enemies (changing depends on the level) and eventually reaches a larger, difficult to beat Boss
enemy which represents the Dark Master of that domain. The Dark Master represents the most well
known face of the website, for example Facebook’s Mark Zuckerberg raining down “Like” missiles,
and bombarding the player with “requests” and “notifications”. Just like in real life!
At the end of each level, the Nerd gains a new
offensive or defensive ability depending on the
website he just assimilated. As you can initially
choose which level to start with, this is an
important choice to make if you want to have an
advantage against later bosses.
Also similar to the classic Megaman games, the
Nerd is initially equipped with a basic Data Gun,
shooting concentrated bits of data at enemies and
causing them to error and crash. Later on more
elaborate weapons such as Beam Cannons and
Swords can be unlocked, giving even greater destruction power for the legions of defenses that are
presented.
The Nerd travels through the depths of the Internet, and thus encounters all manner of domains he
must conquer. Levels include the constantly pestering Facebook, the ridiculous video memes of
Youtube, the popular fads and characters of Online Games, the dangerous domain of Torrents, the
horrific art of DeviantART, and the source of all evils, 4chan.
Before the game and each level starts, depending on the limitations of the GameMaker program
there will be a short scene of words and pictures giving a little backstory to the website, if the player
does not know already.
Jordan Finley – 2D Game Engines
11/02/2011 – Creating the animation frames
I feel that the best way to start would be to create all the character frames, so I have something to
work with when it comes to object programming. To begin with, I want to make the character
running, jumping and shooting animations. With these, I can make the basic movements.
Figure 1 - Idle animation sprite sheet
The Nerds sprite style is based off the image I drew back when thinking up the storyline. On the
outside he looks like a normal person, but underneath unleashes android-like attacks, such as
stretching out his arm to slice through incoming enemies, and turning his arm into a gun.
I am going with the character design originally thought up during the initial idea. The sprites are
around 80x80 pixels, which are a little larger than classic 16-bit sprites, but I didn’t want to lose any
detail in the character.
When thinking of how the Nerd should move, I wanted to convey that he is feeling angry and
aggressive. When standing still, he is shaking his arms and when running, he moves in confident
strides. When shooting, his teeth should be gritted and look even angrier, like he really wants his
target to be destroyed.
Figure 2 - Running animation sprite sheet
This is the Nerds running animation. As this is the main character, I wanted a smooth animation
which meant 8 frames. It had to be adjusted many times during animation, due to small details such
as the belt buckle and areas of shading looking strange.
Figure 3 - Shooting animation sprite sheet
This is the Nerds shooting animation. This time there are only 4 frames, because shooting a gun
should not take as long as going through an entire walk cycle. The way he shoots and loops again
and again works well however, as my game will contain a “hold down the button to shoot a stream
of bullets” method of shooting.
Jordan Finley – 2D Game Engines
Figure 4 - Initial weapon's bullet, the "USBullet"
This is the ammunition of his initial weapon. It is called the USBullet because it comes from his arm
cannon, which is styled off a USB flash drive. It is a relatively weak bullet, but is faster than other
planned weapons.
With these initial sprite animations created, I shall now try and put them into a small test room to
create a working character that can be easily controlled.
13/02/2011 - Coding in Game Maker
Today I have started making the basic motion of the Nerd within the game. Using the information
from the lesson was extremely helpful in starting with, and within less than 30 minutes I had already
made a character that could run left and right, and jump. Extra code had to be added to account for
turning the character to face left or right when he ran or jumped:
The “dir” variable is heavily used throughout the object code to
show when the different animations should be used. Left is
represented by dir 0 and Right is represented with dir 1.
Next up was making the character fire. I did not want to go for the
traditional shooting straight left or right, used in games such as
Megaman because they feel too limiting. Instead I am opting for
bullets being aimed at wherever the mouse is on the screen. With
the directions being controlled by the A and D keys, and jumping
being controlled by the Spacebar, I believe the right hand is left
comfortably free for aiming with the mouse. So far, this is the
hardest part of character control thus far, and took many hours of
looking through the object list and trying different things until it
worked (almost) how I liked.
Jordan Finley – 2D Game Engines
14/02/2011 – Making the character shoot
First, the most obvious way to start was to set which button should be used to fire. In this case, I
used the “Global left mouse button”. The way this works is the gun fires whenever the left mouse is
held. Then, I created the two variables to show what happens when the character is facing either
left or right. This results in the left shooting animation playing whenever he is standing to the left
and the right shooting animation whenever he is standing to the right.
Next up, and the most important part, is telling the game how to fire at wherever the mouse is on
the
screen.
This
required
a
small
bit
of
code
within
the
object:
point_direction(self.x,self.y,mouse_x,mouse_y)
Next up is the issue of the rate of fire with this weapon. Normally it will fire a constant stream
almost like a laser beam, but that would be overpowered and possibly cause frame rate issues. Using
a variable called “canfire” (which lets the player be able to fire) and a timer that only allows “canfire”
to be true every 5 frames; this limits the fire rate slightly. I am still working on what the correct rate
of fire should be.
At this point, the player character can move, jump and shoot in any direction. Next I will develop the
first level in the game, and then try implementing enemies that attempt to attack the player.
Jordan Finley – 2D Game Engines
Jordan Finley – 2D Game Engines
17/02/2011 – Making the game look aesthetically better
To make the game look more professional and not just a generic Game Maker platformer game, I
found out that a unique icon can be added to the game, along with a “splash” screen when the game
is loading, replacing the default Game Maker icon and loading screen. This can be done via the
“Global game settings” option. For the time being, I have made a simple icon featuring the face of
the Nerd, and a splash screen with a bit of pixel art and a box showing the controls.
Later on, I want to have a stylised “Internet Wars” icon and a more simplistic loading screen,
reminiscent of Fallout 3 or Oblivion, featuring just the logo. There will be an option on the title
screen for showing controls, so it does not need to be shown on the loading screen at that point.
.Ico file:
Current loading screen:
Note: Later on, I hope to implement this bionic arm stretch into an attack. It will pierce multiple
enemies without stopping, just as if the Nerd was able to punch right through them. At the moment
I’m thinking this will be a reasonably easy feat to do and will only require the arm to not be
destroyed upon collision.
Jordan Finley – 2D Game Engines
18/02/2011 – Level Design
To begin with, I drew up a few basic layout sketches of the first stage. The stage is split up into three
areas: 1-1, 1-2 and 1-3. The first two areas are general platforming levels and the last area will be a
boss battle.
Facebook Stage, area 1-1
Facebook Stage, area 1-2
Jordan Finley – 2D Game Engines
18/02/2011 – Level 1: Facebook
The first level of the game is based on the Facebook websites. There will be obstacles relevant to the
website such as falling “Poke” blocks and enemies such as Facebook style robots. As this is the first
level, I didn’t want to add too many complex jumps or enemies and would rather just get the player
acclimatised with the controls. There is a relatively simple straightforward path (Although a side
path will reward the player with the “Landmine” weapon) so the level will be completed quite fast.
As of now, the layout of Facebook 1-1 is finished, with tiles similar to Facebooks colour. As the player
proceeds through the level, and especially in Facebook 1-2, the environment and enemies become a
lot darker, to represent the true evil that is lurking within.
To begin with, I will write an overview of the different features and mechanics seen through the
level. Each one will be covered in greater depth in subsequent pages:
-
Moving Blocks
Blocks based on the Facebook level will move up and down and try to crush the player. If the
player gets hit by the underside (or top) of the block, they will instantly die. As this is only
the first level, the blocks are reasonably slow and easy to avoid, although it is easy to
misjudge a block and get caught by it.
-
Enemy Traps
Taking a bad path through the level (sometimes the most obvious path) will result in falling
into the firing range of an enemy, resulting in death or heavy damage. This means the player
needs strategy and fast reflexes to get through the level without losing a life.
-
Food to restore health
Throughout the level I want to place some sort of health restoring item to make the level
easier after a difficult area. There should be two types, a common food that only restores a
little health and a rare food that restores a large chunk of health.
-
Various types of enemies
I want to have a range of enemies, each with different methods of attacking. Some ideas are
a simple patrolling enemy that fires at the player when it comes in range, a flying enemy that
drops projectiles on the enemy, a static enemy that acts a trap to be avoided, and spikes
that damage the player when stepped on.
Facebook 1-3 is a single large room containing a boss encounter, which will be a robotic stylised
version of Mark Zuckerberg, the creator of Facebook. As the Nerd is crusading to destroy all of the
popular new websites, this guy is a prime target.
Jordan Finley – 2D Game Engines
Finished design of Stage 1-1
Figure 5 - Finished design of Stage 1-1 complete with enemy, spawn and health restoring locations
This first level is relatively short, but after extensive play testing it is certainly not easy, which is
exactly what I was going for. After letting a few friends from the course play, I noticed that they
would fall victim to the various traps and enemy tactics, and would lose a life or two, but eventually
make
it
to
the
end
of
the
level.
I am happy with the balance of the level although the fire rate may need to be toned down. The way
the enemies fire is based on a dice roll of 1/50 every frame, which can sometimes be unfair if the
dice roll creates multiple projectiles. To solve this, I may create a different method of when the
enemies should fire, which involves constant fire, but with an alarm that limits the enemy to fire
only every few seconds. This would be a much fairer and easier mechanic for the player to handle.
The problem with this is that at this time I do not know how to do it, but once the second level and
boss have been created, I may have the knowledge of how it works.
Jordan Finley – 2D Game Engines
This is the room being created in Game Maker. The total room size of 1-1 ended up being 1500 x
1050. This does not mean the size of the game window will be 1500 x 1050 however, as there is a
way to zoom in at a specific size, called “view”. Using view, a number of different options are
presented that has been very useful. The use of views can let the player stay in the centre of the
screen without wandering off-screen, and set the resolution of the game during play.
This is the current look of the game when being played. The view is zoomed up to 640x480, with the
camera following the player at 320x240, meaning the player is always in the centre of the screen.
The background is made up of different aspects of the Facebook website. At this point, no enemies
or obstacles have been added. A working health bar is the latest update to the game (see next page)
Jordan Finley – 2D Game Engines
20/02/2011 – The Health Bar
Today I made the Health and Life interface pieces and added the code so they should work.
I found there are multiple ways to do this, with the same results. Either by adding the “Game Start”
event and setting the lives and health via objects there, or by adding a couple of small lines of code
into the Create event:
global.hp = 20 (sets the HP of the player to 20 once the game starts)
global.life = 3 (sets the number of lives of the player to 3 once the game starts)
For now I have global.hp defined in code, and the number of
lives defined via the Game Start event.
Now that the code was implemented, I needed a health bar to
show the player how much health they have. As the game
seems so be loosely based off a Megaman game, I drawn up a
similar health bar to the classic NES/SNES games. Next to the
health bar are the lives, represented by a small head sprite of
the Nerd. He will eventually go through the levels and pick up
these small head sprites to gain another life.
To be shown on the actual game screen during play, a new object had to be made; a couple of new
objects had to be made: obj_hp and obj_life. Each of these objects has a Draw event with the
respective “Draw the lives/health as an image” action defined. This is where the health and lives are
shown on the screen. What I wanted was for the lives and health to be in the upper right corner,
similar to other platformers. As the game is constantly scrolling around the level wherever the
character moves, I need the bars to stay in one place in the view I have defined. To stay inside the
view, a bit of code is required to be added to the x and y coordinates: view_xview and view_yview,
with the coordinates of where you want the bars to be. In the case of the life icons, it is +55, +25.
Once again, there is code that performs a similar task. Also going in the Draw event of its respective
object, it goes: draw_sprite(spr_health,global.hp,view_xview+25,view_yview+85). What happens
here is that it draws the sprite based on the current hp (defined by global.hp) and then shows it on
the screen in the location that is entered, in this case x25, y85. The code also uses the “xview” and
“yview” to ensure they are stuck at a constant place on the screen and follows the player when he
moves around. This is what the health and life bars look like while playing:
Jordan Finley – 2D Game Engines
21/02/2011 – The Health Bars do not work
While the health bars display properly, they do not work when faced with damage.
Initially, when collided with my test enemy (obj_spikes, a
small spike object placed on the floor) the health bar would
not change, nor did any notable HP lower. I later realised that
it was because I defined the collision to lower the “health”
variable, and not the “global.hp” variable I had assigned to
the players health bar.
At this point I was reasonably confident that HP would work
now, but there still seems to be many issues. Now the players
HP will lower, but once it reaches 0 the health bar will scroll
through its frames, and the player will not die.
My initial conclusion is that this is an issue with the controller object for the player’s lives (obj_life).
What should happen is that once the player runs out of health, a life is removed and the player is
sent to the start of the level. What happens now is the player stays where he is, and all lives are
removed. This is where the health bar scrolls through its frames and at this point the player is
invincible.
Another issue I would like to sort out is the fixed amount of damage the player suffers when
standing on a spike. What I want is for the player’s health to slowly decrease, perhaps 1 per second
(out of the 20 maximum). I believe this can be done with an alarm and timer but I am not sure yet.
22/02/11 – The Health Bar and lives work again
After hours of changing variables and adding/removing objects and code, the Health and Lives work
as intended.
The issue was indeed the “obj_life” control object. Previously
upon collision with the spikes long enough for the player to die,
the player would lose a life, and then subsequently the rest of
their lives. This was due to health not being restored upon death,
and therefore started an infinite loop of not having enough
health and dying. This was solved by simply changing the variable
of global.hp to 20 upon going lower than 0 HP.
The only issue with lives now, is what to do when the player runs
out of lives and also runs out of health. I haven’t decided if they
should be sent back to the first stage (Each “world” has 3 stages
- first, second and boss stage) or just send the player back to the stage select screen (not
implemented yet)
Also there is an issue with the “Jump to start position” move. Apparently it sends the player back to
where they started the level, but it doesn’t do anything. Keeping with the theme of objects that
damage the player, next I am going to try and make moving blocks that fall and damage the player.
Jordan Finley – 2D Game Engines
22/02/11 – Enemies
First off, the design of the enemies of the Facebook level will be mostly robotic. That is because
there are not any characters or fads to base enemies off, so the Nerd will be trying to fight against
the website itself. To make up for it, the enemies have Facebook themed colours. So far, 3 enemies
have been made to be turned into objects:
Drone: This robot moves left and right over platforms and fires “Like” bullets towards the
player (normal fire, 1hp damage)
Sentry Drone: This enemy stands still and fires a constant stream of enemies towards the player.
Mostly to act as something to avoid rather than destroy (The rate of fire is so high that the player
would not manage to fire more than a few bullets before being killed)
Sentry Robot: Replacing the Sentry Drone sprite. (Extremely fast fire, 1hp damage)
Helicopter Robot: This robot flies left and right across large rooms and drops slow moving bombs at
and around the player, causing large damage if it hits (slow fire, 5hp damage)
Another damage causing object is the Facebook icon block. Acting as a similar object to the
“Thwomps” in Super Mario, if a player is caught underneath one then they will die instantly.
The blocks move slowly as to not be too hard for this initial level.
The final damage causing object is the previously seen Spikes. This object causes a couple of damage
to the player when stepped on. There is currently a problem with this object, as it only causes initial
damage when stepped on. What I wanted was for recurring damage to be dealt to the player if it is
stood on for an extended amount of time.
23/02/11 – Adding code to the Enemies
Replacing health bars as the hardest thing to implement. Even during the lesson covering this subject
I couldn’t get a grasp on it, but progress has now been made for every enemy. The drone was coded
in the lesson, and the first problem was creating a medium where it would stay on the platform
without either floating straight off it, or falling down onto the lower platform, while moving
left/right whenever it reaches a corner.
A solution was reached, which also works for the rest of the enemies in
the stage, but with slight tweaks (Such as removing the gravity of the
helicopter enemy so it floats wherever it is placed, and also removing all
direction speed from the sentry enemies so they stand still)
This resulted in a number of unique enemies with unique movement and
unique methods of attacking. For this first level, I would say it is almost
complete
now.
Jordan Finley – 2D Game Engines
24/02/11 – Adding the finishing touches to stage 1-1
Health Restoration
To give the level some more content, and to make it slightly easier, I will add health and life restoring
items. To keep with the Internet theme I will make the health restoring items look like cookies and
cheeseburgers (Giving *cookies* to people, and the “I Can Has Cheezburger?” meme)
They are placed in relatively out of the way parts of the level, and once the player touches the object
they restore a fixed number of health and disappear.
Cheeseburger – Fully restores health, only one per level. These are best placed after a
particularly difficult section.
Cookie - Commonly seen around the level. They also drop from killed enemies at a
reasonable high chance.
1up – Increases the player’s health by 1. Rarely found in the level and also planned to rarely
drop from enemies.
Sounds
There are sounds to accompany some of the actions while playing the game:
-
When the player first spawns in the level, a ding noise is played
-
When eating food, an eating sound is played
-
When obtaining a 1up, a ding is played
-
Bullets from the default weapon plays a constant energy bullet sound
Eventually I would like to add sounds for enemy and player deaths and maybe ambient noises for
some of the moving objects such as the Facebook blocks crashing down.
There is also background music for this level. It is called “L\assaut” and is from the Japanese show
Hokuto no Ken. I feel its fast; energy filled beat transfers well to this game.
Starting at the weekend I will start creating the second level of the Facebook stage, 1-2. This stage
will contain even more interesting mechanics and features now that the basic engine has been
sorted and I am more confident with the code.
Jordan Finley – 2D Game Engines
05/03/11 – Creating Stage 1-2
The Concept
When thinking of how stage 1-2 of my game should go, I wanted it to contain many new mechanics
to make the stage more entertaining that the straight passage of the previous stage.
The design for stage 1-2 has changed greatly since its conception in February. A lot of ideas have
come and gone and so far some new mechanics have already been implemented into the stage. I
feel that it is more or less complete, and has gone from the basic sketch shown on 18 th February to
the complete stage featured on the next page.
To begin with, an overview of the different features and mechanics that I will cover in more depth
on the next few pages:
-
Breakable walls
There are solid walls stopping the player’s progress through the level, but unlike other walls they
can be destroyed by firing bullets or other weaponry at them. The player is also under pressure
from other obstacles during this time they have to destroy the walls, making the action more
exciting and intense.
-
Locked Barriers
There are barriers stopping progress in the stage too. The player must take a detour to another
path to find a key that unlocks the barrier. This is heavily defended by enemies to increase the
time spent in the stage rather than just rushing through the stage in 30 seconds.
-
New weapon to be obtained
Near the end of the level, at a particularly difficult area, there is a new weapon that can be
obtained by the player to help clear a path (and also to help defeat the boss in the next stage)
This weapon as of today has not been decided yet, but I am thinking of either have a bouncing
projectile that bounces against the floor and walls, similar to the fireball from the classic Mario
games, or a homing missile or wave beam similar to the unlockable weapons in the Metroid
series.
Once the player has unlocked the weapon, a variable will be set that allows the player to use the
weapon in subsequent stages. This new weapon will probably also be controlled via the mouse
and fired with the right mouse button instead of the left mouse button. As there will only be 3
stages total for this assignment, I feel that this is an adequate control method.
Some other planned ideas for this update are: health food dropping from killed enemies and new
enemies with new mechanics for attacking the player.
Jordan Finley – 2D Game Engines
05/03/2011 – Stage 2-1
Figure 6 - The final entire layout of stage 1-2
Jordan Finley – 2D Game Engines
06/03/2011 – Destructible Walls and Locked Barriers
My First idea when creating this level is that there should be areas of scenery that the player can
break down with their weapons. I personally always liked this feature in games such as Metroid and
Scott Pilgrim vs. The World where the player, when presented with an otherwise empty room with a
dead end, can just try and smash through the scenery to get to the next area. Of course this couldn’t
apply to the entire level, or the player could just fire down, smashing through the level until they
reach the exit. Rather, I have chosen select walls that the player can break through to reach the
objective:
Destructible Walls
I have created this wall to act as the destructible scenery for horizontal areas. Right now I
hope that it is obvious that the wall can be destroyed, and I have tried to show this by
making the sprite look slightly worn down. When finished, I want the wall to show
increasing degrees of damage when it takes more damage, until it eventually crumbles.
Coding this wall was simple; it is basically an enemy that doesn’t attack back. It has a health
variable, and takes damage from the players’ weaponry, but does not cause the player any
form of damage. These walls are usually protected by a number of enemies, making the
game more difficult to proceed as they would need to clear the area first before proceeding
with damaging the wall.
Locked Barriers + Keys
My next idea was to make areas that could not be destroyed even with weaponry. They are
essentially locked doors that the player cannot get past unless they find a key to open it, meaning
the player will have to explore the level and take different routed to reach the key and be able to
proceed.
This was considerably harder to code than the destructible walls, because it required a new variable,
“global.locked” and “var_key”.
The way it works is when the player begins the level; the players’ var_key variable is set to 0 and
when they pick up a key, that variable changes to var_key=1. This now means that when they touch
the locked barrier, the barrier disappears and the player can proceed. This also means that the
players’ var_key changes back to 0, in case there is another locked barrier and key later in the level.
Jordan Finley – 2D Game Engines
11/03/2011 – Latest version update and ideas for the future
-
All enemy fire rates have been lowered to make the game slightly easier
-
A new enemy has been added to stage 1-2: The Eye guy. The Eye guy is attached to the
ceiling via wires, and is immobile. It sometimes shoots out more enemies, called “Fly eyes”
that float towards the player in a homing missile fashion.
Unlike regular projectiles from enemies, these can be destroyed with the players’ bullets.
They move slowly, but if they reach the player then they can cause a large amount of
damage.
-
Music has been added to this second level. This time it is the instrumental track “Ai wo
Torimodose” also from the series Hokuto no Ken. I like using this type of music because it is
full of energy and power, which makes the game more exciting. I’m not sure if this kind of
music is even allowed, although it is relatively obscure and probably does not have the same
extreme copyright issues as mainstream music.
-
I have been trying to make it so enemies can sometimes drop food when they die. Initially I
tried the method of having a 1/3 chance upon enemy death to create an instance of the
health restoring item, but that did not work, and for some reason caused an extreme frame
rate drop. I immediately removed this feature but will try to find an alternative method in
the future.
-
When the basic game has been finished (1-3 and the boss finished) I would like some small
aesthetic additions to be made such as death animations for the player and enemies so they
do not just “disappear” when killed.
-
The title of the game has changed to “Internet Wars: Timebomb to Eternal September”. This
is a reference to a similar happening back in 1994 where the influx of new Internet users
annoyed the experienced long-term users. More information and backstory can be found at
http://en.wikipedia.org/wiki/Eternal_September
and
http://encyclopediadramatica.com/Meow_wars
-
The next important update and the conclusion of stage 1-2 will be the new weapon unlock.
It will be a bouncing projectile that can bounce against walls, floors and ceilings for a short
while until it hits an enemy. I chose this sort of weapon because it helps clear out difficult
areas without having to jump into the fray and lose a lot of health.
Jordan Finley – 2D Game Engines
11/03/2011 – The unlockable weapon: Flamer
No internet discussion would be complete without some flames, and the Nerd has contained this
power for his own just cause. The Flame shoots out of his arm cannon and bounces along the floor,
and against ceilings and walls. This lets the player clear out difficult areas before taking the leap into
the warzone to finish the stragglers off.
It all begins when the player touches the Flamer “item” which appears early on in stage 1-2.
This icon represents the internet’s power of “flames” which is the word
for when someone is hostile to another person over the internet, usually
during an argument or calling someone out on what they posted online.
Each weapon is a representation of some aspect of the offensive actions
of the internet, and this is the first one the Nerd encounters.
Obtaining the item is simple enough; a collision event triggers the
variable that lets the player shoot fireballs using the right mouse button.
(This is covered in more detail soon)
To make the player feel a greater sense of achievement, a splash image appears on the screen
similar to when a new weapon is obtained in Megaman or Metroid:
Jordan Finley – 2D Game Engines
12/03/2011 – The code behind the weaponry
The way I wanted this weapon to work is for it to be shot out of the arm cannon like a regular bullet,
but instead bounces along the floor until it hits a wall or an enemy. For this to be achieved, I would
need to set gravity onto the bullet so it doesn’t fly away as soon as it hits the floor.
A gravity of 1 and a vspeed (vertical speed) of -9 gives the correct amount of bounce for it to hop
onto and across platforms.
Next, I had to work with how the bullet collides with obj_block, which is what the stage is made out
of. First I set the vertical speed to get the correct amount of gravity for the bullet to bounce across
the floor, and next I placed a collision check button to check if there is something in the way. I set
the direction to hspeed (horizontal speed) so the program knows when the bullet is moving at
normal speed, or has stopped (hit a wall). Finally, in the case that the bullet has hit a wall and
stopped, there is a destroy instance (self) to remove the bullet from the stage.
As with all bullets and projectiles, there are the two actions of destroying itself once it leaves the
room or the view.
Now that the bullet has been coded properly to work in game, I want the player to “unlock” the
weapon when he touches the “get flamer” icon. This appears near the beginning of stage 1-2. I
wanted it to appear earlier rather than later because I want the player to get some use out of it and
appreciate the increased firepower. While the flamer has a slower fire rate and is less accurate (it
can’t be aimed with the mouse and instead just bounces straight ahead) if it hits an enemy it is
almost certainly going to kill it in one hit. This is a satisfying change from raining bullets upon the
enemy, but in reality the slow fire rate of the flamer makes it only slightly better at killing than the
default weapon. The true advantage of this weapon is letting the flame bounce ahead onto
platforms containing enemies that would be difficult to handle normally.
To unlock the weapon, the player has to touch the Get Flamer icon. There is a lot of code to handle
the ability to get and retain this weapon, and was quite interesting to make.
The player starts the game with a variable, called has_fire. This is the variable that checks if the
player has picked up the flamer icon yet. When the player picks up the icon, this variable changes
from false to true, and the player can now use the right mouse button to shoot fireballs.
To add to the immersion, there is a short jingle to congratulate the player (right now its set to the
jingle of Super Metroid, but due to copyright issues that will probably change) and a splash screen
appears as seen on the previous page. This picture remains until the player clicks the mouse, where
the regular music resumes and the player can continue.
There were a couple of issues while making this bullet, such as the bullets sticking to the walls (I
forgot to tick a relative box) and an error whenever I pressed the right mouse key before I had
obtained the bullet (I forgot to set the has_fire to false in the player create event) but otherwise this
did not take too long to accomplish.
Jordan Finley – 2D Game Engines
12/03/2011 – The completion of stage 1-2
Now that the level and mechanics have been completed and implemented into the level, the stage is
mostly complete. To make the game start feeling like a game and less like a one off level, I have
connected the two levels together with a room transition. Fortunately Game Maker has a button to
make this easily possible with no extra code or buttons needed. I made 2 door sprites for this, when
placed together they make a complete looking door. The reason for this is below:
The way the room transition works is with a collision object. I could
have just made the transition happen as soon as the player touches
the door, but that would look unrealistic. Instead, what I done was
add the room transition code on the far side of the door (the one
with the darker shading) and once the player reaches the centre of
the door, thus touching the room transition side, the room goes
onto the next stage. I did this to make the whole “going into a
door” aspect seem more realistic, and it works well.
Now, the player can go through stage 1-1, right into stage 1-2 with a nice looking room transition,
titled “push from the left/right” in Game Maker. This scrolls the screen whichever way the door is
facing and makes the transition between rooms smooth.
Looking back on this stage, there were so many things that could not be implemented due to being
too difficult or not fitting in well with the level. Some ideas that never reached fruition were:
-
Floors that fall down beneath the player, threatening to make the player fall and die if he
stopped moving for too long
-
An enemy that charges at the player causing collision damage
-
A room similar to an area with a never ending flow of enemies until an objective is
completed (in this case avoiding the enemy attacks until you close the gate on them and
stop the flow of enemies from appearing)
The coding for the existing enemies and mechanics went smoothly, now that I have some knowledge
of what each button does and have a mindset of how to code something to do what I want it to do,
it was a lot easier than stage 1-1, despite taking more time. A lot of time went into placing each
individual tile onto the room, and it was only ¾ into the room creation that I discovered that by
holding shift and dragging would allow you to select more than one tile to place down. In retrospect
this would have saved over a week of time due to the repetitiveness making me lose motivation in
the whole thing.
Next, the final room to make before the assignment can start to be called complete: Stage 1-3 – The
boss encounter.
Jordan Finley – 2D Game Engines
12/03/11 – Sidetracking to create a title screen
One of the most important things in a game is the title screen; it guides the player to the actual
game and offers options and help such as changing controls, difficulty or sound. I would like to add
something similar to this albeit slightly more basic, just something that the player can navigate with
a nice picture before they start the game properly.
The menu screen will have 3 options which I believe can be done easy enough and will not require
any extensive code. By making the menu screens as “rooms” and the menu buttons as clickable
objects, which can replicate a menu similar to other games well.
To begin with, I created 2 basic menu screens, a Title and a Credits page. These pages contain the
Internet Wars logo, a concept art drawing of the Nostalgia Nerd, information and buttons leading
elsewhere. The menu buttons were created next, and are just words with a transparent background
so that blend into the menus well.
The code for each button was reasonably simple, and consisted of four events: Create, Left Pressed,
Mouse Enter, and Mouse Leave. In the Create event, I have placed 2 actions: an action to make some
background music play, and a change sprite event to spr_startgame which is the original sprite.
This is needed because of Mouse Enter and Mouse Leave. Mouse Enter is the event for when the
mouse hovers over the object. In the case of these menu buttons, they are exactly the same apart
from a small “>” icon to indicate it is being selected:
Figure 7 - When the mouse is not hovering over it
Figure 8 - When the mouse is hovering over it
The Start game icon leads to the first stages “scene” (will be covered later) which is a direct move
onto the next room. If I decide to make a “stage select” similar to the classic Megaman games, then
this will change, but at the moment with only 1 stage this is unnecessary.
The Credits game icon leads to a page with a little information just saying that I had made the game,
and about the course this game was made for. Finally, a Close Game button that closes the game.
Jordan Finley – 2D Game Engines
13/03/2011 – Screenshots of the completed Menu Screens
The Main title screen players see when starting up the game.
The credits screen. Players can go back to the main menu by pressing the “Back to Menu” button at
the top right of the screen.
Jordan Finley – 2D Game Engines
13/03/2011 – Getting carried away with rooms: Creating a scene before stage 1-1
As creating rooms linking to another room was so easy, I got the idea to link multiple rooms sort of
like images to create a scene. In the scene it will just show an introduction to the Facebook level, the
Nerd arriving and coming face to face with Mecha-Zuckerberg (the planned boss for this stage). They
share a few aggressive words and the stages start afterwards.
I really like this idea because it gives the game some soul and prevents it from just being an empty
platformer. The scene is shown below:
This is the title page for this scene. Background music starts playing and the screen fades to the next
one when the “Next” button is pressed.
Jordan Finley – 2D Game Engines
Jordan Finley – 2D Game Engines
Jordan Finley – 2D Game Engines
At this point, another screen transition happens leading to stage 1-1.
While this was easy to make, the main issue was working with all the different background music
from the title, credits and stages. Without adding control objects to stop the previous sound from
playing, they would all stack up and play at once, which is not good.
If I had more time to complete the assignment, I would have liked to hand-draw these images to add
more emotion and humour, but even a single character concept art takes many hours and there just
isn’t enough time anymore.
Jordan Finley – 2D Game Engines
13/03/2011 – Game over screen and issues with the Game over screen
Continuing with the theme of making rooms to add some atmosphere to the game, I made a game
over room when the player ran out of lives:
In the game over screen it is simply an image of the Nerd’s disembodied hand (complete with blood
and robotic joints because he is a cyborg) and also a button to send the player back to the main
menu.
The code that activates this game over screen is in the players obj_lives controller object. It dictates
that when the player goes below 9 lives, the game moves to this room.
This has caused a lot of unknown issues however. For one, pressing the “go back to title” button (not
pictured) sends the player back to the main menu although the health bar and stage theme still
remains. For now I have solved this by resetting the game whenever the player clicks “go back to
title”.
Now that that is sorted, the game should game over normally... But there are still issues. I have set
an action in the create event to stop all sound (to get rid of the stage theme) and to play a new,
game over related background music. This does not work, and for some reason the frame rate takes
a heavy hit. I am currently working on how to solve this.
20:09 Edit: By placing the delete_instance for the control objects obj_life and ob_health, the frame
rate lag is reduced. This is a viable solution as the game resets once the “go back to title” button is
pressed. The game over music still will not play however.
21:04 Edit: The sound_stop_all(); code doesn’t work properly it seems, and even stopped
subsequent music. As a solution, making two buttons to individually stop the stage theme works fine
instead.
Jordan Finley – 2D Game Engines
14/03/2011 – Concept of Stage 1-3
This is the concept drawing of stage 1-3. This is a short stage because the main focus point is to fight
the boss encounter.
When beginning the level, the player has to cross a bridge that falls down as he steps along it. For a
focused player, this is nothing more than a cool effect, but players first playing this stage may be
caught off guard and fall into oblivion. I have not yet thought of a method to create this effect so I
cannot go into more detail just yet.
Upon reaching the main area, a scene will ensue, started by an invisible collision object just nearby.
The stage music will change to a more energetic theme, and the boss will start attacking.
As detailed before, the boss in the Facebook stage is Mecha-Zuckerberg, based on Mark Zuckerberg
the creator of Facebook. He has traditional attacks such as shooting a mounted turret and charging
at the player for collision damage. The player will have to dodge these attacks by jumping onto the
adjacent floating platform and opening fire to cause damage.
I aim for the battle to take at least 30 seconds, so unless some kind of artificial time extending
mechanic is implemented, the boss will probably just have a lot of HP. 10000 seems like a reasonable
start considering the 10 damage of the bullets and a fast firing rate.
The look of the stage will be the same as stage 1-2, using the same tile set.
Jordan Finley – 2D Game Engines
17/03/2011 – Finished product of Stage 1-3
The 3rd and final stage of the Facebook level has been completed. This stage contains some
interesting and complex mechanics despite being the smallest level.
When thinking of this level, I wanted to focus on the battle with Mecha Zuckerberg. Therefore, the
main room is made to battle the boss. To cut off the room once the battle begins, I have added a
floor that falls from underneath the player which would cause the player to fall into a spike pit if
they are too slow. This not only looks cool, but stops the player from running too far away from the
boss during battle.
The boss is of course the most interesting aspect of this stage. Zuckerberg has a number of
mechanics to make the battle interesting and maybe even difficult. He moves away from bullets
being fired, fires a steady stream of bullets rather than randomly like previous enemies, and moves
towards the player in whatever direction the player is.
A number of new aesthetic additions have been added to this encounter as well, including a death
animation for when the player defeats the boss (he explodes when going below 1 health) and drops
a key when defeated, which is needed to progress through the final gate and onto completion of the
level.
All of these features will be covered in-depth on the next few pages.
Once the player has obtained the key, they have to jump onto the locked platform and proceed
to the exit. This is where one of the problems arose with this stage. I initially made a vertical
locked platform, but for some reason it would not unlock when the player collided with it
horizontally. Strangely, if the player stood on top of the barrier, it would unlock. I assume this is
a problem with some kind of horizontal code which is correct only with vertical collisions.
Instead of wasting time finding a solution, I simply made another vertical drop barrier.
When the player has gone through the door, a victory screen displays. This contains a “Return to
title” button because this concludes the content for this game. Of course this button returns the
player to the title screen, where they can replay or close the game.
Jordan Finley – 2D Game Engines
24/03/2011 – The falling blocks and their problems
Before the player fights the boss, they have to cross a platform made of blocks that fall after the
player runs over them. Whilst simple in concept, they have been troublesome to implement.
The blocks have been implemented with code rather than buttons for ease of use. It goes as follows:
In the create tab, I have set 3 variables: falltimer, falling and canfall. This tells the step event how
long the player has stayed on the blocks, and whether or not it is time to fall down.
The step event was set up as code for ease of use, but they are still pretty basic test variables:
This code tests a number of things: first it sets the gravity when the block is ready to fall. Next it tests
if the player is standing on the block, and if he is then the canfall variable changes to “true”. And
finally the variables that tell the blocks to fall (falling=true) when all the other things have been met.
These blocks have gone through multiple iterations so far:
-
The blocks fell down successfully. I set it so they are deleted when they leave the screen. The
problem with this is that the falling blocks stay deleted, even if the player dies and restarts
the level. As the player now cannot get past the chasm created by the falling blocks, the
game cannot be deleted.
-
Spikes where added under the falling blocks. While the blocks still fall off the screen into
oblivion, there is a floor of spikes to run across if the player dies during the boss battle.
-
An alarm was added in conjunction with a “jump to start” button, with the intent on them
respawning after a little while. Instead, the blocks come back and fall back down again
instantly, which repeats forever. I think this is because the variables are still set to true from
when the player ran across them the first time
-
I added a collision event with the spikes so they stay on the screen once they fall down. This
not only pretty much negated the purpose of the falling blocks, but for some reason I could
not run across them properly without jumping forward.
-
A new button was added to the collision event with the bosses bullet: If global.hp is less than
0, restart room. I didn’t know about the “restart room” button until today, which does the
job just fine. The only issue with this is that the music also restarts, whereas it doesn’t in
previous levels. But this is a minor flaw in some good progress.
Jordan Finley – 2D Game Engines
17/03/2011 – the boss of Facebook, Mecha Zuckerberg
Figure 9 - Sprite sheet of the run animation
This is the boss of the Facebook level.
I have since modified the sprite from the original design that can
be seen in the scene before the level that can be looked at earlier
in the document. I replaced the realistic pixellated face with a
sprite
character
to
keep
to
the
style.
I have to say this is the most complex object in the game,
containing not only lots of buttons but also lines of code where the buttons just aren’t enough. To
begin with, a number of variables need to be set to make the object perform a lot of the more
complex actions.
First, the traditional dir variable needs to be set. This is to ensure that the boss is facing the correct
way when the player first encounters it.
Next, there are a couple of variables to set the bosses HP. In this case, the variable zuckerHP has
been used to define the amount of health the boss starts with. Another variable, zuckerHPmax
defines the maximum health of the boss. This is mainly used for the bosses health bar.
The next two variables are for the more complex actions. The variable have_seen is for defining
when the player gets close enough to the boss, the boss springs into action and attacks. When the
player is far away, the boss remains still.
Finally, the variable can_attack is used with an alarm to give the boss constant fire rather than
random fire like the lesser enemies have. This adds more action to the battle as the player has to
constantly to avoid death. This can_attack variable is also used in the players object, albeit at a
slower speed.
The Step and End Step events contain the most complex and time consuming to create code in the
entire game, and I think it would be best if they had their own page to make it easier to understand.
Jordan Finley – 2D Game Engines
17/03/2011 – The Step Event of the Boss
The Step Event contains the most of code in any object in the game.
This is how it’s laid out:
First, the boss has the traditional checking if a space is empty and
setting the gravity so it can move normally on the solid blocks.
Next, code is added which lets the boss know when the player is
nearby. It works by checking the amount of distance between the
two objects and changing the “have_seen” variable to true when the
player comes into range.
Next is more traditional direction based code which most other
player/enemy objects have. It uses the dir variable to know when
the boss is facing left or right and changes the sprite accordingly.
Next is defining the health of the boss, and what happens when its
health goes below 1 (i.e. death). In this case, the boss creates an
instance of the key object (it “drops” the item) and then changes
instance to its dying animation, which is contained in
obj_zuckerdeath. Obj_zuckerdeath has a lot of the same code as this
object so it acts normally in game.
Next is more code that works with the above code. If have_seen is
true, and the can_attack variable is also true, the boss fires a bullet
at the x,y co-ordinates of the player.
The End Step Event
The End Step event adds a bit more direction to the variables
defined in the Step event.
This event shows when the boss has to move when confronted with
the enemy, first activated when the player comes into range of the
boss (triggering have_seen and making it true) There is a move
towards action to wherever the player is located.
The next action defines what direction the boss moves when moving
towards the player, which is defined when the x coordinate of the
player is larger than the x coordinate of the boss, making him
change to the right. Else (meaning that the players x coordinate is
smaller than the bosses x coordinate) he faces the other direction.
Jordan Finley – 2D Game Engines
17/03/2011 – Continuing with the Bosses code
Every enemy needs a collision event with obj_block, and this boss is no different. The code is just the
same as the player and other enemy’s code and does not need to be elaborated on.
Next is the boss’s collision with the player’s primary fire, the obj_usbullet. The boss has 100 healths,
and for this battle the player’s bullet only does 1 damage. This means the player has to hit the player
100 times, but the player’s rate of fire is so high that this only takes a minute or so. Even so, the
player must keep focusing both on aiming at the boss and also dodging the projectiles launched by
the boss. This achieves the goal I planned on when first designing this game.
The boss also takes damage from the player’s current secondary fire, the Flamer. This takes off 5
damage but is unreasonable to be spammed due to its slow fire rate. The player is at the mercy of
the bosses slightly faster fire rate if they decide to try and kill the boss with this weapon. One benefit
of using this weapon however that is it knocks the boss back much more effectively than the regular
bullet. This could be used as a strategy if the player becomes confident during the battle.
Finally, I have added a Draw event into the boss objects code which creates a small health bar above
the bosses head. Rather than making an elaborate health bar that sits on the side of the screen
much like the players (as they do in classic Megaman games) I feel a small health bar will be much
easier to implement. This draw command is entirely defined in code. First I need to draw the sprite
so it does not disappear in place of the health bar. This is done with the code:
draw_sprite(sprite_index, image_index, x, y);
Next I need to draw the health bar above the bosses head. This is done via coordinates based on the
size of the object, the health and max health variables, and the colours of the health bar.
draw_healthbar(x - 15,y - 35,x + 15,y
100,c_black,c_red,c_red,image_angle,true,true)
-
40,(zuckerHP
/
zuckerHPmax)
*
This concludes the boss’s code. With this the boss performs actions and drops the key needed for
the player to progress. Finally, the player walks through the final gate and is sent forward a room,
and presented by a victory screen where they can go back to the title.
Jordan Finley – 2D Game Engines
18/03/2011 – In retrospect
The first level can now be called complete, there are no more major features that I really want to
add, or even have time to add. If I was to continue with designing the game, I would implement:
-
More levels: That is an obvious statement really, but I think the most important part is
developing the new levels and the storyline for them. Right now the “Timebomb to Eternal
September” tagline doesn’t even really make sense with just the Facebook level. Maybe
during the summer I will continue with this game as I have really enjoyed making it.
-
More mechanics: Following on from the extra levels, more stages mean nothing if they don’t
have interesting features and events to make the game fun. This isn’t really an issue for the
current Facebook level because not much more could have been fitted in.
A planned mechanic/level I had thought up for the next stage, which is a one off storylineadvancing stage where the Nerd is surfing the computer highway on a moving train to reach
the next website. The main antagonist appears and puts a bomb on the train, with it
threatening to blow up if the Nerd does not deactivate it in time. This level would have a
timer event and I had already created a working instance of this when practising how Game
Maker works so it wouldn’t be a difficulty. I would also have added a parallax scrolling
background to give the level some depth and make it feel like the train was really moving.
-
A more elaborate boss battle at the end of the Facebook level: While
Mecha-Zuckerberg contained enough good mechanics for the
assignment, I feel like it could have been expanded on a bit more to
make the encounter longer and more “epic”. What I had planned is for
the boss to have different phases. The one included in the game right now is the definitive
first phase where he just shoots bullets and moves left and right towards the player. What I
wanted next is for him to change instance into a helicopter and fly up to the top of the
screen and drop bombs onto the player. Changing instance for this complicated object
caused a lot of issues however and had to be dropped. I had already created a few frames
for this phase, however. Finally, once that phase was defeated he would drop back down
into an elaborate tank with treads. It would dash left and right and cause collision damage
and sometimes fire homing missiles out of the turret. It would be kind of like a refresher
course containing mechanics of all the enemies encountered previously. A person who
dashed through the levels and didn’t figure out enemy attack patterns would never be able
to beat the boss.
-
A Stage select screen: Once the player has completed a level, they would not go back to the
title screen as shown in this “demo” but rather a Megaman-esque stage select screen where
they can choose the location of the website they want to assimilate. Once a level is
completed it is greyed out, but the player could still revisit the level in case they missed out
on an unlockable weapon.
Jordan Finley – 2D Game Engines
24/03/2011 – The Finishing Touches
Added a controls screen to the title page. It is an interactive room that shows the basic controls to
the left, with a small area to the right where the player can control the Nerd. No unlockable
weapons can be tried in this controls room.
And finally I added a new loading screen. The old loading screen also contained the basic controls,
but because the game now has its own controls page, that became irrelevant. It is now replaced a
smaller loading screen. Strangely, the final thing created for the game is the first thing people will
see when they play the game:
Jordan Finley – 2D Game Engines
18/03/2011 – A little help from my friends
While a lot of good things where taught in lessons, there were a good amount of events and actions
that needed to be learnt elsewhere. To learn how to code from scratch in only a couple of months
required
a
lot
of
visits
to
http://gmc.yoyogames.com/index.php?s=5ba0ce0de18f595f587bbc6036abc2a8&showforum=2,
which is the novice/intermediate section of the official yoyogames Game Maker forum.
As a kind of reference page, here is a list of most of the tutorials that I have learnt from these last
couple of months:
http://www.youtube.com/watch?v=K-DY7oiOMfg&feature=channel_video_title
This video tutorial covers the falling blocks seen in stage 1-3. While the video supplies code in the
description, it had to be modified quite a bit to fit the speed of my own game.
http://www.youtube.com/watch?v=qj6L8Vj83GU&feature=related
Another video tutorial from the same video maker, this one shows how to make moving platforms.
While I didn’t use moving platforms that the player could stand on in this game, I used the
knowledge as guidelines to create the crusher blocks seen in stages 1-1 and 1-2.
http://forums.yoyogames.com/forums/10/topics/57257
This topic has a person asking how to create “sparks” when a bullet hits an enemy. The answers to
his question provided enough information to add my own particle effects to enemies being hit.
http://learnbyluke.com/tutorials.php
The most important one of all, this website contains an entire page of tutorials to help beginners
create what they want. While it covers the most basic things like movement and jumping, I had
already learned these things in lesson but what was helpful was how to add lives and show them on
screen. Other tutorials I followed here were the cursor aiming and super Mario style fireball
tutorials; I couldn’t have created the Nerds ability to attack without those.
http://www.youtube.com/watch?v=w5gvDlLqOHQ&feature=related
While not really a tutorial, this short video did show a visual on how title screens where made and in
turn gave me the knowledge on how to add lots of rooms and transitions, which turned out to be a
large part of the game.
http://forums.yoyogames.com/forums/10/topics/42748
This seems to be a definitive guide on how to make and display health bars. I followed this closely
but created the graphics myself instead of using their example design.
http://www.mediafire.com/?mjlmzw24gkn
There was a in-depth tutorial on the enemy AI featured on the boss in stage 1-3, but I have lost the
original forum link. It was written entirely in Game Maker code, but I adapted most of it to work with
buttons instead. They also included this .gmk file which is the only example I can give of this tutorial.