Well, I've read a bit about different languages, and their usage in game development, but I still can't make up my mind for a language of choice to start learning and developing games with. Some of my top picks are C, C++, and C#. Here are my concerns/priorities, and maybe you can tell me which language will best suit these issues: -I don't want to make FANCY 3d state of the art games. At best, 2D-Isometric is what I'm going for. -I'd like my games to at least RUN on most versions of Windows, portability isn't a priority but would be a nice extra feature if games become successful. -I'd like to be able to develop the engine by myself, or with maybe one other person, without extremely long development time, and I want to try and avoid having high system requirements on the games. The lower the requirements, the better.

I pretty much answered this on your other post. My recommendations still apply. If you learn C# then you can use XNA to create games. It is a fairly simple system to use, however there is not a lot of documentation on XNA yet. If I recall correctly, there are a couple of books out so if you have access to a decent library you should be able to pick those up.

Give Python a glance before you dismiss it.

Searching the archives for 'C++ vs C#' and similar phrases will turn up lots and lots of info on this topic.

However, given what you've stated, I think a reasonable answer would be: C#. (I haven't actually done any programming in C# myself, but everything that I know about it suggests to me that, of the three languages you mention, it would be the best choice for you.)

[Edit: Too slow.]

blitz3d VERY EASY TO LEARN i learned enough of it in a month to make a fully functional 3d game! C languages are hard as hell to learn so i gave up on those(not worth the headaches). blitz3d doesnt require a high tech computer infact my comp is pretty old! lolz

I may not be an expert, but I highly disagree with your link on "make games, not engines."

Most game companies I've heard of, always create engines for their game, to allow other people's creativity to become involved without the knowledge of how the code works. (Ex: Map/level designers)

It also allows 2nd or 3rd series of your games to be released without having to rewrite large portion of code.

Aitxyn:
In the case of triple A game companies, I agree with you one hundred percent. The difference here is that you are not one of said game companies. You are one person, and your goal is to create a game. Not an engine. If you are going to have other people working on your game by creating content, chances are you will be making tools for these people to create the content with, or at least tools for yourself to adapt the content they created to your game. In essence, a game engine is an abstraction of an actual game. It is the core, without the content or the specializations. Simply a shell which may or may not accomplish what you want.

In Code Complete the author mentions that at NASA one of the last stages in project development is going through the project and looking at pieces of the code which could be reusable in other projects. At this point, they make changes to make those pieces of the code more modular. You are still thinking about code at a very high level, so this may not make as much sense, but in the case of the NASA example the code first does what they need it to do, and second is prepped to be reused later.

In your case, the article is correct. If you want to make an engine, at least make it after the game. While developing you will discover what parts can be reused and what parts can't. When you start your next game, you will see which parts can be brought in to it from the previous one.

Quote:Original post by bobwrit
BlitzBasic is an easy language to learn and program games with but C is more powerful. In case of C Vs. C++ Vs. C#, I would say C++ but that's because I havn't used C# and in C++ you can use OOP.

You can use the object oriented paradigm in C# too. In fact, C# is actually an OO language where C++ is not, strictly speaking. It typically isn't a good idea to recommend a language over another unless you know enough about both to make an intelligent recommendation.

Quote:Original post by Aitxyn
I may not be an expert, but I highly disagree with your link on "make games, not engines."

Most game companies I've heard of, always create engines for their game, to allow other people's creativity to become involved without the knowledge of how the code works. (Ex: Map/level designers)

It also allows 2nd or 3rd series of your games to be released without having to rewrite large portion of code.

You might give the article another read.

Whether a major development house builds their latest AAA game on a pre-existing engine is more or less irrelevant to the question of whether you (or I for that matter) should make games or engines. Here are a few reasons:

1. Most of those engines came out of a succession of games, were refined with each game, and eventually reached a state where the 'engine' was mature enough to be licensed to other companies making similar games.

2. Most of the engines in question are the product of countless (and I do mean countless) man hours of work and effort, and in many cases many hundreds of thousands or even millions of dollars. They're not the kind of things you just sit down and write in a month or three; they develop and evolve over time, usually over many years, until they've matured into something useful.

3. It takes a great deal of experience to develop an engine that's general enough and well designed enough to be useful to other developers. I couldn't do it, and I consider myself to be a halfway decent programmer. The question then is, is developing a general game engine (even for your own games) a task that you feel ready for, software-design wise?

4. What's wrong with the approach suggested in the article? (At least as I recall it...). Write a game, then when you start your next game, pull out anything that's applicable from the first project and re-use it. Over time, this will develop into your 'game engine'.

There's more that could be said here, but in short, I think you may have missed the point of the article (or maybe you're just trying to apply it in the wrong domain, i.e. the development of big-budget AAA games).