Hello everyone,
I am wanting to know if large games like skyrim and fallout 3 can be written in C (not c++)
Hello everyone,
I am wanting to know if large games like skyrim and fallout 3 can be written in C (not c++)
C has been used to write the code for a great many games. Not so much recently, but in the days before decent C++ compilers existed, it was the go-to language.
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
They could, but C is seriously lacking when a project reaches a certain size. Something like the games you mentioned would definitely not be written in C. C++ offers a lot more for organizing a game design: classes, namespaces, etc.Originally Posted by Mechennyy
That really depends on what you mean by a "certain size" but, in general terms, I disagree.
Yes, some programming languages are better suited - or overtly designed - for large projects. However, as a project gets bigger, the choice of language eventually matters less. Organisational concerns (i.e. tracking requirements, architecture, bug tracking, modularity, extent of reuse, ability to find skilled software engineers, etc) tend to become bigger concerns. All programming languages are designed around some concept or concepts of how projects (or code) will be organised. One difference between a large project and a small one is often that organisation concerns drive choice of programming language, not the reverse.
Given a choice, I'd rather work on a well organised project written predominantly in C than a poorly organised one written in some other language. Because a well organised project will choose a language suitable for the job, and do things so it uses its chosen language(s) more effectively.
I have wondered this myself. My thought's are this: Yes it's totally possible, but it's a little like hammering a nail with a shoe. The lack of premade containers, and encapsulation (I know C has some, but not as much as C++), would just be an extra hassle where there doesn't need to be one. You can mostly overcome these problems (and learn a good bit doing it too), but it would just be too aggravating to me if I was trying to produce an outcome. Also, unless you've done a good job at writing very generalized code, it will be hard to take the systems you've built and adapt them to another project.
That's just my thoughts on writing a large game engine in C. Unless you write your own, you also have to keep in mind the graphics libraries (ect.) you will need, and how the language you choose will affect these. I've only used a few graphics libraries written in C, they were quite good, but if I was writing a game I would want to make sure the library I chose had everything I could possible need during development (I guess where I'm going is just to repeat what Grumpy said, choose the language based on the needs of the project).
Edit: I just wanted to say that I wasn't trying to bash C with the first paragraph. It seemed like the poster might have been asking which language would be the best to learn, with the hope of writing a large game eventually. So I was just giving an evaluation of some of the problems that could come up when trying to do it in a procedural style. Aside from differences in the standard libraries included with C and C++, I don't actually think one language is inherently worse off than the other. They are just suited to different types of programming.
Last edited by Alpo; 11-12-2014 at 10:40 PM.
WndProc = (2[b] || !(2[b])) ? SufferNobly : TakeArms;
Actually, most large games use one or more embedded "scripting" languages to control NPC's, events, game logic in general, and so on. Many are proprietary, but Lua is one anyone can use (it's MIT-licensed).
I suspect you could say that most large games are mostly written in embedded scripting languages, whether you count in man-hours or impact on the final product.
@grumpy
Well, I can't disagree with anything you said. Its still true that C is an old language and wasn't really designed to handle the organizational requirements of modern projects.
Of course, and a "large" project can benefit from using a language like Python or ML that has a module system, for example.
As you know, its a matter of trade-offs. There isn't really a right or wrong answer here.
@Alpo
I know that C++ is considered best for this, but after using both C and C++ I guess you could say I have a somewhat "irrational hate" for c++.
@MacNilly
After doing some research, I've found that Star Trek Online, Neverwinter, and the rest of Cryptic's games(which are mmorpgs) are written in C.Something like the games you mentioned would definitely not be written in C
Along the lines with grumpys point, available/internally created libraries and/or APIs for the various needs required by the project (rendering engine, physics engine, general game engine, config parsing library, graphics libraries, data structure libraries (if not provided by core language) ) tend to be far more important and often drive which language you will be writing core code in.
For that reason, C is actually not a bad choice at all, because of how long it's been around and how popular it is there are already a myriad of libraries available to do anything you can do with C++
quite easily. SDL, opengl, libevent, BSD/POSIX queue.h, libssl(openssl) to name a few. Go look on github and see how many projects there are that still provide C apis and/or are written in C
Also libraries like Glib offer more data types like e.g. Balanced Binary Trees, Linked Lists, Hash Tables.
I'm not an "expert" at all, just some sort of a "hobbyst". That said, in my humble opinion the best language is the one one can manage with as little "thinking" as possible. The optimal language is the one that you can use to express with fluency without any need to think to how you can "say" so that you can direct your full attention to what you want to "say". In a sense, "programming" and "saying" are very similar to each other. Is this a wise approach?
P.S. English is not the best language for me!
Sure, but over time C has been used in enough projects, that there are plenty of techniques available for using it in modern projects.
Then don't try to use my rather general comments - which amount to "the choice of language matters less for large projects" - to support some sort of advocacy for languages like Python or ML over C.
I am not interested in advocating Python or ML over C, nor the reverse. It will be possible to find large or small projects that use any of them, for both good and bad reasons.
In that case, you are limiting yourself to small programs. The thought required to develop a system increases monotonically with size of the system, regardless of choice of programming language.
Last edited by grumpy; 11-14-2014 at 07:08 PM.
Maybe I didn't succeed in expressing my thought properly. My point is that one can't develop a "serious" project while he has to look at the manual of his language of choice every two lines of code he writes. Possibly making a lot of mistakes related to the language itself rather than to project design. That would make it impossible to concentrate on the program, and make the programmer stuck with a lot of problems every few steps. With a solid knowledge of the language, the amount of those paralizing sort of mistakes would dramatically drop.
Does this make the sense of what I wrote in my previous comment clearer and more valuable?
Makes your comment/intent more clear, but I disagree. In fact, you've sort of confirmed my point - your rationale apply to small systems, not large ones. To be fair, however, my concept of a large system is larger than that of most people here - that's not your fault.
In large systems, it is "impossible to concentrate on the program", regardless of choice of programming language. Because "the program" will be a large complex system, that cannot be fully understood by a mere human. People might understand aspects of it, but will not be able to understand all of it. Some will understand the top level structure and architecture. Some will understand the exquisite implementation details in some set of function. Some will have some understanding of the architecture, and understand some of the exquisite details within some functions. No matter how much a guru someone on the team is - and most teams developing a large system have several such gurus - a large system eventually grows to a point where nobody can fully understand it.
That is why large scale system development is very different to small scale system development. The thing is, the thinking that works on small systems does not scale to large systems - including preferences in terms of programming language.
I got it, Grumpy. You were talking about team-work in some sort of a modular way of developing huge projects. In that context you are right. I was talking about developing a relatively big project of such a size that a single developer could manage the whole thing.
Just to say, my curiosity led me to take subsequent looks at the team developing Logic* since it's very birth in the late Eighties (a handful of smart programmers) and then up and up to the Apple years, when that team literally exploded and the program grew into a monstruous beast that (I think) couldn't be managed other than by an equally monstruous team of professionals fed with an equally monstruous budget. A team where the left hand hardly knows what the right hand is working on. Moreover, the architecture of such a program allows for literally endless lateral projects in the form of plug-ins on which the main team has no control nor knowledge at all. On their side, the developer of the plug-ins hardly have a clue of what's happening inside the host program, of course. In such an environment, I think, some modules could even have been developed using a certain language, while some other modules could have been developed using a totally different language!
In other words, you were looking at the subject of our discussion under a modern, hypertrophic perspective, I was looking at the very same subject under a completely different, "ancient", hobbyistic perspective. From your point of view you were obviously right, from my point of viey I was as well. Perspective matters.
*See The History of Logic
Last edited by aldo_baldo; 11-15-2014 at 10:22 AM.
