Monday, November 26, 2012

INFR 3330 - Magic Cards and Stuff

One of the recent topics in our Game Design class dealt with resources in games. Little did I expect was that in one of our lectures this week we would spend the entire class analyzing Magic cards and trying to generate a formula as to how attack and toughness are related to the mana cost.

It was actually a pretty cool lecture. It made me feel wanna play Magic again. I got into it in first year after Branan talked me into trying it. Then like everyone I hung out with at UOIT got into it.

I'm too lazy to get up and take a picture, so here's a fuzzy zoomed picture.

Those were fun times. When GDW and assignments were less work and stress, and when we were actually had free time. I remember playing Magic like 3 - 5 nights a week with anywhere between 2 - 10 people. Miss those times haha.

One of the things I enjoy a lot about Magic is that it's a very complex and intellectual game. There are a bunch of different formats you can play, and within each format there are tons of deck combinations you may encounter. Sure, some are better than others, but you are bound to experience a lot of variety if you just play between friends.

I made an EDH deck with this card and 99 mountains for the lulz. (Gatherer)

I'm a really big fan of games that require skill and thinking. Sure, you don't need to think as much when you spend a trillion dollars on your deck and have the most overpowered cards ever, but generally when you play you have to play with a strategy in mind and learn to adapt to your opponent's moves.

But I find it pretty interesting how the game is balanced. I mean, the game has been out for like 20 years, and there are a ton of cards out. Not only that but there are five main colours, with other varients like multi-colour cards, colourless cards, etc. They all play differently, but for the most part the game is pretty balanced.

Reasonably balanced that is. (Wikipedia)

Like for example red cards embody destruction and reward players for being aggressive and dealing damage. Blue cards are actually magic, and are very spell heavy and used to control the flow of the game. Black cards are focused on death and corruption where they destroy things and leech health and stuff. Green cards are focused on growth and are centered around crushing your opponents with creatures. Finally, white cards are focused on order and protection and they just do things.

I normally play Red/Blue since burn/bounce/counter is like the greatest thing ever.

And of course purple sleeves cause Red/Blue.

I'm actually really curious as to how the design process goes for creating new cards. I think it'll be pretty interesting to know exactly how they do it, and how they test certain things.

Especially when they decide "screw it" and add cards like Emrakul.

Sunday, November 25, 2012

INFR 3110 - NGScripts

GDW is due soon.

Feeling the pressure, and it doesn't feel good. Crunch is upon us and honestly, I haven't ever been so worried for a GDW deadline ever before. In previous semesters we've always had a working game a week or two before it was due, and would just spend the remaining time polishing. This time though, we're behind.

Time to bring this back.

Regardless though, in this blog post I'm gonna talk a bit about the scripting system we have in our GDW game. It's probably the engine component that I'm most proud of that I added into the game because I personally think it's pretty freaking cool.

In previous GDW games, I always hard coded the game logic. This included everything, from enemy behaviours, events, and so on. As you can probably imagine, things get really messy really fast, especially if you wanted some complex enemy behaviours.

See that scroll bar to the side? Pretty much 90% of it from this point down is the update function.

Code gets really messy and long, which we don't really want.

Since we wanted some more complex behaviours in our game, and we wanted an engine that was scalable and easy to manage, I decided to try my hand at creating a scripting system in our game. So one weekend I sat down and came up with a base for the scripting system, and thus NGScripts were born.

Yes, my ego knows no bounds. We've went over this before.

So how it works is that I wrote a parser that parses a text file for keywords and values. Then, based on the keywords and values inputted, I used a bunch of member function pointers and other things to essentially recreate the script into C++ logic.

Then, the scripts can be attached to an object in the game, and when the object is updated, so will the script. Whenever a condition is fulfilled, then the associated action will trigger. It also has a property section so we can also change object values in the script too.

Just like that, and it'll work.

I'm actually really happy with how it turned out. I currently can check for a bunch of conditions such as whether or not the object's health is below/equals/above a certain point, whether or not it is closer/equals/farther than a distance from the player, whether or not enough time has passed, etc.

When the condition is true, then it will activate the action which will do something such as change the AI state or apply a force. It made me feel pretty giddy to see it all work in the game, but it's still a work in progress, many more improvements can be made, and a lot more stuff can be added.

Also I need a better interface for the editor/generator.

Monday, November 19, 2012

INFR 3330 - Design at MIGS


So I went to MIGS this week. For those of you that don't know, MIGS is the Montreal International Game Summit, and it's a yearly game developers conference in Montreal where industry professionals give talks, business have booths, and so on.

It was my first time going to MIGS, and it was pretty awesome. Learned a bunch of cool things and had fun as well, which is great. This post is going to be focused on some of the design elements I experienced at MIGS, whereas this post will focus on more of the tech and engine stuff I learned.

There was a really awesome looking pool outside behind this thing.

So as a programmer, most of the talks I went to were under the tech label. Now, they had a lot of stuff in those talks about design as well, but this post will primarily talk about the other two talks I went to, since the other eight were discussed in the other blog post.

The first non-tech label talk I went to was from none other than UOIT's Dr. Nacke. Before I went to MIGS, I was looking up some of the talks, and was surprised to see him on the list of speakers. I thought that was pretty cool, so on the first day of MIGS during that time slot, I decided to go to his talk.

Like a super lecture.

His talk was on Biofeedback Gaming, which was essentially a talk on some of the biofeedback tools we currently have, and how they can be used to create a different game experience for the users, and how they can be used to improve on them as well.

It reminded me a lot of the Game Design lectures we had in class, since well, it's by the same guy. It was slightly different though since he talked more about the biofeedback side, which I don't believe we spent too much time on in class, if any.

And of course Antimatter would be shown during the presentation.

It was pretty interesting actually, because having biofeedback allows developers to get essentially a different dimension of data when testing and polishing their games. It goes beyond the traditional feedback methods, and allows developers to get a better feel of the sub-conscious emotions their players are experiencing, and thus being able to tweak their game to get the feel they want.

Another thing I found interesting about the talk was the use of biofeedback as an input device. As long as the devices themselves are not chunky and intrusive, I think there could be some pretty interesting applications in how that data can be used to drive the game. I think games that can react to the way the player is feeling would be pretty awesome if done right, and I would really like to see games that do that.

Here's a random picture of Mirza.

The second talk I went to that wasn't under the tech label was actually the last talk of the conference, The Art of Creating Efficient Tools. It was under the art label, but it was actually a really good talk on user interface and design. I've been very interested in designing and developing tools lately, so the talk was really interesting to me.

The presenter was from Ubisoft, and he went over some of the design aspects a person has to think about when creating these tools. He went over a bunch of rules and elements that was taught to us in our Game Design class, but also went over a bunch of new ones that really gave me some insight of how to make better interfaces.

I was pleasantly surprised when the talk started.

He went over design elements such as using different and interesting visual cues to not only make the interface easier to read, but to make sure it is more accessible to different users (say, colour blind). He also went over things like making the interfaces more intuitive and simpler, and just went over a bunch of thought provoking things as to how to design things better.

Overall I would say that that talk was one of my favorites from the entire conference. Top 3 for sure. One of the things that he said that really stuck out to me was that when designing a tool, don't design it based on what it should do. Rather, design it based on what it should achieve for the user.

INFR 3110 - Engines at MIGS

So I went to MIGS this week. For those of you that don't know, MIGS is the Montreal International Game Summit, and it's a yearly game developers conference in Montreal where industry professionals give talks, business have booths, and so on.

It was my first time going to MIGS, and it was pretty awesome. Learned a bunch of cool things and had fun as well, which is great. This post is going to be focused on some of the engines and tech stuff I experienced at MIGS, whereas this post will focus on more of the design elements I learned.

Possibly the first time I ever felt like I should've paid more attention in French class.

Aside from the keynote presentations, there were five talk sessions in each day. There were about five talks to choose from in each session, and so you had to pick and choose which one you wanted to go to. Being a programmer myself, I was really interested in the tech talks, so 8/10 of my talks were actually under the "Technology" labels.

The first talk I went to was the Building Better Tools talk by some guy from Google. This was a pretty awesome talk since I thought the presenter did a pretty good job, and it was on a topic I was pretty interested in. He talked about performance measuring tools, and how a web browser can be used as a platform.

I decided to take pictures of all the talks I went to, but realized quickly these pictures were meh.

Ever since my internship in Hong Kong, I've been really interested in browser based applications and tools, so when he started talking about that, I was instantly hooked. Some of the stuff he talked about I already knew, but other things like streaming "videos" and such was new to me, and was pretty cool.

The next tech talk I went to was the GPGPU talk, where some guy talked about compute shaders. I was pretty excited for this talk, but was quickly disappointed when I got there. It was pretty much the same talk Dr. Hogue gave us for this stuff, but minus pictures, videos and numbers. So it was really dry.

Wish it had more mind blowing pictures and videos.

Following that I went into the Glaicer2 talk by a guy with the most epic name ever, Kasper Storm Engelstoft. He worked for Square Enix and talked about the new engine they were using for some of their games like Hitman. I was pretty excited about this talk, since I'm not only a big Square Enix fanboy, but I was hoping to see learn about some awesome engine stuff.

I was not disappointed  In probably my favorite talk of the day, we had a glimpse of how their engine was built, as well as some of the tools that were built on top of it to make using their engine easier. I'm a pretty big fan of cool engines and awesome tools, so the entire talk was really interesting to me.

Like I said, taking pictures of like the intro of a talk is not that awesome. Although dat bloom effect.

Afterwards in the same room they had a talk about Full Performance Capture from the Farcry series. That as a pretty cool talk too, but it focused more on the way they used to record the motion capture animations, and as well as some of the tools they developed to streamline the process.

The guy also showed a bunch of Farcry trailers, and now I kinda want to buy Farcry.

Advertising during a tech talk. That's the way to do it. (Wikipedia)

The next day the first talk I went to was called Anatomy of a Transmedia Social Game Engine. That was somewhat interesting, but was essentially a talk about how some social game company decided to use Flash to make a game that was cross-platform compatible. It was interesting, but I didn't really take anything of note from that presentation.

Then, I went to a talk called "Procedural: a Realty?", but in reality it should've been called "Procedural: a Dictionary", since he pretty much talked about only definitions, and again didn't have any numbers, videos, pictures or anything cool. Very dry, very definition heavy. I wanted more, but he was on an NDA, which made me sad.

NDAs are ruining eSports talks.

Afterwards I went to my last tech labelled talk of the conference, a next gen development talk from some guys at Ubisoft. That was a pretty interesting talk too, since they talked about some of the potential issues that will be arising in the next gen in terms of what players wanted, and what developers can deliver.

They also used a lot of Assassin's Creed footage, and it made me want to play Assassin's Creed even more. I really need to play more video games.

They both drank from the same glass of water.

Overall, I learned a lot from the talks, and had an overall good time. I wish some of the talks were less dry though, and had more oomph to the presentations.

Monday, November 12, 2012

INFR 3330 - Puzzles and Stuff

In Game Design last week, we spent some time talking about puzzles.

I'm a pretty big fan of puzzles actually. I like games that require some thinking and skill to solve, and puzzles are like the greatest thing for that. That said, I don't really like games entirely built upon puzzles. Like those are fine, but I my personally preference are for games that have puzzles elements in them.

I actually bought a Sudoku game for my DS. I enjoy it, but I can't play it for hours on end. (Wikipedia)

I like games that have some variety in them in terms of gameplay. Random mini games here, random puzzles there, and so on. They make the game more interesting in my opinion, and can provide some different challenges to the player so that the original gameplay doesn't get stale.

In terms of puzzles, the first one I think about when I think about "puzzles in games" is the paradox puzzles in Final Fantasy XIII-2.

I've hit that Retry button so many times. (NZGamer)

I actually hated that puzzle.

It's one of the few types of puzzles they had in the game. The other ones I was totally fine with. In fact, I was ok with the above puzzle type too (It's called Hands of Time btw). However they get frustrating. Especially when in order to solve a paradox, you need to beat many rooms in a row. And there are levels where the entire level is solving many paradoxes.

I'm looking at you Oerba. (Final Fantasy Wikia)

It's frustrating when you have like 10 paradoxes to solve. And like half of them require you to beat like 5 rooms of Hands of Time. I did that all in like one sitting, and by the end I felt like my brain was about to explode.

On the other hand, I really enjoyed the other two types of paradox puzzles. My favourite of the three were the Tile Trial puzzles. In those puzzles, the player has a starting point and an end point. There are a bunch of tiles, and they disappear when you step on them. The goal is to get to the end while collecting all the crystals.

I like this one. (Final Fantasy Wikia)

This one I actually find kind of fun. It still requires thinking, planning, and sometimes even timing. Yet it's quick and not overly difficult. I didn't mind doing a bunch of these in a row since it didn't feel like I was smashing my head against a wall.

Also, I know a lot of my blog posts are on FFXIII-2, that's pretty much just because in the entirety of 2012 I played like. Four games total: Harvest Moon 3DS, FFXIII-2, StarCraft II and Kingdom Hearts 3DS. I just don't have enough recent material to work with, so I keep using the same games.

INFR 3110 - Collision Detection

So last lecture for Game Engines we talked about collision detection. So this is a short blog post on that.

I'm so terrible at collision detection. I've done it a bunch of times, but it's honestly one of those things that have plagued me forever. I can get it kind of working, but normally just an incredibly simple version that's also incredibly inefficient. It makes me so sad when I work on collision.

You know your code is awesome when you have a comment paragraph at the beginning (not pictured) apologizing.

Ugh, everytime I open up SHFT's code I feel physical pain. It is the most hackiest, dirtiest code I've written in recent history. The collision detection algorithm is a monster in and of itself. It's so nasty.

I've gotten so much better at it now of course, but I still can't say its my strong point. Luckily for this semester we have actual engine programmers in my group, and since we're also using Havok, I don't have to touch collision detection. I really don't like implementing it.

Testing collisions in SHFTed.

I'm actually not sure why I'm so bad at it. Like, I understand the theory pretty clearly. But it's just when putting it together in code, everything falls apart. It's weird. It's just always been that one thing I struggle with the most when making a game.

I'm sticking with the idea that everyone has something they're just more comfortable programming, and others where they aren't comfortable programming. Collision detection isn't really my thing, and I've accepted that haha.

Monday, November 5, 2012

INFR 3330 - Sticky Areas in Games

A few lectures ago we talked about sticky areas in games. A sticky area is essentially a place where the player wants to be, normally due to some sort of tangible or intangible benefit. When going through that in class, I thought back to some of the games I played and reflected on the sticky areas in those games.

The biggest example I could think of for sticky areas would be in World of WarCraft. I used to play that game a lot, and I could easily think of certain places where it would be considered a sticky area. For example, a city could be considered a sticky area because being in a city gives you benefits.

Time to open up my trusty Photobucket account and pull all the pictures.

The most obvious benefit would be safety. For the most part, you are safe in a city. You could go AFK and you (probably) won't die. You could just derp around and be safe too.

But being in a city also unlocks gameplay features. For example you can join trade chat to talk to spam talk to others or to sell things, you can use the auction houses to buy/sell things, train professions, access the banks, etc etc.

I had a lot of stuff I could access.

I used to spend a lot of time in the cities, especially Dalaran because I would run out of things to do and just kill time in the city. Whenever I started my day, I would be in Dalaran. Whenever I ended the day, I would be in Dalaran.

In terms of other sticky areas, there's a bunch of them. There are a ton of areas in World of Warcraft where you would go because of other reasons. Areas where there's lots of daily quest givers, areas with a bunch of quick spawning mobs that drop important crafting materials, areas where rare mobs spawn, etc.

I used to farm for a lot of stuff.

I remember farming a ton of motes at the Elemental Plateau in Nagrand. I spent a lot of time there farming stuff so I could craft things and I would literally be there hours at a time, running around throwing damage over time spells on everything and watching them die, loot and repeat.

I also remember spending lots of time doing daily quests in certain areas like in Shadowmoon Valley for the Netherdrake mount, or to get enough reputation to get exalted in a specific faction just cause I wanted a fully lit green bar in my reputations page.

I remember going to that place every day for like a month to get enough rep for this mount.

In fact, now that I think of it, WoW actually has a lot of sticky areas. A lot of these areas aren't even like, short term sticky areas either. Many of them are long term, and stay sticky for long periods of times, ranging from a few days to a few months. There's so many that the player almost never runs out of areas to go to and do things in.

It keeps players busy. Keeps them playing. But most importantly of all, keeps them paying.

INFR 3110 - I am Winnar

So I'm pretty much at 60 experience.

I have all the questions I need shown and accepted by Saad and Buckstein, and all of them are handed in and I'm just waiting for acceptance on Blackboard. But I am essentially at 60. So yay, first person to 60. I lost to Gordon in Graphics last semester, but I ended up beating him to max this semester, so yay.

Winnaring, not Winraring. (Wikipedia)

So I would like to take this blog post to go over the questions I did on my path to 60. Maybe this will help some people, maybe it wont. But anyways, for my easy questions I did the lighting one, the arm one, the dynamic texture one, and the tree one.

Since those have already been cycled out, I won't go into them. The first medium question I did was the solar system one. This is probably the easiest question out of all the mediums. I know a bunch of people already have it done to get to 20, but if you haven't done it already, get this one done.

Some people seek to understand the universe; I create them.

It's honestly the easiest one. All this is is just understanding how parenting works in Ogre with scene graphs. Scene graphs were on our midterm. Everyone should understand how they work by this point. Hardest part of this is to get all the information in, but that's not even hard, merely just tedious and time consuming.

The second medium question I did was the OgreLog Tool. This is probably the second easiest medium question given that you know how to use .NET or MFC. Or are willing to learn and have a capacity to learn it in a non-painful time frame.

You see me (b)logging, you hatin.

The parsing of the actual file is easy. Everyone should know how to parse an OBJ file by now, and if you can do that (and understand how), then you can parse this file. Luckily for me I was somewhat familiar with MFC going into this, so it wasn't hard to learn how to do the Windows stuff, but it's definitely learnable.

Afterwards I did the medium AI question. I was considering going up to hard, but I decided it wasn't worth the effort. Again, this question is pretty straightforward. I mean most of the components of this question were on our Animation homework questions as easy or medium ones.

God I love the flocking one.

Seek, flee, arrive, wander, flocking were all on the Animation homework. Pursue and evade are like the same as seek and flee, but with a small extrapolation. That was a year ago, people should know how to do those know. All you need is basic physics knowledge. The hardest part is getting the lines to draw and display properly, but even that isn't that bad.

The last medium question I worked on was also the last question I handed in, the camera question. It seemed kind of like a mission at first, but after actually reading it it wasn't that bad. Hint, use more than one camera.

Dem frustums.

Figuring out how the camera works in Ogre is fairly straightforward. All you need to know is how to position them relative to an object, which is pretty simple. Bam, you pretty much have the question done. Now you just need to figure out how to make it look at things, and then use Ogre's built in Frustum class to find the frustum points. 

The only hard question I did was the sound question. This one is by far the easiest hard question. Everyone that actually did their own assignments in our Sound and Audio class last year has like half of the question done already.

Most exciting screenshot.

Congrats, you should have half the question done. The other half of the question is actually new, and requires you to learn how to use DSP. Which is even built into FMOD, so all you really need to figure out is how DSP can be accessed, and which function you need to call from there.

So that pretty much wraps up the medium and hard questions I did to get to 60. Honestly most of these are pretty straightforward. Half of every question should be completely intuitive for everyone that got to third year of their own merit. The other half requires a bit of learning/researching, but isn't really that bad.