14 replies to this topic

[Galdred]

I used to work as a low level software engineer, and I have mostly written drivers in C language, and before that, I have done some development in Python, Ruby, and C++ (but I'd much rather use C now), but I want to move to indie game development now.
Last time I was writing a real game (ie not a pong or tetris tutorial clone) was with GFA basic on my Atari, so I don't really know much about topics specifics to game development (I'm a complete newbie when it comes to graphic, sound and interface programming).

I plan to make 2D turn based RPGs (like the old goldbox series for instance), but I don't know which libraries or engine to use, and which tutorials/book to read to get started.

What would you recommend me?

Edited by Galdred, 10 October 2012 - 12:46 AM.

[Cornstalks]

Since you're comfortable with C, I'd suggest SDL. It's a good media library that's been used in a ton of games and can be used to handle the game-ish aspects (graphics, input, networking, etc.).

I won't give you the "just learn to program first" spill because you've got that step down, so just get used to SDL, learn how to make a window, get input, etc. Keep it simple with SDL and make lots of mini-games to practice game programming and design. There's going to be a lot of throw-away code between now and when you have created a 2D turn based RPG that you're satisfied with, so just have fun getting lots of game programming practice in.

Maybe start trying to make tic-tac-toe.

[Dan Mayor]

I'll probably get bashed for saying this but I highly recommend using a more developer friendly and stable language such as C#. Simply put Microsoft has spent millions of hours perfecting code managers, garbage collectors and their IDE that make your life so much easier and frankly you nor I will ever do it any better than they have it right now. By the time you even write your basic dynamic memory management and input collector's you will have already spent over 100 hours on stuff that doesn't even perform half as well as the C# / .NET frameworks do.

It's wiser when developing games to choose a language, engine and development kit that gives you what you need. Which in todays market means C++ or C# period. C is antiquated and not many people use it anymore because it's just an old insufficient language. I understand people will argue with me on this and state how C has way less overhead and it's closer to machine code and it's easier on the processor after compilation and blah blah blah. But these are all counter productive arguments at best, let me offer a few reasons why I think you should move away from C compared to these anticipated arguments.

C has less overhead:
True, but you also have to make the memory manager, library wrappers and many other low level systems. Are you a better programmer than all of the coders at Microsoft? Do you have a doctorate in computer sciences and countless certifications in programming techniques and technologies? No? Then how will you make a better performing memory management system?

C is closer to machine code:
So? The fact still remains that C (and C++) are generalized assembly compile languages. That is to say that when you compile your C or C++ program you target a specific chipset and architecture. This is normally set to a default IBM chipset that normally works decent on any machine. C# is actually an intermediary compilation language. This means that when you compile it you create a binary file that explains to your end users computer how to finish compiling the program. The first time they run your program their computer finishes the compilation process optimizing it to their specific hardware. For you to make a complex C program (like say a game) that runs as fast as it's C# clone you will need to compile your program for your customers specific hardware... In short, your closer to machine code language here is actually slowing itself down where as C# is speeding itself up.

C is faster and easier to process:
This only holds true at the very very very low levels and does not justify the slow downs that you yourself will cause trying to mimic the work that C# already provides. This comes back really to both the above points. C is generic, C# is for YOUR computer. C is bland, empty, theres hardly anything to it. C# Provides almost everything you could ever need coded and optimized by people with way more experience. When you get into the more complex features they will rely on your middle ware coding that handles memory management like functions. This is where you will lose performance in contrast to C#.

Just some final notes here, there are more tutorials and learning sources for other languages such as C++, C# and Java than there are for C. If you are not a master of the language who can answer all of your own questions you should heavily consider support material availability. Make sure that if you get stuck you will have places to turn for more information and help. Keep in mind MSDN has millions of examples, documents and tutorials on C++ and C#, gaming communities and engine websites also provide C++ and C# or Java tutorials.

[kd7tck]

[...] I highly recommend using a more developer friendly and stable language such as C#. [...]

Why re-invent the wheel when he could just use the numerous engines and libraries already written in C. By the way C# isn't easier for low level tasks, better off just using C/C++ and wrapping in a high level scripting language.

Edited by jbadams, 18 October 2012 - 11:25 PM.
: Removed majority of quote contents, which weren't really needed to follow the conversation.

[Black-Rook]

Galdred, use whatever you feel like using regardless of opinions. I've used C, C++, C#, VB, ect... But I never liked C# for games and I just use C++ regardless of opinion and I'm doing just fine!

The Allegro library is something I've been using for a long time. However, SDL is also a good option. Best thing to do is just download them, and get started!

[3Ddreamer]

Well, like I often write to new game developers, any well supported language is just fine for making games. Fantastic games have been made in all of the major ones. Now we are talking game development here, which is a whole coding and software environment added to the making of a game. Another consideration is that you have experience as a software engineer and I assume pretty good with C.

I have done in the last two months a couple hundred hours of research into game development. Let's see if any experts or intermediate experienced people agree with me. It's just a friendly challenge...

Galdred, if you are going to stay with making 2D games, then C would be excellent. If you are going to eventually go to 3D, then I would say migrate to C++ or C#. Though C++ is the majority of 3D AAA games being made, many beginner and intermediate 3D games are being made in other languages and a few AAA games in Java, C, or C#, or other. Okay, that stuff is given, too, now.

Looking at the languages themselves, the more complex the game, then in general the more need for object oriented programming for the core and scripting language for game functionality. Right now and in the foreseeable future, both C++ and C# have huge repositories of libraries, many software applications, and large community support. The C++ is much larger in major ways than C#, but C# is evolving to likely close the gap to a great extent in the coming years. We know that C++ will dominate AAA game development for at least several more years and rightfully so for a bunch of reasons, but many less complex games being sold are written in other languages.

Both object oriented and dynamic writing are improved and will continue to be improved in C#. I believe that C# will eventually fade the need for a scripting language for a C# game because of being more programmer friendly and it is evolving.

As for C, it will be a viable language for quality games for many years to come, as I am sure we can agree. I feel that C would be a great language for 2D games. Having experience as a 2D and 3D artist in the industry for more than two years now, I know how art assets effect game performance of high quality ones made in Java and C++. I can assure you that your turn based 2D games can use the advantages of C while not being able to take full advantage of some performance characteristics of C++ an C#, yet not needing them for most 2D games. Once you get large libraries of code and many art assets in a couple years, then performance might get critical - or maybe not.

I am recommending that you stay with C and make full advantage of your experience in the language and software engineering. Stay with it until you complete your tour with 2D game making. After a year or two, if you then decide to start making 3D games or your 2D games have been filled in order to need the extra performance, then consider C++ or C#. (Who knows: Maybe Java or C will be in the league for the highest performaning games again in a few years.)

Get good at 2D game making before you do deep contemplation about a scripting language. That will take you probably several months to a year or more because you will need to learn the art aspects with the programming.

1) Start game making immediately, such as Tic-Tac-Toe, Pong, Tetris, PacMan, Space Invaders, and/or a clone of a contemporary popular one. You need to understand game programming structure more than anything else at this point.

2) Get a general IDE and/ or a language specific game making SDK. Research and decide this while you make your first few games.

3) Until you need to make art or mod existing ones for your games, get involved in artist forums supporting your plans, incuding in this website. Here we have plenty of information in the beginners forum and the artist forums to help you decide on art software and assets, even in the last few days being posted.

4) Eventually you will likely find a community which focuses on the genre of games that you do in your language.


Working hard is something you already do. You get results. My last advice is to remember to enjoy it all!


Clinton

Edited by 3Ddreamer, 11 October 2012 - 10:57 AM.

[BeerNutts]

Even though I now write my games in C++, I've made plenty of fun games using C, and just a few years ago too. My current Library of choice for graphics, input, audio and windowing is SFML, but that's a C++ API, so you can use SDL for now.

Once you get comfortable, you may also want to look into a 2d physics library. I use chipmunk-physics, and it's API is in C. It makes writing 2d action games so easy.

[Galdred]

Thank you very much for your advice : I am learning SDL right now.

Why re-invent the wheel when he could just use the numerous engines and libraries already written in C. By the way C# isn't easier for low level tasks, better off just using C/C++ and wrapping in a high level scripting language.

I was thinking about using Python or LUA for the game logic indeed (Python because I am quite used to it, and LUA because it seems to interface really effortlessly with C).

Which engine would you recommend me? Most 2D game engines seem to be targeted at non programmers, or towards making flash games, except for a few like SIO2 (but it is mostly targeted at making mobile games), cocos2D and Torque2D.

Edited by Galdred, 18 October 2012 - 11:43 PM.

[joew]

I can assure you that your turn based 2D games can use the advantages of C while not being able to take full advantage of some performance characteristics of C++ an C#, yet not needing them for most 2D games. Once you get large libraries of code and many art assets in a couple years, then performance might get critical - or maybe not.

After a year or two, if you then decide to start making 3D games or your 2D games have been filled in order to need the extra performance, then consider C++ or C#. (Who knows: Maybe Java or C will be in the league for the highest performaning games again in a few years.)

A small correction is needed here as you seem to be assuming that C++ and C# have a better performance than C which is not the case at all (especially in the case of C#). The reason the majority of the industry shifted from C to C++ was do to it being easier to maintain larger codebases with multiple people working on them, and requiring less lines of code... so it was to save time and energy and had nothing at all to do with performance. As the C language is basically an "easier to read" version of assembly you aren't going to get any faster.

Edited by Saruman, 19 October 2012 - 01:27 AM.

[L. Spiro]

A small correction is needed here as you seem to be assuming that C++ and C# have a better performance than C which is not the case at all
…
As the C language is basically an "easier to read" version of assembly you aren't going to get any faster.

You are in fact the one who needs correction.
Most C++ compilers actually convert the code to C before further compilation.
What C++ offers is nothing but “features”, and if you were to implement the same features in C manually (as apposed to having the language do it for you) you would find the performance to be exactly the same.
In other words, just because the compiler detects a .CPP extension does not mean the same code will compile to a slower run-time than if it was instead inside a .C file.
The exact same code, in either language, results in the exact same assembly output.
The difference is that C++ allows you to take advantage of features that could also be done in C with exactly the the same run-time cost, but with a much easier implementation.
And it is yours to decide whether or not to take the performance hit from these features.

If you choose not to use virtual functions, for example, your code will be exactly the same speed whether in C or C++, but with C++ you get templates which can result in better performance than C, since the compiler can reduce templates to the bare-bones minimum set of code, with is then optimized by (again) a C compiler.


L. Spiro

[joew]

Actually that was my point... that you are going to be able to write code that performs the same in either C or C++ with the equivalent skill level.... not that C is any faster, etc. My point was that the author of that post (the sections I quoted) claimed that code written in C is not as performant as code in C++ or C# which is untrue.. I guess I just worded it badly or missed the point.

Edited by Saruman, 19 October 2012 - 03:02 AM.

[3Ddreamer]

Hi Saruman,

My point was that the author of that post (the sections I quoted) claimed that code written in C is not as performant as code in C++ or C# which is untrue..

Uh... That is not correct about my writing.

Pure language coding performance data was not revealed by me, but the language of choice does effect game source code performance because of other issues.

Performance of coding is subject to other influences apart from its raw, native language performance characteristics. The performance of game source coding is also effected by the programmer, community experience, and software environment, as well as the language. As a kind of parable, a heavy, large row boat will outperform a smaller one, but only in certain circumstances like a Roman galley compared to a canoe. If you can't fill the galley with rowers, crew, soldiers, weapons, and provisions, then forget it! Having a huge or complex game source code will require you to have a bigger system just like the galley, but the exception is if you have lots and lots of time in your canoe to get to your destination. The game source coding is the vehicle, the language(s) is the material, the stuff with it contributes, and the game developer oversees it all. So many things are acting toward performance!


I did not focus on the level technical comparison of the coding languages themselves, though L. Spiro did nicely with that. One of my points is that the language does not come alone. Other factors determine the advantages available toward coding performance of any language. In a tech lab, your point is most relevant, however in the real world of language environment in the gaming industry then performance results can be far different: The human factor effects the features being used in relation to a language, impacting performance. Let's not confuse pure language performance with the game source code performance which relates to many external things.


I apologize for expecting too much from all readers of my post. My assumption was that the human factor would be realized immediately.

I stand by my recommendation for Galdred to continue using C until the need becomes clear to add languages to game creation, because of experience and desire to do so. The software engineer won't fully need the advantages of another language environment until expanding the features, assets, and at least one team working under such a prospective leader, if it is the plan to make a mega game. Besides this, who knows where the trends will be in a few years? We have seen new emerging movements in the past.

Game industry experience and tech support of C++ has a huge infuence on the game performance, let alone the game source code low level performance. Software environment of choice by the programmer is another factor which potentially can impact performance of the game. Personal game preferences are another area. For C++, the bigger view is that the programmer will likely get better performance in a complex, asset laden game made by teams with this game industry leading environment. Keep in mind that a 3D game is more likely to need the advantages of the C++ environment than a 2D game. In this sense, C++ development allows extreme teamwork and game source code adaptivity which has many as such advantages toward game performance, but typically in these very complex situations. (Think galley! )

As for C#, I also am assuming the reader will understand the human factor with the learner friendly language and the advantages of the superbly supported .NET Environment toward game performance for the programmer who has these needs. Again, the human factor being highlighted as a major factor toward end result game source code performance, not confused with pure language performance.

The C language will do nicely for Galdred until the software engineer sees the need to switch or add languages. My role is to highlight the human elements with the language environment toward performance. This points light at the coming challenges of deciding how much to do independent and how much will require teamwork, in turn effecting final performance of the game source code.


Saruman, please understand me as saying that environment can potentially influence performance more than the language itself. The C++ or C# (Python or any other language in the future) development advantages (think human factor) in the language environment can outweigh the raw language performance. Low level work in C is just fine for performance, but other needs will come for consideration which impact performance as the developer's organization expands!

Being that you are a professional, I am sure that you agree with much here, but I am clarifying my past assumptions based that the reader has or will do relevant research in these areas. ( I will, too! )


Language + language environment + game industry tech support + game industry experience + technology + personality + other variables = end result game performance:

Various influences are attached to any coding, some special to each language, which may give a language environment its performance advantage in certain circumstances.

Thanks for the opportunity to clear the air. Hopefully, I don't come as all high and mighty and all that stuff because I just want to make this good.





Clinton

[joew]

Actually I believe we both agree on the same point! Although I just took in the human factor of him being a professional C programmer to figure that he would achieve both optimal performance and development time with the language he is used to.

Core language wise of course you could compare something like the templated introsort of std::sort and the C library qsort and the C++ will kill it performance-wise as due to templating it will be typed as well as not need an indirection and there are many places this could be pointed out... although if someone really had a performance concern in C they wouldn't be using qsort (so as you mentioned the human factor). And as Spiro mentioned people may point out virtuals as performance issues due to the cache miss but if a virtual is truly warranted it likely would have been coded the same way in C anyways (by building a vtable of function pointers).

My bad for reading your post incorrectly, I had assumed you meant that you would see a raw performance benefit just by using C++ or C# over straight C but that was not the case.

Edited by Saruman, 19 October 2012 - 02:06 PM.

[3Ddreamer]

An upvote for L.Spiro and Saruman from me on the last posts.


Saruman, it is very good to work with so many reasonable people around these forums!

Hold me to better communication and I will deliver - thank you very much!


Clinton

Edited by 3Ddreamer, 19 October 2012 - 02:28 PM.

[Galdred]

I am going with Cython for the game logic, and C with SDL for the display, and AI. But SDL does not seem that good if I want my game to accommodate various screen resolutions (ie scale graphics on the fly). It looks like I should draw on an openGL texture to have the graphics depend on the ratio only, and scale with screen size. Should I use the beta version of SDL 2.0, or should I use SDL and openGL at the same time ?