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.

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.

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.

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.

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)

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.

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.