Monday you said? Yeah, right ... lazybones ...
Whatever ... On part 1 I had introduced some general concepts about game engines and other components, right? Well, today's post will concentrate on giving a few examples of some of the "helpers" that you may find in the industry, or at least, among "indies".
To do so, I'll will use the same categories of part 1, so If you don't remember the definitions and concepts, or you didn't read part 1 at all, you'd better go and read it first before we continue.
Ok, assuming you did. We shall continue ...
Ahhh, by the way, what you will see is how I see it, ... it's my blog, right? ... so feel free to re-arrange things up in your own list if you think that some component belongs to a different category.
(1.a) General-purpose engines.
If you had paid a visit to Devmaster.net as I suggested, you would have noticed the growing number of engines available in the market, like "Irrlicht", "3Impact", "C4 engine" and "Truevision 3D".
C# developers: although most of them are C++ original, some of them like "Irrlitch" provide a wrapper for .NET technology.
(1.b) Game-type-specific engines.
Our first classic match of the night: "Unreal Engines vs. Quake Engines". That is to say, "Epic Games vs. Id Software".
And lately, a new generation of engines that continue Quake III's legacy: "Doom III engine".
(1.c) Game-bound engines.
Well, to tell you the truth, you can include here any engine created for the sole purpose of developing one game and or sequels for that "title". In fact, the line between the previous category gets thinner when the engines starts to be modified in order to develop new "different" titles.
2. Game Frameworks.
From fully WYSIWYG frameworks like "GameMaker" and "Multimedia Fusion" -which you can get interesting results with, to full 3D-powerhouses like "A6 - GameStudio", "Quest3D" and "Torque Game Engine" -which let you target very ambitious projects, there are a whole range of frameworks to choose.
MAC developers: check out the cross-platform "Unity3D" engine.
C# developers: a new battle is coming: "TorqueX vs. Visual3D.Net". Buy your tickets ...
3. Game-Oriented Languages.
New GO languages are now entering the field but one of the classic battles of latest years is "Blitzbasic vs. Darkbasic".
Choose the contenders you prefer for each side, like Blitz3D vs. DB Pro, and enjoy the match.
OOP developers: both "line of products" above are non-OOP.
(4.a) Game-Oriented Middleware: Rendering.
I could mention too many components here like "Renderware" and "Gamebryo", but I will refer to OGRE (which stands for "Open Source Graphics Engine").
Contrary to what many of you may think, OGRE is not a game engine ... read the "Graphics" part of the "G" abbreviation ... ok, time to run away before the mob reaches me ...
Really. You can build your own engine by using its outstanding multiplatform-rendering capabilities, and you will likely find those who did, but OGRE only provides a set of C++ classes which will make your development life easier for rendering processes.
C# developers: yes, there's an OGRE.NET out there.
(4.b) Game-Oriented Middleware: Physics.
"Bring it on!". That's what companies that develop physics-prone components are saying one each other.
Havok, Newton, ODE, PhysX, Tokamak ... These guys have been around for so long now, and the battle still goes on.
Different type of licensing, different technologies, different features, different logic structure, different support, different approaches to the one domain they have in common: physics' mechanics.
C# developers: be aware that currently most of those companies neither offer nor support wrappers for .NET technology. You may find third-party wrappers, but no guarantees as usual ...
(4.c) Game-Oriented Middleware: Scripting.
Some AAA games have their own scripting language, like "Unreal Script". But there are general-purpose scripting languages that you can use, like "LUA" and "Phyton" (both well accepted in the industry).
Also, there are relatively new entries but yet powerful options, like "Gamemonkey Script".
And finally, I must mention one of the mostly used languages for internet-targeted games: "Actionscript" (built-in language for Adobe's Flash).
A tip for C# developers: with a bit of self-effort you can also use C# as your scripting language.
(4.d) Game-Oriented Middleware: AI.
Ok, you can either use scripting languages to modify the behavior of your game's "bots" or hard code your own implementations but there are some intereting components you may consider to use, like: "AI.Implant", "Renderware AI", "PathEngine", and "Memetic".
C# developers: see the tip in (4.c) above.
(4.e) Game-Oriented Middleware: Networking.
Last but not least, multiplayer stuff. Err ... getting a community of gamers together to play your game.
If you think that the other "areas" were tough, don't forget this one. Believe me. Point-to-point communication, client-server models, world updates, anticipation of each connected player's movements, etc. This requires a lot of patience and experience. Thus, not many games provide this feature.
Luckily, here come some components to the rescue, like Quazal's line of products, "Replica Net" and "Plane Shift".
Now, some final thoughts ... you may have heared about some of the above-mentioned "helpers" or even used them, but the fact is that in order to produce a game from scratch to completion you have to choose the right ones, that is, the ones that comply with all of the requirements for your project: budget, scope, technology, features, comfort, support, ... just to to mention a few.
But one thing is getting to know a bunch of components in order to pick the right one for you and your crew and other very different thing is to "wander" around them in a sort of "never-ending" testing, because you are either waiting for that long-awaited "saviour" component, you have played around so much that you don't know where the North is anymore, or you can't just make up your mind.
One of the huge mistakes that many "indies" usually make -I included- is playing around with some third-party components at the same time for a long time. You may say, "what's wrong with that? One should get to know a component before buying it, right?" I'll tell you what, the problem is that when you use, not one or two, but more components at the same time for a long time you face the risk of not getting to know none of them with the due depth of detail that you need in order to properly deal with your project.
In other words, don't play around with the components as if you were carring on the project it-self in a paralell manner through all of those components, like saying "the one that reaches the finish-line first wins the race" (if you compete with your-self in this one there will be no winner).
Just perform a set of small and accurate tests on the functionality that you need for your game in a sort of check-list verification: "Engine 1 ... checked, Communications ... checked, ... ". And then, having analyzed the pros and cons of the candidates, select one, get to know it deeply and start your project.
And please, don't look back until you finish it or otherwise you'll be only creating abbandonware, potentially speaking.
Just remember, there may exist no perfect components in absolute terms but relatively speaking, there is one (set of) perfect component(s) for your project if you manage to choose smartly. Or was it for soul-mates?
Anyway, part 2 is now finished. See you all next time ...
[... we will only focus on .NET based components]
Showing posts with label Frameworks. Show all posts
Showing posts with label Frameworks. Show all posts
Tuesday, September 26, 2006
Monday, September 18, 2006
GAME ENGINES AND OTHERS: PART 1 OF 3
There goes the weekend. I hope you have enjoyed it. Now it's time to get back to reality ... Mondays = kill-joy ... For some.
Remember last Friday's post? I had commented something about game engines, right? Ok, this is the first part of a small series of posts regarding game engines and other components like: game frameworks, game-oriented languages and game-oriented middleware.
As soon as you try to join the game industry you will run over a bunch of software components which may help you build a videogame from scratch, to some extent. Are all of these components a "game engine"? Quick response: "No". Why not? To answer that, let's first take some due notes of the following concepts:
By doing so, they usually bring at least one implementation layer between your final game and "low-level" libraries (like "DirectX" or "OpenAL"); generally speaking, "low-level" libraries provide access to computer/console hardware through a set of basic functions: take for instance "Application Programming Interfaces" (API) like "Direct3D" or "OpenGL", which can be considered as software abstractions of the "Graphic Processing Unit" of videocards (GPU), thus letting you handle and build "rendering systems".
Please, bear in mind that those 4 concepts are just one general and simple way of categorize the software components that you may find out there. Meaning, you could bring more categories to the field, rename or re-arrange the provided ones, but the important thing is that you realize that when you start to move down "the logic tree" trying to narrow general/base concepts, specificity may be found, and in turn, new categories may appear.
For instance, "Middleware" could sound too misleading for some since the word it-self wouldn't necessarily imply that it deals with just a part of the game-programming chain (contrary to "the whole"), but it'd imply that it brings at least one layer between your game and a low-level API (thus, some could deem "1" and "2" above as more general middleware).
Again, it's up to you to build your basic list of categories and place each component within them either with a great amount of certainty (for "obvious" choices) or "at a rough guess" (for "not-that-obvious" ones).
1. Game Engines.
If you remember one of my previous posts, when you want to program a video-game you will have to deal with lots of main logic areas: Rendering Pipeline, AI, Physics, Scripting, etc.
Game engines come at a hand to such purposes. They bring programmer-friendly solutions, methods, and techniques which will let you face the task of implementing each logic area according to the program requirements of your videogame.
In other words, a game engine will provide you with the proper software components so that you can program the core aspects of your game in a rapid and reliable way. This doesn't mean that you will press some button and, say, the physics of your video-game will be "auto-magically" programmed for you. Following the physics' example, it means that you'll have a group of pre-built functions that will help you set the proper physics' behaviors for your video-game, but how you assemble the puzzle is your Company's task, you team's task or your task.
What kind of game engines can be found? Well, basically there are 3 type of engines: (a) general-purpose engines, (b) game-type-specific engines, and (c) game-bound engines.
(a) General-purpose engine: offers a set of functions so that you can develop and program any type of video-game.
(b) Game-type-specific engine: offers a set of features so that you can develop and program a certain type of video-game. For instance, a "First-Person-Shooter" game (FPS).
(c) Game-bound engine: created for a particular "title" -or series. Its use is normally considered as "one-time" even though sequels of the game may appear, which use a modified version of the base engine.
Most of the (currently available) game engines were developed to be use with C++ language, which is the standard language for game development (alias, the language used by 99% of each and every "Pro"). They are usually deployed as a set of "dynamic-link libraries" (DLLs), or add-ons to the most-used IDEs (like Visual C++, Dev-C++, etc.), so that they can be easily referenced, integrated and used in your game's implementation.
Sometimes, it's curious and instructive to see how these engines have evolved during years. One may think that it all starts with a general-purpose engine and then everything moves in a top-down direction. Makes sense. However, one may go wrong sometimes ...
For instance, GarageGames' "Torque Game Engine" was originally designed for the game "Tribes 2". After that, the engine went public so that developers could use it to build "Tribe-like" videogames for a minimum price which varied as a function of the kind of licenses offered.
Since then, the engine has been modified in such manner that today is one of the most used multi-purpose cross-platform game engines among "indies". What is more, it can be considered a game framework since it offers a whole set of tools that help developers leverage the production pipeline.
Therefore, GarageGames' TGE moved along the whole range of types of engines, starting from "(c)" and upto "(a)".
2. Game Frameworks.
"A suit of robust software and tools that offers a set of rapid and standard solutions to common program requirements and problems, all related to video-games". Meaning?
Game frameworks usually go beyond than game engines do, in the sense that they not only provide the libraries you need to carry on programming tasks with ease but also bring a set of tools into play which help you develop parts of your game in a graphical manner.
By the use of "Graphical User Interfaces" (GUI), the developer enjoys a more controlled experience over areas of programming and design, generally resulting in a more comfortable interaction with game APIs. Although it cannot be always assured that desired results are reached thorough the only use of GUIs, some frameworks also offer the possibility of either using scripts to do a fine tunning of the final output and/or extend the game logic, or accessing the final source code before compilation.
Some years ago these frameworks only consisted of either an add-on to existing languages (the game engine) plus a game-level editor to create new levels for your game. Now-a-days, they have evolved to more complete systems formed by several tools which offer more features so as to produce more accurate results with less lines of source code manually inputted by developers.
Levels construction, pre-calculation of lights and shadows, creation and visualization of meshes and animations, setting of game characters and their respective behaviors, general rules for the game (like collisions and physics), integration of cut-scenes, shaders, music and sound, ... these are just a few elements in the list of features offered by top-most game frameworks.
3. Game-Oriented Languages.
What is the difference between a general-purpose language and a game-oriented one? Simple. With the former you can usually program any kind of software -limitations may appear depending on the language. Take C# for instance, with it you can implement from graphically-appealing applications to console command-type programs. With the latter, only video-game related software can be produced -some exceptions do exist, where multimedia applications can also be created.
Does this mean that I can only use game-oriented languages to create a videogame? No, you can also use general-purpose languages -like C++, C#, Visual Basic and Delphi- by plugging in add-ons, class libraries, game engines and or game-oriented middleware, where available.
Why using then a game-oriented language? That is a matter of assessment, resources and preference. These kind of languages offer their own syntax, commands and structure. Not all of them follow the Object-Oriented Programming Paradigm (OOP) and some of them sometimes consist of a wrapper of a base API (like DirectX) with some moddifications and additions to ease the user experience.
What is the difference with "scripting"? A script is interpretated at runtime. Game-oriented languages usually provide a compiler that converts the source code into machine code at compilation time. Also, many of these languages provide an "Integrated Devleopment Environment (IDE) which consists at least of an official source-code editor.
Should I choose an OOP-tailored language? Again, that is a matter of preference. Some may still find some comfort on using non-OOP languages, but believe me, once you start to understand OOP and appreciate the advantages of OOP languages, you'll use OOP and you won't want to turn back the page again.
4. Game-Oriented Middleware.
Contrary to the criteria that leads a component to be considered as a "Game Engine", this kind of middleware specializes in a certain "logic area of incumbence" of the game-programming chain. For instance, AI.
There is a new growing wave of enterprises that specialize in the production of middleware components that one can "hook" onto their game projects. One of the main advantages of this components is the strong set of features they provide plus a high grade of reliability. One of the "cons" is simple, the more number of components you use in your game project, the more difficult will be for you to assemble the puzzle and follow the evolution of each component. Moreover, performance hit should be monitor closely since using a great number of external components does not necessarily mean that performance will increase, a priori.
The main areas covered by game-oriented middleware are rendering, physics and artificial intelligence. But new specific solutions to general problems are appearing from time to time.
Again, like "game engines" do, game-oriented middleware is generally targeted to C++ market. Some wrappers may exist for other languages/technologies, though, generally provided by third-party enthusiasts. Therefore, if used in a project, these wrappers should be always used with caution, having analized the whole spectrum of options.
Ok, I have read carefully the 4 points mentioned above, but what should I consider so as to choose the proper game components for my game project? Good question: it will be covered in next posts, but here is a short list: price, licenses (royalties, terms and conditions, etc.), support, bugs, average period between updates, performance, features, target platforms, type of deployment/integration, type of files supported (for images, meshes, animations, etc.) and so on.
"I've read your interesting post but I cannot wait for the next 'part' of the series, so where can I find more information about game engines and such?". Impatient, uh!? Ok, you can then pay a visit to "DevMaster.Net" site, where you will find a very extensive and detailed database of engines -most of them ranked by users.
Soooo ... with these words we are reaching the end of this first part about game engines and others. I'm not sure so far but I guess this will turn out to be a three-part series. ETA for "Part 2"? Maybe next Monday ... but as usually said "it will be released when it is done" ... ;)
[We will continue to discuss game engines on later posts, focusing on some of the existing/upcoming engines for .NET]
Remember last Friday's post? I had commented something about game engines, right? Ok, this is the first part of a small series of posts regarding game engines and other components like: game frameworks, game-oriented languages and game-oriented middleware.
As soon as you try to join the game industry you will run over a bunch of software components which may help you build a videogame from scratch, to some extent. Are all of these components a "game engine"? Quick response: "No". Why not? To answer that, let's first take some due notes of the following concepts:
- Game Engine: a software component that provides the core functionality that will help you implement "the whole" programming areas of the videogame.
- Game Framework: a suit of robust software and tools that offers a set of rapid and standard solutions to common program requirements and problems, all related to videogames.
- Game-Oriented Language: a language specifically built to let you program videogames with ease -or at least, (a bit) easier/faster than by using "general-purpose" languages.
- Game-Oriented Middleware: a software component that provides the core functionality that will help you implement only "a part" of the whole programming chain of the videogame.
By doing so, they usually bring at least one implementation layer between your final game and "low-level" libraries (like "DirectX" or "OpenAL"); generally speaking, "low-level" libraries provide access to computer/console hardware through a set of basic functions: take for instance "Application Programming Interfaces" (API) like "Direct3D" or "OpenGL", which can be considered as software abstractions of the "Graphic Processing Unit" of videocards (GPU), thus letting you handle and build "rendering systems".
Please, bear in mind that those 4 concepts are just one general and simple way of categorize the software components that you may find out there. Meaning, you could bring more categories to the field, rename or re-arrange the provided ones, but the important thing is that you realize that when you start to move down "the logic tree" trying to narrow general/base concepts, specificity may be found, and in turn, new categories may appear.
For instance, "Middleware" could sound too misleading for some since the word it-self wouldn't necessarily imply that it deals with just a part of the game-programming chain (contrary to "the whole"), but it'd imply that it brings at least one layer between your game and a low-level API (thus, some could deem "1" and "2" above as more general middleware).
Again, it's up to you to build your basic list of categories and place each component within them either with a great amount of certainty (for "obvious" choices) or "at a rough guess" (for "not-that-obvious" ones).
1. Game Engines.
If you remember one of my previous posts, when you want to program a video-game you will have to deal with lots of main logic areas: Rendering Pipeline, AI, Physics, Scripting, etc.
Game engines come at a hand to such purposes. They bring programmer-friendly solutions, methods, and techniques which will let you face the task of implementing each logic area according to the program requirements of your videogame.
In other words, a game engine will provide you with the proper software components so that you can program the core aspects of your game in a rapid and reliable way. This doesn't mean that you will press some button and, say, the physics of your video-game will be "auto-magically" programmed for you. Following the physics' example, it means that you'll have a group of pre-built functions that will help you set the proper physics' behaviors for your video-game, but how you assemble the puzzle is your Company's task, you team's task or your task.
What kind of game engines can be found? Well, basically there are 3 type of engines: (a) general-purpose engines, (b) game-type-specific engines, and (c) game-bound engines.
(a) General-purpose engine: offers a set of functions so that you can develop and program any type of video-game.
(b) Game-type-specific engine: offers a set of features so that you can develop and program a certain type of video-game. For instance, a "First-Person-Shooter" game (FPS).
(c) Game-bound engine: created for a particular "title" -or series. Its use is normally considered as "one-time" even though sequels of the game may appear, which use a modified version of the base engine.
Most of the (currently available) game engines were developed to be use with C++ language, which is the standard language for game development (alias, the language used by 99% of each and every "Pro"). They are usually deployed as a set of "dynamic-link libraries" (DLLs), or add-ons to the most-used IDEs (like Visual C++, Dev-C++, etc.), so that they can be easily referenced, integrated and used in your game's implementation.
Sometimes, it's curious and instructive to see how these engines have evolved during years. One may think that it all starts with a general-purpose engine and then everything moves in a top-down direction. Makes sense. However, one may go wrong sometimes ...
For instance, GarageGames' "Torque Game Engine" was originally designed for the game "Tribes 2". After that, the engine went public so that developers could use it to build "Tribe-like" videogames for a minimum price which varied as a function of the kind of licenses offered.
Since then, the engine has been modified in such manner that today is one of the most used multi-purpose cross-platform game engines among "indies". What is more, it can be considered a game framework since it offers a whole set of tools that help developers leverage the production pipeline.
Therefore, GarageGames' TGE moved along the whole range of types of engines, starting from "(c)" and upto "(a)".
2. Game Frameworks.
"A suit of robust software and tools that offers a set of rapid and standard solutions to common program requirements and problems, all related to video-games". Meaning?
Game frameworks usually go beyond than game engines do, in the sense that they not only provide the libraries you need to carry on programming tasks with ease but also bring a set of tools into play which help you develop parts of your game in a graphical manner.
By the use of "Graphical User Interfaces" (GUI), the developer enjoys a more controlled experience over areas of programming and design, generally resulting in a more comfortable interaction with game APIs. Although it cannot be always assured that desired results are reached thorough the only use of GUIs, some frameworks also offer the possibility of either using scripts to do a fine tunning of the final output and/or extend the game logic, or accessing the final source code before compilation.
Some years ago these frameworks only consisted of either an add-on to existing languages (the game engine) plus a game-level editor to create new levels for your game. Now-a-days, they have evolved to more complete systems formed by several tools which offer more features so as to produce more accurate results with less lines of source code manually inputted by developers.
Levels construction, pre-calculation of lights and shadows, creation and visualization of meshes and animations, setting of game characters and their respective behaviors, general rules for the game (like collisions and physics), integration of cut-scenes, shaders, music and sound, ... these are just a few elements in the list of features offered by top-most game frameworks.
3. Game-Oriented Languages.
What is the difference between a general-purpose language and a game-oriented one? Simple. With the former you can usually program any kind of software -limitations may appear depending on the language. Take C# for instance, with it you can implement from graphically-appealing applications to console command-type programs. With the latter, only video-game related software can be produced -some exceptions do exist, where multimedia applications can also be created.
Does this mean that I can only use game-oriented languages to create a videogame? No, you can also use general-purpose languages -like C++, C#, Visual Basic and Delphi- by plugging in add-ons, class libraries, game engines and or game-oriented middleware, where available.
Why using then a game-oriented language? That is a matter of assessment, resources and preference. These kind of languages offer their own syntax, commands and structure. Not all of them follow the Object-Oriented Programming Paradigm (OOP) and some of them sometimes consist of a wrapper of a base API (like DirectX) with some moddifications and additions to ease the user experience.
What is the difference with "scripting"? A script is interpretated at runtime. Game-oriented languages usually provide a compiler that converts the source code into machine code at compilation time. Also, many of these languages provide an "Integrated Devleopment Environment (IDE) which consists at least of an official source-code editor.
Should I choose an OOP-tailored language? Again, that is a matter of preference. Some may still find some comfort on using non-OOP languages, but believe me, once you start to understand OOP and appreciate the advantages of OOP languages, you'll use OOP and you won't want to turn back the page again.
4. Game-Oriented Middleware.
Contrary to the criteria that leads a component to be considered as a "Game Engine", this kind of middleware specializes in a certain "logic area of incumbence" of the game-programming chain. For instance, AI.
There is a new growing wave of enterprises that specialize in the production of middleware components that one can "hook" onto their game projects. One of the main advantages of this components is the strong set of features they provide plus a high grade of reliability. One of the "cons" is simple, the more number of components you use in your game project, the more difficult will be for you to assemble the puzzle and follow the evolution of each component. Moreover, performance hit should be monitor closely since using a great number of external components does not necessarily mean that performance will increase, a priori.
The main areas covered by game-oriented middleware are rendering, physics and artificial intelligence. But new specific solutions to general problems are appearing from time to time.
Again, like "game engines" do, game-oriented middleware is generally targeted to C++ market. Some wrappers may exist for other languages/technologies, though, generally provided by third-party enthusiasts. Therefore, if used in a project, these wrappers should be always used with caution, having analized the whole spectrum of options.
Ok, I have read carefully the 4 points mentioned above, but what should I consider so as to choose the proper game components for my game project? Good question: it will be covered in next posts, but here is a short list: price, licenses (royalties, terms and conditions, etc.), support, bugs, average period between updates, performance, features, target platforms, type of deployment/integration, type of files supported (for images, meshes, animations, etc.) and so on.
"I've read your interesting post but I cannot wait for the next 'part' of the series, so where can I find more information about game engines and such?". Impatient, uh!? Ok, you can then pay a visit to "DevMaster.Net" site, where you will find a very extensive and detailed database of engines -most of them ranked by users.
Soooo ... with these words we are reaching the end of this first part about game engines and others. I'm not sure so far but I guess this will turn out to be a three-part series. ETA for "Part 2"? Maybe next Monday ... but as usually said "it will be released when it is done" ... ;)
[We will continue to discuss game engines on later posts, focusing on some of the existing/upcoming engines for .NET]
Thursday, September 07, 2006
LET'S GET STARTED
OK, this is how the deal goes ... I will be creating a new entry in my blog from time to time "after hours" (when my eyes want to pop out of my head) ... So with the exception of today, you will find no more that one entry per day (and I promise I won't add a new entry every day, I have a life, you know) ... And yes! I'm not an English-native speaker so please forget any grammar and spell errors "I certainlywill make" (I know, I know, just kidding: "I will certainly make").
Having said that, we can now move onto the first topic.
If you read my previous entry you will see that I claim that sometimes resources (in any form of documentation, white-paper, book, source code, etc.) in some way assumes that you already know certain concepts, techniques, programming languages ...
Thus, if my blog will mainly deal with game development/programming with C#, what should you know first to properly follow and understand those resources? Think! Think! ... Tic-tac, tic-tac, ... Yes, you're right ... C# (pronounced "C-sharp" ).
1) What is this so-called "C-Sharp" language? In short, it's Microsoft's flagship language.
The long answer, it is a high-level language based on MS framework that deals for you with, among other things:
2) Being C# developed by MS, does this mean that C#-based assemblies will only run on PC computers with Windows OS? No, there is an open-source project called "Mono" which provides the necessary software that let you develop and run .NET applications on a multi-platform environment (Linux, Solaris, Mac OS X, Unix and even Windows).
You can use the "Mono-Develop IDE" to compile and run any assemblies you create for .NET through Mono's framework.
Off course, you can use Visual Studio 2005 to develop on Windows platforms, either on the commercial flavors or the free ones (called "Express Editions"). You can also use an open-source, and yet powerful, IDE called "Sharp Develop".
3) What makes this C# language a value asset for programming? Glad you ask.
Friendly, portable, powerful, fast, with lots of features that help you program ... And as you will see, as long as approach to game-related topics, that it not only a language suitable for applications (for which it is mostly used nowadays) but also for games.
Coming from Java? Not a problem. You will quickly find your-self programming with ease.
Coming from C++? Not a problem either. You will feel a great amount of relief when you notice that you can stop dealing with pointers. Speed? Almost the same under certain circumstances and growing (it will eventually match C++). Differences? Heritage is only allowed on a single basis. Delegates replace function pointers. "Generics" resembles "Templates". Etc., etc.
Coming from any other sort of basic and non-basic language? You will find that it is not hard to learn, even if it is the first time that you get your hands on Object Oriented Programming ("OOP").
4) Which versions of the MS framework are currently out there? Good question.
You have three main versions:
5) Where can I find books, tutorials and any other resources to get my hands on C# programming? Interested, uh?
For books, always visit vendors like "Amazon" and "Barnes and Noble", so to speak. Use the search for references like C#, .NET Framework, and so on.
And for tutorials, you can visit places like "The Code Project", "C# Corner" and "GotDotNet".
But always visit the main source: "MS Developers Network" and "MS Forums".
Well, to finish off today's entry (... yes, please ...) I could spend a lot of weeks and even months to talk about C#, but it is not the point here since you can see you shall find plenty of resources out there. I just wanted to give you a brief explanation of its main characteristics as well as to point you the right places to find resources.
If you aren't a newbie then it's most likely that you already knew all of the above-mentioned information, but if you are a newbie I hope it helps ... :)
Just remember, the use of C# is growing faster and faster among "indies" (we will talk about this in later posts) and I believe it's a matter of time until the game industry adopts it as a standard. And believe me, it will ... ;)
Having said that, we can now move onto the first topic.
If you read my previous entry you will see that I claim that sometimes resources (in any form of documentation, white-paper, book, source code, etc.) in some way assumes that you already know certain concepts, techniques, programming languages ...
Thus, if my blog will mainly deal with game development/programming with C#, what should you know first to properly follow and understand those resources? Think! Think! ... Tic-tac, tic-tac, ... Yes, you're right ... C# (pronounced "C-sharp" ).
1) What is this so-called "C-Sharp" language? In short, it's Microsoft's flagship language.
The long answer, it is a high-level language based on MS framework that deals for you with, among other things:
- Memory management (say 'goodbye' to pointers and function pointers and say 'hello' to the garbage collector delegates and so on, but of course, you can still use pointers with C# if you want, not to mention with C++.NET).
- Translation of source code to MS Intermediate Language or "MSIL" (now, executables and dlls are no longer machine code after "compilation" and no matter which .NET language you choose, you can reference and use assemblies created with other .NET languages with ease).
- Proper execution of assemblies on clients' machines (this will make sure that an MSIL assembly is "natively" compiled to machine code on the machine that executes/calls it in order to avoid the problems of running programs pre-compiled on third-parties' machines).
2) Being C# developed by MS, does this mean that C#-based assemblies will only run on PC computers with Windows OS? No, there is an open-source project called "Mono" which provides the necessary software that let you develop and run .NET applications on a multi-platform environment (Linux, Solaris, Mac OS X, Unix and even Windows).
You can use the "Mono-Develop IDE" to compile and run any assemblies you create for .NET through Mono's framework.
Off course, you can use Visual Studio 2005 to develop on Windows platforms, either on the commercial flavors or the free ones (called "Express Editions"). You can also use an open-source, and yet powerful, IDE called "Sharp Develop".
3) What makes this C# language a value asset for programming? Glad you ask.
Friendly, portable, powerful, fast, with lots of features that help you program ... And as you will see, as long as approach to game-related topics, that it not only a language suitable for applications (for which it is mostly used nowadays) but also for games.
Coming from Java? Not a problem. You will quickly find your-self programming with ease.
Coming from C++? Not a problem either. You will feel a great amount of relief when you notice that you can stop dealing with pointers. Speed? Almost the same under certain circumstances and growing (it will eventually match C++). Differences? Heritage is only allowed on a single basis. Delegates replace function pointers. "Generics" resembles "Templates". Etc., etc.
Coming from any other sort of basic and non-basic language? You will find that it is not hard to learn, even if it is the first time that you get your hands on Object Oriented Programming ("OOP").
4) Which versions of the MS framework are currently out there? Good question.
You have three main versions:
- .NET Framework 1.x: the one that started everything. Many applications still use it.
- .NET Framework 2.x: it has introduced one of the greatest features you will find: "Generics" (some friend!).
- .NET Framework 3.x: formerly called "WinFX". Currently, it's under a beta stage and will ship within "Windows Vista" next year. It will change the way you use the components that form the Framework it-self (from now on referred as "Foundations") . For instance, the "Window Presentation Foundation" will replace GDI (everything will be based on DirectX), and will introduce "XML for Applications" or XAML (pronnounced "Zamel") as a way to create GUI's.
5) Where can I find books, tutorials and any other resources to get my hands on C# programming? Interested, uh?
For books, always visit vendors like "Amazon" and "Barnes and Noble", so to speak. Use the search for references like C#, .NET Framework, and so on.
And for tutorials, you can visit places like "The Code Project", "C# Corner" and "GotDotNet".
But always visit the main source: "MS Developers Network" and "MS Forums".
Well, to finish off today's entry (... yes, please ...) I could spend a lot of weeks and even months to talk about C#, but it is not the point here since you can see you shall find plenty of resources out there. I just wanted to give you a brief explanation of its main characteristics as well as to point you the right places to find resources.
If you aren't a newbie then it's most likely that you already knew all of the above-mentioned information, but if you are a newbie I hope it helps ... :)
Just remember, the use of C# is growing faster and faster among "indies" (we will talk about this in later posts) and I believe it's a matter of time until the game industry adopts it as a standard. And believe me, it will ... ;)
Subscribe to:
Posts (Atom)