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!