Hi,

Much of what you seek is satisfied by using a memory managed language. You need to learn classes, executables, and version (source) control. Much of the other questions which you ask varies considerably in many ways from game to game and from game engine to game engine. Choosing a comprehensive game engine like Torque 3D for example would clarify a lot of things. If you don't want a game engine but want to program games more directly in a computer then you either need to target a runtime environment directly or exploit a graphics API - Direct3D or OpenGL. Look at SharpDX as an example.

List of game engines:

http://en.wikipedia.org/wiki/List_of_game_engines (There are many more game engines and graphics engine out there but these are most of the popular and well developed ones).

Typically a game has classes for most or all of everything. GUI, physics, objects such as characters, vehicles, and land environment (usually called simply "Map") may each have their own classes. Each of these classes could be a major folder in the main directory of your game or be an executable application instead there. The startup and setup executables, like the names imply, are typically responsible for setup and configurations of the game - Setup.exe for example - or starting the game which makes the clock start, GUI appear, scene graph begin running and then all objects and game functionality loaded into the scene - gamename.exe for example or start.exe sometimes. When everything is ready then the player may use the GUI to do tasks and start to play. Most game engines have kinds of templates in all these major areas already in place which usually require knowledge in the programming language to customize functionality or build on what exists in there. If you do not have a game engine or at least some libraries in these areas then you must create all of this and much more yourself. Almost everybody new to game development needs to make games that are so simple that they do not have any executable files. An exception would be the programmer who has made executables in the language though not game related.

Low level programming is mostly far beyond the ability of an inexperienced programmer so it is very important to start very simple. You really need to make some console type games such as Tic-Tac-Toe, crossword puzzle, Trivia Pursuit, Scrabble, and so forth. I'd say my standard 3 to 5 of these. Also, non-game applications such as simple database, letter display application, simple encoder, index with scroll, easy GUI, image loader, file loader, text box display, and so on will give you coding experience - all of which will be used eventually in game development.

By the way, we always need to know what is the language that you are using if you are going to ask these kinds of questions.

Game Coding Complete will show you how to design an engine. Get the latest 4th edition I think.

Good day to you,

Here are my informed opinions:

Running any game creates an intermediate language by an interpreter (such as the Common Intermediate Language of the Common Language Infrastructure which comes with Windows OS for example, or bytecode in the case of using Java and the Java Virtual Machine of the Java Runtime Environment, though Java is one of the standard languages of the Common Language Infrastructure and can be used in .NET Framework development but implemented differently) under your coding to control the machine and/or assembly language, both of which you will likely never handle or see directly.

So we typically see layers:

High Level Coding - using an interpreter to get at low level language functionality or compiling to executable files for a number of reasons and purposes. Research interpreted language. Most high level coding languages are also auto memory managed languages which allow the targeted runtime environment to handle memory issues and threading.

Note: Contrary to popular belief among IT people, the memory management and threading of the application and software need not have anything directly to do with the OS which would create another layer, delay execution, and hurt performance, but instead develop on the native or installed framework (.NET Framework, Mono, or Java Framework) or dispense with dealing with their SDKs directly and target the APIs such as Direct3D, OpenGL, OpenCL, etc. Game engines come with easier ways to accomplish these things than if you use the native SDKs and APIs in some cases.

Low Level Coding - typical handling of low level graphics APIs, input APIs, sound APIs, hardware APIs, by writing code to connect their functionality for creating a game framework.

Warning about the path that you, waffletart, are tempted to take: It is possible to integrate this low level programming with the coding of game scripting but usually results in broken game source code each time new versions of an operating system framework are released. Even an update of a current operating system framework sometimes would break such source code on rare occasion. This doubles the debugging of integrated low level and game scripting code thus making it harder to find the real source of the incompatibility. New versions of your "integrated" game source code is much more difficult and painful than if low level coding and high level are connected but are distinguished with modular struct. This leads to version control, also called source control, in due time which further organizes the development for agility.

What would it mean to target a runtime environment?

There are several most common ways of implementing a game:

1) Target a Runtime Environment (Could be Common Language Runtime Environment, Java Runtime Environment or other such as made for Linux applications)

Every runtime environment includes

a) One Native Language support as well as other major languages.

b) Framework Libraries (Called .Net Framework, Java Framework, Mono, or other Linux based framework) of these languages such as those for device input, graphics APIs of Direct3D and OpenGL, sound, GUIs which are fully supported by the operating system, CPU control such as threading, GPU/VGA control like memory caching, compilers/decompilers, encoders, miscellaneous tools, and interfaces to connect any of these.

c) The frameworks have a Sofware Development Kit (SDK - .NET Framework 4.0 SDK for Windows for example. ) for the features available in a specific framework version. This will make an application or software that you develop run for that version of the framework if installed in the client device.

An Integrated Development Environment (IDE) is a suite of software to handle everything, for example Visual Studio and all the rest. IDE can be used to make your application or software run in more than one framework or more than one version of a framework, fully supporting compiling, testing, and debugging. They allow development with both the lower level functionality such as device input and also the higher level functionality such as a GUI with full Windows OS features yet integrate third party libraries such as Flash video, raster GUI templates, or vector GUI templates. There are even plugins to make a framework IDE or SDK work directly with your favorite 3D graphics program such as 3DS Max, Maya, or Blender, though third party. All of this depends on some brand of runtime environment as an intermediate layer between software and the lowest languages - common intermediate language, binary, or in some instances manipulate machine/assembly language after it is compiled to it - sometimes as executable commands, real time compiling or interpreting, or Just In Time (JIT) compiling above language to below language. None of this should ever be developed by a game developer because huge organizations took many years with teams of coders to do it for you. All you need are the interface software, programs, and some game source coding at least. A game engine is often a better choice, as we will see in a few moments.

The vast majority of commercially sold applications and software are implemented in a runtime environment. For computers the Common Language Runtime and the Java Runtime Environment total more than 95% of implementation in client devices. (Though you may use a framework SDK or a game engine, they still implement in a runtime environment.) This is why practically every commercially sold computer ships with at least one runtime environment installed in it. Windows comes with CLR and other operating systems ship with CLR and/or another runtime environment such as Java Runtime Environment. Most operating systems allow the installation of both CLR and JRE, by the way. The developer may target a specific runtime and require the downloading and installing of that runtime for the client to run the application or software. Sometimes at installation of that developer's product, the installer will inform the user that a certain runtime or version of a framework within that runtime is required or recommended if not installed already. If needed, usually all required libraries (runtime and/or its framework) are included in the download for the client and installed by license agreement before installation and setup of the product. In most cases, the user chooses a product which fits their system and no extra installations or compatibility issues arise.

If you realized that all of this is very very developer intensive in many cases for game development then you are right! This is why software development companies have done much of the low level framework so the game developer can focus on games and not reinventing the wheel.

To make your own framework ( an intermediate system between your game programming and low level functions such as CPU threading or graphics characteristics ) would delay your publishing of games by years, if not decades, because successful frameworks under popular games are always created by teams these days. In my opinion - seems obvious - only teams can keep pace with the rapid updates in standard native frameworks.

2) Game engine can be a layer above the native framework with development friendly interfaces and already existing standard libraries manipulated by those interfaces. With a game engine, the game developer handles libraries or existing code, writes some new code, and uses interfaces in place of doing most of the hard, low level coding required with developing in a native framework directly. Instead of facing a jungle of information in an runtime IDE or native framework SDK, you only face an area reachable by an individual or small team with a game engine typically. (Think whole jungle IDE or SDK compared to only one acre with a game engine - oversimplification admitted by me here)

Game engines typically come with these libraries, depending on design:

Application or software development kit using the said language(s), libraries (sets of coding, for example auto CPU threading for memory managed languages, model importer, scene graph, etc.), custom editors, templates of all kinds - like a basic GUI by default or a level, specialized tools (such as model file encoder, startup executable compiler, etc.) Instead of having to create all these many applications, software, and libraries yourself which takes many years, most of the work is done for you.

3) Use an operating system SDK ( Such as Window SDK ), which is a very high level framework for application and software development, simplier and quicker but also lacking much of the manipulation of low level function.

4) Make console applications and games in which you simply write code and execute by command prompt or framework SDK.

Note for the readers: The lower the programmer goes in programming languages then the harder it is to make games without a game engine. High level language examples are Python, Lua, Perl, C# (actually a kind of middle language) and so on. The C language and certain library implementations of C++ are considered low level coding, for example. Higher level languages generally need interpreters (a type of compiler to low level coding or machine/assembly language) but make development of games usually much quicker than low level languages. However, game engines "level the playing field" so to speak acting as a framework to get at low level functions for any of the most common languages depending on game engine design.

It is generally more efficient, quicker, and easier to customize an existing game engine than to make a new game engine from scratch by far. Making a game engine from scratch which is comprehensive will take an individual 10 to 20 years, but a team can create it in a few years. Customizing a game engine - license required - will take an individual in the area of 1-3 years if the time is available to spend on it. Having a team without a game engine requires each member to specialize in a certain skill set but will still take longer than if a game engine were used.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

All of these strategies create an intermediate language (such as the Common Intermediate Language of the Common Language Infrastructure which comes with Windows OS for example, or bytecode in the case of using Java and the Java Virtual Machine of the Java Runtime Environment, though Java is one of the standard languages of the Common Language Infrastructure and can be used in .NET Framework development but implemented differently) under your coding to control the machine/essembly language, both of which you will likely never handle or see directly.

I have been using c++/allegro and c#, are they memory managed languages? C++ can allow both memory management and also auto memory management, but C# comes with auto memory management natively. C++ and C# both have libraries for memory management, but it is native to C++ and C# requires a special library and corresponding interface to make interpretation in order to program memory allocation. However, keep in mind that when the programmer chooses to manage memory, then more CPUs and GPUs targeted demands more coding, testing, debugging and corresponding hardware and/or software needed, costing money in investment. There are virtual computer components, virtual CPUs and VGAs, in software for testing, by the way, but large developers almost always test in actual hardware for beta or release candidate (RC) versions of the game. C# has auto memory management native: Auto memory management not only saves in development time and pain, but is all that is really needed for most applications, software, and in particular games. Really only the huge complex games have memory management as an absolute requirement for at least some of the source coding. To be clear about my opinion - for a complex game I would use C++ to allocate memory to certain game coding and leave C# or Allegro auto memory management to handle non-critical game scripting in most situations.

I know classes somewhat, a great way to make templates and associate a bunch of data with said template. These libraries are one of the pillars of large scale and flexible software development, including game development, so you are on the right track.

What is version control?

Version Control (Source Control) is keeping copies of versions of any source code, keeping copies or records of any changes, deletions, compiling, debugging results, experiments, and related documents such as management requests, references, licenses, office memorandums, creators of sections of coding - both inhouse and outsource, and so forth. For example, if a new physics library is introduced, then all relevant information, original source code, revised source code, and who did what are included in that particular version folder. There are several source control software available to make all of this as efficient as possible, create backup of everything, and update each members branch of the version control at configured times or manually upon reaching certain goals. Even a lone newbie developer should create a simple version control system with just folders and files then backup copies with each milestone. With smaller game development projects this is all one needs.

Having a team or larger game development project is better served with version Control software. There are actually industry standards for source control. We see version 1.0, v1.1, v1.2, version 2.0, v2.1,v2.2, and so forth - each version has its own major folder containing sub-folders and files unique to that version of the game code or game engine code. Also supporting applications which you make should be included in the version relating to it like certain application tools that you made for a stage of game development, but make a copy to its own version control folder in turn to develop it if needed. With teams of coders, source control software is vital for creativity, innovation, efficiency, documentation, and accountability. In fact successful companies or investors require a developer to have a source control system and the developer creates a better software sooner because of version control - they know that.

I understand I must start small, are all of these games you mention in the console using character tiles for graphics, like a tic-tac-toe board? The purpose of creating (or copy-catting) these games is to learn basic coding for games which is generally standard in fundamentals. Avoid low level graphics for a few games. You need to learn to distinguish game source code from framework coding and also there will many many applications within your games that you need to learn how to make if you want to have a good, modern game done within the next couple years. You are not merely putting the pieces of the puzzle together but you are learning how to create each piece and take some of that coding (if good) with you into future games.

The display of these games is entirely by coding in your language and you may make tiles but you need to focus on game functionality and game play or you will have to return to this subject of fundamentals after creating a framework and be embarrassed that you have a simple engine but no good game after a few years of work. If I were you, I would scrap the framework creation until you know how to script a game so you will know exactly what you need in a framework coding under it. Frameworks are built for game concepts/genres and not games built for framework lessons/experiments.

An executable is just the result of code compiled to run on a particular operating system is it not? Effectively yes, but technically that's a no. Ultimately an executable file targets a particular runtime environment's virtual machine where it is interpreted into assembly code for example starting a game clock of a scene graph or machine code to allocate output of other executable files to certain memory cache if managed memory language is coded for that in the executable file. If the output language of the executable is not allocating to certain memory slots, then it will be handled either by the auto memory management language via a virtual machine in the runtime or by the operating system. Leaving it undefined puts it in the hands of the OS, which is a common cause of stuttering in games, among other causes. In the case of C#, inexperienced programmers blame C# for game stuttering but if compiled correctly then C# won't cause stuttering but prevent it.

If you want to run an executable only in a Windows OS which comes with the Common Language Runtime installed in the client, then you target the .NET Framework. For making an executable run on most computer operating systems, then it would be compiled to be read by the virtual machine of the Common Language Runtime or the virtual machine of the Java Runtime Environment, but requiring that they be installed in the client computer ahead of execution. Note: Typically only a few changes are needed in the executable file to run the executable in different virtual machines of runtime environments. For both operating system and hardware cross-platform development, it is usually most efficient to execute a program or file in the Java Runtime Environment which is better supported for OS and hardware cross-platform than the Common Language Runtime, partly because JRE updates happen less frequently than CLR.

Note: It is possible for the client to install a non-native runtime (sometimes with a few customizations of the OS in settings, such as display screen ratio or resolution), best examples being Java Runtime and Mono in ease of configuration for the user. Again runtimes and frameworks may be installed by the user in most operating systems even if not native, your game may prompt this or even do the installation by Agreement and License of the game user.

Beginners and intermediate game developers should either use a cross-platform implementing game engine or target only one native framework unless prior experience in cross-platform application development, my opinions.

Once you have completed that level of programming, how do you learn about more advanced terms and technologies?

Research in various sources of information is the backbone of game development. Online communities are the first place to go to get tutorials, read good threads on subjects, view reference material such as game or game engine documentation, and ask questions. Books and videos well made are crucial. GamedevDOTnet here is a good place to start.

Is there a particular game engine that explains things like vertices and polygonal shapes? Well, game engines don't explain these things except in the READ-ME files and external documentation. The online community website forums of some game engines have threads where developers are diving into the guts of the game engine to make changes to game engine source code which manipulates or renders these graphics elements. The easiest way to create and manipulate vertices and polygons is by editors of the game engine or by outside graphics programs and then import the game models or objects by a file format acceptable to the game engine.

Always read and fully comply with the end user agreements of any game engine. License is anything from "do as you please and you don't have to tell us" to "absolutely no changes to source code of game engine allowed without permission" and everything in between.

These are just my opinions.