Video Games: Why?

/

Chances are, if you are reading this, you like or even love video games, or at the very least, you can appreciate them. If you accidentally found this post by mistake, I still invite you to stay and read about why video games are so popular. For you gamers reading this, I expect you’ll already know what I’m presenting, but perhaps you never quite thought about it in this manner.

Why are games fun?

So why DO we love video games so much? Why can we spend countless hours in a virtual world tirelessly? A quick but naive answer would be, “because they are fun!” But what makes them fun? It isn’t just one thing, and there is no one size fits all for games. I know personally, I enjoy games that offer a great story with good three dimensional characters and a deep plot. Others, such as Anthony and Nick, prefer games more as a test of skill - something easy to learn but difficult to master separating the men from the boys, so to speak. For some, it is the element of competition between human adversaries, such as those who play League of Legends. I could go on, but the bottom line is: video games mean something different to each person.

Are there any common factors between all of these different interests? What aligns them all in a way that allows us to neatly package the whole experience as, “yes, I like video games?” The answer is rules. Yes, rules. Specifically that our brains love rules.

To understand why that is, we’ll need to take a step back and examine the biology of our brains. First of all, what is a brain, other than a mass of fat-sheathed neurons all excitedly firing at each other. The brain, and not the heart, is also the seat of our consciousness (sorry Aristotle, you got that one wrong). Brains have evolved to be decision makers, and their job is to think about things and direct the body to the best course of action. But in order to make good, informed decisions, we need to understand the world around us, and sort all of the information that come to us through our senses. Because of the brain’s desire to make these good decisions, it loves, and to an extent, demands rule sets, or, more abstractly, patterns.

If you think about it, you’ll realize that our brains are constantly filtering noise looking for patterns. An interesting side effect of this mechanism is demonstrated with coincidental occurrences; sometimes things that are purely chance related seem much more significant to us than they really are. This may happen to you when you learn a new word -- afterwards, you suddenly start hearing it “all the time,” when in reality the frequency of that word’s usage hasn’t increased, and all that happened was your brain added more significance to novel knowledge.

Great, but what does this have to do with video games? Well the answer isn’t just related to video games, but games in general. Human beings have been creating and playing all kinds of games for thousands of years. Everyone generally agrees that it is fun to win games, whether against another player or even playing by yourself. There is a certain satisfaction that comes along with creating an imaginary game space in which the game’s rules are that game space’s laws of reality, and then successfully executing actions to achieve your goals using the framework of the rules.

Successful execution of the rules is probably so satisfying because we are programmed to want to succeed at “the game of life” (not to be confused with Hasbro’s Game of LIFE), where the rules include actions such as eating food, finding a mate, etc. Playing and winning games in this way is a micro-model of “winning” real life. No wonder we love games so much!

Video Games Solve the Complexity Problem

But what about video games? What appeal do they have that your standard board or card game doesn’t? This time, the answer lies in the complexity. Most board games have few rules compared to today’s video games, not because the people who created them were less intelligent, but because adding complexity either adds costs on the players as additional rules to remember, or adds complexity to the board game itself, which could be manifested by adding additional pieces, additional point scoring, additional boards, etc. It simply becomes more of a hassle to manage the game space’s laws of reality than it is to actually utilize the framework. In addition, solving more complex problems ends up being more rewarding, especially when you reflect on the work you did to get to that sweet point of victory. Video games, in all of their virtual glory, do not suffer from this physical problem of complexity and therefore offer all of the rewards solving a complex challenge entails.

Because video games rely on a medium that is transformative (IE your computer monitor or television set), they are able to keep track of the game space rules as well as present additional complexity at relatively low cost to the user. For instance, a Nintendo controller consists of a whopping 5 separate buttons (counting the directional pad as one button). That’s not very many inputs, however, since different buttons performed different actions depending on what screen you are in (the game screen, the menu screen, the battle screen), you are now able to interact in a much more complex manner with the game space without having to utilize more buttons.

While it is true that video games offer more comprehensive rulesets, no video game ruleset encompasses everything. It’s fun to play different games with different styles because we are offered different rulesets to conquer. And now we come to the advantage that Indie games offer over commercially driven games: unique and novel rule sets.

Commercial Games Vs Indie Games

First, though, let’s examine what I’ll call “commercial games,” which I don’t want you to confuse with commercially successful games. They are usually produced by large studios with large budgets, and are ultimately driven by profit. Yes, the game developers are working there because they love developing games, and creating fun, interactive experiences for their customers. Yes the artists and composers and writers are all there because they love what they do and want to produce quality material for the masses to consume.

It’s their bosses, the leaders of the companies that employ them who are the ones demanding profit. That’s not to say they are a bunch of avaricious penny-mongerers, because in order to run a successful business, well, you need to make sure your business is making profits! In the end, however, this constrains the total creativity of everyone who works on the game as a whole. None of the higher ups will approve wholly untested concepts for games because those represent the riskiest ventures; spending $100 million developing a game that could potentially see no return is, at its core, a very stupid idea.

I’ll give you an example: Grand Theft Auto is a great game developed by a great company. In its first iteration, we had a top down view in which you control a little man who can steal cars. Fast forward to Grand Theft Auto V, and the game is radically different, but if you really had to boil it down, you control a guy who can steal cars. It is one of the game’s central concepts, and yes it is recycled because it is a sequel, which by definition would only offer iterative changes at most. But my example goes beyond that: if you compare Grand Theft Auto V to Grand Theft Auto IV, you won’t see much of a difference in terms of the ruleset. The world is different, the detail is higher, the story is longer, but it still follows the same formula, because that formula has been proven. Rockstar knows it can afford the $200 mil on that game because of how successful the previous versions have been. The ruleset remains the same.

Conversely, Indie games, which are NOT driven by profit, offer a realm of total creativity from the creators. We are free to explore concepts not previously explored, and to offer unique rule sets to our players. In a way, we can offer experiences to our players that commercial games cannot. Remember, the brain places significance on novel information, which in turn leads to a more intense experience. That intense experience coupled with the satisfaction of successfully utilizing the framework we present offers something wonderful to our players. Remember, just because the interaction is virtual, doesn’t make it any less real!

Having said all that, I’m not trying to bash commercial games, or say that Indie games are better, but I do want to say that the continuation of the creation of Indie games can only be a beneficial thing. It should never be something that is scoffed at, because if you think about it, Indie games essentially constitute research and development of gameplay. This is cutting edge stuff, folks, and that means you may encounter failures, but like scientists, all we need to do is modify our hypothesis and try again.

After all, games bring people joy in the world, and who could argue with trying to find new ways to bring joy to those people?

Merry Christmas

~Michael

Unity3D: Armor & Weapon Attachment to Character Model

/

For this week's blog post, I'm going to get a bit more technical than we usually do in these blog posts.  This is very Unity3D specific, so if that's not your bag then you've been warned.

Problem

The characters in Shibe Warz can have any combination of armor, boots, helmets, and one weapon/spell in each hand, so how do we attach those models to the character and have them animate when the character does?

Solution

I'll start with the helmet and weapon models, because the method for those is very generic and can be useful in other games.  I've uploaded the entire .cs file here if you want to look at it before/while you read.

1. Create prefabs of the models to be used.

This is pretty straightforward, drag in all the assets you need and make the weapon and armor prefabs.

2. Create a script to assemble the finished model

I named my script "UnitBuilder.cs", and it has public GameObject objects for each model that we just made a prefab for.  In Shibe Warz we have cloth, leather, and plate armor, as well as a bunch of weapons, so the top of my script looks like so:

...etc. The prefabs made earlier can now be dragged into this script, so they are easily changeable later on.  Note the "baseModel" object, which is the prefab of the completely naked unit, which we will be building on top of.

3. Instantiate the unit's naked model

This is pretty straightforward. Notice that I'm using Network.Instantiate here because Shibe Warz is multiplayer over a network. If it's a single player game, you'd just use Instantiate.

4. Attach the helmet

This is where things get a little tricky.  The premise behind having models "attach" to the character is to make them children of the original model, because a child's position and rotation, once initially set, are locked in with respect to the parent. So let's say you make two cubes, A and B.  You make A the parent and B the child.  You shrink B and put it inside of A.  Now when you move A, B will move with it, retaining its position inside of A at all times.

So, what we're going to do is make the helmet a child of the unitGameObject created above.  But we have to be careful here, because the unit's model will be animating, and as such the head will be moving around a lot.  So what we really want to do is make the helmet a child of the unit's head, that way no matter how much it moves around, the helmet will move with it.  How do we do that? Well, first we have to find the head in the model hierarchy. This is how it looks in the unity hierarchy view:

So now that we know where the head is, we can find it in code and place the helmet there.  Beware, the following is hard-coded, which is never good.  But it was getting late, so I was just trying to get things working.  Please refer to my previous blog post, where I talk about how messy your code will likely get while developing a game.

One thing you may recognize is the use of the helmPosition object.  I discovered that I couldn't simply put the helmet at position (0,0,0) because then it wouldn't be fit on the head properly, so I had to mess with it a little bit to make it look good.  Once it looked good, I simple copied the x, y, z values and stored them as private variables in this class.

And voila! The helmet is now instantiated, placed on the head, and made to stay there by setting transform.parent = charHead.

5. Attach the Weapons

This is almost identical to attaching the helmet, the only difference is instead of attaching it to the unit's head, you attach it to their hand.  For the sake of brevity I'm omitting the code, but I've uploaded the entire file here if you would like to see how the sausage was made.

6. Attach the armor and boots

I saved this part for last, because I'm not really proud of how it was done, and I know in my heart of hearts there's a better way to do it, but it works, and if it ain't broke don't fix it, right?

When Anthony created the armor, he was generous enough to attach it all to the same skeleton as the base unit model, and animate it in the exact same way.  This made my job extremely easy, as all I had to do was instantiate the armor at the exact same spot as the unit, and any time an animation is run I just animate both the unit's model and the armor's model.  The same was done for the boots.

So! This was pretty much the entire process of building a dynamic model from scratch.  I hope this can be useful to someone, and if anyone has any questions or wants to say, "Hey that was a stupid way to do that, you should do it this way..." and then provide some awesome way to do it, feel free to leave a comment here or hit us up on twitter, @verusgames.  After all, the purpose of this post is to help people in the future with the same problem!

-Nick