One of the more interesting questions facing schools now days is how percisely to teach people how to code. There are several schools of thought regarding this issue.

*-The hardcore programmers, who say you need to start from Assembler, moving individual bits around as if you're John Carmack himself.
*-The low level language advocates, who generally say teaching a limited subset of C or Pascal as an initial language, where there is an ability to handle memory, but the focus is on understanding data structures and program flow control.
*-Last are the High level/Object Oriented programming advocates, who generally are either trying to be low level and use C++ as a starting language, or just go to the logical conclusion of their arguments and teach Java/C# as a starting platform

Now I'll be giving my thoughts on this from the prespective of a student who has infact started in middle of the road fashion, with Pascal, and whose education now branchs both to the low level(x86 ASM) and high(C#).

Each of the solutions has it's own advanteges and disadvantages, however, before I go on, I want to make clear that the final decision on what is better, is obviously very dependent on the goals of the educational plan. If the plan is to serve assembly-line type-coders(which is another blog topic on it's own), then obviously, the latter plan of high level languages, is clearly better. If the goal is to create extreamly specialised and low level coders which will work on drivers and other such low level tasks, then obviously you have an interest in starting with machine level languages.

Assembler type-languages

Forgive me for blatently ripping off an amazing manual to assembly language, but it provides a very good explanation on this. From here.

To quote, why NOT to learn assembly language?

Assembly is hard to learn.
Assembly is hard to read and understand.
Assembly is hard to write.
Today, machines are so fast that we no longer need to use assembly.

These combine into pretty good reasons not to learn assembly language as a starter language, don't these? Howeve they're all arguments that can be worked around. Also, assembly language brings with it importent advantages.

Knowledge. Your knowledge of assembly language will help you write better programs.

This sums up why I'd support assembly language in any fashion as an initial programming language. The knowledge of how high level language commands translate into actual machine code is something that most programmers will not use in their day to day work, however the knowledge will help people write better code and understand efficient algorithms better.
That is, the understanding that when you define a variable in a higher level language you are setting aside memory in some segment of the RAM for a specific variable, or that you use a FOR loop command in a high level language the computer actully uses some registers that change state depending on run iteration.

This knowledge is not obvious, but is picked up by actully writing non trivial programs in assembler,something not very easy to do at the start of a persons education. This is why I'd rather teach a machine code level language at an intermediate stage of a persons education rather then at the start.

Low level languages-Pascal, C, etc.

Languages above the assembler level can't always be differentiated so easily, so I'll split them like this. Those who manage memory for you, and those who don't.
In this case, I'll focus specifically on Pascal as an example, contrasting to a language like C. The advantages of such a language is that it forces you to learn proper habits, learn how to write things without utilising the myriad of libraries available to any higher level language.
To give just one example, learning some of the basic data types, like stacks, lists, queues, is far more beneficial at this level of a language, as you are forced to learn what a Pointer is, what it is used for, etc. To repeat what I said about assembler, even if you never use the language or the specific knowledge(such as pointers), you will be a better programmer because of it. Just to throw an example, would anyone learning a memory managed language know what a Null Pointer exception is? No, because he would never have learned what a pointer is.

In this case, I would also reccomend a specific language, Pascal, because of it's requirments for proper coding, without any of the various shortcuts that you can use in C. The importance of gaining proper habits early on cannot be overstated, not in coding, nor in any other activity that is more difficult then walking across the street.

High level languages -C#,Java, etc.

There is not much to be said about teaching these languages. On one hand, there is low initial overhead before you can start writing non trivial code, this comes from having a large built in library of stuff you can use. On the other hand, the exact same thing prevents full understanding of what goes on under the hood, because it is all handed to you on a platter.
The main advantage quoted about these languages is that these are the same languages that most people will use in their jobs. The obvious reply is that once you know a low-level language, not only is it trivial to learn another language, but going up a level will be vastly easier, since there is actual understanding of how things function.

To sum it up

It is, as always a contrast between how easy it is to learn something, how relevent is it to the real world, and if it actully teachs you anything. I think the balence here is in the low-level languages, there is enough abstractions that you can focus on actual logic and learning how to code(without learning how to actully write,say, a FOR loop) while not abstracting the actual operation.

Does this mean a low level language alone will teach a person how to code in the best fashion? Of course not, esspecially as more and more code nowdays is actully written in a higher level language. However, there is an inherent advantage to learn how things actully function that enables you to learn how to best use a higher level language. A mix of all three levels of code(Assembler, low level, high level) is the best way I've seen to teach, with a focus on the low level.

We've all seen it a million times. A new startup, an Internet organized group, a few friends saying they want to do it. It's not surprising that people want to make their own games, it's a natural want to express creativity in a new medium. If it's not making your own amateur movies with cheap effects, or running a garage rock band, it's writing your own game. Yet how many amateur game projects can you count, that have succeeded? I'm pretty sure the list is quite small compared to the projects attempted.

Before we can answer what happens, lets identify whats involved in
most amateur game projects.

1. A healthy amount of code. This will vary based on project, and how smart the creators are. If they're smart, it'll be based on an existing engine, or use a lot of free middle ware. The overly ambitious will embark on a genre defining journey of extrema graphics and the best game play. From my tone and common sense, you can guess why that doesn't work.

2. Large amounts of art assets. With no art assets, theres no game. Now many projects either underestimate the amount of art involved(every crate, every box, every tree), or assume it's as easy as rapidly coding.

3. Creativity and working under constraints. Most game projects are not about "What can we put in to make this game fun." but rather "What can we take out without hurting the core game experience." It is for this reason that most games, and most advice to new game developers, start out with "prototype, make it simple, make it fun, go from there."

Now what typically happens in most projects? A mix of hubris and plain inexperience. Most projects, quite predictably, are ambitious and wish to do all sorts of nice things, like redefine a genre, create the best game ever, etc. Not really that useful, nor really helpful for anyone. Also, most game projects are started out by programmers, or to be more precise, technologically oriented people. These people typically do not really understand the large amounts of time it takes to create art assets for games, never mind 3D games. Also, lack of planning is a key problem. A design goal of "Make this shooting thingy fun," isn't really helpful, not to a programmer, to a developer, or to anyone bar the person who wrote this down.

Furthermore, many programmer focused projects carry around with them a self inflated sense of the programmers ability. Typically, the project will start from scratch, and take many weeks to get to a state where it's playable and where other team members input is relevant(getting the engine up to scratch, etc.), this is a fatal mistake. The mantra of some of the most successful hobbyist projects, among them Red Orchestra and Counter Strike(both successful First Person Shooter mods which turned into retail products) has been to build on and improve existing games, and to use their code base. This significantly reduces early development time, and enables developers to reach the critical stage where game play is actually defined and tested.

The other side of the mountain is where most people(who are not programmers) end up. Full of cool ideas, and lack of ability to implement them. In many projects, there's a will, theres a way, but no one is around with a map, or with hiking shoes. It's not impossible to create worthwhile mods using only provided tools without writing a single line of code, but it's definitely easier if someone's around who can actually understand what all the jib-jab about for loops, function calls and objects is about.

As an additional factor that is usually not considered, is what the Internet provides. The Internet is both a blessing and a curse to all game makers. On one hand, it's an essentially boundary-less expanse of talent and interested people. On the other hand, it's an vast, uncivilized land full of people who will take any excuse to deride your project even if they can't do better. Many a project has failed because it forgot that it's possible to find artists or programmers on line, who might be willing to help, either for fun, or for a small sum of money. But there are also projects which have failed because they took in interest input too readily, ending with a project that is full of compromises which satisfies everybody.

If so, what is recommended for such projects to succeed? There is no ten step plan to gaming success, no pre-defined list of what makes games succeed, or grab awards. Gaming is littered with examples of this, from Sims, to Loco-Roco and DEFCON. However, there are some general hints that help.

1. Plan early, plan often. Not to be confused with setting things down in stone ahead of time, but before you start any journey of magnitude, it helps to have a clear set of goals, and requirements. This is especially true of any group effort, where, needless to say, every person has a different view of what the game will be about, how it will look, or play. A coherent effort will bring results far more readily then a dozen people each dragging the game to their own likes.

2. Re-use. There are three dozen or so open source game engines(OGRE, or such) out there, there are several commercial game engines which enable mod development openly(Source, Unreal Engine being the best examples there.). If you're writing a game from bottom up and all you plan is to create a variation of a known genre, you're better off using pre-made tools, it's unlikely a first attempt will be better.

3. Re-use. Yes, but re-use art assets. Does your box really need to look different then every other box out there? There are several open source texture repositories, more which cost a small sum of money. There's no issue using them. Some of the most wildly known games, among them Half Life 2, S.T.A.L.K.E.R and Doom 3 all use the same common texture repositories, changing them only slightly before using them.

4. Know your limits. Don't set out to create a 150-map First Person Shooter, don't write an RPG to equal Lord of the Rings. Common sense, but it's important not to let delusions of grandeur interfere with common sense and a need to get a product out of the door.

5. Release early, release often. While this maxim is more true of open source application development then game development, it really is relevant. The sooner you can get some sort of working executable(or mod package) out there, the sooner you can get wide interest, offers of help from random third-parties, or the such. Waiting for perfection before release will result in vapor-ware.

This post came out of a post in SDN which is here.

Games for Windows is a certification program started by Microsoft in their whole "Windows" branding/marketing campaign. It is similar to Certified to work with Vista, and Certified For Vista branding campaigns. To start out, what is Games for Windows? Acording to Microsoft:

The Windows Vista Games Explorer (GE) is similar in concept to the Windows XP folders "My Documents" or "My Pictures." The idea behind all three of these is to centralize similar content in one place and allow for easier organization and context-sensitive activities. The GE extends the My Documents or My Pictures concept by allowing richer organization and control over games. The GE allows gamers to view, organize, modify and interact with all the games installed on their system. It also offers the opportunity to game publishers to communicate important game information more effectively. The system is completely data-driven, so it is very easy for a game publisher to update game information over time. In this way, the Games Explorer enables gamers to keep up to date with game communities, tips & tricks, etc.

In other words, time to do what consoles have had forever! A quickrundown of it's features from Wikipedia.

An "Easy Install" option that installs the title on your PC in the fewest possible steps and mouse clicks Compatibility with the Windows Vista Games Explorer (see below) Compatibility with the Xbox 360 controller (where applicable) Installs and runs properly on x64 versions of Windows Vista and is compatible with 64-bit processors (though the game itself can be 32-bit) Supports normal and widescreen resolutions, such as 4:3 aspect ratio (800 x 600), 16:9 aspect ratio (1280 x 720), and 16:10 aspect ratio (1152 x 720) Launching from Media Center (Windows Vista Home Premium and Windows Vista Ultimate have Media Center)

Some of the better features are as follows. Taken from the MS Developers network.

The game must be visible within the Games Explorer on Windows Vista. The game must not create shortcuts on the desktop, in the Start menu, or in any other location to launch the game. Instead, this functionality should be exposed through the Games Explorer through the game's icon and associated tasks list. Tasks and shortcuts for uninstall must not be created. Users should be able to remove the game using the Programs control panel (known as Add/Remove Programs on Windows XP and previous versions).

Better controls, not that anyone cares. With a tidbit regarding gamers being forced to use admin mode. This bears repeating. With Games for Windows, you will no longer be forced to use Admin Mode to game, this is an important security step.

All games must execute within the context of a Standard User in order to allow Windows Vista Parental Controls-enabled accounts to play the game. Installation, patching, and removal may require elevated rights, subject to the requirements in section

This also forces intergration with Xbox360 controller, which can only be a good thing, and Live, which again, is not bad. Quite abit of information regarding 64-bit and security, summed up in:

Every executable file (.EXE extension) must have an embedded manifest that defines its execution level. To maintain compatibility with x64 versions of Windows: Titles and title installers must not contain any 16-bit code or rely on any 16-bit component. If the game is dependent on kernel-mode drivers for operation, x64 versions of these drivers must be available. The game setup must detect and install the proper drivers and components for the 64-bit Windows OS. All executable code files (e.g., .EXE and .DLL extensions) must be signed with an Authenticode certificate.

Basically, ease of installation:

Games with a traditional installation must provide a simplified path in their setup user interface: Display a maximum of one EULA Provide default and custom installation options. The default option must bypass all selections for the install (such as installation folder, component selections, etc.), assume the default selections and then run the game or launcher upon successful install without addition prompts. Install any required OS components (such as the DirectX and Visual C runtimes) silently without prompting or guarded by component version checks using the correct Microsoft redistribution package(s). Provide removal only via the Programs control panel for both the game application as well as user-generated game files. This must ensure all installed files are removed and all settings (firewall, registry, etc.) are cleared. Redistributed OS components must not be removed.

Vista Game Explorer is an issue, covered by several developer blogs. In a nutshell, it forces them in how to display certain things, like ESRB information and settings, not inherently bad, just limiting. The other possible issue is covered by Rahul Sood(VoodooPC CEO, good blogger) here.

Microsoft is working to create a community experience similar to Xbox Live called Windows Live, where people can chat, set up games, and play. In the future, PC and Xbox 360 gamers will even be able to play with and against each other, a cross-platform experience that sounds really cool to me. My concern is that Microsoft will charge a membership fee to those who want to be part of this. So long the fee is $50 per year or less, it'll probably be a good deal for users, but game developers that support the GFW cause may have to give up their recurring revenues to Microsoft.

Generally however, it can only be a good thing, if it makes releases stabler, enforces proper interaction standards with the OS, etc. I am quite sure I am not the only gamer who is sick with lack of standards regarding games, Games installation, user right abuse, etc. Any step towards solving this mess is a good step.