Tuesday, December 4, 2012

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.