0r0d

Hello,

I want to be a game programmer. I want to work in game company as Ubisoft, Naughty Dog..

It's my dream and I do for it everything.

It's about one year, when I start programming. I understood concept OOP, and C++ too. I've created 8 2D Games as Super Mario, Snake, Pong ...

 

But now, I don't know what I do next. I can go on 3D programming? If yes, which library a should use? Or I can go on Engines? Or I can stayed in 2D Game?

Moving on to 3D sounds like a good idea at this stage.  I'd suggest you get a good book on OpenGL or DirectX and work through that.  Then make a game using what you've learned and writing your own simple engine.

Then depending on which areas of game development interest you (graphics, physics, gameplay, engine architecture, tools, etc) you can continue to build on and improve your engine and go on to another more ambitious project.  Do a couple of those and you might be good enough to be considered for a junior position at a game studio... assuming they hire junior people in the first place.  Studios like Naughty Dog might only hire mid to senior-level programmers.

Other things you can do while working on that 3D game that will give you useful experience:

-integrate a 3rd-party physics engine like Bullet into your game

-write your own tool for something like object/level/material editing.  You can use something like wxWidgets or Win32 or whatever you like

-multi-thread part of your code

-implement some post-effects using shaders (glow, DoF, motion blur, toon shader,.... whatever)

-learn to use a modelling program

-write an exporter for that modelling program

-integrate a scripting language into your engine and write some game code with it (triggers, UI flow, AI,... whatever)

-write a particle system

-write a UI system

-write a font rendering system

Anyway... there's much more you can think of, but those are ideas that you can integrate into a fairly simple 3D game and gain experience in lots of stuff that will be helpful when you're applying for a job at a big game studio.

Other than that, the things that will help you get a good job are solid knowledge of C++ and 3D math.

I would only say that if your ultimate goal is to become a professional developer, you will need to learn C++.  If that's the case, then rather than starting with C# and then learning C++, I'd recommend starting with C++ and later move to C# if you want.

The reason here is that C++ will teach you the low(er) level stuff that will give you a better understanding of what the computer is actually doing, which is important for things like games where performance if often an issue.  Learning C++ and then C# is like building a solid foundation and then your house on top of that.  Going right to C# is like building the house on the ground w/o a foundation.  Sure it might be just fine, until a storm shows up and your house gets washed away.  I have also heard stories of people who learn C# first and then have trouble getting their heads around C++.  Not just that, but learning C++ first means you'll accumulate a longer amount of time on that language, which is important if at some point you need to use it professionally.  There is definitely a lot to master in C++, and stuff like that only becomes second nature if you use it for many years.

If, however, you dont really think that you'll use C++ professionally at some point, then C# might be the way to go.  I'd consider what platforms you want to develop for and what tools you'll be using.  C++ has the advantage here that it will allow you to put your game almost everywhere without relying on third-party platforms or toolchains.

Hmm that sucks theres so much it can do you would think it could do that somehow.

 

I have 37 header files I want to include that are in a versioned directory ie library-0.4.1/

I could rename the folder to just library but I was wanting to keep multiple versions to change them easily.

When 0.4.2 comes out I could simply change dir defined path to library-0.4.2 and if I dont like it or it doesnt pass the tests I could revert easily

Add a path to that library in the "Additional Include Directories" (for Visual Studio), or whatever is the same thing in your IDE.  Then you can include files from that directory like this:

#include <subfolder/file.h>  // where "subfolder" is a folder inside whatever path you told the compiler about

This will give you exactly what you want.

this is my new question

 

I want to tranform the tangent normals of the texture to world space

I have three vectors in world space that represent a face of the object i am drawing

I will need a 3x3 matrix to rotate this tangent normals

the last vector of the matrix will be the normal of the face: normalize(cross(v1-v0,v2-v0))

the first vector of the matrix will be: cross(last vector,middle vector)

the middle vector of the matrix will be what?

The tangent-space matrix is not guaranteed to be orthonormal, so you cant get the basis vectors like this by crossing them to get the last one.  Also, they will transform the tangent-space normals into object-space, not world-space.  

I think the problem is that you are failing to realize that there are infinitely many possible TBN matrices for any given face. 

This not correct.  For one thing the TBN matrix exists for each vertex, not for each face.  Also, the Tangent is defined to point in the direction of change of the U coordinate, and the binormal (or bitangent as some here are calling it) points in the direction of the V coordinate.

when blender makes the normals in tangent space it has to use 3 direction vectors, one is the normal of a face, the other is vector "b" and the other is the cross between this two vectors.

What is vector "b"?

"b" refers to the binormal.

In tangent space calculations you have the Normal, Tangent, and Binormal.  These 3 normalized vectors represent the basis vectors of the tangent space, which BTW is not necessarily an orthogonal space.  These vectors are in object space, and the 3x3 matrix generated from them represents the transformation from object space to "tangent" space.

The normal is the vector pointing directly away from the surface.  This is calculated from the vertex positions and has nothing to do with the UV coordinates.  The tangent vector points along the direction of change of the U coordinates.  The binormal points along the direction of change of the V coordinates.

if the UV coordinates are orthogonal, then you can calculate the binormal like this:

B = T x N

Sometimes in games, inside the shaders, the binormals are calculated this way.  But, again, this only works if the U and V coordinates are orthogonal, which they're not guaranteed to be.  It's very easy for artists to make the texture coordinates flow however they want.  The general solution is to pass in all three, N, T, and B in the vertex to the vertex shader.

I basically have the same knowledge on all of the above and i wanted to know what should i learn and keep going with?

 

my goal is to create games and someday build (maybe) an engine for myself.

 

i think i want to use OpenGL for that and i figured that if all of these languages have opengl library (now all of them the same i know)

i should go with one of them.

 

what is the best choice to go with?

C++ is pretty hard to learn but i can handle it. (pretty fast too from what i understand)

C# is really easy and i can easily learn that language but it's not as quick as C++ and i dont know if the openTK (or what's it called) is the same as opengl openal.. (same function's)

Java same as C# but i dont really like that language i dont know way lol

 

 

thanks!

I'll disagree that C++ is "pretty hard" to learn.  I started programming with C++ and didnt think it was especially hard.  Also, C++ forces you to deal with things that are essential to how a program (and hence an engine) works like memory management, and doesnt hide it away from you.  But, once you know what you're doing with memory management, using smart pointers is extremely easy and will eliminate the headaches that a lot of people complain about with C++.

So, your goal is to write your own engine, and possibly work in the broader game development industry?  If this is correct and you want to learn the ins and outs of a game engine and maybe work for a professional game studio, then my suggestion is C++.  Considering that you already have the same level of C++ as you do with the other options, I dont see much of a downside with this.  C++ has more code/libs/support out there for you to leverage.  C++ is used in most professional dev studios.  C++ is used to write most professional game engines, and to program most platforms and consoles.

You can also start with C# in Unity3d. Quick and dirty way to make games.

 

I wouldn't say that Unity is "quick and dirty".  Quick yes but Unity is quite a powerful engine and tool kit.  Other than that I would agree.  I believe it would be easier to wrap your head around the game development process by starting with something that uses a language you are friendly with (C#) and is capable of making high quality full featured games.  Also an added benefit is that Unity is widely used, you will have a very large community and knowledge base to reach out to when you have problems.  Another benefit is that many small development studios are using Unity and you will be learning something that will actually give you a bit of a leg up in the market.

While Unity is a great tool, I would not recommend it to someone who is a total beginner in game development.  The main drawback is that it's too much, too soon.  If you jump right into Unity there's a lot of low-level stuff you wont understand, and it'll be too easy to become overly ambitious.  I think you need to start small, learning the basics and getting a solid foundation on the low-level and basic elements of what makes up a game.  

An analogy would be if you wanted to be an architect, but you have no experience.  Someone directs you to software that allows you to design skyscrapers, but you have no idea what the structural properties of a brick are, how steel beams are welded together, or how wind loads affect a large building.  Sure, you can design a beautiful building... but it will probably collapse half-way during construction.

Start small, start with the basics.  You get to where you're going with small steps, not by shooting yourself out of a cannon.

Start with what you know, so C# sounds like the best option.  Then, start small.  Pick a simple game idea, break it down into manageable chunks, and go from there.  If the game is simple enough, you really dont need an engine like those you mentioned.  Then, finish what you start.  This is the most important part, and why starting with a simple game idea is so important.

XNA, which I think was one of the main reasons C# gained traction

 

I hope you meant to add "in the game development community". Because if you are suggesting that C# is popular in general development BECAUSE of XNA then please, share the good stuff you're smoking.

It helps when you read the ENTIRE post.

And I should have clarified, I meant that MS isnt supporting XNA, which I think was one of the main reasons C# gained traction.  It might very well continue to be used in Win8 applications, but since this is a game development forum I'm thinking mostly of... game development.  As far as game development, c++ will continue to be the standard.

 

Now that MS is no longer supporting it, actually yes, it probably will disappear.

 

actually MS is actively supporting and upgrading C#. A recent study shows how C# still is the most used language to develop Win8 applications.

I have no idea if that's true or not, but it's irrelevant.  Just because something is widely used now doesnt mean it'll be widely used in the future.

And I should have clarified, I meant that MS isnt supporting XNA, which I think was one of the main reasons C# gained traction.  It might very well continue to be used in Win8 applications, but since this is a game development forum I'm thinking mostly of... game development.  As far as game development, c++ will continue to be the standard.

ust saying, C# is not a "pet" language of Microsoft.  From what I understand the language definition is under control by the ECMA. 

C# was created by Microsoft and they pushed it along with XNA.  So yes, it was their pet language... at least for the XNA group.   If it wasnt for that I doubt many people would be using it today.

Long story short I've been using XNA for 6 years now just playing around with code, not actually producing anything.  It helped me get to where I am today; a professional coder using C#.  Well, apparently XNA is dead.  After 2 hours of despair I decided that I'd try going to C++ and Direct X (I used them at school so I have some idea of what I'm doing).  From what I've ready I can't do that with the new version of VSE; I have to pay to upgrade which I refuse to do unless I started actually making money from my hobby.

 

So where to now?  I've been looking at Unity, which apparently uses C#, however I've never been able to get into it, like at all.  I install it, see what looks like a map editor, and decide it's not for me because I'm not looking for a game engine I'm looking for a game library.  I'm not really sure if there is anything like XNA out there.  

 

I can say I'm pretty pissed off at Microsoft; all this talk about supporting Indie development then they just yank out the carpet for no reason.  I honestly don't know why they did it, especially with them trying to get people developing cross system apps for Windows 8 and especially with them having C# as a primary app language.  It just made sense to me that they would expand on XNA to work with all versions of Win 8, straight PC, 360, and the new 720, but instead they slammed the door shut.  Don't know where to go from here.

 

Any thoughts?

My thoughts are that whenever you buy into a companies proprietary tech then you're at their mercy.  Now I know that XNA is not just a Microsoft proprietary tech, since you can still use it through other means, but the point is that it's Microsoft's deal.  You somehow bought into XNA and felt entitled to it, and are now upset because MS did what MS is entitled to do... which is to stop supporting it.  Sorry, you need to deal with it.

If you want to stop being at the mercy of companies and their pet languages like XNA and C#, or Objective-C for Apple, then go with C++.  Not sure why you think that you cant use C++ and DirectX with Visual Studio Express, but you're wrong.

Personally I really dislike what MS did with XNA/C# and Xbox 360 indie development... which is to say that they mandated that you have to use it and excluded C++/native development.  I have games that I'd have loved to port to the 360, but basically MS said that they didnt want me to.  The wanted only amateurs developing for their indie games section, and that's what they got.  Now they wonder why it was a miserable failure??  All my code, engine, tools, and games are in C++.  I was not about to rewrite everything to C# just because MS and their XNA group decided to push it.  If it was really so great why is their SDK for professional development in C++?  Answer: because if they tried that game developers would rebel and jump ship like it was on fire.  I'm glad MS is getting rid of XNA.

i, I'm learning how to create threads on SDL and at Qt on the same time and my question is connected with it. Is there are real application for multi-threading in games, especially in nowadays games, are multiple threads used often in game development? And can you give me some examples for using this technique in games creation? Thank you

I just want to start off by saying that multi-threading is a complex subject, and you can be in for a world of hurt if you try to use it in a game without knowing what you're doing.

That said, yes there are a lot of uses in games and any serious game engine will use it.  To what extend it gets used is more a question of whether the engine was built with threading in mind or added in afterwards.  Adding multi-threading as an afterthought can be messy and buggy and hard to do, and it will only give you limited benefits.

Things that can be, and often are, threaded in games:

• asset loading
• rendering
• game logic and scripting
• physics
• networking
• UI
• Loading/Wait screens

So, basically, everything in a game can be threaded.  It can be through hard-coded threads (rendering thread, logic/update thread, loading thread, UI thread) or through a job manager where you break up tasks into separate blocks that can be handed off to a system.  This system then has "worker" threads which handle the jobs in their own time.  The responsibility of the game in such a system is really just to create jobs that it can feed to the job manager.

Most game engines use hard-coded threads, because they're relatively easy to code and can work readily with existing code that wasnt originally built for threading.  This however has it's limits because it doesnt scale well as more cores, and hence worker threads, become available.  It's also normal that this type of system will not be able to fully use all the available CPU time due to some threads having to wait for others.

Few engines use the job manager/scheduler type systems, but they are in theory superior, if harder to architect.  Such a system can be made to more fully utilize the available CPU resources, but this depends on how well the jobs can be made independent of each other.  It also scales well with more cores/threads, since the distribution of what's threaded isnt hard-coded.

I know most people say that C++ is the best, but I don't feel comfortable getting that in-depth into it, and have actually made the mistake of trying to learn it first, and it burned me out. I am making this post after trying several times to get into C++ and failed miserably.

Can you tell us how you went about trying to learn C++ and why you failed?

Personally I started programming with C++ and didnt think it was especially hard.  I took a single semester course at university (Intro to C++) and then went out and got a book (C++ How To Program) and just worked through that.  Before starting C++ I'd only had some experience with Fortran, which is to say not much that was applicable.  =)

I'm not saying that C++ is right for you, it's not for everyone.  But, you obviously wanted to learn it at some point, and there must be a reason for that.  We can help you with better advice if we know why it didnt work out.