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"

MIGs - Look into the Glacier 2 Engine

Just this past monday to thursday, the Montreal International Game Summit took place and Game Devs from all years decided to make the trip down. I will have an overview post of how MIGs went but for this particular post (since it's for Game Engines) I want to talk about one of presentations that took place that was particularly interesting.

Hitman Absolution is the first game released to use the new Glacier 2 Engine

Square Enix has several engines under their belt but the most recently created is the Glacier 2 engine.  Glacier 2 is not for license for other studios unlike a game engine like Unreal 3. This engine is only for Square Enix projects and doesn't include the Square Enix projects in Japan for Final Fantasy and other games. The engine currently only has no games currently released under it's belt but it will soon in the form of Hitman Absolution. Other projects are using it as well but I can't quite remember them all.

Why build a new engine?

This is one of the questions the speaker, Kasper Engelsoft addressed. The reason for having a new engine is of course to compete with advancing hardware and methods of rendering, algorithms and structure to put it in a broad sense. He stated that it also had several other important advantages as well. 

Kane & Lynch apparently used some messy code in order to get features the dev team wanted

One was to target previously problems with the first Glacier. The first Glacier appeared to have "hacks" where the programmers would just modify the code in messy, unstructured ways in order to make things work. We saw some sample code from a few games such as Kane & Lynch that proved this messiness. Glacier 2 is supposed to rectify this problem and include features that are already built in so that these sorts of hacks don't have to be done.

Glacier 2 hopes to rectify problems in the past Glacier Engine

Another thought that came to mind was why not just use another engine such as Unreal? Well this goes along with the points stated above. Not every engine has all the features a game needs or isn't tailored to do certain things that are crucial for a company's needs. Unreal might lack certain things that most games Square Enix is going to need, so that means having their own new engine will tailor it to exactly what they need.

Features!

With those questions out of the way, more content of what the new engine could do came to light. One of the most important parts of using an engine is that if it provides the right tools, it will increase the productivity of those using the engine dramatically.

One of the features the engine had was editing on the fly with the game rendered in a seperate window. Other engines do have this feature though such as Unreal and one audience member did not hesitate to point this out. They must have missed the point the engine is specifically tailored for their needs. Anyways I sidetracked but this feature is of course very useful but the best is when modifying things of the engine on the outside, it actually changed the source code at the same time as well. That means anything added in the visual editor could directly make changes to the source code and make things even faster since you wouldn't have to redefine things inside the source code. This was actually one of the highlight features the engine possessed.

Hitman Absolution uses Glacier 2 to render many NPCs with strong AI

I am going to be honest, from this point I can't say quite as much as I hadn't had much sleep the night before so I didn't hear everything that was said about the engine. We got a look into their code structure which looked very organised and clear in comparison to the code shown from the previous engine. We also got a look into their particle system as well as real time rendering of 500 completely dynamic NPCs with advanced AI. This was a feature brought into Hitman Absolution since Hitman was the one being demo'd at this time.

Conclusion

Unfortunately I wish had more to say and took notes but it was still a very interesting presentation. It was exciting to see the inner workings of a AAA engine first hand and understand  the reasons behind its creation as well. It provides great motivation to make our own engines seeing the capability these engines provide.

Havok - Friend or Foe? ~ Learning Havok

Havok is one of the tools we were provided with this year in order to create our GDW games. One should be excited at the prospect of having a chance to use a top quality, triple A engine. However once you get into it, you realize it won't be as easy as it seems to get Havok fully running and doing what you want it to do. Not to mention we aren't getting the real version of Havok, rather we are getting a free student version that doesn't have all the tools that we might be hoping for. One should think that simply having Havok would be only advantageous and it should be but when it becomes a requirement to have and it's not so straight forward to do, it begins to look more like foe then friend.

First off let's just see what Havok provides.

• Realistic Physics simulation, velocity, acceleration and forces
• Collision detection and collision response with objects of any shape and size
• Animation and skeletal animation
• Creation of it's own objects to be rendered
• Compatability with Maya for 3D modelling
• Sensors, events and callbacks
• Vehicle dynamics
• Rag dolls
• Constraints such as rope attachment
• And many others...

Now that's a lot of features it has and that means the engine has a ton of potential to do amazing things. The problem is that the documentation provided is while very long (1000+ pages) it is not very easy to understand and not very helpful. Many have agreed that the documentation Havok provides to learn it's tools is anything but straight forward. There are also so many things you have to learn about the whole system, that even implementing one of the tasks listed above is anything but easy. In order to correctly implement something, you either have to read through a ton of documentation and might still miss some things, or you're told by someone else.

The documentation isn't exactly straight forward even though it looks like it would

Sooooooo Complicated!

The free version of Havok did not really provide any tutorials to help and any online searching for such help  is extremely difficult. For example, I wanted to figure out how I would get collision response in our game so that when a player attacked an enemy, the enemy might lose health. First of all I looked into the Havok documentation for collision detection. It listed for me, at least a half a dozen things and didn't really fully explain which I should be using, nor how to implement them. So after searching that for some time, I gave up due to how difficult it was to comprehend.

They don't provide proper examples of how to use these for collision detection

I then went to search online for any help in how I might get collision detection in Havok. Again I was frustrated by the lack of any help online due to the wording I needed to use, or just otherwise lack of resources. Havok by itself does collision detection between it's "rigid bodies" but I needed to know how to access when they would collide. Havok would not provide for me a decent answer even with looking for all these resources. Nor do I remember seeing any obvious tutorials that would help show me.

But Demo Samples are useful

Havok demos are the main method of learning Havok

Thankfully not all hope was lost for the samples they provided were actually very helpful. These were pretty much the only way I learned how to use Havok. I finally managed to find out how I would implement my collision response after much searching through the demo samples. They provided source code in these samples so I was able to extract it, figure out how to use it and put it in my own engine. Thankfully this process itself wasn't too difficult as it mostly involved using inheritance and overriding certain functions. It's not that obvious at first though and takes a bit of time to figure out. You also have to take the source code from these projects and import it into your own projects.

The demos finally helped me learn how to use collisions. I turn the objects to blue when they hit.

Through this method I managed to figure out several useful things for our game such as collision detection, collision filtering, attaching rigid bodies to a set path, and a few others. However I wish there was an easier way to learn these things through tutorials or more resources from Havok. From what I've learned it seems like they simply provide the documentation for free students. But for those that pay the full price for Havok they get all features of Havok along with tech support to help teach people. That's the benefit they get while we are stuck with having to figure out everything with Havok by ourselves. Granted its a good learning experience but it makes things dreadfully slow to learn.

Also Havok Demos are very fun, particularly the vehicle demos

The only saving grace was the samples which were very helpful indeed. I know this blog hasn't been about actually learning much today and mostly more of a rant but this just highlights of what to expect if you ever get Havok. Be excited by the potential the system has but be prepared to have to learn a lot and use the samples a ton in order to fully use it.