A question...
#1
Posted 17 June 2012 - 10:07 PM
I'm kinda confused because the both of the choices are amazing but I must pick only one of them, that's why I want to hear your(experienced programmer's) opinion.
#2
Posted 18 June 2012 - 12:17 AM
#3
Posted 18 June 2012 - 12:43 AM
#4
Posted 18 June 2012 - 01:31 AM
teck, if I were you I would download both and try them a little bit. Go as far into development as you're comfortable with and then weigh the pros and cons of what you like and don't like. It will only take at most a week of your time, but that invested time will assure you made the right choice you will be happy with.
#5
Posted 18 June 2012 - 01:49 AM
Believe me, it takes a long time to learn everything necessary. An engine like DarkGDK will save a huge amount of time, but you won't really lose any learning Python and writing some small 2d games before you move on to a 3d engine if you choose to do so. 3d generally means you need to be able to model unless you can find a partner you can work with for no money. You can do some simple 2d art games no matter what kind of artist you are. People are pretty forgiving with it if the game is original and fun, and the restraints will make you a better programmer and game designer.
My personal opinion is that c++ is no longer necessary for an indy programmer and is more of a hindrance. C#, or whatever is handy is just a lot easier to deal with and get the job done in the shortest possible time. If you are doing it all yourself, that's pretty much a necessity. Also, if you learn Python first, you will probably be more likely to use those other languages whether As3, Java, C# or whatever because they only vary in small ways. In my experience, c++ programmers need to do it all themselves and get stuck in the details, which is fine in some circumstances, but when you have to write and do the art for an entire game, that can be a deal breaker. Lastly, DarkGDK will mask a lot of things that, had you done some of it in pygame, you will see what they are doing and understand the structure better.
#6
Posted 18 June 2012 - 08:10 AM
#7
Posted 18 June 2012 - 12:52 PM
#8
Posted 18 June 2012 - 06:13 PM
Always favor the platform/libraries that have the biggest/most vibrant community when starting out. You will want help.
#9
Posted 19 June 2012 - 10:26 AM
Quote
@TheNut
Quote
#10
Posted 19 June 2012 - 09:17 PM
#11
Posted 20 June 2012 - 02:37 PM
#12
Posted 20 June 2012 - 04:30 PM
#13
Posted 20 June 2012 - 06:46 PM
Gtk and standard C (F.e. GNU99 standard) is well... quite a hell. And I mean it, really.
On the other hand PyGtk isn't that bad, it's used and works quite good. I'm not sure, but it's probably even more used than Gtk+ in C++.
It can't though compare with Gtk2HS - Haskell ftw!
Every language has it's advantages and disadvatnages (and is better for something) - there is no "uber" solution (well... except for Haskell!
For example - we actually doesn't write our game + engine in single language (not that it would be impossible, but it's easier to do this in one language and to do that in another one).
For game engine core we're using C++ (GNU++11 (formerly GNU++0x) standard). For actual realtime ray-tracing core in engine we use native C - C99 std (CPU ray tracing) with SSE intrinsics heavy code and C - OpenCL/C99 std (GPU ray tracing). And this is just a core.
We now have game engine editors - e.g. the important stuff, where C# with Gtk (known as Gtk#) is a lot better tool than using C++ (and don't ever use Gtk and C - our first editor was actually writen in Gtk + C - and it WAS nightmare, compared to Gtk#).
Our game scripts can be done in LUA (C/C++ like scripting language) and we're also going to try Haskell on this (and that will own! - it's just for test & fun). The actual game is in our case written in C++ (but! it can actually be also written in C# - which we considered several times, but still we like C++ a bit more).
And at last - game & game engine configuration files - are written in bash-like syntax.
As you can see, we do lots of stuff in C-like languages, but not in single one... why to limit just for a single language, where there is so much of them?
NOTE: You don't want to see makefiles
EDIT: So actually we use lower-level languages, where speed is critical ... and higher-level languages where structure and understanding of code is critical (because 'one does not simply read & understand intrinsics code block on the first try').
If you don't know how to speed up application, go "roarrrrrr!", hit the compiler with the club and use -O3 :D
#14
Posted 21 June 2012 - 01:21 AM
#15
Posted 22 June 2012 - 02:55 PM
teckpow, on 20 June 2012 - 02:37 PM, said:
Do you mean s**t as in "good", or s**t as in "bad"? You can never tell these days...
A language like Python is abstracted at a higher level than C or C++. It imposes limits and other disadvatages, but you can do in one-line what it would take umpteen C lines to do. Where performance in code doesn't matter, but performance in coding/maintaining matters, this is a godsend...
#16
Posted 22 June 2012 - 08:47 PM
Some of the "standard" items supplied with C# are just beautiful.
Like the ability to invoke the C# compiler from within your code, lovely for genetics.
The tools you get to work with in C# are many orders of magnitude better than the tools you get for Python.
Obviously if you want real performance, neither are the best, but for a new coder just learning.... either do it right (C/C++, lot's of time, need talent to have a hope) or use something with a tool set that will ease you in.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users


This topic is locked









