Choice with language Help!

[Pyrotex]

... i just cant see how massive games come about from c or c++?

Chads,

If you really want to program a game worth playing and really learn a programming language, may I offer some advice from 35 years of programming experience?

Building one large "program" that plays a game is going to be self-defeating. One of the hardest problems that ANY programmer must solve (to stay a successful programmer!) is how to "think" like a programmer. Learning a language syntax is not enough. Analogy: you want to be an essay writer; you have to know a language (English); then you have to know how to build a good sentence; the variations on a good sentence; how to select words and phrasing that will appeal to your audience (the "interface"); how to build a coherent paragraph; how to string together paragraphs to go from a starting point to an ending point; and how to create a specific approach to a topic.

 

Ironically, to be a good essay writer, you must work backwards, starting at the last item I listed, and ending with the syntax of the selected language!!

 

Interactive programs (games and such) typically have many levels of functionality. There will be a library of modules that do "atomic" functions with your interface: accept user input and stick into queue; pop next user input off queue, extract parameters; call interface function. You should not embed these routines in your main game code, but code them separately and call each as needed (subroutine calls or object-actions).

 

At the next higher level, you will have functions that perform "larger" pieces of action: move gun left; move gun right; fire gun; detect bullet impact; kill monster; move monster forward; make monster attack; score hit points; drain user health; draw explosion; etc. Again, THESE should be coded as stand-alone pieces that accept all the input parameters they need to do their stuff, such as monster_ID, other_object_ID, action_ID, target_location, etc. And to a great extent, they will be coded via calls to atomic functions.

 

At the top level, you have your game itself. Now, you are NOT programming in atomic level functions, or even in C(++) itself--you are programming in calls to your middle level functions. for example:

 

On_User_Fire(Weapon_ID, Monster_ID, Weapon_Aim_Array, Fire_State_Out)

{

WepnState = Get_Weapon_State(Weapon_ID)

If WepnState = 'empty' or 'recharging'

Then Fire_State_Out = "Fail_Fire"; exit

Else

MonLocn = Get_Monster_Locn(Monster_ID)

Hit_State = Get_Aim_Match(Weapon_Aim_Array, MonLocn)

If Hit_State = 'miss' or 'blocked'

Then Fire_State_Out = "Fail_Aim"; exit

Else...

 

See what I mean? At the actual game level, you should not be manipulating C++ arrays or adding interface pixel distances or all that atomic stuff. You should be manifesting the actual play logic of the game itself in terms that are understandable as primitive actions and results within the rules of the game.

 

So, you build the game backwards. Decide what kind of game you want. Decide the rules of that game. Decide what components you want in the game (monsters, guns, ships, trees, etc). Decide what relationship rules exist between the components (greech has color, greech climbs trees, greech eats rocks, greech disappears into holes, user collects blue greeches, user kills red greeches, etc)

 

Then you design the interface and what the objects look like and how they need to be manipulated.

 

Then you design the atomic functions you need to manipulate the objects within your interface.

 

Then you code the atomic functions.

Then you code the middle level functions using atomic functions.

Then you code the GAME using middle level (and some atomic) functions.

 

NOW... this may be much easier to do in C++ then in C, because C++ already enforces the kind of discipline you need to accomplish all this. In C++, you already have "objects" which you flesh out as Greech_Objects, Tree_Objects, Hole_Objects, User_Object, etc, each with their own specific attributes and specific actions/relationships.

 

Good luck.

[Pyrotex]

...that my friends at Pixar and Disney...

Buffy!!!!!! :eek:

You have friends at Pixar??????

 

Could you introduce me to Steve Jobs, pleeeeeeezzzz????

 

:eek: :) :) :) :) :) :) :)

[CHADS]

Wow

Thats absolutley great advise i can now understand the basic structure of how to go ahead with game creation , Thank you, i think this puzzlement has been resolved at a crucial point in my learning and will certainly bolster my enthusiasm. Would i be right in assuming that the game engines call all created programs and files to the game floor when required?.... And finally on a basic note ,when i run a compiled program on my c compiler the screen flicks off sometimes after its run and i have been using..... scanf("%d",&a);....

at the end of my programms to hold the screen so i can see the results , otherwise it just flips through and exits ... what could that be , what could i use instead of the input function scanf().?

 

Thanks again for the advice guys excellent!!!!!! :eek:

[Pyrotex]

Wow... in assuming that the game engines call all created programs and files to the game floor when required?.... And...what could i use instead of the input function scanf()?...excellent!!!!!! :eek:

Chads,

you are very welcome indeed!

 

I do not speak here from experience but from intuition & logic: "Game Engines" are basically the collection of atomic functions and databases required to instantiate a specific user interface on the screen. That interface incorporates all the "laws of physics" that the designer wants the objects within the game to obey.

 

Assuming you have a Game Engine -- YOU must define the appearance of all the game objects, and YOU must define the relationships that you want to exist between and among the objects (typically these will be the RULES of your game.).

 

Different Game Engines incorporate different "laws of physics". The laws for PacMan are totally different from the laws of Doom.

 

I'm sorry, I cannot help you with your question about scanf(). Perhaps someone else can help????

[IDMclean]

Here's some online resources:

Gamasutra

Amit's Game Programming Information

GameDev.net

Games ++

 

I would suggest that you start with stuff you know and work your way up, don't rush it. If you are going to try for something like a fully 3d FPS, I would suggest sitting down and writing out what it is that you expect of your game and then go through and psuedo code it out. The aforementioned Book by McShaffery is really good for the process of game planning.

[CHADS]

Some nice sites there kickass .. cheers .. i especially liked the a* Algorithm and nodes feature ,,, i suddenly realised why i was so good at games like command and conquer , predictability with forces attacking the same node every time ..... Maybe they should assign the nodes to armour weakness instead of attacking the same piece of wall or sand bag each time instead ofthe nearest base sand bag location.

 

Great stuff ive learned alot latley this is great stuff..

 

My first program is going to be a multiple choice animal mineral or vegetable type , seems simple enough for a novice , but i would like to add some music and graphics to each answer , of course the data base is going to be really basic like the animal life refined to just garden animals or something ,,,, but its as a start ,,, might have to ask for help with the music and graphics allocation procedure if any body has time or can tolorate teaching novicy types ..:cup:

[alexander]

You have friends at Pixar??????

Its a totally different game at Pixar though, its no longer C or DirectX, maybe some C, but not mostly... Mostly probably Python or Python-like scripting language for their crazy 3d animation software and their thousands of unix boxes, so you will probably deal more with OpenGL, which, i think is a bit better then DirectX cuz it is speciffic to video and not all around video/audio tool like DirectX...

 

But many beautiful languages out there, depending on where you wanna go, i would suggest starting with a scripting language, NOT PERL, G-dawg forbid we will get another programmer that has no style and likes to obfuscate code for fun....

 

PHP Python Ruby C++ Delphi Pascal JavaScript Perl Java DarkBasic VisualBasic

 

bout that order if i had to choose, those would be my preferences frol left to right :)

[CHADS]

2 years later

matrix tranformations in fps ..... open gl ..... with open gl you can basically create any situation in the universe ... intense creativity ... c++ rules cheers!:naughty:

[CraigD]

2 years later

matrix tranformations in fps ..... open gl ..... with open gl you can basically create any situation in the universe ... intense creativity ... c++ rules cheers!:naughty:

You've written your own first person perspective shooter in c++ using the OpenGL API?

 

If so, don’t be stingy, share with you hypography friends! :hihi: Building a fps engine from the ground up is something most programmers think about, never actually do, and are always eager to experience vicariously.

[CHADS]

Afraid im not that good .. i have tons to learn still and admiring the possibilities.

[alexander]

i built a racing engine on top of an fps engine, back in HS.... well i was developing and testing it...if that counts for anything...