Quote:
|
Originally Posted by CHADS ... 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.
13 Days in Hell Champion!
3D Championship Golf Champion!
