What programming language would you reccomend?

[Dullstar]

Hey.  I'm working on two game projects, an action/adventure game and an RPG.  While I could use game development software, it wouldn't be a good idea since I need it to work on at least Windows and Mac (because of crashing issues, I don't want to force my players to use Windows!  Also, while this may not happen for a while, my next computer will probably be a Mac).  I understand this would require edits, but what programming language is easiest to use that would be able to do both OSes with the least amount of change between the two versions of the coding?

Keep in mind that I need something that is very basic to learn, as I am new to the programming field.  If anyone knows any way to convert a .exe file for Windows into something that would work with Mac, that will do, too.

[ccexplore]

Cross-platform support can be tricky in general, and definitely limits the programming languages you should consider.

I'm not an expert at this though.  I know Java is designed to be platform-independent (Lemmini uses it), so it's a good choice in terms of that requirement, but I'm not sure whether it counts as "very basic to learn".

There's also http://www.blitzbasic.com/Products/blitzmax.php" class="bbc_link" target="_blank">BlitzMax, which is based on BASIC, so it might be easier to learn.  It does cost you $80 US dollars though, and I think you actually need a Mac to compile your program for the Mac.

I'm definitely not an expert on this, so hopefully someone else can chime in with better ideas.  Who knows, maybe there is some game development software out there that supports both PC and Mac.

If anyone knows any way to convert a .exe file for Windows into something that would work with Mac, that will do, too.

I can tell you that definitely won't happen.  There are just way way too many differences to bridge.  You generally need some sort of emulator like http://en.wikipedia.org/wiki/Wine_(software)" class="bbc_link" target="_blank">WINE to run Windows programs on a Mac, and be prepared that things won't be 100% compatible (kinda like how not all DOS games work well in DOSBox).

[Dullstar]

Ouch.

[GuyPerfect]

because of crashing issues, I don't want to force my players to use Windows!

Well, so much for us Linux users. Oh, and if you don't want crashing, don't code something that will crash. Two and two, man!

Your best bet for cross-platform would be C, as it's generally the first language supported on new architectures. Its cousin, C++, is a bit easier to use, but at a hefty expense to performance because it takes care of a lot of memory management in overhead that you'd otherwise do yourself in C.

Keep in mind that things like windows, sound, graphics output and network interactions will need different code depending on the target operating system, even if you're using a programming language that is supported on all your target systems.

Your best bet for ease of learning is BASIC, though support for that language tends to be minimal at best, and often commercial. What I recommend is that you learn the basics (no pun intented) of programming in BASIC, then shift over to C to make programs with more control over what the computer actually does. The best C programmers have a good understanding of what the computer will physically do when it runs their compiled code.

Another word of advice is that you DO NOT look into a language for the purpose of completing your projects in the quickest and most effortless manner possible. If you're only looking into programming because of the end result of what you could do with it, you've already doomed yourself to fail.

[ccexplore]

Your best bet for cross-platform would be C, as it's generally the first language supported on new architectures. Its cousin, C++, is a bit easier to use, but at a hefty expense to performance because it takes care of a lot of memory management in overhead that you'd otherwise do yourself in C.

There is a specific reason why I did not recommend C or C++.  The C syntax can look a little crazy for beginners (sure, not as "bad" as something like Perl, but still), and more importantly, it is easy to do things in that language that works on one platform but doesn't in another, or even stuff that only works on specific compilers, even ignoring all the windows/sound/graphics/network stuff.  In other words, it takes a little bit of care to avoid doing stuff in ways that are not platform-independent.  C++ might be slightly better in that regard but since you can still do C things in C++, you can still run into these issues.

Also, it's a toss-up to say whether C++ is really "easier to use" than C.  In my experience, some of the additional features in C++ supports add a whole other layer of subtle bugs and gotchas in your programming if you aren't careful.  It is definitely a more powerful language, but that extra power comes with extra care in learning and using the language.  In other words, probably not something for a beginner.

And as sound and graphics are bread and butter for game programming, you are not getting platform independence if you really need very different code for different target OSes.  Fortunately, C and C++ are so widely used that there should be a number of libraries like SDL that goes a great way towards making sound and graphics programming mostly platform independent in C/C++.

Keep in mind that things like windows, sound, graphics output and network interactions will need different code depending on the target operating system, even if you're using a programming language that is supported on all your target systems.

This is one reason I mentioned Java and BlitzMax.  Those languages include platform-independent support for things like sound and graphics that are bread and butter for game programming.  I don't programming much with those languages so I can't say how well the platform-independence work in practice, but at least we know that they design the whole thing with platform independence in mind.

Another word of advice is that you DO NOT look into a language for the purpose of completing your projects in the quickest and most effortless manner possible. If you're only looking into programming because of the end result of what you could do with it, you've already doomed yourself to fail.

I sorta know what you're trying to say, but surely, one of the great things about programming is in fact the end result, the new programs that you can write to do the things you want done! http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" />

[Dullstar]

Since the game is freeware, I need to stay on a minimal budget.  Even the http://dhost.info/dullstar" class="bbc_link" target="_blank">website is backed by free web hosting.  Without ads!

Also, I must point out, I am not screwing Linux users.  I would love it if it worked on Linux, but I want to take care of Mac and Windows first.

And by the way, it's being released in a version 1.1.0, the first after all the testing releases.  I will modify code to fix bugs through the whole thing.
For anyone who's interested, releases are in an x.y.z format, in which x is the episode (game) number (since it's a long storyline, and we don't want to constantly be updating graphics and the engine every time we make a sequel), y is the major release number, hitting 1 after the first complete release, and z being the code version number (for minor changes).

Is there a good Java coding program at very little or no cost?

[GuyPerfect]

[...] it is easy to do things in [C] that works on one platform but doesn't in another, or even stuff that only works on specific compilers, even ignoring all the windows/sound/graphics/network stuff.

I don't follow you here. To me, saying something like "StringsByID = malloc(NumStrings * sizeof(void *));" is going to be the same no matter what system you're running. Anything that's even remotely platform-specific is going to be pulling off of libraries designed specifically for the platform itself, so you're not going to accidentally do anything that will trip you up when you try to compile.

[ccexplore]

I don't follow you here. To me, saying something like "StringsByID = malloc(NumStrings * sizeof(void *));" is going to be the same no matter what system you're running.

Well for starters, if you start writing things to files and you want the files to be binary compatible across platforms, forget doing something like

fwrite((void *)arrayOfInts, sizeof int , numElementsInArray, file);

fwrite((void *)&mystruct, sizeof(mystruct), 1, file);

Problems?  Well let's see:

1) the bytes that make up an int are stored differently on different platforms.  Intel (x86) use little-endian, meaning least significant byte first.  Other CPUs such as PowerPC and Motorola 68xxx (for Macs) use big-endian, meaning most significant byte first.  Reading and writing the bytes out directly like the code above means files created by your program on one platform will not read with the correct values on another.

2) struct is another example.  Here the problem is that the C language leaves the alignment of members within a struct up to the compiler.  Meaning the members in a struct don't have to come in consecutive bytes; there could be unused bytes between members to optimize perf based on the CPU.   In other words, given a struct

struct a
{
    char a;
    int b;
}

Even sticking to one particular CPU where int is 4 bytes, sizeof(struct a) can still differ depending on compiler and compiler settings.  For example, it's likely that the compiler will try to align the int to 4-byte boundary by adding 3 unused bytes between char a and int b, making the struct 8 bytes.

3) speaking of ints, guess what the language says about sizeof(int)?  Absolutely nothing.  You are saved mainly by the fact that most people currently has 32-bit CPUs, where sizeof(int) is likely 4 bytes.

Another area where C is notorious unspecific relates to order of operations.  Again this is not even a cross-platform issue; it can vary between compilers.  For a sampling, consider the following examples from the http://c-faq.com/expr/index.html" class="bbc_link" target="_blank">C FAQ:

Code: [Select]

3.1 Why doesn't this code:

a = i++;
work?

3.2 Under my compiler, the code

int i = 7;
printf("%d\n", i++ * i++);
prints 49. Regardless of the order of evaluation, shouldn't it print 56?

3.3 I've experimented with the code

int i = 3;
i = i++;
on several compilers. Some gave i the value 3, and some gave 4. Which compiler is correct?

3.7 Why did

printf("%d %d", f1(), f2());
call f2 first? I thought the comma operator guaranteed left-to-right evaluation.
The danger here is that if you are unaware of these sorts of things and don't take care to avoid these sort of unspecified expression evaluation order in your code, you can end up writing something that works fine on one compiler (say, the one you are using to compile for x86), but inexplicably works differently on another compiler (say, the one you use for compiling for Mac/PowerPC).

Finally, many popular compilers (like Visual C++ from Microsoft) often add a lot of extra stuff on top of the standard, such as compiler-specific preprocessor directives, extra library functions outside of the standard, etc.  It is possible for someone to learn C using a specific compiler and unaware that some of the things they are using are compiler-specific or runtime-library specific, and then end up with source code that fail to compile on another compiler, or worse, compile but doesn't work properly during runtime.  This is especially easy to do with runtime library functions, since it's easy for someone to look up one in their compiler's help documentation and use it, without paying attention to whether that library function is actually in the standard and therefore supported by all standard-compliant compilers.

============

In summary, it is possible to write portable code in C, but it is not automatic from merely learning to program in C; you need to be conscientious of these "gotchas" hidden in the language that can work against you in code portability.

[The Doctor]

My recommendation is C#, in Mono and using MonoDevelop. Why?

It's available for Linux, Mac OS X, and Windows (and Windows can of course run the software against the .NET Framework). You run Linux, so there we go. To do the game parts, you could use SdlDotNet (also for all three of the aforementioned platforms). This is a check against your list.
From my experience coding my current clone, I don't need to make too much changes from one to the other so that is another check against your list. I have it in Windows and Mono at the moment with no trouble.

C# is also very easy to learn, I have found. There's a wealth of knowledge on C# in many popular learning series (for Dummies, teach yourself in x minutes, etc). It is an object-oriented language, which makes things so much much simpler in large projects. It also has garbage collection, which means you don't need to deal with some of the nitty gritty details like memory management.

Many people will say that perhaps there are more powerful languages, or blah blah blah. Well, I think C# is plenty powerful and further more hits that button which is quite important: easy to learn. Remember, you'll get alot of suggestions Dullstar, pick whatever YOU think matches YOUR needs. Don't let people tell you that you need "x feature" and "y feature". Get what you want, mate!

[Dullstar]

I'm probably best with Linux, Windows XP (Mr. K helped reinstall it so it works), and a version of Mac OS X (Tiger?).  I can test on these.

I haven't used Linux recently, actually, though I still have it, assuming Mr. K's idea of backing up the partition worked (it hasn't been checked yet).

For the points ccexplore brought up, I think I should do the "Hello World" program with Jason's suggestions as a check to see if it will work.

I'm okay with making changes as long as they don't get too complicated.

[ccexplore]

I still think it's worthwhile to try and see if there're game development software that are cross-platform, like a cross-platform version of GameMaker or something.  Graphics and sound programming is often the trickiest and most time-consuming part of game programming, and if someone's already done the work out there (like a GameMaker type thing), why reinvent the wheel?

[GuyPerfect]

Forward: This post is largely in disagreement to ccexplore's last post. Apologies in advance. (-:

1) the bytes that make up an int are stored differently on different platforms.

I will concede that this is a consideration that will not be apparent to new developers, but I always encourage using only char arrays when dealing with any kind of streaming I/O. It avoids the problem altogether as well as enforces strict and consistent formatting.

2) struct is another example.  Here the problem is that the C language leaves the alignment of members within a struct up to the compiler.

This is a feature of the language. The C specification makes no guarantee that elements within structs fall sequentially in memory, on a given byte boundary or even in the same order as the definition in the source code. This falls into the category of "know what you're using."

3) speaking of ints, guess what the language says about sizeof(int)?  Absolutely nothing.

Like the above, the sizes of most data types are not guaranteed and ALL processing that needs to know how big they are should use the sizeof operator. Like my example in my previous post, I use sizeof(void *) because there's no way to determine how many bytes are used for pointer variables. This is a fundamental consideration in programming with C: it's not something a developing programmer should be unaware of unless they're doing their own research and overlook it.

Another area where C is notorious unspecific relates to order of operations.  Again this is not even a cross-platform issue; it can vary between compilers.

This is simply incorrect. The C standard explicitly defines lexical conventions such as the order of processing and the activity carried out by all operators in the language.

Code: [Select]

3.1 Why doesn't this code:

a = i++;
work?
It does work, so long as a[] has enough indeces to write the value of i. i will be incremented after a[i] is written.

Code: [Select]

3.2 Under my compiler, the code

int i = 7;
printf("%d\n", i++ * i++);
prints 49. Regardless of the order of evaluation, shouldn't it print 56?
++, as it appears after a variable, is executed last after all other operations. If I = 7 and A = I++, A == 7 and I == 8 after the assignment. To increment the value before any other processing, use ++ before the variable. If I = 7 and A = ++I, A == 8 and I == 8 after the assignment. In the printf() call above, 49 is the correct output, and i is incremented twice to have a new value of 9 afterwards.

Code: [Select]

3.3 I've experimented with the code

int i = 3;
i = i++;
on several compilers. Some gave i the value 3, and some gave 4. Which compiler is correct?
Assuming the state of i after the i = i++ statement, the correct value for i will be 4. First, i is assigned the value of i (3). Second, the value of i is incremented to become 4.

Code: [Select]

3.7 Why did

printf("%d %d", f1(), f2());
call f2 first? I thought the comma operator guaranteed left-to-right evaluation.
As with the above examples, the compiler that calls function f2() first is defiant of the C specification. All parameters of a function should be evaluated in order from left to right.

The danger here is that if you are unaware of these sorts of things and don't take care to avoid these sort of unspecified expression evaluation order in your code, you can end up writing something that works fine on one compiler (say, the one you are using to compile for x86), but inexplicably works differently on another compiler (say, the one you use for compiling for Mac/PowerPC).

While I agree that the above are indeed legitimate causes for distress by code being interprated in multiple ways by various compilers, it's not because of the C programming language; it's because of the compilers failing to adhere to the C specification. Though to be honest, I can't think of any code I've written that uses i++ except as a statement by itself, and I've never used ++i.

It is possible for someone to learn C using a specific compiler and unaware that some of the things they are using are compiler-specific or runtime-library specific, and then end up with source code that fail to compile on another compiler, or worse, compile but doesn't work properly during runtime.

Again, any extensions to the standard C specification are not C; they are simply add-ons and should not be treated as parts of the language.

Again, sorry to be all "No, you're wrong!" here, but the general premise behind the exceptions you cited boil down to whether or not the program and compiler adhere to the C specification.

[The Doctor]

Very interesting points all around, but may I just suggest we stick to the topic of finding a relatively easy to learn programming language for Dullstar? http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" />

I'll probably get shot for suggesting such a terrible thing, lol. http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" />

[ccexplore]

(Sorry in advance for the long post.)

Forward: This post is largely in disagreement to ccexplore's last post. Apologies in advance. (-:

There's a reason I quoted the http://c-faq.com/index.html" class="bbc_link" target="_blank">C/C++ Faq.  I suggest you take some time to read it.

1) the bytes that make up an int are stored differently on different platforms.

I will concede that this is a consideration that will not be apparent to new developers, but I always encourage using only char arrays when dealing with any kind of streaming I/O. It avoids the problem altogether as well as enforces strict and consistent formatting.

Char arrays doesn't exactly "avoid the problems altogether", at the end of the day, you still need to learn to turn an int into bytes in a platform-independent manner.  Either you learn about endianness and have different code for serializing ints in different platforms, or you learn to do it arithmetically using shifts and bitwise-logic operators.  You need to solve the problem if if there's a chance that your program produces files in one platform that may be consumed in another (eg. a savegame emailed from a PC user to a Mac user, say).

It would've been a better suggestion if you suggest to avoid binary file formats.

2) struct is another example.<snip>

<snip>This falls into the category of "know what you're using."

And my point is, I feel there're a lot of "you better know what you're using" in C.  Hence maybe not a top recommendation for beginners. http://www.lemmingsforums.com/Smileys/lemmings/winktounge.gif" alt=";P" title="Wink-Tongue" class="smiley" />

3) speaking of ints, guess what the language says about sizeof(int)?  Absolutely nothing.

Like the above, the sizes of most data types are not guaranteed and ALL processing that needs to know how big they are should use the sizeof operator.

Remember I'm still talking in the context of file I/O.  Notice that I used sizeof(int) in the example code, but that still means your code can end up writing (say) 4 bytes to the file in one platform and (say) 8 bytes in another, and so files produce in one platform may not be consumed correctly in another.  The most logical thing to use (sizeof operator) actually works against you in this case.

Another area where C is notorious unspecific relates to order of operations.  Again this is not even a cross-platform issue; it can vary between compilers.

This is simply incorrect. The C standard explicitly defines lexical conventions such as the order of processing and the activity carried out by all operators in the language.

Please read the examples I quoted from http://c-faq.com/expr/index.html" class="bbc_link" target="_blank">the C FAQ.  That webpage has the correct answers to the questions; I think you'll learn a thing or two, based on your response to those questions.

Obviously I don't mean that there are no order of operations whatsoever, but there are plenty of cases where the standard actually specifically leaves the ordering open (unspecified) to a certain extent, for compilers to do what's best/easiest on the target platform.  Particularly operators with side effects.

Though to be honest, I can't think of any code I've written that uses i++ except as a statement by itself, and I've never used ++i.

That's exactly what I mean when I say "take care to avoid these sort of unspecified expression evaluation order in your code".  You learn to write your code in ways that make the ordering as explicit as needed.  Then again, printf("%d %d", f1(), f2()); doesn't exactly look like there's a problem on first glance does it?

Again, any extensions to the standard C specification are not C; they are simply add-ons and should not be treated as parts of the language.

Yes, but people usually don't learn C by reading the standard C specification.  For a beginner learning C, depending on how they learn the language, they may not be consistently aware of what is part of the standard and what isn't.  Think of my example of someone looking up a function from the help documentation.

Again, sorry to be all "No, you're wrong!" here, but the general premise behind the exceptions you cited boil down to whether or not the program and compiler adhere to the C specification.

My general premise is that C has a number of gotchas that can work against a beginner, especially in the context of making sure their code works correctly cross-platform.  That said, you can turn this around and say it'd be a good exercise for someone to learn to use the language properly.

[ccexplore]

For the points ccexplore brought up, I think I should do the "Hello World" program with Jason's suggestions as a check to see if it will work.

That's traditionally what they start with for teaching programming to someone.  Definitely go through the "Hello World" exercise, but make sure at some point you also do a more enhanced "Hello World" that involves graphics and sound, to get yourself familiar with whatever language/platform/library you end up using for graphics and sound programming.  Good luck with your game projects!