Personal Blog - Happy Holidays!

Thought I'd take the opportunity to wish everyone a good break, and I'm already looking forward to seeing you all again when the next term begins. And thanks to James for a great introduction to Games Development!

I'm going to be using the time off to try and fix up this blog, seeing as I've not been able to get around to it beforehand. I already sorta know that I could probably do with making it a bit simpler than I was intending to... only a bit simpler, mind you. And catch up on sleep, of course. Lots and lots of sleep.

Anyway, happy holidays!

Assignment 7 - Game Engines

Assignment 7 Game Engines

In this assignment, I will be looking at four game engines either currently in use in today's game industry, or engines that will be released in the future for next generation games development.

Unity Engine 4 is an engine released during the Summer of 2012, and comes in two forms... the basic free version and a paid for Unity Pro version. The engine was originally developed for Apple platforms, although it has since evolved to encompass any platform from games consoles to mobile phones. The developers state that their intention for Unity is to provide a low cost engine to enable more developers to afford to create new games quickly and cheaply, and to that end it includes several features including an asset shop to download ready made assets and supporting software which can cut time considerably. Unity also includes inbuilt animation capabilities to allow animation and motion capture within the engine, certain assets created outside the engine to be automatically updated without requiring files to be uploaded with edits, and for textures and assets to be used across games designed for multiple platforms. Overall, my impression of the engine is that it lacks the punch of other engines, but the above aspects on top of making use of C+ programming languages serves to help a games development team produce games for consoles and phones in a fairly efficient manner, and therefore seems like an engine that would benefit those that are new to the games industry.

The Source engine was developed by Valve and showcased in 2004 in the games Counter Strike : Source and Half Life 2. Since then, the engine has gone through several upgrades as technology has advanced, the same engine being used in more recent games like Portal 2 and Defence of the Ancients 2 with new features designed to ensure the engine's long life, like improved particles and lighting. Additionally, the Source engine is accessible to anyone whom has purchased at least one game, which has made the engine very popular amongst the modding community, although the vast majority of games that are made using Source tend to be First Person Shooters – Exceptions include the RPG Vindictus and the top down shooter Alien Swarm. However, aside from the latter games mentioned, relatively few games have been developed commercially with the Source engine outside of Valve itself, with the unwieldy SDK tool set and a need to deeply understand coding commands being amongst the chief reasons for being underused – with Valve employees all being required to understand how Source engine functions.

Unreal Engine 3 was developed by Epic Games in 2004, and as with previous versions of the engine it has proven highly popular in the games industry, with flexibility to create many different genres of game and a largely intuitive tool kit. Many games I have enjoyed over the years have utilised the engine, including the Gears of War series (made by Epic) and the Mass Effect series, and both of these games are distinctive from one another... with one being a cover based shooter and the other being an RPG. Like Source, UE3 has proven very popular within modding communities, and in 2009 Epic further opened up their engine to allow the development of mods into stand alone games in exchange for royalties and a small fee.

And the last engine I looked at is one that is not yet available, and that is the Luminous Engine by Square Enix, with the real time tech demo “Agni's Philosophy” recently being showcased to demonstrate it's capabilities. First and foremost, Luminous is an engine very much aimed towards taking full advantage of the next generation of gaming consoles, but it also offers the flexibility of being used for a variety of current platforms and mobile devices... a feature similar to that of Unity 4 and therefore potentially of greater benefit to games development teams being able to use one engine to create games for different platforms instead of learning to use multiple engines and of course widen the audience developers can aim at.

One aim for Luminous has been to create an engine capable of creating graphics on par with those used in pre rendered animation, and this also includes aspects like creating particles and lighting on the fly rather than having to render these sorts of changes, which can consume time as builds are tested and iterated on.

Assignment 7 - Luminous Engine

Luminous Engine? A next generation engine currently in development by Square Enix. There, that was a nice start.

In all seriousness however, I've found direct information on what the engine is capable of to be rather... ... sparse. The most recent tech demo released is Agni's Philosphy, a real time demonstration of the engine's capabilities, which I understand many people have already seen in class, but just for emphasis -:



I've only really found articles on gaming sites that hint at the intention of the engine besides improved lighting and an ability to produce pre render quality graphics, with no games presently said to be in development using the technology.

 http://www.edge-online.com/news/square-enix-shows-photo-realistic-next-generation-engine/

http://kotaku.com/5848982/square-enixs-new-engine-could-mean-pretty-games-faster/gallery/1?tag=luminous-engine

A couple of things that I DID uncover however claim the the engine is capable of reflecting light more efficiently than current gen with colours being reflected off coloured surfaces, and including animation capabilities that automatically adjust character animation when using equipment of different weight or if they are walking on uneven surfaces, something chiefly designed to create increased realism in next generation games. If I were to think of games like Elderscrolls Skyrim, character animations were very fixed even when running or fighting on sloped surfaces, or the entire character rising upwards if stepping on a rock.

On top of that, like in Unity 4, the engine is also planned to be functional for multiple platforms, working on current generation platforms as well  as those of the future, and ranging from consoles to phone devices... with graphics etc being scalable.

Assignment 7 - A look at the Unity Engine

I'm not nearly as far into the research as I would like to be at this late stage, but I'm doing the best I can. It is likely that I will be doing some work in college... at least, that is the hope. If there is somethign else going on during the class, then I may be sliiiightly scraped for time.

But I thought a good place for me to start working was the Unity Engine, it being something that we didn't discuss in class. And on reflection, this is proving to be a fortunate choice, for reading up on what the engine is capable of has given me features to look out for in the rest of my research.

I shall try not to regurgitate information found on either their website or their Wikipedia page, but in essence... the engine seems to be focused on accessibility and workflow. Without having used their engine directly I cannot possibly say for certain whether this is indeed the case, but based on their word... Unity is capable of publishing content onto multiple gaming platforms... for example, publishing on Xbox 360 and Playstation 3 without having to work on seperate versions. Being a player of games upon PC, I have witnessed first hand some rather shoddy ports of console games, normally as a result of developers outsourcing to external companies... I imagine that at present, creating the same game for different platforms can be time consuming and a drain on resources and time for game developers. To be able to do this without using too much manpower or exporting it to another company... well, that would certainly save time and money for a team.

Another aspect of the engine seems to revolve around an in-application store where assets can be purchased... and although I question why a development team would want to use something premade... I can appreciate the usefulness this could bring to speeding up the production cycle, like say... if I were making a game and I had a lot of content to create, then being able to purchase some elements to enable more time to work on other elements would be a considerable boost.

I also read about the engine being able to accept edited image files without having to reimport the file intothe engine everytime. That gave me a teeny tiny flashback to Thursday when I saw the on the fly lighting and particle systems in the UE4 engine. That might not be the greatest comparison, given that particles would rather trump imagery/textures, but in both cases, these are all about shaving time off work schedules, and that can soon add up.

And I think I'm going to stop there for now. It is a start.

(Edit: This link )

Assignment 7 - Initial Thoughts

I'm afraid that I haven't had much chance yet to get down to even writing this entry, let alone actually get on with the research. As it stands, I'm now in the midst of moving my belongings into a newly decorated bedroom, but I'm hoping to have this out of the way by Monday.

But to talk on the subject of this new assignment, which is to take a look at 4 game engines and write 1000 words overviewing each of those engines, I have to say that the lecture we had on Thursday was quite the eye opener. I struggled at first to think about how game engines could be used to quicken the working process of developers, and on reflection this stems largely from never having really known just what these engines can actually do NOW, or what technology is just around the corner. I really don't know what I was expecting.

I find the topic to be very interesting, however. I already know that I'm going to take a look into the following;

• Unreal Engine
• Source Engine
• Unity Engine

But I'm still looking for that final engine to fill in the empty space. I'm resisting the instinct to look at Cry Engine... partly because I have no real connection to any of the games made with that engine, and partly because I feel like it would be cheating to look at that on top of Unreal and Source after looking at all three in class. I'm going to finish my move and then think of some games I've enjoyed playing and finding out what engine powers them.

(I did try to look at Visceral Engine, used in Dead Space 2... but I'm really guessing that is an internal engine, I really couldn't find any information on it other than as part of a top ten on IGN. Oh, and a wikipedia entry that only exists in Russian... which I somehow suspect doesn't have anything to do with what I might be wanting to research. 

Onwards and outwards!

Assignment 6 Conclusion

Tuesday has been and gone, work handed in and everyone's work reviewed in an informal discussion. Everyone did very well with the assignment, and it was great to see what sort of levels were being made.

What I didn't enjoy though was having to stand in front of the class and explain the map. And this isn't necessarily because I am shy... because really, I'm not. I'm just not capable to thinking up a talk on the spot, and I was simply caught offguard and unable to express my reasoning for the level being structured as it was. Hopefully I can do that now.

In essence, I felt that I bit off a little more than I could chew with the level, setting it in an outdoor environment, although I still believe that I worked the best I could and made something that with some further development could be made into something fun and challenging. And the one thing that I really want to get off my chest is that although I did not place too many placements specific to certain classes, if one is to look into the level design of the maps already in Mann Versus Machine, they are not made to the same standard as say, a capture point or payload map. There is not quite so much emphasis on creating class specific routes and that is because the AI used in the mode follow fixed paths... fixed paths that can differ from wave to wave, but fixed paths none the less, and with very few exceptions there are not spots or paths that can only be accessed via double jump or rocket/sticky jump. I made the level so that certain points COULD be rocket jumped and certain distances double jumped, but at no point did I want to create an area that could potentially prevent robots from being able to reach players.

I made some poor design choices along the way, and the more I look at the map now, the more I wonder if I really should have had the path go back on itself toward the end... or if the level is simply too long in length. In any scenario, I'm satisfied with the assignment, and if anything it only gives me the drive to go back to the drawing board and refine the design some more. I made the mistake of ending up working on the fly rather than drawing out alternate ideas... one I shall try not to repeat next time.

Assignment 6 3D Level Design

I consider this as close to being finished as I can achieve whilst flailing my hands on the keyboard in the vague hope I'm learning something.

Anyway, this is my map for the assignment, a Mann vs Machine level for Team Fortress 2. And to explain MvM in a nutshell, players spawn on one side of the map, which is also the area they are defending. AI controlled robots approach from the other side of the map, trying to deliver a bomb to the player spawn... if the bomb makes it, the wave is lost... and if the players defeat all the robots, the wave is won.

I designed my map around the idea of a vertical level (Inspired by Upward and Offblast maps in TF2), meaning that the map itself may not be all that large, but the ability to ascend and descend compensates for this. The idea was partly inspired by the airblast mechanic as used by the Pyro, a level that held a lot of opportunities for being pushed off the map or to a lower level. I included fences to make it harder for a Pyro without upgrades to achieve this.

  And so yes. Basically, the robots start at the bottom of the map, and climb their way up to the top, and the players must prevent them doing so. (Would write more, but short on time thanks to sudden dinner and early trains)

Assignment 6 - 04/12/12 @ not 7pm

 And I've probably got as much done as I feel I am able to do. I might make some final adjustments when I next wake up before heading to college, but for the most part, this is my level.

I'm going to draw up a proper key to accompany these pictures and the work I'll be submitting when I hand in the work tonight. But in a nut shell, the magenta signifies areas that the player cannot walk on, and the bright blue signifies robot spawns. I hid some extra spawns in other parts of the map as well to allow for spy bots to appear behind players. The green squares in turn signify ammo and health pick ups, and the tiny bit of red is the player spawn.

I wanted to include two 2-story buildings on either side of the map to provide another route to the higher road near the end, but I found it too fiddly to hollow out the grey blocks I created as placeholders. I may add black squares to signify entrances and exits. I also had to move the alternate routes from the first island to the second, although I like this compromise... it fits a lot better.

First part of the map, robot spawn point.

First mountain on the second 'island'

The alternate route off the main path... links up to the third 'island'

Player Spawn and Bomb Chute. Medic for size comaprison.

Assignment 6 - 03/12/12 Part 3

I seem to be doing a lot of updates today. But given that development has to be shown, I might as well explain what I'm up to at present.

I decided to ask some friends about their thoughts on the design I had from the previous post, and the feedback was positive... one said that it would make a great Payload Race Map (Another mode in Team Fortress 2, where each team has a bomb that they are trying to push to a goal whilst trying to stop the other team from doing the same.), and to add some platforms and such.

Building/cover placement has proven difficult and it continues to give me grief as I try and finish the design... it is starting to deviate significantly from the top down design I drew up to help me. The main path towards the objective remains relatively unchanged, although the alternate route for the first section of the map has had to be removed due to the space between the first and second section being a lot larger than I thought it would be. I still need to get that alternate route in somewhere, although I also need to think about platforms that players can set up snipers or sentries on, and luckily I'm on the right path I think.

I'm also still having to consider which areas are going to be falling hazards, and which aren't. Without further ago, pictures.

View of the front of the map. The bottom left platform will be the area that robots spawn during each wave.

View of the back of the map. The red circle signifies the bomb chute, and the red roofed blocks are the player spawns.

Top Down view. The basic design is relatively faithful to the drafts.

Assignment 6 - 03/12/12 part 2

The work continues. The terrible realization that I've perhaps made the map too large has started to dawn on me, but I feel that it is now a bit late to change much of this. Priority remains getting the actual map done before I try to make corrections, and for the most part I am still working alright with my top down design. But enough typing, updated pictures.

The image that makes me honestly believe that the level is too large. Those two blurs towards the left are a Heavy and Medic.

Assignment 6 - 03/12/12

My work isn't progressing as quickly as I was hoping it would. It doesn't help that half way through, I realised that I could make things simpler on myself by concentrating on one side and then using the flip along action to mirror the map. This is likely going to be rather useful to me as well as hopefully speed up my progress in the final stretch.

Also working against me is the realization that I could work the paths a little differently to provide more of that vertical gameplay I want. I will only make those additions if I feel like I have enough time to do it.

It still isn't anything to look at, but another couple of screenshots taken just a few moments ago.

Assignment 6 - What am I doing?

I'm not uploading any more pictures, at least not yet. When I get round to showing some other aspects of my research, I'm going to try and link the images to their original source.

But I've not made much progress over the last couple of days. I've had a busy couple of weeks and I've been trying to unwind with little success. Some research has been made into New Mexico deserts to try and get a feel for what I'm trying to do, although I'm undecided if I'm basing the level on that classic TF2 default or if I'm perhaps going to go more for the Alpine theme that the game also features.

That said, I don't think I'm going to be able to make the map all THAT elaborate. I simply don't know Sketchup well enough and I'd rather get the level completed then get lost in details. Historically, I'm very much someone that wants to make things as perfect as possible... but I already know that I don't know how to do the things I want to do here. Curved, sloping paths that connect each vertical height are my main obstacles right now, and I'm close to resorting to keeping it square for the sake of simplicity. Priority remains getting the map planned out before I try to make anything look even slightly more organic.

I want to be able to hand the work in on Tuesday with something that resembles a map design.

Assignment 6 - Starting Sketchup

With the 2D design largely done (I'm been running along the lines of having to see how the basic level idea looks in a 3D environment before working out any additional details like scenery and platform placements that will be needed) I've finally started work in Google Sketchup, and I'm happy with what I've done so far. Not bad for someone that struggles to think in the third dimension... though I'm also telling myself that I have to be a bit realistic about the assignment, and that I won't be working quite so well in an area I am unfamiliar with.

Without further ado, a couple of screenshots from my early efforts.

I'm only focusing on one side for the time being, seeing as the map is largely mirrored. Although working so far, I already feel like I could make some changes in places. I will elaborate when I've worked some more.

What. Tuesday mouse doodling. Ugh.

Assignment 6 - More Level Design

That is right.

So my idea had been to create a sort of road style map, with a gas station and a scrap yard incorporated into the design. And to be perfectly honest, it sounded better in my head than when I committed it to paper. The basic flaw was that I was imagining the world quite flat, as one would really expect for a desert gas pump station. I tried to fiddle with a different design more based on farmland, but that didn't interest me greatly.

I initially lost hope on the idea of an MVM map. But inspiration struck me whilst I was on the bus to college on Tuesday (27th) as I began to think instead of something along the lines of a vertical based level. Mountain trails. The sort of little retreats one might go to with the Scouts or something along those lines. I thought mostly about the sort of precarious roads hugging the edges of steep cliffs as seen in many a film... and ran with that sort of theme. A level heavy on the potential for knocking robots back, but where a misplaced step could lead to certain doom.

(By the way, that recurring fellow is called Bill Dup)

I'm still not sure, honestly. I tried to create a mock up in Illustrator that I coud try and work out smaller details like obstacles or buildings, and I ended up making the map fold back on itself a little bit. I made a rudimentary key to go with it, but forgot to include the yellow, which represents the straight path to the bomb chute.

Assignment 6 - Vertical Level?

Continuing the work on designing a Mann vs Machine map for Team Fortress 2, my attempts at level design have proven fruitless. As with last time, I tried not to get frustrated by the lack of progress and instead looked at the aspects that were causing problems. And I found that the theme of scrapyards and gas stations was not working mostly because I could not work out how to make the level branch out, nor how to keep the player within the playing area.

Instead, I've decided to reevaluate my ideas, and I have begun to work along the lines of a more vertical based level, like the maps Offblast and Upward that already exist in Team Fortress 2. I also worked with the idea of an area disguised as a scenic mountain trail, with environmental hazards keeping the player from trying to explore beyond the playable area. A level that ascends upwards also allows me to make use of twisting paths which I think could prove interesting.

I'll upload rough designs once I return from college, but for now, some images lovingly pilfered from http://wiki.teamfortress.com/wiki/Main_Page. Just to show roughly what I am trying to aim for.



http://wiki.teamfortress.com/wiki/Offblast



http://wiki.teamfortress.com/wiki/Offblast

http://wiki.teamfortress.com/wiki/Upward

http://wiki.teamfortress.com/wiki/Upward

Assignment 6 - Things To Consider

Oh boy. Things to consider. Yeah. I've not made the sort of progress I'd have hoped to have made by now, mostly because it seems like I am in demand until Friday and this is lowering my mood for doing work. But I've done what all that I could with the time I've had.

When designing a Mann vs Machine map, I have to consider a number of things that must be included. As mentioned previously, there must be a player spawn and a robot spawn. But beyond that...

• There must be additional spawning points within the map for Spy Robots. Seeing as they do not enter the map in front of players but behind them.
• There must be one or two spawning points for tanks to enter the map, which is generally in the same area as the normal robot spawn. The difference being that they appear from behind fences on ground level.
• I believe with the player spawns, there needs to be either one large spawn point that includes two stores where players can upgrade their weapons, or two smaller spawns each with a store. 
• Some maps do not have holes with which to dispose of a carried bomb. Instead, they have bridges which bomb carrying enemies can be pushed off, which means that the bomb carrier must backtrack down a path to return to the main route. I have a choice between having pits or having these lower paths. 
• Maps are generally rectangular in shape, which allows players plenty of distance to keep the robots away from their base.
• Players must be able to see which robots they will be fighting before they enter the map. This can be done with elevated ground the players can stand on or a slope that the robots run down.

 I'll be bringing some graph paper into class tomorrow to get started on a more elaborate map design if I manage to get a scribbled version down in time. I know I'm looking at having four paths for the enemies to run down, and I know that the players will be defending their point in a junk yard. I'm looking at using barns to help keep players in the map, and that is about all I can write right now. Tired.

Quick Post

Because spotting a brief article on Ether One on Gamespy is possibly worth linking.

http://uk.pc.gamespy.com/articles/122/1226736p1.html

Assignment 6 - What is MVM?

This might well classify as initial research, although the certainty is not one hundred percent. None the less, I shall write now.

Having decided to focus on creating a map for Team Fortress 2's Mann vs Machine mode, and getting the idea of using a middle of nowhere road setting, I've taken a step back in order to take a closer look at how the three existing maps function. To roughly explain what Mann vs Machine IS, the game mode is about a team of 6 players defending a point from several waves of enemy robots that are trying to transport a bomb to the player's point. Although what kind of robots will be appearing will show up at the top of the screen, they still have something of a run up to give the player time to see which robots they will be encountering (They are invincible at this point to stop players killing them before they've made it into the map.). Essentially, each Mann vs Machine map offers branching paths that the robots may take in any wave, and not all of them will necessarily take the same one. These paths also offer opportunities for the player team to defend and halt the robots progress. Some maps also offer trap holes that the bomb can be forced into, forcing a new one to appear at the robot's spawn point.

To show this, I made a rough top down illustration of the map Decoy with the coloured lines showing the possible routes that the robots can take.

So with any map I try to design, I will need to bear in mind that the robots must have enough branching paths to go down without also overwhelming players, and provide vantage points for said players to be able to make a stand. I will also have to be concious that I need to consider suitable spots for Engineers to build sentries and for Snipers to... snipe from.


As I mentioned in an earlier post, I'm working towards a gas station theme, which I've been doodling on loose paper and my magic pocket book.

I'm going to try and work out ideas along the way, I only know so far that I have a gas station and junk yard idea (a 50's/60's style gas station would look pretty neat) and a road. Along with some hills for the robots to run down during waves. I'm currently considering how to make the paths branch and make sure that the player can't wander out of the playing area. I might have to build the area up some more.

Edit - A little further internet scraping has yielded http://wiki.teamfortress.com/wiki/Example which is quite literally an example Mann vs Machine map. I might go into the source engine or Gmod and have a look through.

Assignment 6 - Initial Thoughts

Right. So Assignment 6 is to design a 3D level in Google Sketchup using a game of our choice, or even our own levels from the earlier 2D level design. My mind isn't in the right place at present, as a long trip to Sheffield for no discernible reason at the crack of dawn would probably do to most gentlemen of the 21st Century.

I've given the task some thought, and although my plans at present are to try and recuperate from what has been a busy week packed to the brim with early mornings and late nights, I have decided that I'm going to focus my attention on creating a Mann Vs Machine map for Team Fortress 2. Partly because I can't envision extending my 2D level design despite initially wanting to, and partly because it would simply be fun to try and make something I've always wanted to do for a game I enjoy immensely. Of course, I'm under no illusion that we're working in a program that won't translate to any game engine, but it never does any harm to have a dream. Besides that, over the christmas holiday it might be a fun little project to learn how to use the Source engine and create a rough version. At least, if I get that far.

I shall be scanning some pages from my book and uploading some found imagery at some point over the weekend, and my early ideas are focused around the idea of a highway, with a middle of nowhere gas station and scrap yard. I'm not expecting miracles in Google Sketchup, so the plan at present is to only create rough silhouettes of objects rather than attempt to create perfect likenesses. I've also been dissecting the existing MVM maps to try and get a rough idea on how to approach the design... given that one has to consider the players as well as the paths for the AI team to follow.  Again, those drawings will be uploaded in due course.

Assignment 5 Conclusion + 3D Level Design

Well, today's lesson has come and gone, work handed in and feedback received. I'm satisfied with what the tutor said to me... I was far less certain about what to discuss regarding the game mechanics than I was about the art aspects of Team Fortress 2. I have a great interest in the TF2 art style, which lead me to have already delved into the whats and whys and appreciate it. Certainly if there was another chance to write this document, I would strive to be more focused with the mechanics part and whittle it down - I felt like I was trying to explain too hard.

And now Assignment 6 is up and running, to be handed in in two weeks. After a brief play in Google Sketchup, we have been tasked with created a 3D level of our choice. Right now, I'm torn between trying to make a 3D version of the 2D level design I did in the third assignment... or making an MVM map for Team Fortress 2. Each has it's advantages and challenges... so one is going to sleep for the night and get some preliminary ideas down tomorrow. For now, BED.

Assignment 5 - Oh Dear

I've just uploaded my assignment to the best of my ability, and I feel forever thankful that I decided to look at my blog list before going to bed. My assignment was finished, and I somehow made the dreadful mistake of believing the deadline was on Thursday, so I have pretty much run out of time to correct any flaws in the work. 

I can't help but feel that I should have gone more in depth with the piece, although given that I'm already 78 words over the word count... that might not be possible. It may be too late now for the printed version, but I might yet be able to make refinements to the online version. 

For now, Frank is going to sleep. 

Assignment 5 - Deconstruction and Analysis

My chosen game for this assignment is Team Fortress 2, released in 2007 by Valve Software. A sequel to the Quake 1 mod Team Fortress (1996) and the Half Life 1 mod Team Fortress Classic (1999), Team Fortress 2 was in development from 1998, and the game evolved in several directions and incarnations as it first changed from the Gold SRC engine to the Source engine, moving the game from a modern setting to a human vs. alien invasion setting before finally concluding with the game we know today, set in the late 1960's and inspired by early 20^th Century industrial artwork. My aim for this assignment is to explore how Team Fortress 2 uses both familiar and original game mechanics to create a game that encourages and rewards teamwork whilst also satisfying a player's competitive nature, and how it's distinctive art style helps the player identify other players and navigate the environment. 

1. Gameplay

Fundamentally, Team Fortress 2 is a multiplayer team based first person shooter, and in terms of basic gameplay a player can run, shoot, jump and crouch, actions that are common across all 9 available classes. Already discounting iron-sights or the ability to sprint or walk, the game further deviates from others in the genre by creating different play styles for every class, so how one would play as a Soldier differs from how one would play as the Scout. And it is these differences between the classes that actively encourages players to work together – each class can counter another class, and there is no advantage in players all choosing to play the same character class. Instead, the opposite is true with class stacking resulting in diminished results against a team of players working with different classes. And in that vein, the euphoria that a player can experience when a team is well balanced and cooperative as they fight for victory can be highly rewarding, further rewarded in being able to kill the losing team in a“humiliation mode”.

Rough example of how three classes counter the other

It is from these individual mechanics for each class that encourages and rewards players for working together as a team for a common goal. Like most multiplayer games, Team Fortress 2 includes a kill feed displaying which killed another player and the weapon used which adds to an individuals score, however it also brings a notion of assisted kills, with the last two players to kill an opponent being credited with a joint kill, with points being allocated to both the player that made a kill and the team mate that assisted. On top of receiving points for killing opponents and capturing points, those playing as classes that don't necessarily fight directly can also receive points for helping out their team, whether it be points for Medics healing injured players, points for the Pyro and Sniper extinguishing team mates that have been set on fire, or points for the Engineer for other players using a teleporter he has built.

Kill feed credit for a kill being allocated to two players. Also a credit for defending an objective.

  However, individual player points rarely mean anything if the team does not achieve it’s objective, and instead points are used as a way for the player to track their personal records – this is especially important when it comes to new players unfamiliar with the game. Death in general is approached in a light hearted manner, and as the inexperienced player improves, death will sometimes bring up a message informing them of having dealt more damage or healed more points than in previous lives, rewarding persistence and challenging the player to improve to beat their previous record. As mentioned above, these stats are more than most kills, and can involve the number of captures, number of teleports, amount of healing achieved and so on. The game further tracks these records, and uses them to encourage new players to beat their previous best rounds, and also challenges more experienced players to continue improving. 

A kill screenshot, with a message indicating that the player almost beat their previous record in assists

Another example of Team Fortress 2 using game mechanics to direct players towards working as a team rather than acting selfishly includes one of the most distinctive features of the game, the Uber Charge. Most other games that feature medic classes, for example the medics in Killing Floor (Tripwire, 2009), Brink (Splash Damage, 2011) or even the original Team Fortress Classic, requires the player to be in close proximity to an injured team mate in order to restore health... and as a result, players in these games generally play more selfishly by using the healing abilities to keep themselves alive whilst fighting with the rest of the team instead of helping those in need of health.

As a Medic heals injured team mates via a healing beam that visibly shows a team coloured effect when used, he will also slowly fill a bar at the bottom of his screen, which will flash once the player has filled the bar entirely. At this point, whilst continuing to heal a team mate, he can activate an Uber Charge, which is effectively 8 seconds of invincibility for the medic and their chosen patient. The Medic cannot attack and be invincible at the same time, and the team mate must be connected via the healing beam to receive the benefit. 8 Seconds of invincibility can make the difference between victory and defeat in the choke points located in every map, a way of breaking through the enemies defence to create a path for their team mates to continue. The Uber Charge is a reward for the Medic player's patience and hard work to heal and stay alive, and a reward to his team mate if the uber is used effectively to break through an enemies defence, both players stacking points in the process… furthermore, the praise players may receive from their team mates for successfully using an Uber Charge can create positive encouragement, especially during a final push that results in victory shortly afterwards.

A Medic deploying an Ubercharge with a Heavy, defending a control point.

 

2. Art

Another aspect of Team Fortress 2’s underlying design involves the art style and how it is utilised to enhance the gaming experience beyond cosmetic appeal. On face value, the game simply appears cartoon like and heavily stylised, and upon the game’s final appearance being unveiled the initial reaction from fans of the original were negative decrying a lack of realism and ‘kiddie’ graphics. Since release, Team Fortress 2 has instead received praise for it’s distinctive visuals, and like the rest of the game the graphics were a very deliberate choice in the game's design. Stylised, cartoon appearances help to emphasis the humour and fun that the game presents to the player, instantly making gameplay aspects like rocket jumping seem more feasible than if the graphics were set in a realistic environment.

Typically, games that have separate character classes make all player models appear identical in shape, and rarely provides the sort of visual information that allow team mates to easily identify which classes the others are playing. Looking at Killing Floor once again, any character model can be used regardless of the class chosen, and as a result it can be difficult to identify which classes the other players have chosen. One of the principle ideas behind Team Fortress 2 was to make it easy for players to easily identify their enemies visually, even when the player may see nothing but an outline, and with that philosophy in mind made each class bear a unique shape distinct from the others. Furthermore, the characters are designed with the most detail being allocated to the chest, to direct the player's eye towards the weapon being carried at the time. Together, even in silhouette, a lot of information is presented to the player in a clear and concise fashion without being intrusive or distracting the player with excessive information.

Demonstration on how each class is unique, even in silhouette

 Likewise, the art style of Team Fortress 2 is used in the design of the levels featured in the game, the colour palette being subdued and neutral with the suggestion of detail rather than than featuring elaborate textures. This in itself serves to look visually pleasing without distracting, and also further emphasises each team's base... which stand out with their team colours. Whilst maps are entirely asymmetrical, each team bears distinctive flairs to distinguish one side from the other, with the Red team appearing old and wooden and the Blue team appearing sleek and cold, adding to the cartoon and stylised appearance of the game by making the concept of two rival groups being situated opposite each other feasible by following a vintage spy theme, with secret bases hidden by innocent and bland buildings in the middle of nowhere. In terms of the actual game, it aids the player by making it clear where they are at any time and reduces the odds of a player getting confused and lost – the asymmetrical level design also serves to prevent one team from having an unfair advantage over the other.

Team logos and bases from CTF_2Fort

Although I have barely managed to scratch the surface of what makes Team Fortress 2 an ingeniously designed game, the aspects I have brushed upon hopefully serves to highlight the very basics in how the game conveys information visually to the player, and how the game uses game mechanics to encourage team work as well as to encourage individuals to continue playing and improve.