Video Game Design/Programming

Programming is the way you put your concept in practice, how you build your game. There are a wide variety of programming languages. These languages will be covered in more detail later on.

Game programmer or game developers, take the implement the game design, most parts of a video game programming are boring and non-creative unless the game design requires some innovation or updates. But take care the worst situation for any developer especially one implementing a video game is in having a poor video game design to start with, the inability to make decisions or be non committal to choices will result in the developers having to implement bad concepts until the game designer accepts the results (or is forced to give the go ahead because of time/costs constrains), resulting in a substandard product.

Not all developing is attractive and in games most of it is not, for instance the front of a game is mostly common amongst most games designs doing one more is just going through hops. Now let's take for example the task of supporting hardware changes in video cards or even the low level optimization tasks, that would be the top of the cream for a creative programmer.

Note:
This notions can also serve to establish a good game developing team, not all jobs are the same or even as complex and depending on how down to basics you wish to go on developing your idea, you may need very few expert programmers.

Because it is arguably the most difficult part of game design, we are going to spend a fair bit of time on it. If you have some idea of what language you want to learn and have read up on the various languages, you should actually start learning. If you can take classes that is great, if not there are many alternatives. Buy some programming books, look up some tutorials on the Internet or on Wikibooks and look through the source code of Open Source programs. Don't think it will be easy, it is not; but try and have fun with it. If you do not have fun that sort of defeats the whole purpose does it not?

Before you start programming, it is important to choose a programming language that suits your needs. Remember that no language is perfect for everyone or every situation. There is such an incredible selection of languages that it can be nearly impossible to choose one. Before you make up your mind to learn Java or Assembly, make sure you know what you are planning to make. How complex is the game? Certainly it would be counter-productive to spend a lot of time and energy learning a language that does not have the power to make what you are planning, just as it would be counter-productive to learn a language that is overly complex for your needs. When you start reading about the various languages, you will inevitably read about "low-level" and "high-level" languages. At this stage this does not concern you so much, but later on it will be very important. Essentially, low level languages (ex: C++, C, Asm) are more powerful and faster allowing you to control the inner workings of the computer. However, they are generally harder to learn. Higher level languages (ex: BASIC) are easier to learn and use, but lack the power and flexibility that lower level languages have.

Sound plays an integral part in any game as it affects the mood of the player at a conscious and subconscious level! Could you imagine playing UT or Quake without sound? It would be unbearable! Sound in games ( depending on the game of course ) generally consists of background music, event sound effects ( honking a car horn, gunfire etc ) and environmental sound effects (footsteps, wind blowing, birds, beach waves, bugs, echoes etc).

Background music depending on the game can play all the time, but also like in film stop completely and change to fit certain moods, such as if you enter a battle the music might change to a track with a faster beat or become more erratic.

Sound effects on the other hand, play when they are triggered by some event. If a player were to open a door, there could be creaking noise coming from the door. Sound effects can add a lot of realism to a game and choosing the right sounds can really make a game come alive. Please note however, too many of them, or ones that have unrealistic properties, can hurt the game experience, or annoy the player. For example there is a game with a jetpack in it. This jetpack has unlimited fuel, so players can float in the air for an indefinite amount of time. While the jetpack is running, it makes a noise like rushing air. This noise becomes very annoying over time, because it is heard a lot during the game. Also, if a sound has strange properties, it can detract from realism. Eg, a machine gun that goes quack, or a machine gun that has sound faster than its actual firing rate.

Environmental sound effects are triggered simply when the player enters the environment and play in a loop until the player leaves. Please note that these sound files are most numerous and multiple sounds are sometimes looped in a random order to create a sense of variety in a environment (i.e. two birds singing that sound completely different or two characters walking and the shoes clucking sounds different for each character).

Games usually give many options to players regarding input. Common means of input include the mouse, keyboard, joysticks, and gamepads. Ideally, a game engine should abstract the input so that the user can select from any of the above. Furthermore, one important thing to remember is that all gamers have different preferences in regards to key or button placement, and often want a certain specific configuration. This means the input should also be abstracted to allow buttons or keys to perform different actions in the game.

It's important to first understand the different ways keyboard events can be interpreted by the program. The most common ways to receive keyboard events are through callbacks and polling.

Callbacks - Often used by games that utilize the GLUT library, function pointers are passed to GLUT which "register" that function as the keyboard event callback. This means, any time a key is pressed or released, GLUT calls the respective function, passing the key data and allowing the program to respond accordingly.

Polling - Used more often by games using SDL, polling is helpful if callback functions break abstraction in an engine. Polling is a process by which the game checks a collection of keyboard events in its spare time. So, for each pass through the game loop, your game can poll the collection, resulting in quick response to key events, and no loss of data.

Every operating system has its own TCP/IP API, so if you are planning on developing for a specific platform, then you must look into that OS's SDK (such as WinSock for the Windows API). If you are writing games for portability across multiple platforms, one good possibility is SDL_net.

After choosing the networking API, classes should be constructed for a game engine that encapsulate sockets. One must also make the decision between networking protocols, TCP and UDP (although through abstraction, either could be used).

TCP - This protocol sets up a connection between two computers. Data sent between computers is resent if any errors are present. The disadvantage to this protocol is that it is not as fast overall as UDP.

UDP - This protocol does not set up a connection. Data packets are sent to an address, and the sender does not know if it arrived properly and error free. A protocol could be written using UDP to provide error checking and resending.

The decision is up to the programmer, and what is best for the game. If the subject is an online game of chess, where speed is not a major concern, TCP could be used to avoid some headaches. But, for a large team of people in a FPS, UDP would be a better choice, due to speed.