Game Design Blog #3

This week I'm going to talk about one of my favourite games, and one of the reasons I love it: Its pacing! The game in question, is the lovely, the fantastic....

So first things first, I will end up going more into depth over the overall pace of the game rather than the pace in specific levels. This is because there isn't a whole lot to write about in terms of the pacing of levels, it's not that it's bad it's just that it's pretty standard. Now then, why do I love the overall pacing for the game? Well, to put it simply the game does a good job of keeping a steady but ever-building pace. When the game starts (and after the tutorial), the player only has 2 members on their squad and they are given 4 missions which reward the players with additional squad members. By doing this the player is given a chance to experiment with their squad without the number of unused squadmates getting out of hand. After a point in the game the player unlocks an additional 4 missions which are much the same, allowing for a break before the player gets new squad members.

Another interesting thing is the Loyalty Missions. These are missions which require the player to go in with 1 squad mate preselected for them. This gives the player a chance to interact with characters they might not necessarily interact with and get used to working with them. This also serves as a strong way of preparing the player for the finale of the game in which they go in with every squad member and have to divide it up into different teams while making use of their different skill sets.

In terms of the story pacing, the game does an excellent job of providing the players with points that ramp up into action while providing brief interludes where the player doesn't have a lot of stress on them but the game isn't boring, i.e. the missions to acquire new squad members are in the slower points of the game and serve to help build up anticipation for the next big missions. The overall pacing for the story does a good job of building the players anticipation and interest until the big finale of the game which puts the player in a position where they simply do not want to stop until the end of the game.

Overall, the pacing for Mass Effect 2 is quite good at maintaining the players interest and allowing them plenty of time to learn the skills and squad members that they gain over the course of the game.

That's it for now!

Game Design Blog #2

Alright, time for Game Design blog numero two! Unlike the last blog I'm not going to talk about a specific game, rather I'm going to talk about a control scheme that has become so prevalent in a certain genre of game and put in some guesses as to how it as persisted for so long in gaming culture. What control scheme might I be talking about? Well...

That's right, I'm going to be talking about the First Person Shooter (and Third Person Shooter) control scheme on the PC! The above picture is for the game Team Fortress 2 so there are some parts of it that aren't going to carry across games, but the main things that you need to focus on are WASD, R, Ctrl and Space keys. Now first of all, what do these keys represent? Well WASD is movement in the 4 cardinal directions relative to the player, R is for reloading, Ctrl is usually for crouching and Space is used for jumping. This layout has been carried across many, MANY games in the past. Why might this be? 

Well if you look at the layout of the WASD keys, they're positioned in such a way that the player can leave their left hand in a position they normally have it on the keyboard allowing the fingers to line up in a normal and comfortable way. Another advantage is that the ring, middle and index fingers line up vertically with the 4 keys in to three distinct columns, allowing for easy use. Finally, the WASD keys form a sort of compass by which can easily be interpreted by the player. This analogy between the player and the game works incredibly well as the keyboard movement of forward, left, right and backward carries over perfectly between the players perspective and the perspective of the character in game.

Now let's take a look at the placement of the other keys:The position of the R key keeps it within easy reach of the player's index finger and it's also tied to a button that players can easily reach based on muscle memory as they only have to think about press R to Reload. The Space key would have been chosen as jumping is an action that players will end up using quite frequently which makes its size and position relative to the players thumb allows for easy and frequent use. Lastly, the CTRL key makes use of the players remaining finger while also staying within easy reach of a single hand.

Overall this layout allows the player to easily use one hand to perform all their movements and any necessary miscellaneous movements. However, shooters also rely heavily on the player's mouse which acts as a camera control through movement. This allows for rapid yet precise manipulation of the player's perspective. The left and right mouse buttons will also see use for a weapon's primary (left) and alternate (right) attacks. This works well as the left click on the mouse is often used for most primary actions such as selecting icons or pressing buttons, allowing the player to make an easy association between the click and the action. The same can be said for the right click which sees use for additional actions in day-to-day use.

Overall, the control scheme for shooters is one that allows the user to make many easy associations with the use of the keyboard and immediate actions in the game, as well as analogies which allow the user to perform actions with the keyboard without having to put too much thought into them. This scheme is very sensible and will likely be around for many more years to come.

That's it for now!

Game Engines 4: Valve Hammer Editor

Okay so this blog will be a bit more jumbled since I'm going to be talking primarily about 2 very different topics: Binary Space Partitioning and different methods for culling. The one thing that links these two topics is that I'll be talking about them in the context Valve's Hammer Editor (a level-editing tool for the Source Engine), and most of the talks will be in regards to how it works with Team Fortress 2 as this is the area in which I have the most experience using the editor.

First of all, let's talk about what Binary Space Partitioning is. BSP will essentially parse a file (such as a level) and continuously subdivide it into different nodes until a requirement is met. This allows a level to be broken down into far more manageable chunks. Unsurprisingly, this method was once (and still in fact today in some cases) seen primarily in Shooters as they usually end up having a variety of rooms which can be interpreted as nodes on a tree graph. In this scenario, using a BSP allows the engine to cut down on the amount of checks it needs to make for render culling as it can easily work out all the rooms attached to the one the player is currently standing in.

The practicality of this system in regards to shooters makes it no surprise that it's used in the Source engine which is primarily used to develop shooters. The system can be further enhanced by using a portal-based rendering (which is another prominent feature in the Source engine). Portal-based rendering is essentially the process of treating every door or window connecting two areas as a 'portal' that the player can see through. When the engine goes to render a scene it will use frustum culling to remove any objects that are not within view of the player...But it then encounters a problem where it will try to render an object behind a wall. In order to cut down on this, we only render the objects in one room before casting frustums from each visible portal to figure out what objects there are in a different room which we can see, once the engine knows what objects we can see in other rooms it adds them to the render list. With BSP and portal-rendering combined we can pretty effectively cut down on the demands put on the renderer as we reduce the number of rooms that are being checked for rendering and cutting down the size of the render list by a significant amount.

Now, how does the engine know where to find the portals as well as figure out ways to make subdividing the level easier? Simple, you leave it up to the level designer (or atleast someone who is making the level)! One of the things about the Hammer Editor is that it has a LOT of materials that do not get drawn during render time which are meant to be used more for letting the engine have an easier time or for gameplay (i.e. Spawn areas will often use a material that has a No Draw texture, but it will have gameplay triggers tied to the box representing the spawn). For some idea of what the editor looks like while you work in it, here's an idea:

I'm sorry to have brought up the Source Engine again, but I just find it to be such a great little engine that has lead to a lot of interesting games. While it may not be on the same level of flexibility as Unreal or Unity, it's still capable of producing some truly magnificent games and its level editor can give a lot of unique insights into how the engine as a whole operates (from interpreting game systems to rendering). For an idea of how flexible the level editor is, it allows for something that could be seen as making rudimentary scripts for its gameplay systems (i.e. this object will move when this condition is met) and a level designer can VERY EASILY set this all up.

That's about it for my ramble about Source. If you made it this far, then congratulations. Cheers!

(Image of the Hammer Editor gotten from: http://www.moddb.com/engines/source/images/hammer-editor )

Game Engines 3: Scripting

And now for Game Engines blog #3! This week I'll be giving a breakdown of Scripting and how it applies to game engines. First of all, what is scripting? Scripting is essentially creating a smaller program that can be executed by the game They come with a variety of perks as well which make them invaluable in game development:  They can be easily used in an ECS; They can compile a lot faster than normal C++ files;And be recompiled at runtime. One of the most important things is that they can easily be edited and programmed.

First things first, how do scripts work? A script can be written in notepad (although you really shouldn't since notepad is horrible to work with) like a text file and is then interpreted by the system in such a way that it knows how to act in terms of the game system. It's pretty straightforward and it's more or less identical to how one would set up a program in C++. In fact, when you compare how scripting is supposed to work and the method in which we create our custom components for 2LoC, it's very similar with the main difference being that the custom components take longer to compile than the script.

Now, why do these features make them so great? Well for starters when it comes to an ECS you can make a script component which only needs a path assigned to it to be created, much like you would with a mesh component. This then saves you the trouble of creating custom components and custom component systems like you have to for creating a custom component with 2LoC and cuts down on the number of files that have to be linked during compilation. It also allows you to keep the number of different components you need to have in your ECS to a minimum as you aren't forced to create unique ones for each circumstance and can instead rely on multiple script components to do the same job.

Scripting also has a few perks in terms of hardware, as mentioned a few times earlier. Their very nature eliminates the need to create and link different objects for classes and cuts down on the overall amount of code drastically, allowing for developers to have much faster compile times. The other advantage to working with scripts is that they can easily be recompiled without interrupting the system overall. This is actually a huge advantage as it allows you to change code on-the-fly without having to rebuild a project. All you have to do is open the script, edit and save then recompile the scripts.

Lastly, scripts are useful for non-programming developers. They are generally easier to grasp than the underlying code of engines and are easier to play around with. The ability to edit and reload them without interrupting the game is also very useful in terms of design as it allows designers to see changes to values immediately rather than having to stop and recompile an entire project or ask a programmer to make the change for them.

Overall, scripting is an invaluable tool in game development. It allows us to save time in various areas from building the final product to quickly testing the game as we go. It also helps by reducing the complexity of developing the game and can help drastically improve a system's versatility: Case in point, Unity is used to create a large range of games in different genres while developers can only add their own code through scripts. The only difficulty comes in setting up a scripting language to work with your engine, but once that's done you've overcome the hardest problem.

Until next time!

Game Engines 2: Components

Time for blog #2 for Game Engines! Today I'm going to be talking about one particular topic that has become very prominent in the Game Industry and in game engines in general: Component based systems!

So first of all what is a component based system? Essentially a component system relies on two things: Entities and Components. The Entity is the container for all the components and is basically an object in the game world. The entity only has to worry about having a tag and an ID (and even then, an ID is usually enough) to allow for developers to easily track down an entity in the system. On the other hand we have the Components in the system which is the meat of the object that can then make it unique. Components can range from things such as transformations to meshes to scripts and contain different values that allow the entity to interact with the game world.

So now that we know what an Entity and a Component are, what does this mean? Basically we can have a huge range of flexibility with our Entities. In previous system designs that rely heavily on inheritance we would have to deride from a long range of classes to create an entity that can do what we want (i.e. Entity->Character->Enemy->Flying Enemy->Drone) and we would have a harder time crossing over features from different classes. With components we would only have to worry about adding something such as a Flying component, Enemy component and any components that might be specific to the Drone enemy. This allows for anyone working with the engine to easily make an entity that can fit their needs (so long as they can make their own components).

That's the general summary of how an Entity Component System works on the surface. In my next blog I'm going to go into some of the lesser well-known components that you can use in an ECS (and that isn't currently implemented into 2LoC: Scripting!

Game Design Blog #1

And hot-on-the-heels of my Game Engines blog is Game Design! For this one I'm not totally sure what to do, so I'm going to play it safe and talk about the recent topics and how they relate to one of the few games I have played recently: Tales of Xillia 2! The two topics I'm going to focus most prominently on are the controls and the UI.

First a little summary of the game: Tales of Xillia 2 is a role-playing game with instanced, party-based combat. When the player enters combat they are in a circular arena with a character they control and up to 3 AI (or player controlled) characters. Now on to gameplay!

The controls of the game, on a PS3 controller. The game itself switches between two states (not including things like menus and not going into a LOT of detail): The overworld state and the combat state. The overworld state is when the player is able to run around freely (i.e. towns, fields and dungeons), obviously this has been simplified but that's more to cut down on length. In this state the player can encounter monsters (in the latter two) and controls by using the left joystick to move their avatar and the X key to interact with objects. The player can then transition to the combat state by colliding with an enemy on-screen and in this state the controls become drastically more complex. The player moves their character by moving the left joystick left or right (the player is on a fixed axes for the most part), but can press L2 to enter a 'free-run' mode where they can move in any direction on the field with the left joystick. The player can attack and guard using the X and square buttons respectively. The player can also use the circle button with the left joystick or the just the right joystick to activate special attacks. This is more or less the basic gameplay (not going into the depth of special stuff). Now a quick breakdown of how intuitive the gameplay feels!

The overworld gameplay doesn't have that much that needs to be said about it. It worked pretty well but it wasn't exactly special. The gameplay in the combat state though flows very smoothly, the basic attack handles very smoothly and the idea of tying the special attacks to the movement in a small-but-unaffecting way actually helps make the gameplay much easier to handle without breaking the flow. I don't think that there's anything that could be done to improve the gameplay as it requires the least amount of movements on the players part to change actions.

One gameplay mechanic for combat that I had previously omitted was the ability to partner with one other party member to work with them in combat (i.e. the character can block to stop you from being attacked from behind or flank an enemy you're fighting). The way a player links with another character is by pressing on the D-pad in the direction of the character's icon on the HUD. My reason for listing this is separately from everything else is to tie into the....

UI! The UI for the overworld state is pretty straight forward with a mini-map that shows where the player and other things of note are, as well as the option for pop-ups like objectives. It's very simple to understand and isn't intrusive, so it gets a pass! The combat state UI is very much geared towards melding with the controls by having it so that important meters are on the left and right while the names and stats of the 4 party members is laid out in a diamond on the bottom-center portion of the screen. This last part works very well with the the ability to link with the other party members as they line-up perfectly with the D-pad so that it's very intuitive. Overall, the UI is very clean and easy to read (for me, anyway). But I'll let you decide by finally providing a screenshot of the game!

And I'm not going to be going into super-fine detail on everything (I'm sure you can see that there are quite a few finer detalis) but that will just entail going into a lot of depth that you learn over-time.

At the end of the day, the game is very well-designed and friendly to both old and new players. Though far more importantly than that: The game is FUN!

And with that, I'm going to call this blog done...Namely because I'm rambling.

Thanks for reading, cheers!

Game Engines 1: The Source

Alright, after a long delay I'm back! Jumping right into this I'm gonna be talking about one of my favourite game engines for this new class, the wonderful engine that has given us so many games by Valve: The Source Engine! I'll be doing a quick-review off it from its beginnings to its future while going through some of the special features implemented it as time went by, but first I'll give a quick summary of what the engine is!

As mentioned before, the Source Engine is Valve's in-house game engine. It was designed to be used for first-person shooters (a genre which Valve excels in) but has been successfully repurposed to be used for other genres (such as top-down shooters like Alien Swarm).  It evolved from the GoldSource Engine which was built off of the Quake Engine.

Now, there's something rather special about the Source Engine in relation to our class: It is made entirely in C++ (well, C++ and then it uses OpenGL and DirectX3D for shaders). This means that there are only two things to stop a UOIT student from making an engine as powerful as Source: Experience and manpower. I consider that fantastic motivation to start learning the ins-and-outs of engines to make my own. Anyway, on to the features that were added!

So the Source Engine is constantly evolving with new games adding new features to it. For example Left 4 Dead 2 added dynamic 3D wounds for the engine, these essentially being a unique way of creating wounds on characters that would change the appearance of the model in a drastic way (i.e. arms falling off and having the bone sticking out). The game DOTA 2 introduced keyframed vertex animation to the engine and then there's a much longer list of features (with things like blending skeletal animation, inverse kinematics, dynamic water effects, etc.). The development of the engine does not have them keeping track of it by versions like you would typically see (i.e. version 1.0.0, version 1.0.1, etc.), instead simply updating in smaller or bigger ways as required.

Looking at its design, the Source Engine has the capacity to constantly grow as time goes on and add new features. Though this approach would ultimately prove a bad idea as new techniques and design patterns are constantly emerging and the base code for the engine simply could not easily be altered without potentially ruining the engine. This seems to be something that Valve has picked up on as they are currently developing (or, if rumors are to be believed, have already released) a Source Engine 2. This engine should see an overhaul to the lower-level architecture of the system so that it could run much more efficiently and have greater potential than the previous one.

On a semi-unrelated note though, the Source Engine is also a great example of how powerful a game engine can be in the right hands. Valve has used their engine not only to make games but also to make offline tools such as the Source Filmmaker and Hammer Editor which they could then use to improve their production pipelines. The Source Filmmaker allows for easy development of in-engine cutscenes by allowing them to create a scene in the engine like you would with Maya, but it instead uses the engines lighting systems. The best example of its potential is the Meet the Team videos for Team Fortress 2. Meanwhile, the Hammer Editor functions as the company's in-house map editing tool, Not only does it allow users to create the shape of the map, it also allows them to set up things such as game triggers which the engine can then use to construct the full level experience.

Overall, the Source Engine is a fantastic piece of technology, in my mostly biased opinion. Unfortunately, I have not ever used it so I could not make any comments on how user-friendly it is or some of the downsides it has developing for it. I hope you've enjoyed reading this rambling blog!

Cheers!