Saturday, March 31, 2012

Feedback and Polish

Game Design and Production - INFR 2330

So last class, we talked about the value of testing and feedback. I've always known that feedback and testing is a vital part of the creation or development of anything. Writing need to be reviewed and edited, shows need to be watched and improved upon, and games need to be tested and polished.

As such, testing is a big thing in the games industry as it actually allows developers to make sure their game is good and to improve on areas where it is weak. Large game companies test all the time. They have internal testers used to test preliminary builds, and then they may release it prior to release as a beta for the public to test. Finally, once the game is released they still have testing phases as the game is never truly "finished" now as patches can be made to the game through the Internet.

Mmm.. WoW Patch Days, when the servers lag for 3 days after release. (Kotaku)

As people know, I'm a pretty big Blizzard fanboy. One of the things that I feel Blizzard does pretty well is to monitor their games and make changes as necessary. They do this in pretty much all of the online games they create. They release the game for beta testing to iron out the bugs and to obtain feedback from the public, and then they constantly monitor the game and add content or fix issues.

Balance testing is one of the things I'm actually really interested in. I used to play World of Warcraft a lot, and then now I kind of moved onto StarCraft. Both of those games actually require a lot of balancing since both games have competitive environments. If the environments are unbalanced, then the game is no longer fun.

Balance. (Yahoo Memes)

For example, in the original World of Warcraft, there were many classes and combinations within classes that were useless. No one every had a DPS paladin in their group, they were always healers. No one ever had demonology warlocks, as they were garbage. Druids were almost always exclusively healers since all the other forms were meh.

But through expansions which completely changed the game, and through patches which edge the game in certain directions, eventually the classes were balanced out so they were all somewhat viable. Now, I haven't played in a long time, but when I still did it was normal to encounter ret paladins or demonology warlocks (Even I went demo at one point) or even cute Boomkins which wreck your face.

Ehhhh. Can't think of a comment.

For a game like StarCraft balance is even more essential since the game is played on a competitive level. If the game was imbalanced, it would quickly make the game not fun to watch and play competitively since a player who isless skilled could easily beat a player that is more skilled because their race is "imba". eSports would die if there was a huge imbalance between the races.

As such Blizzard constantly gathers data about the game and then analyzes it to figure out if anything needs to be changed. If the win rate between Protoss vs Zerg was 52:48, then that's actually pretty good. It's almost impossible to outright make it 50:50, so a small deviation like that is actually really good since there are so many other factors that come into play. However if the win rate was 60:40, then something is wrong and needs to be looked into.

Buff Zerg please. (SC2Statistics)

The feedback we accrue from testing also directly applies to us too. Last semester, we went and showed our GDW game to a bunch of people including Dr. Hogue. Everyone gave us feedback, and we all considered it and put a bunch of them in the game. Literally a week before our game's presentation, our game was completely different. But through feedback we were able to implement a lot of features and things into our game that made it feel a lot more polished and complete.

Yesterday we decided to do something similar by showing our game to Dr. Hogue and Dr. Nacke for feedback. Both of them gave us some pretty good feedback as to how we should improve our game. I was kind of scared at first since our game isn't at the point where I thought we should be at at this point in the semester, but they were both pretty gentle and said our game was fine.

We didn't show them the Spiderman version.

Naturally we still needed improvements though. Dr. Hogue told us things like to implement some more shader effects to make the game pop a bit more, and Dr. Nacke gave us a lot of general feedback about the feel and design of our game. We're planning on making as many changes as we feel we can and should based on the feedback we were given.

Last semester our game was made a lot better in the last 1 - 2 weeks through feedback and polish, here's hoping its the same this semester.

Monday, March 26, 2012

I Need to Get Into Shape.

The second part of Homework 7 of Game Design.

Game Design and Production - INFR 2330

For this assignment, I have based it on a true story that I experienced relatively recently. You play as an out of shape game development student who spends too much time indoors programming and no time exercising. I call this game “return exercise = false;”.

One Friday afternoon as you arrive at the bus stop ready to go home for the weekend, you realize that you have forgotten your bus ticket in your room at the school residence. Knowing that you have mere minutes before the bus arrives, you must embark on an epic journey as you run back to the residence to grab your ticket, and run back to the bus stop before the bus leaves and hope you get a good seat. 

Although you almost never get a seat to yourself anymore. (Go)
As I mentioned before, the theme of this game was based on an experience I had recently. Last week when I was going home for the weekend I forgot my bus ticket and had to run back to my room to get it, and run back. However since I am completely out of shape it was a very sad experience as after only a few minutes of running I was dead tired and exhausted. For the entire duration of the bus ride I felt sick. As such, this is a real world example and situation that people experience.

However, this game would be altered slightly from the experience to make the game more multiplayer and board game friendly. The game would be a race to the end board game for 2 – 4 players and the premise would be about the same, except the bus only has one spot left and the first player to make it back gets the spot and the other players must wait for the next bus, defeated and exhausted.

But I don't want to wait for the next bussssss. (Go)
The gameplay would be similar to the game “Snakes and Ladders” where the players move by rolling a dice and must make it to the end. However it would be re-themed and modified in a variety of ways to make it work for this game. The first change would be that the “end” of the board would be the bus ticket, and once a player reaches the end, they must make their way back to the start to catch the bus. 

The second set of changes would be to modify the snakes and ladders to make them more appropriate for this game. The ladders would essentially stay the same mechanically, but they would be changed aesthetically to be “shortcuts” instead. This is due to the fact that a university campus has many different paths and routes to the same location, and as such a person could potentially take a different path from the bus stop to the residence and vice versa. The mechanic of having to go to the indicated location on the board would stay the same.

This fundamental gameplay mechanic from “Snakes and Ladders” would not need to be altered as you would be playing as a game development programmer. You (are assumed to) have a solid understanding of programming efficiencies which you like to think would make you a more efficient person outside of programming as well. This allows you to effectively look for shortcuts and alternate paths and be able to mentally calculate how much more efficient it would be to take that route.

I calculate Big-O real time in real life. True story. (Wikipedia)

The snakes on the other hand would be changed into wildcard zones. This is because it does not make much sense thematically for a player to end up going backwards when time is of the essence, so I feel that sending a player back would not fit with the theme of the game. Instead, they would wildcard zones that when a player lands on them, they would have to draw a card from a randomly shuffled deck of cards.

The cards would have an effect associated with them and when a player draws that card, they would instantly have to activate the effect. There would be three types of cards in the deck and there would be an equal amount of them. They would be called “Breather”, “Security Guard” and “Untied Shoelaces”. In addition, there is a special card that is not in the deck, and must be activated once a player reaches the residence called “Faulty Keycard” until the player fulfills the requirements. The descriptions and effects of these cards will be detailed at the end of this document.

To go a bit more in depth about the “Faulty Keycard”, when a player reaches the residence at the very end, they must activate this special card immediately. The player cannot progress and get the bus ticket from his or her room until they successfully pass the requirement placed on them by the effect card. After they do so, they can then proceed back towards the bus stop. Before the card effect is fulfilled, the player may not travel back.

And you also have to take a picture after walking in the rain for 10 minutes.

Each of those cards are essentially negative effects that will hinder a player’s progress across the board. Thematically, they represent some real world issues and obstacles the player would have to face while rushing from one location to another. This balances out the shortcuts that are also placed on the map so that there will be nodes that will benefit the player and nodes that hinder as well.

When a player manages to go from the bus stop to the residence and back to the bus stop, they win the game. The game could either end immediately with everyone else losing, or the remainder of the game could be played out with the remaining players and then second to fourth place could be decided.

The board.

The cards.

Sunday, March 25, 2012

Ninjas? Ninjas.

So the latest (and hopefully last) Game Design homework assignment was broken down into two parts. The first part deals with creating a character and setting up his or her background. Here's his biography that I made up for him. I kind of fused together a story arc with the biography. Also I don't have pictures, but it's a story, you can make up pictures as you read it.

Also indentations.

Game Design and Production - INFR 2330

               Born in 1621 in a small fishing village in the Hizen province of Japan, Daiki Kadoya was born to Hidari Kadoya and Yamamoto Natsumi. The Kadoya family was a poor family of fishermen who made a living selling fish to the other citizens of the village. However one day when Daiki was four years old, his parents were killed after refusing to surrender their fish to passing soldiers. The soldiers were not punished for their actions and at that defining moment, Daiki’s life was changed. He swore to avenge his parent’s deaths no matter the cost.

                From that point on, Daiki was forced to live on the streets by himself. Everyone in the village was too poor to be able to support him so he had to live for himself by himself. After a year of living on the streets doing odd jobs for people who needed it and stealing food when it was possible, Daiki was scouted by a ninja of the Tokugawa clan looking for trainees.

                Daiki was secretly approached to join the Tokugawa clan to undergo the training of the shinobi. Remembering the vow he made to avenge his parents, Daiki decided to become a ninja. He was then brought out of the village in the middle of the night and was led to a secret location for training. The other citizens of the village did not know what had happened to him and eventually just assumed he was dead.

                Throughout the many years of his training, Daiki learned about the art of ninjitsu and mastered a variety of techniques and weapons. He abandoned his last name Kadoya and adopted the name of his clan, Tokugawa, instead. As he was a street rat used to stealth and thievery he excelled in the subtle arts of espionage and deception. On the other hand he had many problems with weapons mastery and as a result sustained many cuts, bruises and scrapes during his training that left disfigured scars to this day.

                However after a lot of hard work and determination, Daiki managed to master the usage of weapons like the kusarigama, katana and shuriken and quickly rose in the ranks and became a prominent trainee of the Tokugawa clan. His constant devotion to working hard paid off and he eventually became a master of the entire ninja weapon arsenal. He was shaping up to become one of the best assassins the clan had ever seen.

                When Daiki was twelve he was determined to avenge his parent’s deaths. He asked for his masters’ permission to go out and to kill the soldiers that murdered his parents but was quickly denied. Daiki was not deterred by his refusal and instead managed to sneak out of the training compound and headed back into society. There, he spent many months illegally going through military records looking for any clues as to the whereabouts of his targets.

                Eventually Daiki found a lead in the form of the names of the soldiers he was looking for and used his ninja skills to eventually track down every member of the four man patrol. The first member he found was sleeping in his home and Daiki silently slit his throat and watched him die. The feeling that coursed through him as he watched the life ebb out of the soldier’s body was one of anger and rage rather than of satisfaction.

                The second and third soldiers were found patrolling together near the Hara Castle. Daiki waited in the trees as the soldiers patrolled past him. Then, he slipped out of the cover of the trees and snuck up quietly behind them and quickly beheaded one of the soldiers from behind with his katana. The other soldier reacted fairly quickly and tried to draw his sword to defend himself, but Daiki responded by throwing a black egg into his face, causing sand and dirt to enter the last soldier’s eyes. As the soldier fumbled around struggling to regain his senses, Daiki stabbed him through the heart and retreated back into the forest.

                The fourth and final soldier was found sitting at home with his family as he was injured previously in another battle. As he was wounded and could not fight, his family was constantly by his side tending to him. As a result Daiki could not find an opening to assassinate him and resorted to gathering as much information as he could about the soldier’s routines and habits. Daiki noticed that every day the soldier would start the morning with the same type of tea, so without much planning he went into the house that night and poisoned the tea.

                The next morning Daiki watched in horror as all the members of the soldier’s family drank the poisoned tea that was meant only for the soldier. One by one all of them died from the poisoning. Daiki set out to kill only the members of the patrol that killed his parents, but his impatience and rage caused him to miss certain details that resulted in the deaths of innocent people. This was a devastating moment for Daiki as he effectively became one of the same as the people he wanted to kill.

                As a result of his failure, Daiki returned to his clan’s secret training location where he was punished severely for his disobedience. Daiki suffered many months of torture and pain due to him disregarding a direct order to not pursue his parent’s murderers and due to his accidental assassination of innocent people. While he was being punished physically for his actions, Daiki was also mentally punishing himself as well for being too quick tempered and emotion-driven.

                After the punishment period, Daiki emerged a different person. It was a defining moment in his life as he decided that emotions were for the weak and simpleminded. He made mistakes because he gave into his emotions and ever since has become cold and emotionless. He resumed training with the rest of his clan members with renewed determination to becoming the best ninja in all of history.

                After many more years of training and service to the Tokugawa clan, Daiki successfully completed dozens of covert missions ranging from thievery, assassination and espionage. Daiki watched many of his clan mates die and suffer during their missions, yet he felt no more sadness. He was no longer the son of a fisherman Daiki Kadoya he once was for he was now the ruthless ninja Daiki Tokugawa. He was one of the best ninjas in the clan and was feared and respected among members of all clans.

                In 1637, Daiki was called upon by shogun Tokugawa Iemitsu to fight against the Christian rebels at the Hara castle. There he was one of the primary forces that resulted in the successful takeover of the castle. He was part of the raid on the castle’s provisions where he led his own group of ninjas to discretely steal important resources and documents.

                His success was not met without any resistance as he suffered many wounds ranging from small cuts and bruises to a large gash down his side. The constant action kept Daiki busy and he would occasionally succumb to weariness and make small mistakes that he would normally never make. However his constant success in acquire enemy intelligence and sabotage eventually led to the crack in the castle defender’s defenses and allowed for the capture of the castle.

                Daiki was never seen again after that point and it is unknown as to whether he had died or was merely never identified again.

Saturday, March 24, 2012

Integrating GPU Mesh Skinning

Long post is probably long.

Intermediate Computer Graphics - INFR 2350

So for people who don't know, my GDW team member Gordon has been working on GPU mesh skinning for about a month and a half now. He started trying to do mesh skinning with BVH files last semester but couldn't get it to work. This semester he once again tried to get it to work, but also to get it on the GPU so it's actually usable as CPU skinning is horrible.

Between me helping him sort and parse data, Branan rigging and animating models and Gordon doing most of the heavy lifting, we finally managed to get it working about one and a half weeks ago. Naturally it wasn't perfect, but we did a lot of debugging and tweaking to try to fix as many issues as we could before we integrated it into the main project which I had.

Looks legit.

So yesterday morning we decided it was time. It was time to integrate it into my project.

Now, a little context is required. Neither me or Gordon ever really had to ever work with another programmer in a big project, as a result we didn't really know how to get things done and we both had our own completely separate projects where we did our thing. Naturally, this is terrible and we're never doing this again since it's a huge pain to integrate our work.

As an aside, we tried SVN today but DevIL is being dumb so bleh.

I have no idea why but I want to eat a turtle right now. (Wikipedia)

So knowing that this was going to be a pain and probably going to take forever, we decided to meet up yesterday at 9 AM in the Game Lab. Thankfully both of us use classes reasonably well so we just had to copy and paste some classes and functions into my code and bam, all the code was in my project. Also we didn't integrate the proper way by debugging after every large change.

We kind of just put everything in and then went "Oh I hope this works!" and hit F5. Dr Hogue does not approve of that by the way. Naturally it didn't work. Many errors popped up and it was crashing all over the place. That was 10 AM btw.

Wasn't as bad as this one, but it was still pretty bad.

So we started debugging. And debugging. We had two main issues. The first one was the game would crash when we would try to draw things when using the mesh skin shader, and the second one was when we disabled the mesh skin shader, but after a few seconds it would just crash.

11 AM. We thought we had a tutorial so we went to the class. Apparently we didn't have one so we went back to debugging.

3 PM. Literally still no progress. No progress whatsoever. At this point I had to go tutor people, so I left Gordon with a copy of the code and I went to tutor, all the while just debugging in my head.

I swear, we used like a million of these.

When I had some down time at tutoring I opened up my laptop and went straight back to debugging. I was debugging constantly. Finally I managed to isolate the issue where the program would run, and then crash moments after. Apparently our timer was stepping out of bounds because we missed a -1 in the range check.


One issue down. When I had a bit more time I ran back to the Game Lab to see if Gordon had any progress. Apparently he couldn't even open my project because DevIL was being dumb (I hate DevIL) and even when he solved the linking issues it would still crash. It wasn't the most awesome news, but whatever.

Once I was done tutoring at 8 PM I went back to the Game Dev lab where me and Gordon continued to debug the code. At one point Albert, Harrison and Monika were there too so they took a look at our code and tried to debug it too to no avail. A part of our level was crashing when we tried to mesh skin our character, which made zero sense.

Oddly enough though our menu was magic and never crashed.

Eventually me and Gordon realized that we had one of the values wrong. We were telling it to draw numOfVertices * 3 elements when we needed it to draw numOfFaces * 3 elements. The program never crashed before since it was just wasting memory which was meh, but due to us passing in attribute pointers for the mesh skinning, it would crash because we would be passing in 3 times as many elements as we had attributes.

So we fixed that, which kind of solved things. But our level was still crashing. However, we realized that if we were to disable our level, it wouldn't crash, so we hoped we would be able to see our mesh skin. Naturally that didn't work either. We couldn't see anything on the screen.

Kind of like this. But maybe not as black.

After a certain amount of time passed (We honestly lost track of everything), I realized a few things. First, I haven't eaten dinner yet and the closest thing I had was an Ice Capp that I was currently drinking. Second, because of the fact that all my other vertex shaders do vertex transformations in the shader, it would make sense that we wouldn't see our character since no translations would be applied, hence it would still be drawn at the origin.

We ran to the origin as fast as we can, but still, it wasn't there. We couldn't figure it out at all.

Eventually though we were looking through the Cg code again and then I saw it. Gordon uses modelViewProj for his model view matrix. I used modelViewMatrix. Those two are obviously not the same. As a result nothing was being passed into the shader for the model view matrix and as a result it wasn't drawing anything since everything was a zero.


So we fixed that and had more face-desking. We ran it again and bam, we saw our character mesh skinned on the screen! Except it was running at 5 frames per second. And it was exploding all over the place. Regardless, we had progress. I wasn't even sure what time it was anymore, but we had progress.

We disabled everything on the screen except the character and the frame rate jumped to 50 something. Which was incredibly weird to us since that should not happen at all. Shaders should not kill your frame rate by 50 something by just drawing things. It made zero sense. Like all the other mistakes we made so far.

It's a gameplay feature. Promise.

So to summarize, at this point we had four major issues. The first was that our frame rate was way too low, the second was that our level would crash when we drew it, the third was that our skeleton was really glitchy and the fourth was that I was hungry since an Ice Capp is not dinner.

It was approaching midnight at that point, and sometime before that I said something on the lines of "Man, if this works I'm going back to my room to eat some soup." and then someone (I think Albert? I don't remember) said something on the lines of "Victory soup?" and I was like "Yea, victory soup. And if we don't figure it out I'm gonna eat some disappointment salmon."

It was totally random, but I was being serious. I had canned soup and salmon in my room.

These are things now. Remember them.

At that point though I was actually really tired and hungry. I figured we already spent like a trillion hours debugging it, we wouldn't get anymore done tonight so I decided to call it a night and head back to my room. We planned on meeting up at 9 AM the following morning to go talk to Dr. Hogue and see if he could solve our issues.

Also since we couldn't fix it I went back to my room, opened up a can of disappointment salmon, and just had that for my "dinner".

Saddest dinner of my life.

Then I went to sleep. Naturally I couldn't sleep since all I could think about was the code. When I finally went to sleep I had the weirdest dream. First I was debugging a bunch of if statements that had a bunch of float4s and float5s (like, what?). Then I dreamed I went back to the Game Lab where Gordon was still there debugging the code.

I told him I felt bad because I went back to my room to sleep while he spent the night debugging, but he was like "It's ok, I figured it out" and for some reason he was debugging StarCraft instead and said that if we disabled the particles the Archons would work.

Well, makes sense. (StarCraft Wikia)

Then I woke up and realized that that dream was dumb. Float5s are crazy.

So we went to Dr. Hogue's hallway where we met up and started to debug code again. At this point we were both tired and frustrated and just tried random things to make it work. Eventually I actually broke everything. Like I wasn't sure what I did, but literally the entire project died. It would say that the program couldn't load and it would crash.

Thankfully I had made a backup of the code from last night, so I loaded that up and tried to debug it again. At that point we were both pretty disheartened and defeated. We were totally thinking of just rewriting the game from scratch so that it would work with mesh skinning. We had to get it in the game.

We almost gave it up. (Wikipedia)

So determined to not have to rewrite the game, I started debugging again. I break pointed. I F11'd. I went through everything again. Then again.

Then I saw it.

We were passing in attribute pointers. As a result we had to enable the client state to get it to work. But. We. Were. Not. Disabling. The. Client. State.

I immediately threw this into the draw function and hit F5.

nfnfIUANf AfnkisanfiasnflkaSnfkinf

And it worked. The game ran at a smooth 50+ FPS and it didn't crash. The character still looked really sketchy, but we could deal with that. That was a skeleton issue. We fixed the biggest issues and I honestly felt like I won the game.

Best feeling ever. Afterwards we celebrated by having some victory soup.

Victory never tasted so random.

We had mesh skinning in the game. It looked really sketchy still, but we had it. After our soup we went back to debugging our skeleton since with renewed spirits. We literally went through everything again, checking every single piece of data, everything we could.

Finally we narrowed it down to one function. Then we narrowed it down to one for loop. Then we narrowed it down to one function call. It was the normalize function.

So inconspicuous, yet so devious.

Gordon's looked pretty much the same too. Except he did it in two lines instead, one to calculate the magnitude, and one to call a scalar multiply function where it would multiply everything with the magnitude. It looked legit, everything was fine.

But it wasn't. My data samples were dying when it passed this point whereas Gordon's wasn't. After more debugging I once again figured it out. The scalar multiply function Gordon was using returned a quaternion. It returned a quaternion. Returned. Meaning that it actually wasn't even normalizing anything, it was just returning a value which got deleted. So he tried to normalize something but it wasn't even normalizing.

Returning things that are perfectly fine should be a crime.

So I quickly commented out my normalize and hit F5 again.

Worked. Perfectly.

It only took us 15 hours of debugging yesterday, and about another 5 hours today to fix it. 20 hours total for literally the smallest mistakes ever. Embarrassing, yet I really don't care. We have GPU mesh skinning in the game. Hell yea.

We also skin meshed our shadow because we can.

Also Branan, your run cycle derps in our game, so our character is walking everywhere from now on. Game design!

Monday, March 19, 2012

Memorable Characters

Game Design and Production - INFR 2330

So we just got assigned a two part assignment due next week for Game Design. It's actually a pretty big assignment and it's right during crunch time so I'm definitely not too happy with it. However, I'm a student, so I have to deal with it.

The assignment deals with memorable characters. A lot of characters are memorable, but many more are not. In my opinion, the same characteristics that make a character memorable in video games make a character memorable in pretty much every other medium too. A good character would be memorable whether or not he or she is a character from a video game, movie, tv show, book, whatever. So what exactly makes a character memorable?

Batman is memorable because he's Batman. (Wikipedia)

Obviously a character is memorable for different reasons for everyone; every character has qualities about them that stick out to certain people. Trying to just figure out exactly why certain characters are memorable to me is actually pretty hard. It'll take a lot of time and a lot of effort to actually list out the exact traits. As such, I think for this blog I'm just going to list three memorable characters to me and then list why. Maybe it'll shed some light as to why I find certain characters memorable.

The first character that comes to mind when I think of the worlds "Memorable Character" is actually Chrono from Chrono Trigger. Although I love Chrono Trigger, I actually have no idea why he's the first character I think of.

Maybe because Luminaire is the sickest ability. (Chrono Wikia)

So Chrono Trigger is a pretty awesome game. I highly suggest everyone to play it. It was a game released on the SNES and then re-released for the DS and it pretty much is the definition of a classic JRPG. As it was a classic JRPG, Chrono actually doesn't talk. I don't believe he has a single line in the entire game yet I still love him as a character.

This obviously must mean that a character is memorable not necessarily because of what they say, but can also be memorable due to their actions. Chrono starts off as a pretty regular spiky haired, sword wielding guy who just wants to have a good time at the fair. Due to events that I won't spoil, he ends up becoming a time traveller who travels through time with a bunch of awesome people in order to save the future.

Man I need to play this game for the 2151248th time. (Capsulecomputers)

I think part of the charm that makes Chrono memorable is that he doesn't talk. I mean, he doesn't talk, but I think that actually lets the player project his or her own ideas and thoughts onto the character and make them more "relate-able" I guess. I mean, I'm sure everyone has at one point or another thought about how awesome it would be to be able to travel time and control lightning.

Actually, you know what? Like every single character in Chrono Trigger is memorable. Every single one of them. The game was actually designed in a way that every character has their own story arc and the player experiences each and every single one of them thus being able to explore that character's history and origin.

These glimpses into the character's background actually is a really nice design element since it allows the player to better understand the reasons behind a character's motives or personality without having to be spoon-fed details through a narrative. I mean, let's take Frog for an example.

I'm so disappointed that Googling "Frog" doesn't return this picture first. (Chrono Wikia)

First off, this is a frog in armor with a sword. Now, I hate frogs, but Frog is awesome. The game goes incredibly in depth into Frog's history and it explores many elements of his past. The game goes into why he became a frog, what drives him to go on this quest, who his mortal enemy is, and how straight up baller he is in one beautiful story arc.

If you never played the game, Frog would look incredibly silly. But through his story arc in game, the player comes to empathize and understand Frog as a character and that makes him incredibly memorable. His entire life he was always second to his best friend (SPOILERS) Cyrus until Magus decided to kill him and turn Frog (who was called Glenn) into a frog (END SPOILERS). This makes Frog swear an oath that he will one day kill Magus.

Oh God, I just noticed what hes wearing. (Chrono Wikia)

Who you can actually choose to not kill and have him join your party! Although Magus starts off as the primary antagonist and what seems to be the super bad guy that's trying to ruin your day, he actually isn't that bad of a guy. (SPOILERS) Like Frog who was driven to a point of blind rage because Magus killed his friend, Magus was driven to a point of insanity because his sister died (END SPOILERS).

Magus also has his own story arc where the player gets to understand the character's history and drive and then all of a sudden his actions all make sense. Chrono Trigger actually does a beautiful job of exploring a character's history as they do it in such a way that it's not intrusive and gives actual insight into the character. It builds up the character and gives them more dimension; makes them more real.

As real as pixelated sprites make them at least. (Chrono Wikia)

I think for me, a character really starts to get memorable if we know more about them. I mean it's great if the character is angry and just wants to kill things, but without the proper understanding of why the character is doing the things they do, it just doesn't seem the same. I like understanding the characters, being able to predict what the character would do, and why they would do it.

I mean, when I play games and make choices, I like to make choices that are consistent with how I think the character would make them. If I know the character better, I guess I feel more "attached" to that character in some way or another. I think for me, the character is memorable if I understand them or if they are similar to me. Those things stick out to me and a lot of the characters that I find memorable fit into one or both of those ideas.

Saturday, March 17, 2012

Transformations in Shaders

Intermediate Computer Graphics - INFR 2350

So I've been talking to a lot of people lately. A lot of them have talked to me about putting vertex transformations in shaders because I actually had it done for a while now for our GDW project. It's actually fairly straightforward to put transformations in shaders and it's actually really great, since it would make your program speed up due to the fact that you would be doing the calculations in shaders, and you wouldn't have to use glTranslate, glRotate or glScale.

For those of you that do not know, glTranslate, glRotate and glScale are terrible. They get the job done when you want to transform objects, but they don't do it well. There's a ton of crap associated with each of OpenGL's built in functions that actually end up slowing down the transformation more than it needs to be. In addition shaders are obviously run on the GPU which would also make things faster.

GPUs are better because they look more ballin. (Tigerdirect)

Now, doing transformations on your vertex shader is actually pretty straightforward, but you need some knowledge of linear algebra which you should (hopefully) know. The biggest things that you need to know are rotation matrices, homogeneous matrices and matrix multiplication. It's pretty apparent that these all deal with matrices, so make a matrix class because they're awesome.

Normally you could do all of those transformations separately using their base matrices, but you could make things easier for yourself and create a homogeneous matrix that does all three transformations with one matrix multiplication. How you would do that is pretty simple, first you create your resultant rotation matrix by figuring out how much you need to rotate along the X, Y and Z.

Y axis rotations are the best rotations btw. (Wikipedia)

You would do that by just taking the rotation matrices for each  axis and then plug in your numbers and then do some quick math to figure out the result. Then after that you take your scale matrix, which is just essentially a 3x3 matrix with your scale values in the diagonal and 0s everywhere else and you multiply it with your resultant rotation matrix to get a final matrix.

With that in place, you just place that into a 4x4 matrix and then input your X, Y and Z translation values down the rightmost column and then stick a 1 in the bottom right slot to complete your matrix. Easy.

I remember being so confused when I first saw this on lecture slides. Now it's like lewl.

Now I just essentially made a function called "createHomogenous" which would essentially just generate a matrix when I need it, so I personally make one for every object drawn on the screen and update it when necessary.

Passing it into the shader took me some time to figure out since I wasn't too familiar with passing in matrices into the shader. I didn't want to just hard code all 16 values as separate variables, so I was trying to figure out how to pass in a float4x4. I failed.

Ehh. Good enough.

However, I ended up just passing in 3 float4s, since the bottom row is garbage and unnecessary. Passing in float4s to your shader is fairly straightforward. Once you get the three float4s into your vertex shader, all you really need to do is to dot product the each row with your input position. You dot product because dot product is essentially matrix multiplication, but obviously instead of returning one float you get a couple.

So you code that in your shader, and bam. Done. Simple.

Generating your homogeneous matrix is really the hardest part, but it's fairly ok.

Monday, March 12, 2012

Carrot Cakes

Not that this post is not actually about carrot cakes.

Game Design and Production - INFR 2330

So since the prof was at GDC this last week, we didn't have a class. As a result he gave us a two week assignment to create a physical or digital game that had the mechanics of the game hopscotch, but a different theme.

We decided to take some literal mechanics from hopscotch as well as some non-literal elements to create a Flash game called Carrot Cakes (I'll get into why later). It's a fairly simple game. You play as an omnipotent being who can shoot this magical spinning ball and you want to turn on all the numbered tiles from one to ten by having the ball land on the correct tile.

I art good.

I did all of the programming for the game in Flash. It was pretty straightforward to make actually since compared to C++, Flash is a lot higher level and doesn't require as much setting up. You literally just throw things on there and go.

We used two literal game mechanics of hopscotch for this. The first one was the act of going from one to ten. Hopscotch does this as players need to jump from node one to a number, generally around ten. The second literal mechanic we used was the act of throwing a ball or rock. We implemented that by having the gameplay focused around shooting a ball onto the play area.

I don't think I've actually ever played hopscotch before. (Wikipedia)

The non-literal elements we took were things like balance, precision and timing. This game requires a lot of those elements because the arrow that represents the direction the ball will shoot out in constantly rotates. As a result you as the player have to constantly plan out how much power you want to employ on the ball and when, as if your timing is off you would miss the slot completely.

After I drafted up the game, our artists took what I had and made it pretty. I'm a terrible artist so I had a working game, but it looked very primitive. Our artists went and made it look fantastic.

Slightly older version; this version turns off the tiles instead of turning them on.

A huge improvement over what we had before.

Now, as for the name of our game. You may have noticed that there is nothing related to carrots or cakes in this game, yet we still named it Carrot Cakes. Why is that? Well I couldn't think of a name and I was talking to a friend on MSN telling him I couldn't think of a name. So I jokingly said something random like "I should totally name it Bacon Cakes or something" and he was like "Nah, you should name it Carrot Cakes".

So I did. Obviously at that point it was temporary, but then I talked to my artist and asked her to think of a real name, she was like "Carrot Cakes is a good name" and then made it official.

Chinese carrot cakes are the best type btw.

It's actually a pretty tough game though. But once you get used to the timings, it becomes a lot easier. My record is 17 shots to beat the game.

Shader ALL the Things

Just a random thing about shaders that I figured out today.

Intermediate Computer Graphics - INFR 2350

So I've been working on my GDW game a lot lately. But for some reason it seems progress still seems really slow. No idea why. However, with every day that goes by, it seems that I'm getting things done, but from a game perspective aside from a few new textures it looks practically the same now as it did like two weeks ago.

One of the things I had issues with was 2D stuff. We're talking about the HUD and the 2D sprites that may or may not be displayed on the screen. Even back in last semester with SHFT, I had some issues with them. The first issue I had was that the text would be the same colour as the last texture that was drawn, so to bypass that I had to load in a blank model with a solid colour texture.

This is sir blank, and he is not amused.

It got pretty bad, so I had to actually use sirBlank and madamBlank. It was pretty bad.

The second issue I had was with PNGs. The transparency worked fine unless if we had transparent sprites overlapping each other. If that happened, then which sprite was on top would draw fine, but even if you were supposed to see the bottom one through the top one, we wouldn't be able to see it.

You can't see the issue because it's invisible, but it's (not) there.

I kind of just left them. Couldn't fix them, so I left them alone.

When I worked on the Batman and Juliet game for Game Design over reading week, I had similar issues so I had to employ similar methods. It was ugly and I hated it. The text would be the same colour as the last texture that was textured, and 2D images wouldn't even load in properly. That's why our Batman game had no sprites, it was just text.

We also had that issue.

So how does this relate to shaders? Well apparently shaders solve everything. We obviously needed a proper graphical UI for our GDW game, but I couldn't get it to work properly. Now even the sprites were just being colored the same as the previous texture. I knew what was going on, but I didn't know how to fix it, which pissed me off a bit.

So today, I was trying to think of ways to fix it when I thought, "Wait a minute. Let's just throw everything at the GPU, maybe it'll fix it.". So I did that. I went into the sprite and text classes I had, and literally just copy and pasted my shader stuff into it from my quad class. I also noticed that the sprites were being drawn with a bunch of glTranslates and stuff, so I got rid of those too. I hit F5 and..

That tree is supposed to be in the platform.

Bam. It worked. The text on screen was white, which is what I wanted, and the cursor was displaying normally. It somewhat blew my mind. It made sense since shaders are awesome and having everything run on the shader made everything neater anyways. But at the same time I was kind of surprised that it was actually such an easy fix.

Really didn't occur to me before that I could just do that. Now I had a question as to whether or not the transparency issue would still happen, so I quickly made a PNG in photoshop and loaded it in.

Overlapping PNGs? Madness.

Yay. It transparencies properly too. Which is great. With those issues fixed I could finally start working on a proper HUD for our game. Makes it even more awesome knowing that I got rid of some inefficient function calls too since I'm throwing everything into the shader instead of using nasty calls like glTranslate.

But yea, shaders are magical.

Sunday, March 11, 2012

Game Design - Homework 6 - Vegetables and Fruits

Part two for Homework 6 for Game Design

Game Design and Production - INFR 2330

According to Foodland Ontario, there are many types of local fruits and vegetables available in Ontario throughout the year. I have decided to make a card game to teach players when which vegetables and fruits are available in which season.

The game I have designed is inspired by the season based system in Harvest Moon. Harvest Moon is a series I enjoy a lot and it is a farming and life simulation video game. In Harvest Moon, the player plays a farmer who must manage a farm which can produce crops and animal based products.

Best game. (Wikipedia)

I really enjoy the farming portion of the game as it is actually very addictive and methodical. Certain crops are only available in certain seasons and thus the player must plan out their crop growing season properly to maximize profits for that season.

Unfortunately, not a lot of crops are “season exclusive” in the real world unlike Harvest Moon, so a lot of the crops I chose for this assignment have some sort of overlap with other seasons. For example, a lot of the spring crops could overlap with the summer ones, and a lot of the summer ones could overlap with the fall ones too.

For my game, there will be the following vegetables and fruits in play. Spring will consist of rhubarbs, parsnips and mushrooms. Summer would have cherries, strawberries and watermelons. Lastly, fall would have beans, corn and Asian vegetables. Winter would not have any fruit or vegetables available since not many things grow in the cold.

Asian vegetables are the best btw. (Pham Fatale)

The game would essentially be a deck building game. There would be ten of every type of fruit and vegetable cards and fifty one-gold cards, thirty three-gold cards and twenty five-gold cards. There would also be ten of the following ability cards as well, thievery, water and guard dog. The effects and costs of each card will be listed below in a chart. 

Each player starts off with five one-gold cards at the beginning of the game in their “deck”. They are all face down and on the first turn, three cards are drawn. On subsequent turns, only one card is drawn. If the deck runs out of cards, all cards in the discard pile are shuffled into a new deck. The game works similarly to the game Dominion, except there's a different theme and the flow of the game plays out differently.

Farming is more fun than conquest anyways IMO. (Dominion Game)

The goal of the game is to spend your money to acquire either ability cards or plant cards and to make as much money as possible. Once a gold card is spent, it is placed into the discard pile. Plant cards can only be planted during the season that the vegetable or fruit is available in. While they are being planted, they are in a “dormant” phase where they are in play and not in the discard pile.

Once the plant reaches its maturity phase, the player can harvest the plant on their following turn and the player gains a number of money depending on the plant. That plant card then goes into the player’s discard pile so that it can eventually be shuffled back into the player’s deck.

Hm. Reminds me. Haven't planted anything in a while. (EPA)

The game starts off in the spring and year zero and the game ends after five years. Each year is defined as a cycle from spring to summer to fall to winter and back to spring. Each season lasts for five days and each day is defined by one round of play.
Tokens can be used to represent how many days a plant has been growing for and for which year, season and day it is. During the winter, players are expected to just plan for the year ahead and buy seeds ahead of time and to start saving money.

We're assuming this happens to your farm in the winter. (Guardian)

If a plant is currently growing when the season changes, then the plant “dies” and is immediately put into the discard pile. Ability cards can only be activated on your turn aside from the guard dog card which can only be used in response to a thievery card.

After the five years of play, whoever has the most money wins the game. This game would teach people about some of the vegetables and fruits that are grown in Ontario and would give them a rough insight as to when they are in season.

Click to enlarge.