• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Galdred

C developper, but newbie gamedev, where should I begin?

14 posts in this topic

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
1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
[quote name='Dan Mayor' timestamp='1349938388' post='4988986']
[...] I highly recommend using a more developer friendly and stable language such as C#. [...]
[/quote]

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
: Removed majority of quote contents, which weren't really needed to follow the conversation.
1

Share this post


Link to post
Share on other sites
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 [i]game development[/i] 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 [i]software engineer[/i] 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... [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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! [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]


Clinton Edited by 3Ddreamer
0

Share this post


Link to post
Share on other sites
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 [url="http://chipmunk-physics.net/"]chipmunk-physics[/url], and it's API is in C. It makes writing 2d action games so easy.
1

Share this post


Link to post
Share on other sites
Thank you very much for your advice : I am learning SDL right now.
[quote name='kd7tck' timestamp='1349943154' post='4989016']

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.
[/quote]

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
0

Share this post


Link to post
Share on other sites
[quote name='3Ddreamer' timestamp='1349973897' post='4989155']
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.
[/quote]
[quote name='3Ddreamer' timestamp='1349973897' post='4989155']
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.)
[/quote]
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
0

Share this post


Link to post
Share on other sites
[quote name='Saruman' timestamp='1350631636' post='4991706']
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.
[/quote]
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
1

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
Hi Saruman,

[img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

[quote name='Saruman' timestamp='1350637112' post='4991727']
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..
[/quote]

Uh... That is not correct about my writing. [img]http://public.gamedev.net//public/style_emoticons/default/huh.png[/img]

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

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 [u]not[/u] focus on the level technical comparison of the coding languages themselves, though L. Spiro did nicely with that. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] 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 [u]language environment[/u] in the gaming industry then performance results can be far different: The [i]human[/i] 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! [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img])

As for C#, I also am assuming the reader will understand the human factor with the [i]learner friendly language[/i] and the advantages of the superbly supported .NET Environment toward game performance [u]for the programmer who has these needs[/u]. 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 [u]environment[/u] 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! [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]

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.

[img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]



Clinton
2

Share this post


Link to post
Share on other sites
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
1

Share this post


Link to post
Share on other sites
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! [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]

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


Clinton Edited by 3Ddreamer
1

Share this post


Link to post
Share on other sites
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 ?
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0