Jump to content

  • Log In with Google      Sign In   
  • Create Account

C in game development


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • This topic is locked This topic is locked
36 replies to this topic

#21 kunos   Crossbones+   -  Reputation: 2207

Like
2Likes
Like

Posted 17 August 2013 - 06:11 AM

 

I do not know how would it be in a very large game project

I was not talkin on that, this would quite different topic 

 

 

 

wtf? In your original post you talk about "big games" and now you say you are not talking about that? Make up your mind.

 

Anyway, my advice to you would be to study software design and different modern languages... C++,C#, F#, Haskell, Go, Rust.. expand your vision, try to understand what they bring on the table and what they are trying to solve. Approaching problem solving with big globals will just bring you bugs and broken software.. also you won't be able to communicate with other devs because you'll be missing the vocabulary..  it's 2013, software design has evolved in the last 50 years and so should you if you want to be relevant in this industry... it's fine to like and prefer C, but it should be the result of learning and experimenting with different techs.. not the result of lazyness and desire to treat eveything as a big global spaghetti ball.


Stefano Casillo
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

Sponsor:

#22 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 17 August 2013 - 06:30 AM

 

 

I do not know how would it be in a very large game project

I was not talkin on that, this would quite different topic 

 

 

 

wtf? In your original post you talk about "big games" and now you say you are not talking about that? Make up your mind.

 

Anyway, my advice to you would be to study software design and different modern languages... C++,C#, F#, Haskell, Go, Rust.. expand your vision, try to understand what they bring on the table and what they are trying to solve. Approaching problem solving with big globals will just bring you bugs and broken software.. also you won't be able to communicate with other devs because you'll be missing the vocabulary..  it's 2013, software design has evolved in the last 50 years and so should you if you want to be relevant in this industry... it's fine to like and prefer C, but it should be the result of learning and experimenting with different techs.. not the result of lazyness and desire to treat eveything as a big global spaghetti ball.

 

 

Main topic was question Is there 'old' c-way programming present in

todays big title productions and at how much big extent -

not arguing "how to write" big programs in c (the second is much heavier topic), (also noting about spaghetti balls and stuff)



#23 Malabyte   Members   -  Reputation: 589

Like
3Likes
Like

Posted 17 August 2013 - 09:08 AM

The infamous C vs. C++ debate.

 

Understand, however, that the gaming industry is gradually evolving more into management and design, and away from core, bottoms up programming. The industry has already gone far past the threshold of object-orientation. C++ and Java are examples of OOP, and nowadays we got a host of simple and advanced game engines and other resources that game designers can quickly pick up on. In the future, there's going to be an even bigger pool of hobby designers who don't even know how to write in code, due to how accessible the higher-up tools have and will become. Just think of GameSalad and the iPhone, and that's just the start.

 

I think C is going to survive all this, but it's going to lie deep beneath the earth while designers are soaring between the skies. Two vastly different worlds. Well, who knows, but one can speculate at least.


- Awl you're base are belong me! -

- I don't know, I'm just a noob -


#24 Toothpix   Crossbones+   -  Reputation: 810

Like
-1Likes
Like

Posted 17 August 2013 - 12:51 PM

I have no qualms with OOP, in fact it is a very natural way of thinking: people naturally quantize data and methods in order to achieve a more organized train of thought. Computer memory is lossless and void of distraction, so computers can do one thing for one year and (assuming the program doesn't use consistently more memory after each execution cycle) and not lose any memory and not be "distracted." Computers are procedural and can only execute one thing at a time (yes you have multi-core systems and OpenCL/CUDA, but for the most part this is true).

 

I like C. I really like C. You can tell by my signature what I feel about the future of computing and what language I like. I think OOP is a good way to design a program, but not the optimal way to implement it. OOP in C is not the solution. Folks that pretty much re-write the C++ runtime in C for their program and then bash C++ are better off to just quit programming altogether. I find C very suitable for games because games are based off of the game loop. While some people think that since games have discreet and definitive systems (audio, graphics, etc.) that they are all just waiting for C++ implementation, but that is false. C++ is, IMHO, almost trying to get the computer to think like a human. C, IMHO, is almost like trying to think like a computer. I will still be writing my game and tool suite in C.


C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.


#25 phantom   Moderators   -  Reputation: 7321

Like
5Likes
Like

Posted 17 August 2013 - 04:43 PM

C++ is, IMHO, almost trying to get the computer to think like a human. C, IMHO, is almost like trying to think like a computer. I will still be writing my game and tool suite in C.


Dumbest thing I've read in some time.

Putting aside the typical sin of thinking "C++ equals OOP" which is flat out wrong (C++ is just as valid in procedural and functional as it is as object style), at the end of the day for given functionality the CPU will see approximately the same code.

You are not making the CPU think in any particular way at all, to even consider that is frankly stupid.

#26 Ravyne   GDNet+   -  Reputation: 7498

Like
1Likes
Like

Posted 17 August 2013 - 07:28 PM

Programming languages are for people, not computers. Even assemblers offer us meatbags much in the way of convenience over inputting op-codes by hand (or even the hypothetical worlds simplest assembler that only lets us write those opcodes with symbolic names). So it is kind of silly to say that using one language or another makes the computer think in a certain way. Demonstrably not true. Using one language or another makes you think in a certain way, but not the computer.

 

Program in C if you want. That's fine and dandy, but the only thing that C actually offers over C++ is that its a model your own human brain is more comfortable with, and perhaps that its marginally more portable to extremely limited or esoteric platforms, related mostly to the fact that its runtime is simpler and more compact than the C++ runtime -- take note, however, that only the first of those things is any benefit to you as the programmer.

 

There's a significant amount of software out there that's written in C, its not going to disappear. A lot of that software re-invents aspects of what's already provided in C++ or in other languages. But given that C is a nearly-perfect subset of C++ (There may be differences in the standardese or other small things, but truly impactful differences are essentially non existant), Microsofts slow adoption of C99 not withstanding, there's no really reason to limit yourself to 'C'. If strict C compatibility isn't something you need, you can merrily code along in C and then pull in bits of C++ as needed, rather than reinventing them yourself. Its probably wiser to just learn and use C++ proper, but at least it saves you reinventing the wheel.



#27 frob   Moderators   -  Reputation: 21475

Like
3Likes
Like

Posted 17 August 2013 - 07:53 PM

This has devolved into a language flame war.

There are no solid numbers that say "x% of all games are written in language y", and even if there were the numbers would be useless. It does not matter.

Major games are written in many languages. At work I routinely have files open in anywhere from four to ten languages at a time, all used in building a single AAA game. The languages used are irrelevant, all that people care about is that the game runs and is fun to play.

You can write games in whatever language you want. Write them in C, C++, C#, Java, Python, JavaScript, ActionScript, Basic, or any other language you want.

All of those languages have been used to write commercially-successful games. If you are looking for approval or someone's blessing before starting out, you have it. Write your game in ANY language that you want.
Check out my personal indie blog at bryanwagstaff.com.

#28 Hodgman   Moderators   -  Reputation: 30424

Like
3Likes
Like

Posted 17 August 2013 - 08:58 PM

I worked for a big company a few years ago, with 400 staff, multiple offices, and their own engine team, who made quite a few console games per year.
Their engine code was all plain C.
The tools were C# and other languages.
The games were a "C with classes" style of C++ (no templates, constructors, destructors, etc).

 

So yeah, it is used. I'd definitely say that C++ is more popular though (although the sanctioned sub-set of C++ that's used will vary greatly from studio to studio)


Edited by Hodgman, 18 August 2013 - 04:36 AM.


#29 Norman Barrows   Crossbones+   -  Reputation: 2158

Like
2Likes
Like

Posted 17 August 2013 - 09:19 PM


worse thing is that they are static sized tables and i do not know how achive flexibility in such static array approach,

 

soft code array size in data file. 

 

read in array size from data file at program start. then malloc entire array at once at program start, and free at program end. set array size big enough to get the job done.

 

the speed of static arrays, and the variable size of malloc'd arrays.


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#30 Norman Barrows   Crossbones+   -  Reputation: 2158

Like
2Likes
Like

Posted 17 August 2013 - 09:52 PM


c in game development (in relation to c++ usage) ? In big games?

 

i've been writing games in C since 1989 or so. I've done a number of large titles in C. my current project is in C (in a c++ compiler) and tips the scales at about 70,000 lines of code so far. a typical big game for me is about 100,000 lines of code.


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#31 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 18 August 2013 - 01:09 AM

 


worse thing is that they are static sized tables and i do not know how achive flexibility in such static array approach,

 

soft code array size in data file. 

 

read in array size from data file at program start. then malloc entire array at once at program start, and free at program end. set array size big enough to get the job done.

 

the speed of static arrays, and the variable size of malloc'd arrays.

 

 

But what with large c projects (such like windows/linux/gcc)

Are they internally static array based, what is their main containers for data? As I said if this is static arrays it is prone to overflows (mallocked to), static arrays with realloc? If this is something like linked list of structures it would be much slower... 



#32 fir   Members   -  Reputation: -460

Like
0Likes
Like

Posted 18 August 2013 - 01:14 AM

 


c in game development (in relation to c++ usage) ? In big games?

 

i've been writing games in C since 1989 or so. I've done a number of large titles in C. my current project is in C (in a c++ compiler) and tips the scales at about 70,000 lines of code so far. a typical big game for me is about 100,000 lines of code.

 

 

I would say 100k-lines are medium size not big. I belive any big title commercial game shipped to shops is much larger (how much?)

My own home framework with some unfinished prototypes

of 2d games has 100k-lines by now. Big game is probably about 1M-lines and more



#33 GeneralQuery   Crossbones+   -  Reputation: 1263

Like
0Likes
Like

Posted 18 August 2013 - 04:23 AM

This has devolved into a language flame war.

You say that as if it were a surprise :)

Granted, this was a zeitgeist topic about, what, 15 years ago but when have these threads ever ended well? Still, if anyone needs any more gasoline to throw onto the fire I'm here all day (or at least until the inevitable lock).

#34 weeska   Members   -  Reputation: 255

Like
0Likes
Like

Posted 18 August 2013 - 04:44 AM


if anyone needs any more gasoline to throw onto the fire I'm here all day

 

now i got your first comment on that^^



#35 Toothpix   Crossbones+   -  Reputation: 810

Like
-1Likes
Like

Posted 18 August 2013 - 08:01 AM


You are not making the CPU think in any particular way at all, to even consider that is frankly stupid.

I'm not talking about the physical CPU. I'm talking about the CPU from the vantage point of purely the language. If I could express my point more clearly in the previous post, what I was trying to say:

 

Computer instructions are roughly the same either way on the physical machine for similar C and C++ programs, but C++ offers a different way of organizing your data and methods. The computer, however, runs instructions one by one (for the most part) in programs, and does not concern itself with objects and the like. The computer just runs a sequence of instructions. C, however, is more closely based off of the linear organization and execution path that an actual computer follows. The underlying computer does handle functions and memory addresses and data types. The underlying computer does not have class/object manipulation instructions or private/public this and that.

 

I wasn't trying to make it sound like I thought the CPU architecture was dynamic based on the language used to program it, although you may find this post equally stupid.


C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.


#36 phantom   Moderators   -  Reputation: 7321

Like
2Likes
Like

Posted 18 August 2013 - 01:25 PM

Computer instructions are roughly the same either way on the physical machine for similar C and C++ programs, but C++ offers a different way of organizing your data and methods. The computer, however, runs instructions one by one (for the most part) in programs, and does not concern itself with objects and the like. The computer just runs a sequence of instructions. C, however, is more closely based off of the linear organization and execution path that an actual computer follows. The underlying computer does handle functions and memory addresses and data types. The underlying computer does not have class/object manipulation instructions or private/public this and that.


And the private/public nature of fields and functions has zero impact on the instruction stream the CPU sees, they are just a human abstraction, so what is your point again?

More importantly why is that abstraction 'bad' yet structures, which a CPU has no concept of either, fine?

Also CPUs don't "handle functions"; they have jump instructions but the whole 'function call' concept is, again, a human abstraction. A CPU has no more idea about a calling convention or a flow than a hamster does.

It sees a stream of instructions; coming from C or C++ makes zero difference in the grand scheme of things.

Edited by phantom, 18 August 2013 - 01:26 PM.


#37 frob   Moderators   -  Reputation: 21475

Like
3Likes
Like

Posted 18 August 2013 - 03:45 PM

I was hoping the gentle reminder about it becoming a language war would be enough to push it back toward a topic. As we all know, language wars are not constructive. Closing.
Check out my personal indie blog at bryanwagstaff.com.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS