3Ddreamer

Hi,

 

Coming to this website and getting involved in this community was a wise choice, so I welcome you.

 

I am a 2D and 3D computer video graphics artist specializing in the games and simulations industry with freelance Information Technology consulting on the side.  Learning Java, C#, and game development are hobbies of mine which I plan to grow into a business. Some of my colleagues, associates, and friends are skillful coders (in C#, Java, C++, high level scripting languages, and web-based languages) CEOs, professors, consultants, game designers, game developers, artists, and consultants.

 

 

(Now i know, that XNA is definitely dead, because Microsoft does not develop it further...)

 

 

When a company stops developing a program or software - as long as it still functions well, then it is mature and not dead.  The Software Development Life Cycle (SDLC) of XNA continues in implementation development such as Mono and other third party efforts.  XNA itself will function full and well for years to come in Windows operating system. Though Microsoft does not directly develop and support XNA anymore, it continues to supply clients with everything that they need to use it and run it in Windows, such as runtime updates.  This, again, will be the case for years to come. More than half the U.S.A population is still using WinXP, WinVista, and Win7, which will be the case for quite a while.  This means that anyone using this should be encouraged to learn game development with XNA for a few years at least.  Mono/ MonoDevelop platform is a very good and fairly up to date implementation of the technology.  Also take a look at MonoGame. 

 

As a developer and CEO of a company, to you I suggest being careful about labeling things as "dead".

 

For an experienced programmer and IT expert such as yourself, it makes no difference if you settle on C#, C++, or both - speaking in a general sense. With existing libraries, both languages are very capable of being used to reach from very high level to very low level functionality of a game.  Performance is excellent with both if done correctly in coding and implementation.  Quite a number of game engine and game developers use both languages, typically C++ to handle lower level optimizations such as mult-core/multi-threading and memory caching, while C# is great for scripting or general game functionality.

 

I recommend to everyone that they create their own games for at least a couple years before trying to make their first game engine, but most should probably never begin game engine development.  There are many quality game engines in existence and more to come!  "Why reinvent the wheel?" is a common and legitimate question asked in these game development circles in regard to game engines.  A comprehensive game engine usually takes 5 to 20 years to mature from beginner to completion and developing games will add years by themselves.

 

Since you are a very busy person in the software industry, you likely don't have time right now for anything other than learning how to develop games.  Make 3 to 5 simple practice games using an existing game engine.  Choose a game engine and use its main language.  I recommend Unity 3D (originally deriving from Mono), Unreal Engine (UDK), or Torque 3D to you for  cross-platform, large community, extensive updated libraries, tutorials, and no cost or little cost art assets to get you well on your way in good time.  You have the coding and programming experience to use these in creating fun games at an accelerated pace.   

 

Here is a list of some of the more popular game engines:

http://en.wikipedia.org/wiki/List_of_game_engines

 

SDKs - At least one of these will be used by you in game development or game engine development eventually.

 

These are not called Software Development Kits for nothing. As the name implies, they do not focus on the art aspects of game development but rather the coding aspects. These may target a runtime environment such as Common Language Runtime (Windows mainly), Java Runtime Environment (operating system cross-platform), or Mono Runtime Environment ( an operating system cross-platform implementation of CLR ). They also may use and/or include APIs for the hardware cross-platform that you are seeking, being OpenGL, Direct3D, or Mono, as well as other APIs for sound, device input, networking, servers, and so forth. Note: APIs typically are low level handling of coding and directly impacts hardware issues such as graphics. 

 

SDKs are typically kits which focus on at least one native low level language and maybe few scripting languages.  Support for advanced game art creation in the form of editors and specialized game art tools may be limited from an art creation viewpoint.  However, almost all of them support very well the import of art assets from common graphics programs such as 3DS Max, Maya, Blender, and so forth.  

 

If you want to become an independent game developer, then create games with an existing development platform such as SDL, SFML, Mono/MonoDevelop, or SharpDX, especially if the games are not going to be art intensive because you are not an artist.  They do support your development toward game art goals of the future if you eventually need them, being scalable according to plug-ins and your coding skills. 

 

An SDK is an excellent compromise which provides most of the low level coding for you to focus on customizing existing code and creating proprietary game source code on top of the platform.  Games made with such an SDK can be programmed to allow the end user to download and/or install the necessary runtime libraries if the game installer detects that the client does not have the runtime installed yet or it needs updating. Important:  End-user license terms and agreement must be displayed and agreed by the gamer for all software and libraries according to the license terms of agreement, including third-party ones. This is a great saving in coding effort provided by the best SDKs, accelerating your game development by months.  Having the low level coding libraries mostly provided to you to customize saves you years in development time and money.  They also provide all the technical documentation and license agreements which is part of the time and effort saved. Very supportive communities further shorten the development cycle.

 

Game Engines

 

As the name implies, these are systems of game development aimed at games mostly and not the other coding issues such as making your own graphics, physics, sound, scene graph, or other coding intensive underlying areas. Plugin alternatives often exist.   Libraries, including terrain editors and character animation editors or plugins are provided for you.   All of these utilities are specially designed for game design and art creation pipeline flow for maximum efficiency, saving you years in coding your own libraries. Sure, you can usually customize those things all that you want, but it will take years in its own right to mature.

 

If the game concepts in your goals are art heavy, then you would be better served with a game engine like the ones I recommended which attract many skillful game designers and artists.  These will require that you form a team and delegate areas to members.  They are proven most attractive to everybody involved if you are a good team leader.   The most is achieved in the shortest amount of time with a good game engine.

 

 

APIs

On the other hand, if your goal is to create your own game engine (5 to 20 years includes your first successful game as well) and launch your games off it, then I highly recommend an API.  OpenGL and existing Software Development Kits (SDK) for it are among the most efficient for implementing across hardware computing devices. In fact Java and the Java Runtime Environment or directly targeting OpenGL are the most efficient for hardware cross-platform implementation, for example created software to run on computers with any OS and also iPhone/Android mobiles.  This is a great choice if your games will be more coding intensive than art loaded.  As an alternative, many game engines include tools for working with an API such as OpenGL for hardware cross-platform implementation.  For being able to run your game in a computer and also most mobile devices, OpenGL API is very common.

 

Summary

Creating and publishing your first successful and profitable game might take years.  Developing your own game engine will add some years to the release of your first comprehensive game.  A good and popular compromise is to use existing libraries (such as GUI creation editors, physics, device input, and so on) which come with an SDK, such as Mono ( Remember that hardware and OS cross-platform Unity 3D was initially derived from Mono, for example, showing the potential. )

 

To start totally or almost from nothing, then you need an IDE (Integrated Development Environment) such as Java IDE, Visual Studio, Eclipse, SharpDevelop, MonoDevelop, or other.  Assuming that you are an expert in coding, then writing all that physics, sound, editors, encoders, GUIs, input device application, graphics, networking/server, and special tools will take at least 5-10 years in my opinion, but maybe 10-20 for a beginner. If you compromise with libraries in these areas which are designed to be used with one of these IDEs (perhaps only by plug-in for the IDE), then you are still looking at 3-5 years to develop your own game engine which is complete and ready for a team.

 

Team Required for professional results in only a few years:

Game engine development, using an existing game engine, relying on an IDE, SDKs, and APIs for low level coding, and creating several of your own major libraries - all demand a team for company success (unless you intentionally want to create legacy style simple games or games so easy to develop that a student could do it, such as "arcade games" or simple mobile device games).  

 

Game development or game engine development each take years alone. Being a solo game developer adds more years from beginner to pro release of a profitable game in many cases.  A team with good chemistry will save years, money, and pain, while adding to the gross sales and profit rate potential.

 

Recommendation to You:

OpenGL used with an SDK (if you are a solo developer making simple games, want to create much low level coding, or art assets are light)

 

=or=

 

OpenGL with a game engine (if a team will be formed and/or art assets are heavy in the game design)

Knowing how much art asset will be in your games and also whether you are a solo or team oriented developer may be the two most deciding factors on your strategy of a business model for game development. Selection of development software obviously is top of the list of tasks related to these.

Game Development Organization:  Acquiring an existing game engine and a team saves you years from start to release of a complex game that turns a profit.

Solo developer making simple games and much low level coding with easy art assets: Using an SDK such as SFML, Mono, or SharpDX .  

Game engine developer:  An IDE with plugins and existing low level libraries becomes more valuable with the low level coding of game engine development. API coding to develop for OpenGL is fully supported with an IDE.

Hardware Cross-platform Deployment is most efficient with Java, Java Runtime Environment, Mono, or OpenGL/ Open APIs such as OpenCL, though C# and C++ application development is supported in various ways with all of these.  (Hardware cross-platform development is more low level coding than Operating System cross-platform development in general, hardware cross-platform development always involving an API such as OpenGL)

Hi,

Coming to this website and getting involved in this community was a wise choice, so I welcome you.

I am a 2D and 3D computer video graphics artist specializing in the games and simulations industry with freelance Information Technology consulting on the side.  Learning Java, C#, and game development are hobbies of mine which I plan to grow into a business. Some of my colleagues, associates, and friends are skillful coders (in C#, Java, C++, high level scripting languages, and web-based languages) CEOs, professors, consultants, game designers, game developers, artists, and consultants.

(Now i know, that XNA is definitely dead, because Microsoft does not develop it further...)

When a company stops developing a program or software - as long as it still functions well, then it is mature and not dead.  The Software Development Life Cycle (SDLC) of XNA continues in implementation development such as Mono and other third party efforts.  XNA itself will function full and well for years to come in Windows operating system. Though Microsoft does not directly develop and support XNA anymore, it continues to supply clients with everything that they need to use it and run it in Windows, such as runtime updates.  This, again, will be the case for years to come. More than half the U.S.A population is still using WinXP, WinVista, and Win7, which will be the case for quite a while.  This means that anyone using this should be encouraged to learn game development with XNA for a few years at least.  Mono/ MonoDevelop platform is a very good and fairly up to date implementation of the technology.  Also take a look at MonoGame. 

As a developer and CEO of a company, to you I suggest being careful about labeling things as "dead".

For an experienced programmer and IT expert such as yourself, it makes no difference if you settle on C#, C++, or both - speaking in a general sense. With existing libraries, both languages are very capable of being used to reach from very high level to very low level functionality of a game.  Performance is excellent with both if done correctly in coding and implementation.  Quite a number of game engine and game developers use both languages, typically C++ to handle lower level optimizations such as mult-core/multi-threading and memory caching, while C# is great for scripting or general game functionality.

I recommend to everyone that they create their own games for at least a couple years before trying to make their first game engine, but most should probably never begin game engine development.  There are many quality game engines in existence and more to come!  "Why reinvent the wheel?" is a common and legitimate question asked in these game development circles in regard to game engines.  A comprehensive game engine usually takes 5 to 20 years to mature from beginner to completion and developing games will add years by themselves.

Since you are a very busy person in the software industry, you likely don't have time right now for anything other than learning how to develop games.  Make 3 to 5 simple practice games using an existing game engine.  Choose a game engine and use its main language.  I recommend Unity 3D (originally deriving from Mono), Unreal Engine (UDK), or Torque 3D to you for  cross-platform, large community, extensive updated libraries, tutorials, and no cost or little cost art assets to get you well on your way in good time.  You have the coding and programming experience to use these in creating fun games at an accelerated pace.   

Here is a list of some of the more popular game engines:

http://en.wikipedia.org/wiki/List_of_game_engines

SDKs - At least one of these will be used by you in game development or game engine development eventually.

These are not called Software Development Kits for nothing. As the name implies, they do not focus on the art aspects of game development but rather the coding aspects. These may target a runtime environment such as Common Language Runtime (Windows mainly), Java Runtime Environment (operating system cross-platform), or Mono Runtime Environment ( an operating system cross-platform implementation of CLR ). They also may use and/or include APIs for the hardware cross-platform that you are seeking, being OpenGL, Direct3D, or Mono, as well as other APIs for sound, device input, networking, servers, and so forth. Note: APIs typically are low level handling of coding and directly impacts hardware issues such as graphics. 

SDKs are typically kits which focus on at least one native low level language and maybe few scripting languages.  Support for advanced game art creation in the form of editors and specialized game art tools may be limited from an art creation viewpoint.  However, almost all of them support very well the import of art assets from common graphics programs such as 3DS Max, Maya, Blender, and so forth.  

If you want to become an independent game developer, then create games with an existing development platform such as SDL, SFML, Mono/MonoDevelop, or SharpDX, especially if the games are not going to be art intensive because you are not an artist.  They do support your development toward game art goals of the future if you eventually need them, being scalable according to plug-ins and your coding skills. 

An SDK is an excellent compromise which provides most of the low level coding for you to focus on customizing existing code and creating proprietary game source code on top of the platform.  Games made with such an SDK can be programmed to allow the end user to download and/or install the necessary runtime libraries if the game installer detects that the client does not have the runtime installed yet or it needs updating. Important:  End-user license terms and agreement must be displayed and agreed by the gamer for all software and libraries according to the license terms of agreement, including third-party ones. This is a great saving in coding effort provided by the best SDKs, accelerating your game development by months.  Having the low level coding libraries mostly provided to you to customize saves you years in development time and money.  They also provide all the technical documentation and license agreements which is part of the time and effort saved. Very supportive communities further shorten the development cycle.

Game Engines

As the name implies, these are systems of game development aimed at games mostly and not the other coding issues such as making your own graphics, physics, sound, scene graph, or other coding intensive underlying areas. Plugin alternatives often exist.   Libraries, including terrain editors and character animation editors or plugins are provided for you.   All of these utilities are specially designed for game design and art creation pipeline flow for maximum efficiency, saving you years in coding your own libraries. Sure, you can usually customize those things all that you want, but it will take years in its own right to mature.

If the game concepts in your goals are art heavy, then you would be better served with a game engine like the ones I recommended which attract many skillful game designers and artists.  These will require that you form a team and delegate areas to members.  They are proven most attractive to everybody involved if you are a good team leader.   The most is achieved in the shortest amount of time with a good game engine.

APIs

On the other hand, if your goal is to create your own game engine (5 to 20 years includes your first successful game as well) and launch your games off it, then I highly recommend an API.  OpenGL and existing Software Development Kits (SDK) for it are among the most efficient for implementing across hardware computing devices. In fact Java and the Java Runtime Environment or directly targeting OpenGL are the most efficient for hardware cross-platform implementation, for example created software to run on computers with any OS and also iPhone/Android mobiles.  This is a great choice if your games will be more coding intensive than art loaded.  As an alternative, many game engines include tools for working with an API such as OpenGL for hardware cross-platform implementation.  For being able to run your game in a computer and also a most mobile devices, OpenGL API is very common.

Summary

Creating and publishing your first successful and profitable game might take years.  Developing your own game engine will add some years to the release of your first comprehensive game.  A good and popular compromise is to use existing libraries (such as GUI creation editors, physics, device input, and so on) which come with an SDK, such as Mono ( Remember that hardware and OS cross-platform Unity 3D was initially derived from Mono, for example, showing the potential. )

To start totally or almost from nothing, then you need an IDE (Integrated Development Environment) such as Java IDE, Visual Studio, Eclipse, SharpDevelop, MonoDevelop, or other.  Assuming that you are an expert in coding, then writing all that physics, sound, editors, encoders, GUIs, input device application, graphics, networking/server, and special tools with take at least 5-10 years in my opinion, but maybe 10-20 for a beginner. If you compromise with libraries in these areas which are designed to be used with one of these IDEs (perhaps only by plug-in for the IDE), then you are still looking at 3-5 years to develop your own game engine which is complete and ready for a team.

Team Required for professional results in only a few years:

Game engine development, using an existing game engine, relying on an IDE, SDKs, and APIs for low level coding, and creating several of your own major libraries - all demand a team for company success (unless you intentionally want to create legacy style simple games or games so easy to develop that a student could do it, such as "arcade games" or simple mobile device games).  

Game development or game engine development each take years alone. Being a solo game developer adds more years from beginner to pro release of a profitable game in many cases.  A team with good chemistry will save years, money, and pain, while adding to the gross sales and profit rate potential.

Recommendation to You:

OpenGL used with an SDK (if you are a solo developer making simple games, want to create much low level coding, or art assets are light)

=or=

OpenGL with a game engine (if a team will be formed and/or art assets are heavy in the game design)

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.

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.

Hi,

There is way to do this in Max and it is too clumsy and time consuming to me, so I use Wings 3D to merge many things, including scenes, but sometimes the basic info is merged and things like shaders added later.  Blender can merge scenes but I have never used it for that. It is so important to get as much of the geometry done as possible - preferably all - before even working with a UV map and/or textures, materials, and shaders among other things.

Blender, 3DS Max, and Wings 3D are all used by me based on workflow pipeline needs.  I even on occasion use Deep Exploration, Milkshake 3D, or plug-ins for 3D programs such as Panda and Collada.  You will eventually be forced to expand to other programs, too, so the sooner you get accustomed to several programs the better for you.  This strategy will open your creativity and innovation to amounts achievable only this way.

Clinton