Mark Calugay

ITGM 315

Text-based RPG

Game Summary

You are  warrior who just arrived in the Himalayas. Now defend it because there will be monsters coming from everywhere to attack the small village that you have come to know and love. You work for a certain number of hours to earn some gold. Afterwards maybe go do some shopping and acquire better gear and weapons. Train with some warriors and trainers to increase your combat and defense skills. After you have done that, you are ready to go to battle.

This text-based made up of a while loop. Initially it prompts the player to state his name and then choose between 1-4 the things that the player can do. You can work up to eight hours to earn some gold. Receiving 100 gold per hour. Going shopping lets you buy new sword and a new shield. This increments the variable swordLeve and sheidLevel by 1. Players can also train with a trainer, gaining 5 experience points every time they train. A maximum 100 experience points is needed to increase attack and defence. The last choice is go to battle. This choice makes the player leave the village and go attack incoming enemies. The game ends.

Reflective Statement:

Overall this was a good project. I looked to others for references and tried to change the story. Understanding the roles of while loops and switches really helped. I had failed a few times in doing some

Twisted Metal

http://www.youtube.com/watch?v=-zcytenauxc&feature=youtu.be

This is a Deathmatch type game but with cars. Achieving the level or smartness with the AI was difficult. Controlling them and asking them to fight between themselves and in a team was unattainable. I have created a small level with simple bots following a path that would then find the other team and start to shoot. The game is over when all the bots are defeated. Or when the other team is  defeated. Players don’t have any weapons, and can only destroy an opponent by means of vehicles.

Creating the level was done by terrain editor. I explored the terrain editor because I wanted something that the players could explore with mountains and rough rocks and dirt. I feel as if it would be more natural to explore a world with uneven grounds. I explore how to paint with the paint tool and understand alpha channels between layers to create the illusion of having different terrain on the same plane.

Programming the bots was easier than I thought. Making them follow a path was as easy as placing pathnodes all around the map and making them choose between destination or origin. I have finally achieved this by placing pathnodes in between so the bots would know where to go and have that illusion of AI going around and fighting with other AI. For team Deathmatch game modes, it would somewhat override my kismet programming and I took too long in trying to solve a simple problem that was never solved. Preprocessed programs and kismet programs where doing different things and were causing a lot of bugs.

Reflective Summary

This program deemed to be far more difficult than I have ever imagined. Even the week that I thought would be more than enough, wasn’t enough. I was glad to have bots being spawn where I wanted them to, set to a specific team, find a car then go and fight with another bot. It is fun playing and driving around, but right now it is just pointless to even play because the objectives are a little whack!!

Assignment: SEGA game of choice

Game Designer: Mark McAwesomness Calugay

Class: ITGM 315

Sonic Gameplay

Game summary:

 Level

This platformer consists of rings, jump pads and even enemy bots that you have to dodge. In Shadow’s universe, there were shooting bots that allowed for extra challenge. This along with collecting all the coins and being able to tally up the score was the main part. There is a small detail in creating a puzzle that requires the player to open the door by means of a trigger. This was achieved by placing camera’s indicating the location of the trigger. This was programmed using a tool called Kismet. A visual scripting tool, built into UDK.

Character

All characters are made up of pawns. A pawn is a static mesh with bones that can be controlled by either a human player or an AI.

Sonic was placed in replacement for Shadow as for time constraints, Sonic was more popular than shadow and finding a model mesh for shadow would have been very challenging. Sonic was rigged with bones already and had physics precoded when acquired.

Enemy character’s: used default enemy provided in UDK.

Gameplay

This game showcases the knowledge of UDK by means of applying physics on terrain and visual scripting of the coins being picked up. The door is opened by means of a trigger. Touching the jump pads require a bit of speed. You have to be running at a certain speed in order to reach the other side of the map. Players also have to aim right, just slight angle displacement will end up killing Sonic and the player

Reflection:

I enjoyed learning a new engine over the week. I learnt a lot through failure. Coding was a little different however. Unreal Script is a little different from C++, but it was good to learn it as well. My main challenges were getting the source files being in the same folder for any of the test maps or levels to work. Coding has to be compiled and all the classes have to match in order to do a successful compiling and launch of the game engine.

It was fairly simple learning how to navigate, the tools, simple steps, shortcuts and tools within the tools of a tool. Toolception. What I mean by this is learning to use Kismet and Matinee. Which are visual scripting tools within UDK itself. There were a few ways of telling pawns to perform a specific action. Scripting is common but Kismet and Matinee enhance that by being visual. Kismet is really just a dialogue of if statements that can be used.

I’m excited to use this again for the next project.

Game Title: Bboy-trix

Game Developers Name: Mark Calugay

Summary:

In my pursuit to recreate Asterix for the NES I was looking into the actual game itself. I got myself an emulator and played a few levels of the game. I enjoyed the music and the gameplay as I punched through a few boar’s, knights and porcupines.

My approach was simple. Create a sprite that would go left, right, jump and attack. I named this sprite Bboy, because in my version he breakdances to hit foes. The first thing that I looked at was the background and how my sprites would be interacting with it.

I achieved this by creating sprites that would correspond to the branch, hence if Bboy sprite is touching set bottom to 1. Bottom is a variable that I established that will be used for the jumping script. This is when up key is pressed gravity is set to 15 when bottom is 0, finish the jump script when bottom is 1.

Before I get too ahead of myself, let me just state all my variables. Gravity: This is obviously used for jumping. Bottom: as mentioned before this sets the sprites from recognizing where the ground is when being touched. By default it’s set to 0 so that anything that is floating around will fall down and reach the ground sprite and will automatically set this to 1. Coins: used for points and score Lives: to visually show players if they get damaged Score: shows how much is being earned during gameplay Time: decreases every second so to keep the player in track. If it reaches 0. Game is over Health: there is a maximum of 7 in the health bar. When this reaches 0, lives is subtracted with itself. When lives reaches 0, Game is over. Stage: Unlike Nintendo. I’m working with scratch. I don’t have the ability to follow the player with a camera. Instead. it’s a fixed camera. I created this variable to set the stage for the background. If stage is 1, background will switch to costume 1, and all the elements in stage 1 will show. If it changes to the next stage, background costume will change and all the elements from that stage will show and automatically hide elements from the previous stage.

*

There was a lot of if statements that I used to make sure that transitions between switching of costumes or changing of stages would go smoothly.

Reflection:

After exploring much on Scratch I have gained further appreciation for scripting sprites doing specific things, whether it’s making it play a sound while changing the x value going 90 degrees in direction to hiding when touched by another sprite. My biggest challenge was trying to make sure that everything from Stage 1 appeared when is should and disappeared when it shouldn’t. The transitions between stages really took the most thinking. Attacking, jumping and moving was easy enough to do because I had friends to turn to for information and I had the internet in my fingertips.

It was an enjoyable experience playing around with the variables and broadcasting specific messages. I really used broadcasting to my advantage because I was trying to look for a way for scripting for sprites to apply to another. When one sprite would broadcast a message and another would receive it, an interaction is done in between and the variable changes. For example. When the sprite touches the edge, it will broadcast Next Background. This I used for the Background, when it received that specific message it will change the variable stage and when it equals the number as the corresponding costume it would change to that costume. It was an ingenious way of going back and forth with stages.

By setting the stage, I also set the parameters for all the sprites within one stage. In stage one there would be a bad guy, some floating coins to collect and maybe some dangers, but in stage two, those disappears and is replaced with other sprites. I mostly struggled with getting the corresponding sprites to appear when they should, but when achieved, it was a great feeling.

Overall, this was another good experience in using Scratch. I would not use it for publishing of other games though. I’m limited to using blocks and where I want to type a line of code, I can’t. I do would like to explore more on Scratch, for creating kids games perhaps.

Author: Mark Claugay

Class: ITGM 315

Professor: Jose Rueda

Learn more about this project

Game Summary

The firs thing I did was create, the ball was the most program heavy element in the game. It was created with a lot of if statements that when true, elements such as playing a sound and changing directions would execute. First off, when space key is pressed and if the ball color is touching the background move 5 steps.

This enables the ball to move constantly until it touches another color. For example, when ball color touches block color, change direction and play sound. For the brick, when color of bring touches ball color, hide. In choosing a direction, I looked into the angles in which the direction of the ball could travel. I put in a ‘pick random’ operator and an arithmetic operator. When changing direction it would pick a degree in which it faces downwards mostly. I limited the choosing of direction to about 90 degrees.

What I mean by this is when the program chooses a direction it will choose less than or equal to 90 degrees in radius. In the example above, there is a maximum angle of 90 degrees in which the ball will bounce back, and this usually bounces back the opposite direction in which it touched. If color (ball) is touching color (block) point direction in [pick random] from 135 to 225. When touching the paddle, it does the same thing but in an upwards direction. When touching the sides it would go on a horizontal direction. The Blocks change the variable Score when get hit and hidden.

Now programming the paddle was a lot simpler than the ball. Basically, if left arrow key is pressed, move -10 steps and if right arrow key is pressed move 10 steps.

This is where I set the variable lives to change. And when the variable reaches 0 the game script stops and it displays the message “Game Over”

Reflective Statement

From the plethora of Atari 2600 games, I decided to re-create Breakout to the best of my abilities. While using scratch I figured out a few things. Such as making sure that the angle in which the direction will change has to make sense. For scratch, 0 degrees is up, 90 is right, -90 is left and 180 is down. As annoying as this was, it wasn’t that hard to convert the system to accommodate what I was working on.

Before I started working on the actual program, I played a few breakout games on the net and tried to figure out how people approached this. My findings come with the realization that the block were creating by the use of a matrix. This would have been very useful in scratch because I wouldn’t have has to create each block as a sprite but rather I could have generated a grid in equal spacing to each other and that would be the blocks that the ball would destroy. I also learned that the color order in which the if statement is declared true matters. When ball touch brick, in which case if color (of ball) touches color (of block), hide block and change ball direction. For the reason that arises, the color of the dynamic object has to go last in the order.

Overall this was a good project for me to explore. It gave me a chance to understand how C++ programming works on a visual medium and to practice what I already understand. Scratch was easy to learn but hard to get to know. It took sometime for me to find where some scripts where and how to apply them. When errors occurred, I simply had to go to an alternative.

Developer Rules

• Use Kinect to configure player
• The Kinect sensor will be utilized for input in various gameplay
• Speed of gesture affects the speed of the action (i.e. player swings hand faster hits the ball faster, etc.)
• Any movement done by the player is mirrored in the game
• Rallyball: A setup of blocks and targets in a stadium like atmosphere. Third-person view looking at the avatar. Smash as many blocks as possible within the time limit. There are 3 levels. First level is 5 layers of a 2×3 grid. Second level has 2 layers of 3×3 grid. Third level has 3 layers of 4×4 grid

Players Rules

• Rallyball: Smash all the blocks, serve with either hand, block the ball with your body, hit the ball hard to use Fire Ball, hit the rallyball for extra pins, and play side-by-side with a friend
• Each game has coins to collect, the more collected the higher the score. The higher the score, the better the grade (bronze, silver, gold)
• Smash as many blocks as possible before the Time runs about. If you have time left over you get bonus points.

Implicit Rules

• Only the movement of body allows the game to occur
• Every part of the body is usable to play the game
• Game is paused when the player leaves the space
• Each player has to make big gestures to move the character in a direction, to perform an action and to complete a task shown on screen.
• Positioning in a 45 degree angle brings up the menu that allows the player to select options, ‘leave game’ settings or ‘return to game’ settings
• Gesture one hand in front to indicate the cursor (the cursor activates as an action made by the player)
• Gesture to an action shown on screen to execute it