Breaking Down UGC - HCI Entry #1

After a long hiatus, I've decided to start posting up some of the blogs I've had to do for classes once again. The most recent class to require blogs is Human Computer Interaction, which is essentially how to effectively created user interfaces and give feedback to users in order to give the best experience possible. The journal entries I will post for these have been done earlier so the date they are posted aren't reflective of the day they were actually done.

HCI Journal Entry 1

January 15^th

                After having taken several Human Computer Interaction courses, it’s allowed me to understand more about the concept of HCI and how it’s used in our everyday lives. I specifically want to focus on how it was used in some of past game development projects at UOIT and how well they implemented feedback for players or not.

Ultimate Gladiator Coliseum : 80 AD

                UGC 80 AD was a third person, gladiator combat game based around arena fights created in my second year of GDW. The goal of the game was to fight through several battles, earning gold along the way to purchase items to become more powerful in order to fight more difficult bosses down the line.  I will be taking a look back at the game to compare its use of HCI during combat sections, in the HUD and the end goal of the game. I will judge the extent of player feedback that was provided to see whether or not the game was easy enough to understand. I’m also keeping in mind that the game was developed with a limited time frame and we had a surprisingly large amount of content we had to cover, but this doesn’t mean I can’t criticize it still.

Start Menu

(From UGC : 80 AD beginning menu)

                Right from the start the opening is an eyesore. The logo itself is extremely pixelated and a bit glitch, the stats in the top left aren’t very visible and aren’t visually exciting (the same goes for the text near the middle). The menu in the middle gives a look of simplicity and looks a lot cleaner but clashes with the rest of the HUD elements already on display. Going over the resume, start, controls and exit sections will highlight them which helps give feedback which button you’re on but it’s hard to tell in the first place that they are buttons you can scroll over.

(Controls image)

Going over the controls section will bring up this image, which is highly pixelated and not easy to read due to the choice of font. It explains the basic controls of the game but in a very typical and non-engaging fashion since players don’t get to learn through a tutorial.

During Combat

(First Stage)

In game the HUD elements show player health, stamina (for special power attacks, blocking and other actions) as well as an icon representing your character and weapon. When you get hurt, the health meter will go down, same as the stamina bar when using abilities which are perfectly fine in representing information to the player. The other stats that were on display in the start menu are gone now however. These only show up during the pause menu which actually helps avoid showing clutter during battles. Between showing the stats in battle and during the pause menu, my team actually made the better choice since you didn’t need to know what stats you had upgraded during battle.

When taking damage, your character would make noises when being hurt which helped give the player feedback. However when attacking enemies there was no substantial noise to confirm you were hitting the enemy. It was a simple “swish” sound that occurred whenever you attacked, giving little to no feedback. The only feedback that was displayed was that the enemies would flash a bit whenever hit. The lack of sound on impact hurt the feedback players would get in whether or not they hit an enemy.

(Left: Red screen indicating dangerously low health – Right: Player game over screen)

Further damage taken would also begin to show a red shader effect to represent low health. This was definitely one of the better choices to represent feedback during the game as it clearly showed a sign of danger to inform the player they were close to death. We would also display a message saying that you lost gold and that you needed to press a certain button to respawn. Although it displayed the information we needed, it obviously wasn’t very engaging and obvious to the player. There was no real time update showing your gold going down and we didn’t even show a proper gameover screen or at least a proper respawn screen. Players would just wonder why they were suddenly placed in the middle of the sky.

The image displayed above showed a quest marker which took you to the next area when you defeated all enemies. This was fairly animated as it bobbed up and down. The design of it was fairly effective in comparison to other elements. Although it did not specifically state it would take you to another level, it still drew players in due to its appearance and animation.

Items and Quests

(Side Quest area and shopkeeper on right)

                Our game featured a blacksmith character who allowed you to purchase items and also gave you quests in which you could earn gold. There was an arrow located above the head of the player that pointed you first to the Blacksmith so at least we were telling the players where to go. It would also update to point to enemies you had to defeat should you accept a quest. During a quest, if you tried to accept another quest, the game would inform you should complete your other quest first. This was a good HCI feature to add considering all the other ones the game was missing.

(Blacksmith menu : Quests on left – Upgrades on Right)

                In the image above, in order to even talk to the Blacksmith, you had to attack him. This was an obvious flaw since we didn’t highlight a specific button for interaction with NPCs, nor did we state that anywhere else in the game. We pretty much had to assume people would be confused and eventually just attack the Blacksmith which would finally open the menu.

                From there we at least provided two different menus that the players could choose from to purchase upgrades or do quests for rewards. We displayed the upgrade cost on the right side and it worked on a formula that increased every time to purchased a new upgrade. This system is never explained in game but players can at least see the upgrade cost increase. It worked but it wasn’t the best design for upgrades. We never showed what your upgrade levels were in this menu. You could only see your upgrade levels in the top left corner where the stats are. When you purchased upgrades, players got feedback by the either the sound of gold being dropped (meaning a purchase was made) or the Blacksmith would tell you he couldn’t sell you the upgrade. Although we had a audio component in feedback, we lacked the visual component which hindered the experience a bit,

(The health bar extending over which showed you had more health but looked really ugly)

                Some upgrades did have visual aspects however. The sword when upgraded would turn a different color, up to four times. The health bar would extend and so would the stamina bar if you upgraded those. Unfortunately that also made the HUD look worse since the bars extended over some aspects of the HUD. The speed upgrade didn’t show any visual signs like the others and you could only notice it by watching how fast your character moved.

Judging the Goal of the game

                The last problem we had in terms of communicating the end goal of the game of UGC was that we didn’t. We never showed any proper feedback that players were participating in a gladiator tournament and would be facing harder and harder opponents until they reached the final boss. We just spawned new enemies whenever players entered the arena again. We didn’t even have an indicator saying they had reached a new level. We should have at least had some simple text or image representing that as we had never really shown the progress of players. This was a simple but easy thing we should have implemented but we couldn’t due to time constraints.

Final Thoughts

                Looking back at UGC, we have a fair number of elements that did communicate a lot of information to the player. The amount of information displayed for the side quests and upgrades was more than I remember. The lack of some in game combat visuals and audio as well as the lack of showing the end goal of the game were the worst offences in terms of player feedback however. Overall UGC gave a decent amount of feedback for players but was clearly lacking in a lot of key areas.

GDW is over - Red Dawn

It’s been quite some time since I last updated this blog but it hasn’t been without good reason. My program always keeps me busy, especially near the end of the semester when crunch time is highest in order to finish our GDW game. But now its finally over, my 3^rd year and final GDW game ever is complete. I may have briefly mentioned what it was in a previous post but that was so long ago I wouldn’t even have remembered writing it. 

All sorts of events happened before the final submission to UOIT such as LevelUp where students from U of T, OCAD, UOIT and others showed off their games to the public. In fact our game even got an honorable mention as well!  There was our own UOIT event called Gamecon where the game devs from all years would show off the almost final versions of our games and capstone projects. I'll cover both of these in a later blog but for now lets get to what my team's game is.

Download LINK

Apparently there was a movie  called Reddawn that came out before we named our game. We had no idea what it was. Moving on from that though, our game is a ship to ship combat game with a heavy emphasis on multiplayer and looks like Windwaker. Players will control one ship, sailing in a battleground with several other ships and your objective is to destroy them. There are multiple different modes to choose from such as death match, timed matches and last man standing matches as well as multiple different levels to select.

Controls

The most important part of the game is how do you control your ship? You can increase your speed or decrease your speed which increase your movement but inversely decrease your turn rate. The faster you go, the harder it is to turn. You also don’t have to hold a button to increase your speed. Once you are at a certain speed it won’t change unless you to choose to increase or decrease.

We wanted to make it feel like a ship, so that meant you weren’t just shooting some machine gun in whatever direction you were pointed. Since ships have stationary placement for cannons on the sides of the ships, that’s how you shoot. You control the left and right sides of your ship with the Xbox Controller triggers. Left trigger would fire cannons on the left side and right cannons would fire cannons on the right side. The same applies for flamethrowers located on the sides of your ship.

You also have access to a harpoon at the front of the ship that fires forward. If it connects with another ship, the two of you will be dragged towards each other, allowing you to do some weird physics defying drifts to aim your cannons in cool and interesting ways. Its used as a chasing tool for those pesky ships that try and run away from you. You also have access to mines that deploy from the rear of the ship. They do massive amounts of damage and you can leave up to 8 on the field at any time.

How to win

When you select a new game it brings up a menu that allows you to customize the match in any way you see fit. The main types of modes are deathmatch, life match (last man standing) and timed match. You can also choose how many AI you want to fight against, if it’s a team battle and also what level you want to go to.

For the modes, deathmatch is the typical get X number of kills to win. Last man standing is where you have a pool of lives which run out as you get killed. If you lose too many lives you’re out of the match. Timed match runs a set time and every kill you get gains you a point while every death nets a loss ofa point. So 7 kills, 5 deaths = 2+ points.

When a match ends your stats will be displayed, which are your kills, deaths, and team. A good way to compare yourself to the competition.

Multiplayer

I said the game was multiplayer so that means playing with your friends. This GDW year we had the opportunity to learn networking in our games and so that applied perfectly with the concept for ours. You can connect on local LAN to other computers who have the game (unfortunately we didn’t learn how to connect across the internet though). All you have to do is have someone set up a Red Dawn server, have people connect to that person’s IP address and “Board the Ship” to establish connection.

Due to time constraints its not as user friendly as it should be but it still works quite well once you’re in. You can setup a match just like in singleplayer mode for everyone else in the lobby if you’re the first one to connect. You can chat before match and once everyone presses the ready up button, the match will start. It will even keep track of your wins and losses when you return back to the multiplayer lobby.

DOWNLOAD

That’s a basic overview of our game. I have made it available for download for anyone that would like to try it. There is a download link above and right here.

Download Link

I shall probably write another post for Post-Mortem of the game and also an overview of the Year and the UOIT event GAMECON where all of the GDW games are displayed.

MIGs 2012: Creating Efficient Tools

Amongst the presentations at MIGs, one of them was so simple and yet so well done that it had my attention the entire time. This presentation was"the Art of Creating Efficient Tools" presented by David Lightbown who had just recently joined Ubisoft Montreal to work on the exact topic he was covering. The presentation was coveyed not with heavy text, but with simple images and through enthusiastic presentation. You were paying attention to him the whole time and the presentation in the background helped to demonstrate his points nearly flawlessly. He even had volunteers to come up and gave a free copy of Assassin's Creed III afterwards. No other presentation I saw had volunteers at all.

Now the topic doesn't sound all that interesting, but honestly it's the core of usability. It's the core of ease of access for anything and everything relating to the creation of pretty much anything that requires software or even hardware. The point of this presentation was to be aware of how important making tools that are easy to use will help the entire process of creating something like a game. He pointed out an interesting system that we use in our everyday life when using tools.

Look -> Act -> Think

So what happens is we look at the tool and then we begin to act. But then we think about if we are doing the right thing, or wondering how I am supposed to do a particular task using this tool. It could be thinking about something as simple as finding out where the print button is or something like that. What is happening with complicated software that when we are having to look and think too much, we do not act. That means we do not get the task we want to accomplish with the software completed. What we want to happen is to maximize the amount of acting. Well the only way we accomplish this is reducing the thinking and looking time!

It's such a simple looking process and I have never thought about it because it just comes naturally. But it makes a whole lot of sense. From my personal experience, I have hard coded values to place a whole bunch of objects in a world. Now that works, I can get the objects where I want them to be but I have to think more to make sure I am adding the right parameters for each object, if it has health or what not. Instead of doing that I could use a PREFAB. A PREFAB would be an object that contains most or all of the necessary information to place an object where I want. So instead of 10 lines of hard coding per object, I reduce it to 1 line of code using this PREFAB, it makes it a whole lot faster. More acting.

The User Experience

The user experience is key. We want users to be able to have a streamlined experience that maximizes acting and reduces looking and thinking. Well he gave a few tips on how to best maximize acting.

Form and color was the first thing mentioned. Form and color are so simple and yet they can represent so much. A simple circle combined with a color provides a lot of information for us. For example street lights have red and green circles for stop and go. They are simple shapes with colors and yet they tell us information we need to make an action almost instantly. A good point was brought across that you should not only use colors though. There is still a large portion of color blind people and a green and red hue circle nect to each other would still be confusing for them. A combination of a different shape for each along with the different color will make it adaptable for more than one kind of user.

Which object would be more likely to represent STOP?

This shape idea ties into the next point which is interaction design. With the Mental model and conceptual model. These two models are essentially "How do we think?" vs "What it actually does". Essentially its like comparing two objects to be similar, so you say something like "Its as easy to learn as riding a bike". Typically learning to ride a bike is easy for most people so the message is essentially that the material will be easy to learn. This ties into how shapes have certain meanings. A circle is a softer shape and we think more along the lines of smooth, nicer objects. Meanwhile a hard edged square we might associate as more aggressive.

In the Real World

After pointing our some tips on how useful shapes and thinking are, he began to point out some very useful real world examples. So let's say we need to make a tool to help users build levels for a game. Well there is something known as the 80 vs 20 model (I THINK). Basically what you need to do is focus on satisfying the 80% of people using the tool because it will be near impossible to satisfy the other 20%. For example the earlier example of "Easy as riding a bike" would apply to 4 out of 5 people, except the 5th person who had great difficulty learning how to ride a bike. The analogy doesn't apply to that person, and the usability you provided in your tools won't either.

If there are 4 out of 5 circles that can use your tool efficiently already, forget about the 5th circle

Another point is that tools should be streamlined to do certain tasks. Don't make it a jack of all trades tool that does everything. Making it do everything makes the interface of the tool even larger and more cluttered which makes it more difficult to navigate and perform the tasks you need. If you are just making a level loader tool you don't have to give it the option to be able to create models either. It only complicates things even more.

This leads to the next point which was the statement that intermediate users make up the bulk of users for the tool. There are some experts of course but it's a small majority. There are also beginners who will be learning to use the tool. Now the more complicated the tool the harder it is to learn. Make it less complicated and there will be less beginners and more intermediates who know how to use the tool fairly well. You cannot expect all users to become experts, especially if its a tool that's very complicated. Even if they may know all the shortcuts that makes them very efficient, it won't apply to all users and the extra features will slow most users down. Overall the workflow will decrease due to the larger amount of users slowing down versus the expert fast user.

So how does this overall affect our workflow? Well like we stated earlier, more acting means more productivity. The easier we make the tool the more workflow we get and the more people we have working on making content instead of wasting time thinking on how they need to solve a silly problem. We can same hundreds, thousands of work hours by simple usability.

Do these apply for Game Design and Game Engines?

Well actually yes they do.. Game engines is the easiest to identify that this lesson helps because a Game Engine is in fact a tool. It's a tool that helps to make the game in a more user friendly way. The Unreal Development Kit is a game engine that tries to streamline the process for even non programmers. Ogre SDK provides plenty of functionality that we wouldn't want a weaker programmer having to waste his time figuring out. Point is that yes these lessons apply especially for Game Engines.

What about Game Design? This is much trickier to answer. Usability is a very important concept in games. No one wants a game that is extremely difficult to control and is a complete nightmare to figure out where to go. Usability and functionality attracts players because if they are able to do cool things with button presses rather than having to do crazy complex combinations to accomplish a lesser task, then there will be more of an audience. Just look at games that have simplified controls. A simpler fighting game such as Smash Bros has a lot more sales and more of an audience than a fighting game with crazy controls such as Blazblue or other complex combo fighting games. Even the shapes idea can lead into character design which reflects the game designer and etc.

Smash Bros used simplified controls to great success

The only way to debate this topic is the fact that some games actually want controls to be harder because thats just how the gameplay works. While some games go for simplfied controls, others want more complex interfaces. Take Lord of the Rings Battle for Middle Earth, an RTS that simplified the control scheme while looking at something like Supreme Commander, on opposite ends of functionality. And yet they both sold relatively on the same level anyways. That goes to show functionality doesn't always lead to better games but neither do complex ones either. So the conclusion for game design is that really, is that efficiency in being able to perform tasks in a game doesn't mean a better game. Unless its a level building game, then you want to be able to build levels easily like Portal 2 Level Editor.

Conclusion

Anyways going back to the actual presentation, it was great. It was simple, it was very well done and got the point across. Though I might have known most of this information before, the presentation really helped reinforce it my mind now. I believe it's stuck there permanently. What to take away from this presentation is that creating efficient tools reduces thinking time, increases work productivity which means more time to make stuff!

Game Engines in Review

The semester is nearly over and the last class of Game Engines just passed on Monday. It was a class that was difficult but also very interesting and quite fair. The topics that were discussed were quite broad but were all very interesting. All the lessons from in class to the tutorial sessions were all useful and both professor and TA were extremely helpful, easy to listen to and really great overall.

As for the work to be submitted in the class, this course used Hogue's infamous/famous XP system where doing homework questions would grant points. Get enough points and you write the midterm and eventually enough will get you to the final exam and even grant bonus points if you go high enough. The questions themselves were all quite tough and took a significant amount of time to complete them. Nevertheless some of them were still quite fun. I particularly enjoyed the AI question involving flocking, seeking, fleeing, etc. Though I cannot program very advanced AI yet, just simply seeing the AI in action is very fun to watch.

I recall many of the lessons that were taught in class and they were all useful though some were review since they had been partially taught the semester before. My only vice with the course is that, according to the text book that we'd be assigned to read, this course should be split up into 3 which means the material we got for the lectures is very condensed and therefore not as focused as it could be. Though I admit it sounds very difficult to come up with a proper selection of lessons for a course as broad sounding as Game Engines. That's pretty much computer animation, computer graphics, programming and a whole bunch of other courses put in a nutshell for one more course. That's definitely not easy to plan out.

One particularly interesting thing is that, in a previous post I talked about how my group was planning on using component systems. Well it came to our professor's attention that people were discussing component systems and did one last talk on it the day before this post. Our Professor had actually done a paper on component systems so it was clear he knew what he was talking about. He reinforced to us to learn Object Oriented Programming more (the type of programming we were taught since first year) but opened our eyes to more about the component system. There is still a lot we haven't fully implemented and made some mistakes in our component system that he helped clarify.

If I were offered to take a course under this combination of TA and Professor again, I most certainly would. The course was a pleasure to learn and the teaching particularly clicked with my style of learning so it just helped reinforce learning it even more. Anyways this was just a short post this time since I can't really think of much else to say. Overall Game engines was great fun but hard work.

MIGS 2012 : Directing Visual Design in Games

It's been a while since I did a post of any sort due to GDW deadlines and what not. Now that it's finally over I can fill in some blogs I wanted to do a while back. First off I mentioned during my MIGs experience that I wanted to talk about one of the talks, which was the Art Direction for Rage.

It went over the following note points for the development of RAGE over the course of the hour long talk

• Assessing the Visual state of the game
• Assesing the limitations of technology
• Priorities and Targets
• Wishlist

First off the Director of Art for RAGE Stephan Martieniere talked about how he first joined the project. He spoke of how he had to adapt and make use of assets that were already in existence when he came in. By that time the RAGE development team had a lot of landscape already and a good skybox. However Stephan Martieniere had to take what already existed and not only improve it, but to find ways to fully implement it and work with the gameplay of RAGE. I will go over some of the notable points he talked about that really help show how important visual design is to the overall feel, look and even the gameplay of the game.

SkyBox

The first thing he improved was the skybox of the world. It is an essential look to the asthetic design of the game as he explained. Why is that? Well the skybox in a world like RAGE, where you can see it whenever you're out exploring the world makes it a very important asset to get right. You will be seeing it time and time again and it has to compliment the scenery and not be an eyesore. It needs to be pretty to look at and draw you into the beauty or ugliness of the world. Its more important than you would think at first glance.

Breaking the World

When he spoke of this he meant breaking the world that already existed. As I mentioned earlier he came into the project a bit late, when some assets were already in place. In this case the landscape of an entire world was already in place. What the team had to do was take this existing land and punch new areas that could be filled with content. But it wasn't just a simple, open up a new place and hope it works out. They had to actually plan out how the world would work. The places that would now be created needed to be logical to the geology of the world and needed to be located in a place relative to how it would reflect in the lore of the world. Breaking up this new places took a land that was already defined and made it seem even larger than it already was.

Avoiding Containment

When he spoke of containment he spoke of the presence of the high valleys and cliffs that cluttered the world of RAGE. He specifically got into how the large valleys would serve as a way to make the players feel more constricted and feel like they are in a smaller world. In that sense it meant making far away landscapes and more of the skybox visible. It allowed for a sense of change and direction as there was more to see in the distance. You could see landmarks or cities and have a good idea where to go. It would present itself to gameplay as well for the exploration and discovery of the world since you have more to see.

Establishing Narrative logic and Visual Coherence

Next he spoke about what I have mentioned a few times earlier in this blog and that the environment is about the characters as much as it about the story. The Environment needs to be a fleshed out world, a place that characters inhabit and therefore leads to the story. The gameplay needs to take into effect the characters and monsters you might face in the world, the cities they live in and how they might behave. Incorporating all of this together is visual coherence. For example you would put a character in a an environment that suits them, that they belong in. 

A high tech city gave way to bandits with high tech looking weapons and armor. This affected their visual asthetic for sure. This also affected gameplay as well as it might give access to new equipment as well. The characters would be designed to match and compliment the palette to the city so that they would not only fit but be visually pleasing as well.

He also briefly spoke about ways to enrich the story in subtle ways. Billboards in cities, signs, logos, landmarks were all used in RAGE's cities. Each of these tell their own story, some lore in the game that would help flesh out the world. You would see some billboards advertising products that fit in the world of RAGE, movie posters that would show what kind of movies they watched before the apocalypse, etc. These would help flesh out the world and make it it's own and though we might not always pay attention to these extra tidbits, they really do help make the world feel believable and engrossing.

Extra Tidbits

I can't really put the rest of what he said into one larger catagory but I'd still like to talk about them.

One thing he mentioned was that the design of the environemnt was all about the information that would be revealed to the players. This has an obvious gameplay aspect to it as it helps show and guide players where they might need to go, what to do, or just engrossing the player in the world itself. Environments should be composed in a manner not to overwhelm the player but to provide enough information and give them a good idea where to go and still have the beauty of the environment. Again this is visual coherencing and mixing game design with the art design.

Another neat thing he mentioned  was that when making environments he stated that it helped create the NPCs that inhabited them. Like was mentioned earlier, the NPCs are supposed to be able to inhabit the location they are at, or at least the world. Making a specific kind of environment lead to how inhabitants might dress, what kind of equipment they might possess and how they might act. This again leads to their AI, new weapons, new story and a lot more game design elements.

Conclusion

Stephan Martiniere had thought he had an hour and a half but only had an hour so he didn't have time to speak about everything he wanted to. Nevertheless I learned a lot and it helped reinforce in my mind that game design and art design really shouldn't be seperate at all. For higher level games they should be fully integrated together if a believable world is to be created. Even if the art design leads to level design, the gameplay needs to take place in those areas which leads to influencing how gameplay is. The large overworld of RAGE meant there would be a lot of driving and exploring which was an entirely new gameplay feature different than simple shooting.

It makes me want to discuss more about the visual design of the environments if I wish to make a fully fleshed out world for a game someday. This honestly sounds like the key to making a great environment to fit a great game.

Component Systems

Over the course of this semester, a topic has been brought up between some groups regarding different ways to approach engine design. We wanted to come up with a way that we could make our engine flexible and provided a lot of functionality. One of the subjects of the topic went over something called a "Component" based engine. Before I go into what this system is I want to explain what I did last year for my 2nd year game.

UGC: 80 AD - Inheritance

In the code for our group's game from the last year, it used inheritance, a lot of inheritance. There would be a class called "Character" which had subcatagories of "Player", "Enemy", and further subclasses such as "EnemyFinalBoss", "EnemyLion" and such. The cool thing about this is that I could easily make put all of my Character objects into a list and update them all. All of them would have a "virtual" update function that could be inherited and overwritten so that specific characters could update to different parameters. For example the player character could update to increase his HP over time, while the EnemyLion would instead update his stamina or something of the sort.

If I wanted to access specific functions, I wouldn't be able to with the EnemyLion normally since he would be created as a "Character" class and insert into a "CharacterList". However if I really needed to I could "cast" it which forces my EnemyLion into an actual EnemyLion class temporarily so that I am allowed to access it's functions. Normally I would have only been able to access the character class.

Character class needs to pass in the four values on the right, but not every class under it has use for these

Now the problem with this entire structure while it sounds like it works well is that it was cluttered, unorganised and I had functionality and attributes in some classes that never even used it. For example, my Character class had a whole bunch of integers to represent health, damage, speed, etc, and some of the classes under it didn't always use them all. I had "Damage1 and Damage2" that were only used by the Player character but the Lion had to inherit both of these even though he only needed "Damage1". This happened for quite a few classes in fact since I needed to update these parameters all the time and check for them. This made the entire system clunkier than it needed to be.

Introducing Components

Now that I have covered the flaws of my engine last year lets talk about this "Component" System. Components basically mean that they are attachments to a base object class. So for example I create an object, it essentially has nothing inside of it. What I do to make it have functionality is attach "Components" to it. These components can literally be almost anything, they can represent a model, rigid body, health, damage, etc. This means almost any object can be anything and do anything, it makes for an extremely flexible system that allows a lot more freedom for the objects to perform actions.

For example I could attach a health component and damage component to the player but for an NPC that can't attack I will only attach the health component, or I might not even attach that since I probably won't need to hurt him. He would simply have his model and rigid body and perhaps some other component to trigger an event to talk with him. The skies are limitless with what you can do with these components.

With components we can attach any component to any other component. We can also make certain components interact with each other such as health to AI.

There are a lot more complex aspects of the component system that we haven't touched yet or learned but these are the basics of the system. We used a combination of inheritance and components, making a pseudo component system. We add a component list to each object. Each of these components is essentially a really empty class template that will be inherited from by the Health Component, attack component, etc. We simply override it to have the functionality we need and if we need to access specific functions, we simply cast it to the appropriate component type (i.e. Health component).

Final Thoughts

I don't want to reveal everything about our component system but that's basically a simple gist of how a real component system might work, or at least a pseudo component system. We hope to learn more about it because so far the results of the component system have been infinitely more flexible to use than with the old inheritance system. Essentially we can make any object do anything. I can make a key turn into an enemy and attack people, make it have an inventory and give it some gold to hold onto.

MIGs 2012 - Trip Experience

Just this week from November 12 to 15th, the Montreal Internation Game Summit took place. Developers from all over the world ranging from programmers, game designers, artists, audio technicians and even the CEOs and executives of companies came to meet over the course of these days. Some even gave very useful presentations about their field of study that would unveil new technology and techniques to either market their own company or help audience members for their feature endeavors.

The Trip Begins

A trip for UOIT students was formed and I was among the students taking the trip to Montreal, leaving on the 12th and leaving home the night of the 14th. We spent only two nights there, being at the conference for day 13 and 14 which were the most important days anyways. We took the 6 hour long bus ride to reach our hotel on the 12th and pretty much spent that day exploring Montreal. The tickets we had purchased did not include the 12th or 15th in it's admission so we would not have been able to get into MIGs for that day.

The first night concluded and the first real day of MIGs began. We spent a 20 minute walk towards the hotel in which it took place (though we got lost the first day) and came late to the first presentation. The first presentation came from Tim Sweeny, the CEO of Epic games in a talk about Challenges of the Next Generation Consoles.

Highlights included a speech from CEO of Epic Games Tim Sweeney

On a side note I want to state that there are lot of important game industries people here at MIGs (though perhaps not as much as there would be at GDC). Tim Sweeny is the CEO of Epic Games, developpers of Gears of War and Unreal and they are a very powerful company for both making games and developping tools for making games. Other speakers included Peter Molyneux, formerly with Lion Head Studios and created Fable, Black and White and other games.

Going back to how the day went, I missed the entire first lecture since I had to help my friend Mr. Freeman who did a problem with tickets. I then split off to go to the lectures I wanted to look at. I was very curious about a lot of the art related topics interestingly enough. Though I pretty much mostly focus on programming in Game Dev, I am still extremely interested in art, perhaps more so than programming.

A quick note about the presentations is that every time slot is an hour. Also there are always 5 other presentations going on at the same time so that means I missed some other presentations I wanted to go to due to conflicting time slots.

To get an idea of the presentations and topics covered, look here! 

The Presentations Begin - Day 1

The first lecture I went to was "Drawing Inspiration" Bringing Characters and Worlds to Life" by Samantha Youssef. She works at Disney now and went to Sheraton College in the art program, being the only one from her year to be hired by Disney when she graduated. Her talk was incredibly informative regarding art and it was very useful as it opened my eyes to some new techniques she talked about (and she was pretty). I took notes as well and I plan to do a personal write up about this topic and some of the other topics later.

Then came lunch break where I explored the rest of the show floor, but before that I will go over the presentations I went to first.

Guild Wars 2 artwork from Lead artist Kekai Kotaki (now at Bungie)

Amongst the other presentations the first day included Kekai Kotaki, the lead artist who worked on Guild Wars 2 and worked on Guild Wars 1. Unfortunately his presentation got shafted as he was supposed to be provided a tablet so he could draw live for us and teach us techniques. Instead he did not get one and was forced to simply go over his existing work which was still interesting but kind of dry since he was not prepared for this event.

I then went to attend a programming presentation, one on GPGPUs which should interesting since it regarded the use of GPUs for more uses but the delivery was very dry and kind of boring so I almost fell asleep unfortunately. I do not remember much from that presentation and if I had been less tired at that time I would have absorbed more information.

Square Enix featured their new Glacier 2 Engine

The most interesting presentation followed, a look into Square Enix's Glacier 2 engine. I have already made a write up of my impressions of the engine here. To sum up that experience, seeing a AAA game engine close up and learn more intricate details and its features is awesome.

I pretty much ended my day there even though there was one more presentation that day since I was probably going to fall asleep in the next presentation

The Presentations Begin - Day 2

The first presentation I went to was the earliest slot, with a keynote from Peter Molyneux. We got in a little late once again and he talked about "Experience and Innovation". It was a little strange though since he was there via Skype call instead of in purpose. Apparently his new game "Curiosity" became so popular it had a server crash and he needed to stay there. He pretty much talked about Curiosity, how it works and a look into the office where the studio works.

I went to a presentation on audio afterwards which I unfortunately fell asleep in. Not because the presentation was boring, in fact it looked really interesting, but I was kept on too late the night before and got very little sleep. Sadface.

RAGE - Featured in the Art Direction presentation

Following that I went to a talk on Creating and Art Direction Visually Successful Games by Stephan Martiniere, who was lead art director for RAGE. It was extremely informative and in fact related highly to game design surprisingly. A few key points about it for now is that he was designing environments the NPCs themselves could inhabit and the environments would reflect in their outfits. I.E. a tech city would have people in more high tech looking outfits. It was a mesh of visual design being coherent to the world of the game and being immersive. The talk was so interesting that I will probably have a write up on that later on.

Details regarding Battlefield 3 Cutscenes and use of Facial motion capture were presented

Afterwards I went to a presentation regarding Voice Acting/Performance Capture, featuring Battlefield 3. The presenter Tom Keegan talked about the use of motion capture needing a lot more physicality now as the actors need to be able to act naturally and actually envelop the character for more natural movement. So an actor playing a soldier would need to hold a rifle and move around like they were doing it. He even talked about having all actors in at once to do a scene versus voice actors just going on different days and doing their recordings separately. It was an eye opener into some of the techniques they use for MO-Cap acting.

One of the most interesting talks of the day came from David Lightbrown, recently hired by Ubisoft Montreal for designing user interfaces. The talk was about "The Art of Creating Efficient Tools" and was actually VERY interesting and very well done. The presentation itself was the most engaging out of all the of them, he actually used the audience, he was funny, his presentation wasn't heavy on text and used simple shapes to engage the audience. This is one of the talks I am going to write about in the future but essentially it was all about developer tools that are so well done that they will reduce the work time to learn them and just use them to create content.

The final presentation came from a combination of a lot of speakers talking about how they think the future of gaming will come about. Some were more serious speeches, while others were more light hearted. It was interesting to see all these people talk on stage within an hour and everyone had a different opinion and topic they coverered. With that, the MIGs trip ended and we took the bus home!

Extras, Extras!

In my lunch break time and time I didn't spend in the presentations, I looked around the rest of the show floor. There were several booths for many companies, from Game Development studios, to Colleges and programs that specialized in teaching Game Development. Amongst them included Eidos (Deus Ex: Machina - Human Revolution), Ubisoft Montreal (Assassin's Creed III), Bioware (Mass Effect 3), and several others I can't remember. At these booths you could meet with the representatives of those studios and get contacts for networking.

Ubisoft Booth

There was also several others areas such as a demo booth which developers of any sort (including indie) could get space to display their new games. Another area was the art gallery featuring art submitted by people for a small fee to be displayed and voted on. The winner would get a prize of some sort (I have no idea what that prize could have been). There were two catagories, one for pictures which included 2D concept art, 3D models, illustrations and another catagory for video. The video could be trailers, or some artsy looking cutscene. Some people even submitted just a piece of music they had composed themselves.

The Sketch Duel area - Participants are focusing intensely on making their art

To top off this area, every now and then they would have a sketch duel. The first day featured professionals going head to head where they would have 15 minutes to draw something based on a randomly generated template. It could be something like "Draw a samurai dancing beside a house", which they would have to agree on. After the 15 minutes the audience would vote on the favourite. The same rules applied then next day when non professionals were allowed to enter and I watched the entire thing to see their technique. It was mostly speed painting and was another good motivator to learning more art.

Unfortunately I forgot to take many pictures and I should have gotten the art gallery...

Final Notes

So that was pretty much the MIGs trip in a nutshell. It was a really fun and interesting experience, something I would love to do again. Next year I plan to have my portfolio all ready, business cards ready and improve my art experience so I can have a chance at winning the Art Gallery. The presentations were definetely interestin and I learned a lot from them, so I will definetely check them out again.

Stay tuned for more posts for MIGs. I will probably have the following topics covered in more details in the future.

• "Drawing Inspiration" Bringing Characters and Worlds to Life"
• "Creating and Art Directing Visually Successful Games"
• "Art of Creating Efficient Tools"