Lets get rolling…

Tuesday, April 16th, 2013

Game Summary:
The third assignment required the class recreate an old Sega game using the MIT Scratch developer toolkit. Admittedly, I’ve never been a fan of Sega games so it was a difficult task to come up with a game to make. Ultimately though, I decided on building the original Sonic game. This was because I wanted to focus more on the character mechanics this round, instead of gameplay and level mechanics like I did with the Nintendo game.

Sonic is, at first a seemingly simple platformer game. It isn’t really until you look at the range of animations and character interactions included that you can begin to see how complicated the game is. A single sprite sheet for the main character includes over thirty sprites, compiled this become the animations for jumping, running, rolling, and walking. I decided I really wanted to replicate this, along with the signature fast paced running mechanic.

So with all the elements I needed decided on, I started constructing a scene, pulling elements from the game to build a basic level that includes the mechanics I need. This comprised of a sloped game world, and the classic “loop” block. While I intended to include the tunnels, time constraints proved difficult.

Environment
A staple of platformer games, is naturally the scrolling worlds. This was easy to achieve through a method called “Parallax Scrolling”, though the limitations of Scratch meant that I would have to get a little creative this time. Scratch doesn’t allow sprites to extend beyond the dimensions of the stage fully. If I wanted to have a long level, I would have to splice my world up into segments, and using code, move them independently of each other. Instead of moving the character along the “x” axis, I simply move the world around him. Then, I offset all the stages depending on their load order. For example, the first chunk would have no offset, the second would be offset by 400pixels (the length of the stage), the third twice the amount and so on.

Navigation
A relatively unseen element of its age, are sloped environments. This proved to be an interesting challenge as I would have to allow for the player to move around hills and such without breaking the game. This was done, however not as well as I would like, via a simple collision detection system. If the player was touching the ground, push him up until he isn’t. If he isn’t touching the ground, push him down until he is. The allows the player to stay exactly in between the ground and “air”. However it causes a lot of jumping, which is something I couldn’t fix. The next biggest challenge was momentum. This was an exciting challenge for me to tackle, and required a lot of unexplored concepts. In the game, sonic can build up speed, allowing him to navigate the world. At the core of the mechanic, I have an acceleration variable, which builds up when the movement keys are pressed, but declines when they’re released. Then I have, in the animations function, trigger points for the different animations. When a certain speed is reached, an animation trigger is broadcast telling the sprites to update to one of the four implemented animations. Idle, Walking, Running, and Rolling. This allowed me to easily change the animations depending on user interactions with little demand.

Loop
This was the hardest part of the game demo, and sadly still requires a bit of polish. To recreate the games “loop”, I looked towards a few methods. I decided on using the mathematical model for orbiting. When the player hits a trigger point, it will create a centerpoint around the loop, which the player will orbit. When the system has detected that its done a full circuit, or the players acceleration has declined, it will reverse or terminate the orbit. This creates the loop effect. It took a lot of work to implement and sadly requires a lot more polish, but given the time constraints I was very happy with the outcome.

Reflective statement:
While I accomplished much of the original games mechanics in the conception build, I found I was severely limited by the Scratch Engine yet again. I was disappointed with what I couldn’t accomplish, but very happy with what I was able to do with the time constraints. The coding process was streamlined due to more experience with the product and I enjoyed myself immensely this time with the project. I originally intended for much more, such as tunnels, like I said earlier but it would be too complicated to create.

Filed in Uncategorized | | Permalink | Comments (0)

Scratch: Nintendo Pokemon

Monday, April 8th, 2013

Scratch: Nintendo Pokemon

Game Summary:
The second assignment required the class recreate an old Nintendo game using the MIT Scratch developer. After digging up my old GameBoy and playing with some of my old school favourites, I decided that it would both be challenging and interesting to recreate my first true game – Pokemon: Blue.

Pokemon Blue is an incredibly complicated game with many layers and elements to it that all need to run cohesively and smoothly. At the root of it is the navigation – the player explores the world of Pokemon through a range of environments such as building interiors, towns, plains, and caves to name a few. The world in turn is to a degree interactive with barriers that pokemon providing the player with limitations and challenges. Populating the world is a range of NPC’s that add more depth to the game. They can be friends, foes, or general characters that give helpful advice and battle the player. If I wanted to recreate the game, I’d naturally have to have all types of NPC’s present. The other key element, are of course the battles. It was crucial to have this recreated. I wanted to recreate the feeling the players had when walking through long grass and other environments, and I wanted them to be afraid of NPC battles too.

So with all the elements I needed decided on, I started playing the game to find a stage that recreates this. As expected, the best example of all elements resided in the first 10min time frame – the introduction. Here Nintendo cleverly introduced the gameplay elements to the player in a simple, unobtrusive manner. The player is introduced to NPC’s, warned of the danger of long grass, given their new pokemon, and finally – introduced to their first battle and ultimately the world of Pokemon. I set out to recreate the first two towns, joined by a simple route.

Environment
The world is recreated using three core elements. The environment, which is the graphical representation of the world. The boundaries, which represent the barriers and other elements the player can’t walk through. Then, the triggers, which represent doorways, broadcast message, and trigger battles. Of these three mechanics, the triggers are the most complicated. When the player hits a box, a function is run to determine the X and Y position of the hittest. If the player has touched a box that’s in the upper left corner of the current stage, it will determine that they’re touching a doorway and then trigger the appropriate response. Using this method, I was able to have one sprite while separating its operations into different functions.

Navigation
An interesting problem I encountered in recreating the player navigation was that the character moved in “increments”, initially I found this to be mundane but after early tests I realised it was crucial in recreating the player movement and environment interactions. So I devised a method in which the player position would be logged as the key is pressed, then the character would glide in positions of 8px per second. If the system detected the player was colliding with an NPC, or boundary it would then revert back to the previous position.
When walking through long grass, for each repeat of the key press, a random dice roll of 1 to 11 would execute, if a value of 1 is returned it would then trigger a battle with a pokemon hiding in the grass, locking player movement until the battle is over.

Battles
For the battle system, a complicated system was devised. While in previous experiments I attempted to have three Pokemon, I decided it was too difficult to accomplish in the allotted time. When a battle is broadcasted, a new background is given, and an enemy pokemon is randomly generated and a dice is rolled to determine who goes first. When its the players turn, four buttons are displayed that when click, broadcast the appropriate attack. When the attack is broadcasted, it determines which pokemon to generate the sprite over, and animates before dealing damage. Once the attacks executed, it broadcasts a message to the the blurb and health indicators telling them to update the user. This is then repeated for both sides until a pokemon’s health reaches below 0.

Reflective statement:
While I accomplished much of the original games mechanics in the conception build, I found I was severely limited by the Scratch Engine yet again. I was disappointed that I couldn’t control the PEN tools layer, something required for the health system to work as intended. Other issues was that I would have to constantly create redundant code to have the same actions initiate for different objects. The actual development period was better managed I think however. The coding process was streamlined due to more experience with the product and I enjoyed myself immensely this time with the project. I originally intended for much more, such as NPC battles, and more complex battle animations. However due to time constraints I had to cut them off, lest I risked implementing a half baked feature into the game.

Filed in Uncategorized | | Permalink | Comments (0)

The pitfalls of Pitfall

Tuesday, April 2nd, 2013

As an introductory course to Game Design programming, I was tasked with recreating an original Atari Game with MIT’s Scratch program. While I found the game itself easy to replicate, the engine itself was incredibly lackluster. Proving to be difficult in allowing me to accomplish what I wanted.

Game

For my game I decided to recreate Pitfall (Atari 2600) as I found it included many complicated elements that could be replicated easily in Scratch. To summarize, Pitfall is a 2D side-scrolling where you must navigate a complicated jungle comprised of numerous traps (rolling logs, crocodiles, quicksand to name a few) all within a 20 minute time limit. The player (called Pitfall Harry) is an “Indiana Jones” type character that’s trying to recover treasures. His abilities are purely athletic, and he has no weapons or ways for inflicting damage. Through the jump command he is able to avoid rolling logs, and cling onto swinging vines.

Environment

The environment is controlled mainly by a variable (stage = 1), using a global variable I was able to achieve a simple item spawning system. When the character hits the edges of either screen it adds or subtracts from the variable, changing the background, and items to match.

Movement

Movement is the most complicated aspect of the game’s core mechanics as it includes hit detection as well as sprites. The player can use the Space, Left, and Right keys to respectively control the characters movement on a small platform hidden over the background piece. This acts as a buffer between the dynamic environment and as a device to allow for a simple jump command. When the player presses the Space key, the character changes his Y position repeatedly until a limit is reached, or the key is released, before executing a similar code in reverse – until it hits the platform again.

Swinging

A core mechanic of Pitfall is the ability to swing across vines. This was a largely complicated feature that requires the game to move the character itself. To accomplish this, I created a “letterbox” cinematic. Firstly, upon itself the vine is swinging, changing a variable from direction 1, or 0 (1 being left, 0 being right). Upon the character hitting the vine, the controls are locked, and depending on the direction variable, the player is transported to one of two locations, on the other side of the vine and hidden until the animation is completed. The vine itself switches to the variable ‘occupied’ and changes its animation to that of one with the player clinging onto the vine.

Reflective statement:

While I accomplished much of the original games mechanics in the conception build, I found I was severely limited by the Scratch Engine. A core mechanic of the game is changing states featuring spawning items, which move, and traps. I found it difficult to create a system in which the player can move between stages and keep the multiple items associated attached only to that stage. This was ultimately accomplished – but only at the cut of the spawn system for logs. Ultimately it was deemed that the outcome didn’t reflect the need so it was dropped.

 
Scratch Project
 

Filed in Uncategorized | | Permalink | Comments (0)

Intelligent Design

Sunday, February 3rd, 2013

Artificial Intelligence is the backbone of videogames, without it you would have no challenge and no fun. It’s used to add more realism to the game by providing challenges to the player, therefore making the game fun. Artificial Intelligence uses many techniques to interact with the environment. I am extremely fascinated by A.I. and hope to pursue a future in this field of game development. Already I’ve learnt a lot about A.I. development, and aside from applying it into my game, I felt compelled to explain the issues and feats behind A.I. development.

The main technique is “If and Else” statements. Basically, this tells an A.I. what to do, for example, if I do this you do that. Even though this may seem pretty easy, it’s not because there are hundreds and thousands of ways to have an A.I. interact with its surroundings. This is where Behavior Tree’s come in. They cut down on the amount of “If and Else” statements and organize the A.I. behaviors. Think of it as a family tree but instead of people, you have reactions and actions. Behavior trees allow the A.I. to narrow down its choices and select the perfect reaction.

The above process only allows them to decide, the main method used for the A.I. to interact and interpret the environment is called the “Limited Knowledge Model” This tool allows the A.I. to see what’s going on around it. To stop the A.I. from knowing everything, designers used a method called the “internal model”. Using this, the A.I. has no knowledge to start with and can perceive the world in its own way. The only way it could find out is by seeing, hearing or by getting information transferred through another A.I. through communication. If an A.I. saw you and you hid behind a wall, the A.I. woukd know you’re there but he may not know if you moved or didn’t. This allows the A.I. to make mistakes, therefore making the game realistic, because not even humans are 100% correct all the time.

The purpose of A.I. is mainly to provide a challenge to the player through opposition. However, artificial intelligence is also used to give the player assistance and add more realism to the game. For example, in the game Fable 2, the player is given a dog. The designers were originally going to have the dog controlled by the player. However, they decided that it would be more “magical” for the dog to be an A.I. What’s great about this is the way the dog then interacts with the environment and player. Another step forward with game A.I. is the enemies in Far Cry 2. They’re so advanced that they can interact with the game in ways never before seen. For example, the game is based in Africa, so if it get’s hot, guards patrolling will seek shade and take longer breaks. Another example is how the enemies interact with each other. If a patrol is shot and another patrol sees his friend on the ground, he’ll run to him whilst seeking cover from gunfire and pick him and carry him to a safe zone. Despite these advancements, there are many issues that face artificial intelligence. I have to say that A.I. is the slowest developing product in game development. This is due to many things but the main issue that it faces is pathfinding. Each new game that comes out has more geometry, more advanced terrain, more obstacles and more A.I. interacting with each other.

A recent advancement by Epic Studios could fix this problem however. Called the “navmesh”, this coding method collects data on the games geometry and meshes creating a clear picture in the A.I.’s head of it’s surrounds allowing it to navigate a map with hardly any effort of the designer. Another setback is animations. Each movement or gesture an A.I. makes had to be made by an animator. This severely restricts the movement an A.I. can make and cause the A.I. to sometimes fail. As Damian Isla from Bungie Studios said “If I move my hand to pick up a pencil, I first move my hand back a little bit before moving it over the pencil and picking it up with my fingers, A.I. just can’t do it because we haven’t gotten to the stage where an A.I. can make it’s own animations”. There is however a program in its early stages called Euphoria that can do this. It allows an A.I. to make its own animations and move its body around like a real human would.

However, it’s still early on in development, and the two games it been used in so far has found numerous glitches. Other issues that face A.I. are actually due to programmers and not programs. People are deterred by the math involved as it requires lot’s of mathematical knowledge. Even though A.I. is traveling at a slow pace compared to other gaming disciplines it is still progressing at an enormous speed and one day we will have an A.I. that can pick up a pencil much like we would.

Filed in Uncategorized | | Permalink | Comments (0)

Nostalgia at its best.

Sunday, February 3rd, 2013

Released in the fall of 2007, Halo 3 was to date, the fifth best selling Xbox 360 game of all time, and the all time best selling game in the Halo franchise and Xbox exclusive titles.

While there were more than one million people playing Halo 3 on Xbox Live in the first twenty hours of its release, now after six years since release and three new franchise titles its almost impossible to find a game to play – that was until this weekend, February 1-3, 2013. Discontent with the Halo 4′s lackluster multiplayer experience, fans congregated to the Reddit website to form a re-population effort aptly dubbed “The Great Journey” – the goal: get as many people as possible on the Halo 3 servers to relive the golden era of Halo’s multiplayer goodness. While some found it boring or broken claiming Halo 4 to be a superior product with its fast paced, streamlined gameplay, others sided with the classic – citing it had aged far better than it should have. I am on the side of the later.

Gameplay:

The Halo series is well known for its combats “golden tripod” – Weapons, Grenades, Melee. The core elements create a highly skilled based competitive environment. While Halo 3 introduced another layer in the form of “equipment” (deployable lifts, EMPS, health regeneration and such) that could be found in the arenas, the gameplay remained roughly unchanged though – only rejuvenated with a refreshing element of chance. Halo 4 brought these back as perks (jetpack, promethean vision, thruster, etc) - equipment that you can purchase and have on you the whole time. For me, the perks  made countering far to unpredictable and unbalanced. While Halo 3 had the chance to find an collect equipment  Halo 4 forced players to select their perk outside of gameplay, making things far more unbalanced.

In another drastic change Halo 4 had the weapon placements changed. While previous Halo titles had a series of weapons (all ranging in power) strategically placed around the maps, Halo 4 had supplementary and power weapons called in via “drops” in an effort to streamline gameplay. Once a player had reached a certain amount of points an option to call in a weapon would be given. This completely changed the flow of gameplay. No longer were points on the map fought for so as to hold the weapon spawn points, in fact there was almost no strategy at all. Situations were less precise and forced into “who has the better weapon and better ability for this specific situation”. Making it much more difficult to counter an attack and far less entertaining.

Replaying Halo 3 reminded me how much more personal the game felt when fighting. From the start of the game, everyone was on equal footing – no special abilities or weapons. Picking up the special abilities like Bubble Shield and Regen Field felt good because you had earned that kind of ability by making your way to it without dying, instead of just starting with them automatically. Holding power weapons felt far more rewarding, as you had fought for the right to claim them. While ultimately the mechanics in Halo 4 are far better and refined, the core gameplay that was from Halo 3 is still superior.

Filed in Uncategorized | | Permalink | Comments (0)

So, our game is called “Halo”

Friday, January 18th, 2013

It was the year 1999, Apple’s Steve Jobs, about to introduce a brand new game hands of the stage to a nervous Jason Jones. After shaking his hand he turns to the audience and begins simply: “So, our game is called Halo”

No one really knew it at the time, but this new game would shape the gaming world for years to come. Running in real time, in OpenGL, on a Macintosh the demo while a technical feat wasn’t that interesting. The frame rates were horrible, the animation jarring and the idea – bland. No one expected it to amount to anything, it was just another sci-fi opera that would be forgotten in a matter of months. Eleven years later and Halo is a million dollar franchise with 7 titles and and spin-offs. It changed the world, but most importantly it changed me. Halo was my first true gaming experience, from the very beginning I was hooked. The universe it had created around me was intriguing, the music gorgeous, the gameplay amazing. Ever since that day my dream job has been to work at Bungie. To be there where the magic happens and help craft it into the best it could possibly be.

Bungie was the company that got me interested in gaming, I love them and their culture. It shifted my life onto a whole new track. While I had always been interested in making games as a child it was only out of boredom. The games I made and played were nothing more than an elaborate way to kill time. Within 10 minutes of playing, I was hooked on the story alone, within the next 50 I was completely absorbed in the universe. Not so long after that I was drawing up my own levels and creating my own side stories. I wanted to make games like Halo. I wanted to create magic, like Bungie creates masterpieces.

Ten years later, here I am; A game design major climbing through the ranks, getting closer and closer to my dream job.

Filed in Uncategorized | | Permalink | Comments (0)

This is my Blaghhhh!

Wednesday, October 17th, 2012

This is where I shout and scream at the world about everything thats happening in my life relevant to gaming. It’s completely up to the world to listen in or not. Anyways, despite being fed up of the wordpress system (bloatware much?), and the fact that ALL THE TEMPLATES PROVIDED, are the most hideous, revolting, unoriginal, and bland designs ever – I’ve started to write a blog, or blaghhh as I shall hence call it.

“Why are you writing a blog dearest, benevolent leader?”

Simply put; I have to. (Yes, yes, I know I don’t *have* to, but stressing the word “recommended” basically means “Do it or die) But it’s not like I’m against blogging, I just find WordPress to be the most frustrating spaghetti code ever, it’s bloated with the years or feature creep and lost it’s goal – it’s trying to be too much. Oh, also…I suck at blogging. I tried a few times but to no success – there’s always too much going on in my head to write it down without getting distra – OH LOOK, A KITTY…

Still reading? Goodness, points to you sir. Well then I better tell you about myself. I am a twenty year old developer / designer living in Hong Kong. I spent the first 13 years of my life living in the lush country side of Australia riding Kangaroo’s and camping with Steve Irwin….at least…I think I did? Now I live in Hong Kong, eating things with chopsticks and practicing Kung Fu on Pandas, no really I am. I spend my spare time making websites, playing videogames, and watching movies – I’m so thrilling right?

(Getting very distracted, time to wrap things up)
For the next few weeks (unless I forget) I’ll be writing and bitching about games and stuff. Probably posting pictures of otters too, maybe not.

Filed in Uncategorized | | Permalink | Comments (1)