Introduction

   It took me many years to learn the fundamental principles of creating a game. Although I can not claim to have a complete grasp on the matter, I do believe that what I have learned would be useful for those wishing to enter the field, but are unsure of how. The Beginner may find themselves in a new world of immense complexity with which they have little to no experience, and many of the tutorials already existent seem to either cover a very specialised topic, or already assume that you have a general comprehension of the process of developing a game.  However, my initial motivation to write this tutorial was perhaps not as grandiose. One day I sat down and realized that I was bored. After a dilemma of perhaps twenty painfully long seconds, I have decided to write this tutorial, outlining the basics of developing a game. This tutorial should help you understand how to create a game, or at least what to look for in order to learn what you need to do. Of course, this is not an in-depth tutorial, for such a task would require the composition of books as opposed to posts. But with luck it should prove to be useful for those of you who desire to take up the occupation of creating a visual and interactive manifestation of your ideas.

    What you may not find in this tutorial is a description of how to create a 2D game. While I may add this information sometime in the future, at the moment I will rudely redirect you to perhaps read into the wonders of SFML and RenPy ^_^

    The general intention is for you to use this tutorial as a starting point to launch your study. Step 3 in particular is most beneficial if you take your time to google the things mentioned, looking at them from different perspectives. Information on them is widely available - it may simply be difficult to know what to look for for those unfamiliar with the concepts.

   Before we commence, I should note a few prerequisites. The main one is: you must be willing to learn. The journey of creating a game may be turbulent if pursued in haste, and you may save some time by ensuring that you are willing to embrace genuine criticism and advice. There are many young (and maybe even not-so-young) developers who enter the scene by immediately attempting to organise a team on some forum, often with the subconscious goal of basically having others work on what they feel is a good idea they have. Indeed, I was once such a person. I was rejected on many occasions, and when I was not the team merely fell apart within days. In retrospect, the forum posts I made at the time may be some of the most embarrassing things I have ever produced. Such behaviour should be avoided. Instead, one should begin by learning on their own, and perhaps making a small game or two. Otherwise, one can hardly claim to have the experience to be taken seriously. I am merely warning you so that you would not make the same mistake as I did. If this was indeed your approach, the following point may prove illuminating.

   Ensure that you are not afraid of learning, especially the more technical aspects of development. Programming may seem a daunting thing to learn. It would take months, so is it worth it? This may apply to a variety of topics (in this case, my opinion would be "yes"). However, learning these things is often quite fun if you are patient, and honourable goals in their own right. Patience is key to game development, which can often be a time-consuming and error-prone activity. Not unlike more traditional art, truly.

   Anywho, the more technical prerequisites would include an internet connection, and the ability to perhaps download at least a few hundred megabytes of material. The desired power of the computer would mainly depend on the type of game you wish to create. I personally have managed to write a pong clone on my Android tablet in under a few days, but I would certainly not be able to boast the same for a game with graphics rivalling GTA V, which would require a modern desktop machine to create. Aside from that, your most useful tools would be patience, and persistence.

   If you have any questions or comments, I would be interested to see them and perhaps modify this text in accordance to the new information/request.

   Now that we are done with the tiresome introduction, we may begin ^_^

Step 1 : Design the storyline + Game mechanics

   the first step in creating computer game, usually, is drafting the storyline. In the game industry this is usually one of the first steps undertaken and should not be ignored, unless your intention is to merely create a quick game without any profound story for your personal education and fulfillment. The degree to which you develop the story may depend on the type of game, and its distinguishing factors. Certain games, Minecraft being a popular example, rely on (at the time) unique and interesting game mechanics to propel them into fame. Others, such as Silent Hill, focus on the opposite, keeping the game mechanics fairly standard and instead concentrating on the story. The balance you wish to strike would be your own choice, although I should note that having one does not require the lack of the other. A game with unique gameplay mechanics could very well contain a profound and memorable story. Maximising both of these factors simultaneously may hint at a talent for game design.

   When writing your story, you may wish to keep it somewhat realistic and engaging. Contrary to popular belief, a good game often is not merely limited by the artist's imagination, and may rely on a convoluted set of systematic concepts that combine to form a single complex experience. One thing to warn against is the absence of logic in puzzles. While it may be tempting to write a puzzle (and I am using the term broadly here) where the solution is not so obvious, you should make sure that this ambiguity is not a result of simply giving the player insufficient information to make a choice. Ideally, the perfect player should be able to complete the game without a single failure, not having to rely on pure guesswork or to try to understand the eccentricities of your mind (unless the game is trial-and-error based, as in the game Limbo). Meanwhile when I said to try to keep things realistic, I meant to keep them realistic in the context of the game world. If your world is designed to have Gigeresque biomechanoids roaming an abandoned space station, or perhaps flying rabbits, your story may still be fully acceptable as long as the world they inhabit reflects and explains their presence. A true travesty would be to have things that would be unrealistic for the game world you have established (such as, flying rabbits in a biomechanoid-infested space station). Your imagination may be powerful, but genius often involves directing it towards a consistent vision.

   You should ensure that if you do choose to design a game that naturally relies on a story, you should keep the story... Well, somewhat interesting and preferably omnipresent. Were you to create a game that is simply a series of levels and zombies, then you may encounter some difficulty in captivating your audience. Try to find more information about developing the kind of story that would suit your game, and of course make your own reflections and choices. One great source of information regarding game storylines is the one written by Frictional Games, and is entitled 'In the Games of Madness', although it is aimed more at horror games. Also you may want to look for video game cliches and what makes games boring or great, as this would help you with creating a believable story. One fruitful and exciting way to explore how to make a theme great I found to be to take elements in that theme (provided it is well-established), and write about them, attempting to explain them and the reasons behind them. Write about what you found works in games, and what you found didn't work, and explore why these things worked or failed. You may be surprised as to what you would discover, and with luck the topics you cover will naturally lead to explain other topics once combined. As you progress, you should become more confident in how to create a story that truly works, and the pitfalls to avoid.

   I wish to note the definition of the word 'story' in game development. Most importantly, it is not simply a plot of events. It is everything there is to the world of the game. It explains why there might be a gun lying around in a casket, why there are monsters roaming the streets or simply why there is this smiley face trying to save the world. No item in the game should be placed without the story in mind. Place an overturned chair and a broken bottle after a party, but never an F-16 stuck through the window. While this may seem obvious, you should bring the concept further. Items do not simply happen to be lying around. Somebody threw them there, in a rage, perhaps, or simply because they were too drunk to do otherwise. All of this is part of the Story, and it would not matter how small and insignificant it seems. A great game may contain many hidden sub-stories for the players who care to explore, and this can turn the experience from "just another game" to a truly unforgettable experience.

   One way I use to think up ideas is to remember my dreams and nightmares. They usually provide unique stories, and if slightly altered, could be sufficient for complete games. Listening to music certainly helps in designing the atmosphere. Another method is to simply create a level based on a general theme and then develop various ideas to conform to that level. Although this method might seem ineffective, it is a possible solution, used by some professional game developers in the past. I personally prefer to reach a balance between the two. In the 'real world', as some call it, the architecture of an area does not conform to a storyline, but the opposite is true. Although it would be acceptable to change an area to fit the story, I have discovered that this should not be overdone. The appearance of fine-tuning for the player can be catastrophic. You should not create an area simply to provide for the storyline, but must also take into account the various props which would have been present without the story, such as toilets, car parks, torture chambers etc. and make sure that they present the appearance of being constructed for efficiency and not the gameplay itself. For example, vents should not only be present to reach the current objective, but to ventilate the air. Other vents should exist, even if their only purpose is to provide air conditioning (nevermind that games often don't have actual air).

   A vital component of games only briefly touched previously is the game mechanics. This would include how the player would interact with the world, whether the game is an fps or a tps (first person shooter or third person shooter), point-and-click vs GUI (graphical user interface) interaction, and so on. In some cases this might come as greater inspiration than the proposed story itself, though care should be taken as not to simply slap on a story onto the game. Equally, one should not slap some puny game mechanics onto a story to provide the excuse to call it a game. It would be advisable to develop these two concept parallel to each other, as it might be necessary to modify one in order to benefit the other. All games should be unique, or you might as well copy and paste another game. While complete uniqueness may be an unrealistic goal, the least one should strive for is a feature that distinguishes it from all the other games out there. Otherwise your game may turn into yet another clone, to be scorned and then forgotten.

   I also wish to note that all of these concepts should be considered dynamic, and the development process never be limited to what is drafted on paper. If an idea comes up which appears better and would not conflict with the already created assets, then it should be investigated. Even if it does conflict with the assets, if the idea is good enough, the waste may be forgiven. In the end you decide what is the best course to take (or, well, whoever is in charge!).

   Another good thing to do would be to familiarise yourself with the limitations of game technology before you embark on planning all the millions of cities you want to be accessible by the player. Some things are yet beyond the capabilities of modern machines, and many things (such as dynamic model modification) can be slow as a consequence of modern PC architectures. On the other hand, some things may be possible, but not supported by existing high-level game engines, which would require you to implement them on your own.

   It is often advised to develop a game prototype as soon as possible, which would help determine the worth of the game before much time had been spent on developing it. Prototyping involves simply putting in place the general gist of the game without focusing on the details with the main goal of producing a playable game quickly for testing purposes without much emphasis on quality. For example, animation may be overlooked, and the levels may be whiteboxed (as in, merely composed of rough shapes to serve as placeholders for upcoming assets). Games with heavy atmospheric emphasis may find this less useful, however.

   

Step 2 : Decide on our software

The next thing which you should do is choose on the the software that you consider should be used for your game project. I will go through some choices that I have found optimal. Many of these are not entirely free, but some can be for educational purposes. In any case, free alternatives are provided.

Modeling: Here are various programs which could be used to create models. If you are unfamiliar with the concept, the next section will explain it in more detail.

1. 3ds Max is a package provided by Autodesk that I personally find quite effective when dealing with models and everything model-related (Texturing, UV Mapping etc.) While it does not handle sculpting as well as may be hoped (despite having support for it), its poly-modeling capabilities are ideal for games. You would be able to download the 3ds Max trial here: http://usa.autodesk.com/3ds-max/ and try it out for yourself. It supports hundreds of tools necessary (and optional) for game development, while not being limited to the field, and is used by professionals worldwide.

2. Blender is a popular free alternative if you do not have the money to spend on expensive software such as 3ds Max. I do not truly have much experience using blender, and I have heard that the learning curve is steep, but many people have created decent models using it and this seems to be a good reason to recommend it. But choose this only if you are unable to afford 3ds Max and are not a student, as, from my knowledge, Blender is somewhat more unstable and less sophisticated. You can download blender from here: http://www.blender.org/download/get-blender/

3. Zbrush is another program that can be used to create models, but especially high-poly "sculptures". Although learning it is also somewhat difficult and it requires actual skill, working with it is basically like working with clay if you take the time to learn how to use it. You can download the Zbrush trial from here: http://www.pixologic.com/zbrush/trial/

    An alternative to Zbrush is Sculpturis (Free) (http://www.pixologic.com/sculptris/), which is made by essentially the same company. It is quite powerful, and should not be overlooked if you are not willing to spend much money.

4. Mudbox is similar to Zbrush, and is provided by Autodesk, which means that it has quite good support for interaction between itself and other Autodesk software (such as 3ds Max). The learning curve is considerably less steep than in Zbrush, and I find the user interface much cleaner. While it is less powerful, its superior support for a Wacom touch tablet makes it personally my tool of choice for digital sculpting.

Of course you might decide buy something exotic such as Maya, but in my opinion it is more suitable for movie development and visual artist. As game development in many cases involves the careful manipulation of polygons, Maya does not seem to be as suited for the task.

Audio:

   Although I am not much of an audio artist, I am still able to recommend a few programs that would let you create and manipulate music/sound effects.

1. Audacity (free) is a good choice for your general audio needs, and has many features you may find useful. It is a quite popular choice, which I feel to be justified. One thing it may not allow you to easily do, however, is create music from scratch.

2. Reason is a quite good synthesizer I have discovered that allows you to create music from a huge range of extensible instruments. While somewhat expensive, I was not able to find any free alternatives that yielded decent production quality.

3. Record your own sounds, or use the internet. It is very difficult to create sounds using the computer, so my advise would be to buy a good microphone and record different sound effects for your game. Then perhaps edit them to achieve a science fiction or horror feel. If you get a keyboard, you may record directly to the computer without much quality loss with the correct cables, and you would be able to use it to directly control software such as Reason through a MIDI interface. While learning a new instrument may seem like a daunting task, as many things, it is generally fun, and surprising results may be achieved even within a couple of days. Chances are you may find yourself developing a new hobby with your daily practice sessions.

Texturing: Textures are also an important part in creating a game. You should be able to use all of the software under the "Modeling" section to texture, so I will only show you software that would convert your textures from simple images to seamless normal-mapped textures.

1.Photoshop is a natural solution, albeit a rather expensive one. However, once obtain, it should serve the majority of your texturing needs, rendering the other tools essentially non-essential for any practical benefit.

2. Crazybump allows you to generate quality normal maps from a texture without having to create it yourself by hand or using special hardware, which can save quite some time. This is the tool which I currently use use for normal maps.

3. Paint.net is a program which allows you to manipulate textures in order to combine or enhance them. It is free, and much easier to use than Gimp (at least from my limited experience) and especially photoshop. I constantly use it in order to help texturing my models, and it never fails me in what I need to achieve, especially with the wide range of plugins available.

 

Game Engine: The final piece of software you will probably need. It basically combines all your assets together, allowing you to create levels, script them and play them. There are only three game engines that I have any mentionable experience with, and they are all relatively high-level. Anyway, they are:

1. UDK, commonly known as Unreal Engine 3, stands for the Unreal Development Kit and is a quite good choice for the ambitious developer. It has everything that you might need to create a game, although be warned that it is generally designed for FPS-style games, and may not be as suitable for other genres. Also, it features quite some overhead, so if your goal is a simple game then you may wish to avoid it. I find that there are also some difficulties and problems, such as the quality of real-time lighting and the difficulty in creating intractable meshes. Others, on the other hand, do not seem to have much difficulty with these things, nor with what I consider a quite outdated interface. It can be downloaded from here: http://www.udk.com/download

A recent development was the introduction of Unreal Engine 4, which can be downloaded for a small fee complete with source code (code that runs the engine itself). This certainly seems to be the better choice for the experienced coder, although it is still in an early stage of development. A powerful computer is required to run this version.

2. Unity offers a much more flexible interface compared to UDK, with a greater ease to alter the gameplay, allowing you to disassemble every asset and script it using the easy-to-use C# or JavaScript. Although Unity does not feature any node-based editors such as UDK's Material Editor and Kismet, it still might be easier in the long-run as it does not require you to look through all of the code already present (plus, such features may be gained with the use of plugins). Writing in JavaScript is much simpler than it seems, and can be done by mostly anyone who cares enough to attempt to learn the language, although I found it at a disadvantage to more complex languages when it comes to scripting more advanced things. The biggest disadvantage of Unity is that it does not offer as many features as UDK, making its graphics seem laughable in comparison in spite of recent developments. But If you are intending to create a small game, possibly to be played in the browser or on mobile, then this may be the ultimate choice. It might not have as many features, but it is certainly much easier to implement and script new assets in Unity compared to other game engines. You can get Unity here (Free/Pro trial): http://unity3d.com/unity/download/

3. Cryengine 3 is a great alternative if UDK and Unity do not suit your lusts. Now, I would go further and say that it is the superior of these engines, but that would only be my opinion. Packed with great dynamic lighting, realtime development and a friendly interface (all of which are not present in UDK), it is a great engine to use in order to fulfil your gaming dreams. Any info, as well as the download page, can be found here: http://www.crydev.net/

There are many more engines out there, but most are perhaps not worth mentioning. An exception would be the range of of lower-level engines, such as SFML and Ogre3D. These are engines (if the term applies) that directly integrate into the game code you are writing (assuming you choose to write the game yourself in a programming language such as C++). This, while making them more difficult to use, gives you much more flexibility. If you desire full flexibility, however, and are willing to spend time learning new concepts, you may wish to consider to merely use a graphics library such as Direct3D or OpenGL (the latter being my tool of preference). These are considerably harder to use, but are the things that essentially power the graphics of all of the game engines mentioned above. If you choose to use them, you will no longer be as constrained by arbitrary rules and limitations that you can't control, although in the end these may be more suitable as an educational experience.

Step 3 : Start creating

Now, as you are ready to start creating your game, the most important step is to actually start doing something. It is doubtful that one person alone would have all the skills required to create a game, unless you are starting small as I have mentioned you should try doing. If you are not, I am assuming that you have some experience, in which case you may consider searching for a team of sorts.

First of all, I will introduce some of the basic concepts you may wish to know before you begin.

Static meshes:

Static meshes are basically objects that make your game look better, but usually not actually serving any purpose, except perhaps to block the player's path. These include houses, pipes, rubbish, glassware, tables, chairs etc. These objects usually do not serve a gameplay-related purpose and are simply there to make the scene look life-like, as well as potentially contributing to the story. To create a static mesh you should first create the model in an external modelling package such as 3DS Max. Common techniques are poly-modelling (manipulating individual polygons and geometric figures to look like the thing you are hoping to represent) and sculpting (using a program that essentially simulates clay, allowing you to sculpt in details similarly to how a traditional artist would). The latter is generally best done with a graphics tablet. How to do this is beyond the scope of this tutorial, but is widely documented online. When you are done, you should get working on the UV map, and any textures you may need.

   Textures are essentially images that are applied to the 3D geometry you have created to add extra realism. You might decided to use/create a proper texture (detailing the specific intricacies of the object you are texturing) or simply a basic material, such as perhaps metal, to apply. Both can be used depending on the type of model you have. For example, a rock may only require a generic 'stone' texture, while a building would require something more specific.

   How a texture is applied to the 3D model is controlled by what is called a UV map. A UV map is basically the 3D model flattened onto a 2D plane, where each polygon represents the corresponding polygon in the final 3D product. Essentially the idea is to conform this flattened object to the texture you have designed. If you do not wish to suffer the pain of UV manipulation, you may wish to consider using a tool such as Mudbox, which allows you to automatically generate a UV map and essentially paint directly onto it using digital brushes. However, this approach has its own disadvantages, such as the inability to tile textures (as in, repeat the same image multiple times.

   My approach to creating a UV map is this: add a UV map (usually a box) to the model, unwrap the UV map, load in the texture you have designed, and begin conforming the UV map to the image. I am specifically thinking of 3DS Max, but the approach should be similar for other software. It is by no means a perfect solution, but I found it to be reasonably effective. Alternative you may be presented with an option to render the UV Map to an image file, and create a texture that fits to the UV map you have created, essentially working in reverse. If this is confusing, the don't despair. It is much clearer when you actually attempt to do it with the help of more specific tutorials detailing a suitable approach for your software of choice. If you do not apply a proper UV map, any texture you apply to the model will look stretched and generally strange.

   When models are imported into a game engine, the textures also need to be imported and made into materials. The materials are basically a combination of your textures (Diffuse, Normal Spec etc...) with additional properties and effects. They can be adjusted to suit what you need, and end up usually much more than simple images. Materials may be made reflective (to an extent), refractive, glowing, pulsating, etc. These materials are then to be applied onto the appropriate objects. Collision is applied/generated. Static meshes by then are ready to be used in your level, while other objects may require animation to be applied, programmed, have sound effects associated with them, etc.

Characters:

Characters are generally more difficult to create than mere static meshes.  They would require extra programming, and probably animation. To create a character, both main and NPC, you first have to prepare the model as described in the Static Mesh section, but then you also need to create what is called a skeleton to go with your character. The skeleton basically tells the engine (and your animation program) how to move the limbs in order to give them a realistic look, deriving its name from the fact that it often resembles the bones of an actual skeleton. Without it, the computer would simply interpret your model to be a basic set of polygons. After this is completed, different animations should be created, such as walking, running, turning left etc. Animations are generally done using key frames, which let you specify a specific position in space for something at a particular time. These positions are then interpolated to result in smooth movement. Perhaps the final step would involve programming the character: giving instructions such as: 'Play THIS animation of THAT button is pressed', or 'Ragdolize if health reaches 0'. This step would mostly depend on the game engine you are using, as different game engines provide different interfaces to program your game.

   If you have decided to create a first person game, then the playable character is generally much easier to create, only requiring hands and perhaps a weapon. Most importantly, less time may then be spent on player animation, which can be a quite difficult thing to accomplish well.

   Naturally, not all games would have a human as a main character. Many may not have humans at all. Some may have spaceships, while others cars. What animation you create, if any, would truly depend on the context.

Level Editor:

Game engines often allow you to edit the scenes in your game directly using a level editor. A level editor allows you to place objects into the world, rotate and scale them, change their materials, add animation that you have pre-defined, etc. It is basically where you would generally compose all of the assets you have created into each level, resulting in the final game. If not using a high-level game engine, one may want to program their own level editor to save time in the long run.

Lighting:

Lighting is very important for games, as it is one of the main factors in determining how well the game looks. Pre-baked lighting is when light is basically 'painted' onto the world once, and then never changed. This can allow for realistic effects without any performance loss, since the lighting would be pre-generated, but requires that affected objects never move. If objects do need to move, then pre-baked lighting is often not applicable, and realtime lighting must be used. Realtime lighting is generated for each frame by the player's machine, and thus has a greater impact on performance. However, it can allow for a variety of interesting effects, such as beautifully moving shadows.

Post Processing:

This is when special image effects are applied to the game after it has been drawn to the screen before being presented to the player. These effects may range from simple colour-correction to faked shading (such as SSAO or SSDO). The latter is possible because unlike with traditional images, games often generate depth data, allowing some quite useful effects. Deferred shading is using this to apply lighting itself as a post-processing step, which has a number of benefits (most notably, better performance with a large quantity of lights). 

While there are many more concepts that can be discussed, they are quite broad in span and can often be very specialised to the game engine you are using. To gain a more comprehensive understanding, I advise you to explore the engine of your choice, pursuing tutorials specific to those engines. Either way, the following information should also help.

General steps to creating a game:

While the process can vary greatly depending on the type of game and style of development, here is what I imagine may be a good starting point:

   You should begin designing your story, planning the general outline and establishing your desired game mechanics. This was covered in the previous section. However, you should not delay in the following steps, for they may yield vital insight.

   You should perhaps create a few models for the game. To begin with, you should keep them very general, not focusing on the details of the world as much. While at it, you should begin programming the game, unless the gameplay is so generic that most of your needs are already satisfied by the game engine's default character (if one exists). This should be done in accordance with the story.

   You should proceed this way, and you will see your game develop into something actually playable. You may wish to change parts of the story, and make adjustments to what you have created. 

   When you feel you are nearing completion, you should integrate proper sound into the game, adding music and whatever else you may prepare, as well as voices, subtitles, and essentially anything else you feel your game needs.

   At this stage you may wish to consider getting other people to test your game. Bugs and mistakes will undoubtedly be found, which you will need to fix. Then parts of the game may simply be boring, which may force you to redesign them.

   Well, that's pretty much it. After you do the last step a number of times, you should hopefully have something presentable! Sounds easier than it actually is, for a large game may be composed of thousands of assets. The general routine, however, is often comparatively simple.

Step 4 : Concentrate on the purpose of the game itself.

   Since all of the technical aspects of creating a video game are dealt with, the most important stage begins. Making sure that people like it. You could hire/ask some people to review your game by playing it, or even release a public early demo. As your knowledge grows as to what people hate or like about it, you should be able to improve the experience by changing the game in order to be more fun/horrifying. After all, a game is a failure if nobody likes it.

   Of course, this process also involves fixing glitches or other issues, but by that time you will have enough experience to be able to deal with them.

   Now, all you have to do after it is finished, is to publish it. My preferable scenario would be paying a few percents to a guy who does it for me. Yours might be different. It is your choice.

P.S. If you are interested, here is the latest video of the game which I am developing: http://www.youtube.com/watch?v=4Ixr02N_NO4 (or not the latest... Just check through my channel)

A Quick Overview of Basic Definitions

   On your journey, you may, and should indeed, encounter a variety of terms which are often used by game developers to reference certain fundamental and/or widely used concepts within video games. The majority of the terms listed here are related to visual game features, but I will do my best to also list terms from other areas of the development  process. Please note that this list is not exhaustive and may be updated in the future.

Antialiasing: This is a technique to conceal visible pixellation caused by the limited resolution of a monitor by essentially altering pixels to smooth edges and other visual crispness. This image effectively demonstrates what is meant.

Frames Per Second (FPS/framerate): This is the number of frames that are updated per second. As monitors create the illusion of movement by rapidly updating the image on the screen, the game needs to render a certain number of images (or frames) per second to create the impression of smooth movement. The framerate commonly used in films is 24 frames per second, which is also acceptable for games. However, an FPS of 60 would usually provide the best experience when gaming. It is greatly affected by the computing power of the system and the processing demand of the game, both factors which should be constantly considered throughout development.

Refresh rate: This is the actual image update rate of a monitor. It is not affected by the machine's performance, and acts as a barrier to the maximum fluidity of the visual experience. However, the vast majority of monitors have a refresh rate of 60 hertz or more, which is perhaps the maximum that the human eye is able to perceive. For this reason, it is often irrelevant, with the exception of the next point.

Vertical Synchronisation (vsync): If the game is running at an FPS that is higher than the monitor's refresh rate, certain vertical 'ripping' may occur as the monitor is sent more frames than it is able to display at a given time. Vertical synchronisation is a method to fix this problem, at a potential reduction of the framerate.

DirectX: This is a framework employed by the majority of Windows games to help with the processing of 2D and 3D information. Its greatest competitor is perhaps OpenGL, but DirectX is mainly used. The three major versions currently in use are DirectX 9, 10 and 11, 9 being currently the most popular one due to the limitations of game consoles and the lack of ground-breaking advancements in the other two versions.

Tessellation: A feature of gaming that mostly came with the introduction of DirectX 11, this is the dynamic increase and deformation of polygons on the surface of an object. A greyscale bumpmap may be used to determine this deformation, although other means also exist. A comparison between no such effect being applied, normal bump mapping and tessellation may be seen here.

Assets: This often refers to objects within the game, mainly 3D models.

Polygon/Triangle Count: As may have been mentioned earlier, game objects are normally composed of triangles, and the number of these triangles has a direct impact on the game's framerate. Modern systems can handle many hundreds of thousands polygons on screen at any given time, although they are an important consideration when creating assets.

rendering: This refers to the process of analysing 3D data and transferring it to a 2D image for display on a monitor. In games this is usually a performance-intensive task that essentially paints the image onto the screen, allowing for beautiful effects and realistic scenery to be conveyed.

Draw Calls: These can have a profound impact on a game's framerate, although it is not truly easy to define. It is affected by many factors such as the number of assets used, the repeated use of assets, the number of textures used and the number of lights, among others things. It essentially occurs when a block of data is sent to the GPU (or video card), and should always be considered when assets are created and implemented. Lights in Forward Rendering quickly increase the number of draw calls, so few lights may be used. However, in Deferred Rendering, hundreds of lights may be used without having any major performance impact with only minimal disadvantages.

Culling: In many games, scenes contain far too many polygons to be rendered simultaneously without reducing performance and causing the FPS to drop dramatically. For this reason it is often necessary to conceal parts of a scene while displaying the other parts. For example, if a player stands near a tall wall, all of the scenery behind that wall should ideally disappear to maximise performance. This is often done by simply hiding objects that can not be seen, and creating areas which can only be viewed essentially one a time unless in transition between two such areas. Per-polygon culling can also be used, although nowadays it is normally restricted to only certain objects (such as terrains) given its intensive CPU usage.