Should I give up?

No matter what language you use, there is always something that has to be distributed with it.

With C/C++ programs, you'll have to distribute the proper library DLLs and make sure the user has the right version of the C/C++ runtime installed. Then there are video card drivers. The DirectX user redistributable, etc...

So nothing will change. Just the name of the language!

In most games the game data will end up MUCH bigger than any runtime/exes anyway so its generally a non-issue size wise.

No matter what language you use, there is always something that has to be distributed with it.

With C/C++ programs, you'll have to distribute the proper library DLLs and make sure the user has the right version of the C/C++ runtime installed. Then there are video card drivers. The DirectX user redistributable, etc...

So nothing will change. Just the name of the language!

I see what you are saying, but I'm not sure it's strictly always true, it depends on the type of game / app you are writing, and the market (think e.g. casual games, apps, versus AAA games).

If you write c / c++ and statically link to the runtimes, there are no dependencies due to the language, only core OS dlls (which will always be present).

The need for more and more sprawling dependencies is up to you, your choice of language / tech and what third party stuff you decide to pull in. (Sometimes you can statically link to third party stuff though).

I think azonicrider is right to an extent .. end users are easily put off installing stuff. If your game needs a 15 minute download from a third party and separate installation just to run, they'll probably move on. I know I do. If I see a 'your java needs to be updated' or flash or whatever, I'm like 'forget it'. So there is a good argument for considering your market before deciding what dependencies to rely on.

Check out some of the games you can buy on Steam. There are Flash games, Unity games, XNA games, even a couple written in Java in addition to all the normal native code apps. If you make a fun game it doesn't matter the technology used or the amount of pre-reqs that need to be installed for it. That kind of thing only runs the first time you play the game.

I for one automatically install Flash/C++ Redistribuable/DirectX/.NET/Java and even XNA redistribuables when installing a new PC. I would think twice about installing a "Strawberry Perl" package that I never heard about though.

I think azonicrider is right to an extent .. end users are easily put off installing stuff. If your game needs a 15 minute download from a third party and separate installation just to run, they'll probably move on. I know I do. If I see a 'your java needs to be updated' or flash or whatever, I'm like 'forget it'. So there is a good argument for considering your market before deciding what dependencies to rely on.

Yep you understood what I meant. I doubt distributing the Strawberry Perl folder is enough, its more than likely having to use the Perl exe, then Command Prompting the 5 minute SDL installation.

Do you think I should convert to a language thats pre-installed in computers, to not deal with this? (such as C)

Find out what's needed to make an installer first. Maybe you can even make a folder that contains everything you need without an installer, it's worth a shot. There are probably people that have done a game with it before, try the IRC channel mentioned here: http://sdl.perl.org/

If it doesn't work or gets too big and complicated, then yes it's probably a good idea to try out another language. Already being familiar with SDL should help you use it from C easier.

Yea I won't give up yet. I bet I could mickey-mouse a Wizard together, that includes the bare essentials I need from the Strawberry package, and my game files.

I've found out that SDL is just a module folder, so I don't need to worry about retrieving that from CPAN(the Perl network) using Command Prompt.

It's possible, in C#, to embed .dlls in your application and have no need for separate installs (theoretically). Perhaps you could look into that idea for Perl?

In the end, if the game is fun and people want to play it, they will do what they need to do. People will buy proprietary controllers, get new video cards, even buy entire new computers to play fun games. Guild Wars 2 only cost $60.00, but I spent several hundred upgrading my CPU, RAM, and Video card, just so I can squeeze every little ounce of speed out of my aged system while playing the game.

There is a game mod I was messing around with a couple months ago called DayZ, and OMFG, I swear you need a degree from MIT plus all the stars in alignment just to get it installed and running, yet there are tons of people who have gone through the hassle, just to play the great game.

Like you, I have also had trepidation about what to do once a project is complete. Trying to figure out a good distribution method, how to take payments, advertising, as well as worrying about piracy prevention... It is quite overwhelming.

No. Do not give up.

You could learn C and write a simple front end. All it would need to do is call the necessary scripts from the command line.
For example it could do the following:

Download a copy of perl from internet.
Install it on target system.
Set up scripts folder on system.
Modify system paths to point to scripts.
install another exe that autoloads you game scripts
Make desktop icons that link to the script loader exe, parameters passed with the link tell the loader what to load.

From the users perspective all they would have to do is double click the exe, and presto all done.

This is why people favor languages like C, C++ and C# for game development. You can theoretically write a great game in any Turing-complete language, but some are just more conducive to game development than others. For instance, writing a game in C++ is a hell of a lot easier than writing it in assembly language.

What language you choose is mainly up to you, your goals and your target platform(s). I suggest C# a lot (as I love it and I'm biased, for one), since Mono has made it a true cross-platform language and there are excellent DirectX wrappers (SlimDX, SharpDX, etc) and OpenGL wrappers too... even wrappers for CUDA and PhysX... so if you know what you're doing you can get all the benefits of C# and run it damn near anywhere.

Again, this is just MY personal bias/opinion, but I couldn't imagine trying to write a game in a language like Perl, Lisp, Python, or some scripting language, etc... though some other people pull it off smoothly, I'm just heavily in favor of the "curly-brace" style and C-like syntax in more "conventional" languages. And I like the lower-level features and capabilities it gives me to communicate directly with hardware and rendering APIs...

I have a slight experience with .exe files.

This is why people favor languages like C, C++ and C# for game development. You can theoretically write a great game in any Turing-complete language, but some are just more conducive to game development than others. For instance, writing a game in C++ is a hell of a lot easier than writing it in assembly language.

What language you choose is mainly up to you, your goals and your target platform(s). I suggest C# a lot (as I love it and I'm biased, for one), since Mono has made it a true cross-platform language and there are excellent DirectX wrappers (SlimDX, SharpDX, etc) and OpenGL wrappers too... even wrappers for CUDA and PhysX... so if you know what you're doing you can get all the benefits of C# and run it damn near anywhere.

Again, this is just MY personal bias/opinion, but I couldn't imagine trying to write a game in a language like Perl, Lisp, Python, or some scripting language, etc... though some other people pull it off smoothly, I'm just heavily in favor of the "curly-brace" style and C-like syntax in more "conventional" languages. And I like the lower-level features and capabilities it gives me to communicate directly with hardware and rendering APIs...

Perl borrowed tons of C syntax, and uses curly braces.


What really is quite strange, is I'd have the most trouble with Perl on Windows. Perl is already pre-installed in Linux and Mac, and I'd just have to set-up the SDL files into the correct location.

In terms of using games with lots of pre-reqs and/or uncommon languages have you heard of Severance: Blade of Darkness? It's written in Python and most (all?) of the game is actually compiled at runtime. Did this effect the awesomeness of the game? Not at all, it was such an amazing game and it was packaged with everything you needed to run it. Most people didn't even realised it wasn't written in a common language.

As long as you're working with a language that you can accomplish your goals with then stick with it. And we look forward to seeing the end product in IOTD!

Do you think I should convert to a language thats pre-installed in computers, to not deal with this? (such as C)[/QUOTE]

C is not pre-installed in any computer, per-se. In fact, what do you even mean by "pre-installed in computers"?

C needs a compiler to work(and a linker, usually, and parsing, and a preprocessor, text-editor, etc., etc., etc.). C compilers are not pre-installed in most factory bought computers.

The only things you can basically use in most computers in this department of "coding" is HTML/CSS and Javascript. Everything else must be manually/automatically installed for use.

So I don't get your sentence there at all ... if you want an easily playable and downloadable game file, make the process of installing/playing it faster and easier.

You said,

I have to somehow include Strawberry Perl and SDL in the installation wizard, and I would be surprised if I could get that to work error-less. Even then, the Strawberry Perl package is quite big, and the file size will probably throw-off users.[/QUOTE]

So don't use Strawberry Perl then, if you think it will turn-off possible users of your software.

There is no direct integrated language in a "machine", (assuming you mean a processor) and you need to download the necessary programs and data to write, compile, and create software. This goes for every other language as well. The processor doesn't work with C, Perl, or anything like that.

A processor works with machine language (and that's not really even a "language" at all), and all the higher-level tools/programs to convert to it are unavoidable and tweakable at best for the best possible situation.

Along the lines of what Pointer2APointer was getting at. If you can compile your game so it's not an interpreted script, but rather native code you won't need to distribute the runtime.
First google: http://stackoverflow.com/questions/2948405/how-to-compile-a-perl-script-pl-to-a-windows-executable-exe-with-strawberr

Take a break. I'm developing a large game called "Ant Farms 2" and we started to get burned out so we made a little game called "Match". Match is almost done and prjected to make a little profit. Were refreshed and ready to work on Ant Farms 2 again. Match has taken us roughly a week to make but provided a great break from Ant Farms 2.

C is not pre-installed in any computer, per-se. In fact, what do you even mean by "pre-installed in computers"?

C needs a compiler to work(and a linker, usually, and parsing, and a preprocessor, text-editor, etc., etc., etc.). C compilers are not pre-installed in most factory bought computers.

The C code itself is obviously unusable for most Windows users (OTOH gcc comes preinstalled with basically every Linux distribution), but it is pretty clear he is talking about binaries made from compiled C code, which may only rely on built-in and system libraries, which means it'll work on *any* Windows computer. But this is not quite true - any moderately complex game is going to be using external libraries (from DirectX to an asset-loading manager) which may require additional .dll's or frameworks to be bundled along. There is no perfect solution - if you use anything other than system, standard, or built-in features, the user's gonna need them somehow.

Do you think I should convert to a language thats pre-installed in computers, to not deal with this? (such as C)

C is not pre-installed in any computer, per-se. In fact, what do you even mean by "pre-installed in computers"?

C needs a compiler to work(and a linker, usually, and parsing, and a preprocessor, text-editor, etc., etc., etc.). C compilers are not pre-installed in most factory bought computers.

The only things you can basically use in most computers in this department of "coding" is HTML/CSS and Javascript. Everything else must be manually/automatically installed for use.

So I don't get your sentence there at all ... if you want an easily playable and downloadable game file, make the process of installing/playing it faster and easier.

You said,

I have to somehow include Strawberry Perl and SDL in the installation wizard, and I would be surprised if I could get that to work error-less. Even then, the Strawberry Perl package is quite big, and the file size will probably throw-off users.[/QUOTE]

So don't use Strawberry Perl then, if you think it will turn-off possible users of your software.

There is no direct integrated language in a "machine", (assuming you mean a processor) and you need to download the necessary programs and data to write, compile, and create software. This goes for every other language as well. The processor doesn't work with C, Perl, or anything like that.

A processor works with machine language (and that's not really even a "language" at all), and all the higher-level tools/programs to convert to it are unavoidable and tweakable at best for the best possible situation.
[/quote]How come I can run C and C++ programs without installing anything, yet when I run a program written in Java or Ruby, I need to install the compilers for those languages?

http://en.wikipedia.org/wiki/C_%28programming_language%29

C is one of the most widely used programming languages of all time,[sup][6][/sup][sup][7][/sup] and there are very few computer architectures for which a C compiler does not exist.[/quote]
(I don't know if you guys are against quoting Wikipedia)

UglyDavis, yea I understand that. I did the same thing with Python before, and I could probably get it to work with this Language.