Hello everyone.

Let's assume I'm totally new to game development, even if is not true.

Now, what I'm asking for is a tip about which platform and language to develop for in life.

I'm considering Android or PC and HTML, Flash or BASIC.

If you were in my shoes, which one would you take?

Please don't just answer but motivate your outlook.

Note I'll not develop for consoles, iPhone or Mac, Linux.

Android a main platform? Then Java. Though I honestly don't know where that will lead, their reluctance to implement something semi compatible with Java 7 (and 8 is coming) doesn't shows much on that side...

Why not choose something cross-platform if you can't decide? Unity + C#/JS and LibGDX + Java both support Web/Desktop/Mobile, just to name two. There's a wide array of cross-platform options. As for language experiment with a few first get an idea of what you like in a language and don't then choose one that best fits your needs and preferences, if you like easy syntax choose python, if you like performance choose C++.

thanks for your time, i'm also considering "standard" application programming, not just games.

just to ave an idea, is tere any list of cross platform options to pick from? (maybe on wikipedia for example)

anyhow as mobile platform i would stick with android, if it will still be there in te future.

i would develop for pc and the web, so what should i pick off?

p.s.: i gave a point to each

Honestly, I'm biased because professionally and personally I'm a C# developer, but I think it's a really good language to get into, especially if you're starting out. Reasons why:

1. Clean, modern syntax.

2. Learn C#, then it's not that hard to go to Java, or C++. Same can be said of those other two, I guess. But certainly better than learning Flash or BASIC, especially if you're interested in getting into general application development.

3. Unlike Java, you get more flexibility when dealing with memory (value types, non-heap allocated objects)

4. Unlike Java, it's really easy to do unmanaged-to-managed interop, so it's a lot easier to use that native library you see your eye on.

5. Unlike C++, the memory model is a bit easier because its managed, but of course you lose flexibility as a consequence (doesn't impact a beginner in my opinion, in fact quite the opposite! More apt to blow your foot off).

6. Like Java, C# has a rich standard library to draw upon.

7. .NET is limited to Microsoft platforms (Windows, and windows derivative). There is Mono, the open source implementation of .NET, as well as Xamarin which gets you Android and even iOS.

I'm not a game developer, I work on CAD products, which we use a combination of C++, C++/CLI, and C# (I lean more to the managed side of things on that spectrum). And in my own time, I use C# for graphics projects. So in my opinion, it's a great language for games, graphics, general applications, what have you.

Also since you're a beginner, I highly recommend starting small and sticking to one thing. Saying you want to develop for pc, for web, for mobile, etc can stretch you too thin where you're chasing too many rabbits and you wind up not learning a whole lot. I would stick with just one platform - PC, to gain experience in how to put together an application, then branch out. Especially if you're interested in general application development.

4. Unlike Java, it's really easy to do unmanaged-to-managed interop, so it's a lot easier to use that native library you see your eye on.

Sorry to hijack the thread a bit but I wanted to ask this to a C# dev.

In Java making the JNI work is a bit of a mess, though there are utilities/libs made to make it easier (like Java Native Access ).

I've heard that its much easier on C# but someone made the point that its easier as long as you're on .NET world, that working with native libraries in Mono isn't as easy. Adding to that, you'd need to write Mono specific code, and .NET specific code.

Whats your take on that?

OK, thanks again for your time.

Searching around the internet I found FreePascal targets iOS and Android, other than PCs (win lin and mac).

Maybe I could stick with it, what about?

I can't make the decision for you because I don't know what your goals are, but I'll try and do what I can to guide you on your way to deciding. First one thing to note first:

A common problem a lot of people have, especially when starting out(Although for me I still seriously struggle with this even years after first starting), is spending to much time making sure they make every decision about WHAT they're going to do perfectly, and then not having much time left ever to actually DO the thing. For me I wasted a lot of time starting out trying to decide which language to use, and now that I've been through a couple languages and am done with that stage, I waste way to much time deciding which resources to use(books/articles/whatever) and not enough time actually using them. Anyway, my point is, regardless of how much time you spend trying to make the perfect decision you can never guarantee that it'll actually be perfect, you may think you have found the perfect platform but after spending a couple weeks working with it you're bound to learn new things about it that you didn't know and you might end up changing your mind.

It's more efficient to put little(still some, but not a ton, in fact I think 'going with your gut' would be good for this kind of decision tbh) effort into deciding what you platform you want to use and then spending the time you saved trying out whatever platform you choose, and then if it doesn't work out you can always go back and use all the knowledge and experience you gained from the first platform to decide on and learn a new platform. The more time you spend doing things the faster you'll get something done and the faster you'll learn, and those are likely to be your main goals anyway.

On to the platforms now though:

Android - this is a great platform to get started with. I like mobile because it's more common to see great games made by small/1 person teams(although this still happens on desktop and consoles too, and plenty of mobile games have huge teams and budgets). Being able to actually complete a game on your own without too much time or experience is actually a really valuable thing in my opinion. Not only is it awesome to be able to make your own game but it is great for motivation. Burning out is probably the #1 reason games don't get finished and developing for mobile reduces this risk.

PC - PC is another one of my favorites, just because PC games are my favorite. Take into consideration what your favorite platform to play games on is, because you'll likely have more good game ideas for that platform, you'll be more motivated to make a game on it, and you're likely to understand it better. Aside from that PC is good because there are no extra things to deal with, no extra mandatory SDK's or tools to use and less hassle. Also PC's are powerful so you can get away with inefficient coding as a beginner and you can do more cool things(cool graphic effects, hi-poly graphics, cpu-eating AI, etc). And don't underrate how awesome it is to be able to just hit play and almost instantly be able to test out your game without having to deploy it to a cellphone or anything.

Those are the only 2 platforms I can speak about with any kind of experience, I do have a great suggestion for you though, especially based on your first post and how you said you were considering Android or PC/html. Right now I am using LibGDX to make an android game and I highly recommend it, It is not only an android game library but can also run on PC, Html5, iOS(with some effort, but there working on it and very soon iOS won't require much extra effort at all), and some other things too I think(Mac/Linux?). It's great to use because it makes things a lot easier but also allows you to write straight OpenGL code and is open source as well, so for a game engine it's very non-restrictive(which is the common complaint that people make against using game engines). Another great thing is that since it's cross platform(as in you only need to write the code once and it'll run on Pc/Android/HTML) if you are making an android game you don't need to wait for your app to deploy to your android device or emulator every time you want to test a little change you've made to the code(which at some points in development will be veeerrryyyy often), you can just run the desktop version to make sure it's doing what you want it too and then every once in a while when you just want to get a feel for how it works on the mobile device you can spend the time to deploy it to your phone. I remember hearing people tell me about that when I first started and not thinking it was a big deal, but it honestly saves a ton of time. I'm sure I'll miss it if I ever move on to a different engine.

Okay that was long, I'm done now hope this was helpful

4. Unlike Java, it's really easy to do unmanaged-to-managed interop, so it's a lot easier to use that native library you see your eye on.

Sorry to hijack the thread a bit but I wanted to ask this to a C# dev.

In Java making the JNI work is a bit of a mess, though there are utilities/libs made to make it easier (like Java Native Access ).

I've heard that its much easier on C# but someone made the point that its easier as long as you're on .NET world, that working with native libraries in Mono isn't as easy. Adding to that, you'd need to write Mono specific code, and .NET specific code.

Whats your take on that?

JNI is an absolute beast to work with and was one of the reasons why I jumped ship from Java many years ago (before JNA, which I believe is modeled after C#'s P/Invoke). In C# you have a few ways of calling into unmanaged code using P/Invoke, either through static DLLImports or loading the unmanaged DLL (e.g. LoadLibrary) and marshalling function pointers to managed delegates. These require the unmanaged library to have exported functions. Otherwise you would use C++/CLI (or do something extraordinarily fancy like SharpDX, which unlike SlimDX is not written in C++/CLI, but straight C# and with much of the interop generated at the IL level, or something like that^TM).

C++/CLI interop is a no go for Mono because they don't support it at all. So that's probably where you'd be writing specific code for different platforms. For example, say you want to use a library that you need to link to. You may have to write a C-API around it, then P/Invoke into that wrapper from your C# app. Honestly, I don't think this is a common use case.

For static DLLImports there's the issue of handling how library paths are found and library naming, which they have a mapping solution for. And obviously, if you're P/Invoking into kernel32 functions, then that isn't going to fly for a non-Windows platform (honestly, that's a non-issue in my book, if you design your application for platform flexibility).

Compared to JNI, P/Invoke is "easy" using static DLLImports, you declare the native function like so:

[DllImport ("MyLibrary")]
private static extern void Frobnicate ();

And then call it like you would any other. Easy is of course in quotations, because getting the signature right can be tricky for some functions. And ensuring data is marshalled correctly across the managed-unmanaged boundary is sometimes not trivial (but the runtime does offer a lot of support to get the job done).

A real life example would be my AssimpNet library. The native Assimp library is cross-platform already and exposes a C-API. The C# wrapper uses that second option I mentioned rather than straight up P/Invoke exemplified above - the native library is loaded dynamically at runtime and unmanaged function pointers get marshalled to managed delegates that you call to communicate with the native library. The loading scheme has different implementations for Win32 and Linux, which automatically are chosen depending on the runtime environment. The platform implementations, for example, P/Invokes into kernel32 or libdl functions to load the library/free it/do error reporting. So it's for whatever platform-dependent functions that need to get called outside of the Assimp library.

Of course, the sticking point in this is it doesn't work on iOS apparently (as reported by a Unity3D user), because you can't dynamically load DLLs or something, so they're still using an older version of the library which used static DLL Imports for the P/invoke. I'm digressing, but the point is interop is hard and tricky, but C# offers a lot of nice solutions where you don't go bat-crazy and want to pull your hair out just to do some simple interop.

thanks everyone.

following moe091's suggestion, I'll spend more time on lazarus and less searching around, if anything goes wrong I could anyway turn back.